Visibility of compiler symbols between executables and DLLs

Charles Wilson cygwin@cwilson.fastmail.fm
Tue Sep 27 00:43:00 GMT 2005


Brian Dessent wrote:
> Max Bowsher wrote:
> 
> 
>>I'm fairly sure that it is impossible. Actually, it might be possible if
>>there was a flag to convice GCC to add an import table to the built .exe,
>>but last time I investigated that, there was no such flag. But even if that
>>was possible, the .dll would need to explicitly link against the .exe that
>>was to load it, for this method to work.
> 
> 
> This does actually work, AFAIK.  You need to use __declspec(dllexport)
> on the symbols in the .exe, and produce an import library
> (-Wl,--out-implib) when building the .exe which is then used in linking
> the .dll.  It hardcodes the name of the .exe in the .dll though, so it
> also means that you cannot use the .dll as a general purpose library.

Correct.

You can also link the executable using a .def file listing the exports 
you want -- this way you don't need to use __declspec() in your app or 
library code (auto-import will work as well).  However, even in this 
case you also need to generate an import library, as Brian describes above:

gcc -o foo.exe foo.def foo.o -lsomelib -Wl,--out-implib=foo.dll.a

And, as Max pointed out, when you link the DLL you have to give it a 
reference to the .exe's implib:

gcc -shared -o bar.dll -Wl,--out-implib=bar.dll.a bar.o foo.dll.a 
-lotherlibs

Which brings up TWO problems:

(1) foo.exe can't depend on bar.dll (because then each would need the 
other's implib in order to link; chicken/egg problem)

(2) As Brian points out, the 'foo.exe' name will be hardcoded into 
bar.dll's internal import list, so bar can't be used with any other 
executable.

> Refactoring out to a common .dll is much cleaner.  You can also design
> the API so that you pass pointers to the symbols as arguments to
> functions in the .dll.

Yep.

--
Chuck


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/



More information about the Cygwin mailing list