Delivered-To: listarch-cygwin AT sourceware DOT cygnus DOT com
Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com
X-Authentication-Warning: modi.xraylith.wisc.edu: khan owned process doing -bs
Date: Fri, 12 Feb 1999 11:56:49 -0600 (CST)
From: Mumit Khan <khan AT xraylith DOT wisc DOT edu>
To: John Fortin <fortinj AT ibm DOT net>
cc: "'cygwin AT sourceware DOT cygnus DOT com'" <cygwin AT sourceware DOT cygnus DOT com>
Subject: Re: ld, dlls, and windows libraries
In-Reply-To: <36C4582C.A302D915@ibm.net>
Message-ID: <Pine.SUN.3.93.990212113933.18731B-100000@modi.xraylith.wisc.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Fri, 12 Feb 1999, John Fortin wrote:

>     Is there the equiv. of -mwindows for ld.  The trouble occurs when I
> build a DLL which uses win32 api, I get a bunch of errors for unknown
> symbols.  If I manually add ( by trial and error at this point )
> -lkernel32 -lm and other libraries, I am able to finish the build of the
> DLL.
>     Is there a shortcut, or is there a list which indicates which
> functions are in which libs.  I suppose I could use nm, but that seems
> inefficient.

Yes, use gcc! 

<gratuitous gripe mode> I frequently see folks using ld to build DLLs,
and run into all sorts of problems. Why use ld when gcc does all of
this and more?? Is it because Cygwin User Guide shows the most 
convoluted and error-prone way to build DLLs? Also interesting is the 
aversion to using the search facility in the mailing list where I and 
others have posted info on portably building DLLs many many times. 
<off now, whew!>

Here's a start:

  $ gcc -c foo1.c foo2.c
  $ dllwrap -o mydll.dll -mwindows --export-all foo1.o foo2.o

When DJ's excellent work on ld is released, you'll be able to do:

  $ gcc -shared -o mydll.dll -mwindows --export-all foo1.o foo2.o

The --export-all exports all the non-static symbols as done on most 
Unix systems. If you want to restrict the exports, you have two choices:
  
  - provide a DEF file via ``--def mydef.def'', or
  - use __attribute__((dllexport)) or alternatively __declspec(dllexport) 
    in your sources, 

instead of using --export-all. The option --add-stdcall-alias adds aliases
for STDCALL symbols without the trailing @<n> to be compatible with MSVC.

Regards,
Mumit