Re[4]: Importing a variable from a DLL

[Paul Sokolovsky <paul-ml@is.lg.ua>]

Hello Mumit,

Mumit Khan <khan@xraylith.wisc.EDU> wrote:

MK> Paul Sokolovsky <paul-ml@is.lg.ua> writes:
>>
>>     But at least there might be achieved proper diagnostics of such
>> issues, if dlltool would correctly mark data symbols in def, that
>> implib would only contain __imp_<symbol> and not <symbol>, and we'd
>> get link error when linking with object which doesn't have
>> __declspec(dllimport) on that symbol, and not runtime segfaults,
>> as we have now.

MK> Sure, but it doesn't solve James' problem. If James could create the
MK> import libraries with all the data marked DATA, it would imply he
MK> already *knows* which these data items are!

    I am still feeling misunderstood. Let me go with it once again,
with examples.

    So, dlltool has ability to create implib from def - it's all nice
with it, it supports DATA, sure.

    But it has ability to dump all defined symbols into def file -
about this operation I am talking. So, suppose we have library of

---a.h
extern int data;
int code();
----
---a.c

int data;

int code()
{
  return 0;
}
----

    We compile a:
gcc -c a.c

    And now creating def of it:

dlltool a.o --export-all --output-def a.def

    What we now get is:
---a.def
; G:\GCC-2.95\BIN\DLLTOOL.EXE --export-all --output-def a.def a.o
EXPORTS
        data @ 1 ;
        code @ 2 ;
----
and it's bad! Suppose we'd get instead
---a.def
; G:\GCC-2.95\BIN\DLLTOOL.EXE --export-all --output-def a.def a.o
EXPORTS
        data @ 1 DATA;
        code @ 2 ;
----

    We create implib from that:

dlltool --def a.def --ouput-lib liba.a

And then compile client application:
---client.c
#include "a.h"

int main()
{
  data=1;
}
----
When we link it

gcc client.o -la

What we get? Of course, "client.c: undefined reference to `data'"!
We now grepping, finding out that 'a.h' declares that 'data' and tag
it __declspec(dllimport). Repeat while needed.

   So, it doesn't solve problem we're talking about automagically, but
it defines clean procedure, which, while being incremental, will
converge fast. Much faster than having to catch segfaults for hours
and then having users complain of occasional ones for months, as we
have now.



MK> Regards,
MK> Mumit





Best regards,
 Paul                            mailto:paul-ml@is.lg.ua



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com