Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-owner AT sources DOT redhat DOT com
Message-ID: <39E3F410.FAAD8E20@ece.gatech.edu>
Date: Wed, 11 Oct 2000 01:01:04 -0400
From: "Charles S. Wilson" <cwilson AT ece DOT gatech DOT edu>
MIME-Version: 1.0
To: Ross Smith <ross DOT s AT ihug DOT co DOT nz>
CC: cygwin AT sourceware DOT cygnus DOT com
Subject: Re: AW: Linking Dynamic Libraries
References: <004501c031f0$10478ad0$0d33028b AT zapperlot DOT materna DOT de> <39E1CC08 DOT F475851F AT ece DOT gatech DOT edu> <39E2468B DOT BFDD3AB7 AT ihug DOT co DOT nz> <39E259A7 DOT CBAD325F AT ece DOT gatech DOT edu> <39E26078 DOT 3F382C71 AT ihug DOT co DOT nz>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ross Smith wrote:
> 
> Charles Wilson wrote:
> >
> > You still need to worry about things like __declspec(dllexport) and
> > __declspec(dllimport).
> 
> What's the point of --export-all-symbols then? I was under the
> impression that it was intended to duplicate the Unix convention, where
> all external symbols are automatically exported from a .so. (Actually,
> the help refers to "global" symbols, not "external", but I assumed that
> just meant that whoever wrote the help didn't know C++.)

--export-all-symbols works as expected with C code. Based on your tests
and my duplication of your tests, --export-all-symbols seems to NOT work
with C++ code, but neither of us has done enough testing to make a
definitive statement. 

We're all hurting because the acknowledged guru of cygwin-gcc, Mumit
Khan, no longer appears to have time for the project (but many thanks
are due for his tremendous contributions in the past)

<snip>
 
> > NOTE 2: I used the extension '.dll.a' for the import library; cygwin's
> > linker will search for 'libfoo.dll.a' in preference to 'libfoo.a';
> > libfoo.a is assumed to be a static library (although the linker will use
> > libfoo.a if .dll.a is not found)
> 
> Could you amplify please? I don't understand what you mean by this.
> libfoo[.dll].a is a static link library. If I put -lfoo on the link
> command, it looks for libfoo.a in accordance with the normal linking
> procedure (even if a DLL implib has a different format to a normal
> static library (I have no idea whether it does), the linker has no way
> to know it's dealing with a DLL implib until after it's found and read
> the file). If I don't put -lfoo on the link command, it has no reason to
> look for foo dot anything. That's certainly the way all the system DLLs
> work: if I want to use, say, wsock32.dll, I link with -lwsock32.

On pei386, which includes mingw and cygwin, ld can link many different
objects to create an executable or dll: static libraries, other dynamic
libraries, object files, and import libraries (which are really just a
special kind of static library).

So, you can explicitly list the following files on the ld command line:
  foo.o  libfoo.a   libfoo.dll   libfoo.dll.a

Now, just like unix versions of the same tools, the linker provides some
shortcuts for libraries.  In "normal" unix, specifying "-lfoo" on the
commandline tells the linker to decorate the name "foo" with a
prefix="lib" and a suffix=".a" (if using the -Bstatic ld option) or
suffix=".so" (if using the -Bdynamic ld option).  Actually it's more
complex than that, but you get the idea.

On pei386, -Bstatic still means "only decorate with lib<>.a".  However,
-Bdynamic uses a complicated search order:

lib<>.dll.a  (assumed to be an import lib) 
<>.dll.a     (ditto)
lib<>.a      (could be import lib, could be static.  
              it's here in the middle for historical,
              back-compatibility reasons)
**note**
lib<>.dll    (link directly to a dll)
<>.dll       (ditto)

'gcc -static' will call ld with the -Bstatic option, while "normal" gcc
calls ld with the -Bdynamic option.  The above search order assumes that
folks are following this naming convention:

  libfoo.dll.a is an import lib
  foo.dll.a is also an import lib (but not ordinarily used)
  libfoo.a is usually a static lib, but older packages
     might use this name for import libs
  libfoo.dll is the usual name for a dll
  foo.dll is an alternative name for a dll
<<tentative: see **note**>>
  cygfoo.dll is the preferred name for dll's on cygwin
  pwfoo.dll is the preferred name for dll's on pw
  etc etc
<</tentative>>

We use this search order, because ordinarily we want to link
dynamically, using an import lib if available.  If that fails, then try
to link to "lib<>.a" -- it *might* be an import lib.  If *that* fails,
then try to link directly to the dll.  The "link directly to the dll"
capability is really there ONLY to enable us to link to system libraries
(dll's) for which we have no import lib nor static lib -- so it goes
last.  Import libs *must* be preferred over dll's because some libraries
*must* be linked using an import lib, NOT the dll. 
cygwin1.dll/libcygwin.a is one example -- the import lib libcygwin.a
contains static code in addition to the imports for the dll. 
Unfortunately, names matching "lib<>.a" *must* be preferred to dll's --
or a whole slew of things break.  Thus, the order above.

As for your wsock32.dll example, you're actually linking to
/usr/lib/libwsock32.a, an import lib provided with cygwin (which
"fronts" for the real WINNT\system\wsock32.dll).

**note** a recent patch, not yet accepted (see
http://sources.redhat.com/ml/binutils/2000-10/msg00040.html) puts an
additional template here. <prefix><>.dll, where <prefix> is specified on
the command line with --dll-search-prefix=<prefix>.  For cygwin, the gcc
spec file could be changed to use --dll-search-prefix=cyg.  This was an
attempt to help mitigate dll naming conflicts between the various
co-existing win32 platforms like cygwin, mingw, pw, uwin, etc...  See
the above reference binutils message for links to the relevant
discussion threads.

Hope that explains it.

--Chuck

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com