From: Charles Wilson <cygwin@cwilson.fastmail.fm>
To: cygwin@cygwin.com
Subject: Re: Visibility of compiler symbols between executables and DLLs
Date: Tue, 27 Sep 2005 00:43:00 -0000 [thread overview]
Message-ID: <43389176.3050006@cwilson.fastmail.fm> (raw)
In-Reply-To: <4337C029.5786F209@dessent.net>
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/
next prev parent reply other threads:[~2005-09-27 0:25 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-26 9:32 Nick Glencross
2005-09-26 9:42 ` Max Bowsher
2005-09-26 10:22 ` Brian Dessent
2005-09-26 13:40 ` Christopher Faylor
2005-09-27 0:43 ` Charles Wilson [this message]
2005-09-26 21:41 ` Nick Glencross
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=43389176.3050006@cwilson.fastmail.fm \
--to=cygwin@cwilson.fastmail.fm \
--cc=cygwin@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).