Re: cygwin ld import library issue fix (removing unused "_nm_" symbols)

[Charles Wilson <cwilson at ece dot gatech dot edu>]

Ralf Habacker wrote:


>>b) build an app that uses that dll, and which accesses both a function
>>export and a data export from the dll.
>>
> 
> ------------------------------------------------
> $ cat client.cc
> ------------------------------------------------
> #include <stdio.h>
> #include "dll.h"
> 
> main()
> {
>         funcs();
>         vars();
> }


Except that I'd access 'v0000' *directly* from client.cc; you're not 
*really* accessing the variable yourself; you're calling a function in 
the DLL which accesses the variable.

However....

> $ make client.exe
> g++     -c -o client.o client.cc
> g++ -o client.exe client.o -v -Wl,--enable-auto-import  -L. -ldll
> Warning: resolving _var0000 by linking to __imp__var0000 (auto-import)


^^^^^^^^^^^^^
shows that the linker IS able to resolve the reference (although why it 
even tried to do so is another questions...)


>>c) rebuild the dll using your modified ld.
> 
>>d) does the app still work, without relinking?
>>
> 
> $ ./client
> printfunc0000 called
> v0000=0000


Nice...

> e) additional relink app with unmodified ld to see if old ld can handle this
> import library
> 
> $ cp /bin/ld.exe.2001_10_03 /bin/ld.exe
> 
> $ rm client.exe
> 
> $ make client.exe
> g++     -c -o client.o client.cc
> g++ -o client.exe client.o -v -Wl,--enable-auto-import  -L. -ldll
> Warning: resolving _var0000 by linking to __imp__var0000 (auto-import)


^^^^^^^^^^
Again, it seems to resolve the v0000 import.

 
> $ ./client.exe
> printfunc0000 called
> v0000=0000


But client doesn't really access the variable directly.


> So this seems to work.


Cool.

--Chuck