Mail Archives: cygwin/2005/09/26/20:25:50
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/
- Raw text -