public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
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/

  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).