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
Message-ID: <36C46C50.823DE2F4@ibm.net>
Date: Fri, 12 Feb 1999 13:00:48 -0500
From: John Fortin <fortinj AT ibm DOT net>
X-Mailer: Mozilla 4.05 [en] (WinNT; U)
MIME-Version: 1.0
To: Mumit Khan <khan AT xraylith DOT wisc DOT edu>
CC: "'cygwin AT sourceware DOT cygnus DOT com'" <cygwin AT sourceware DOT cygnus DOT com>
Subject: Re: ld, dlls, and windows libraries
References: <Pine DOT SUN DOT 3 DOT 93 DOT 990212113933 DOT 18731B-100000 AT modi DOT xraylith DOT wisc DOT edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Oops, your are definitely correct.  I should have checked the mail archives
first.
Sorry about that.  And yes, I was following in instructions in the users
guide.

Thanks for the info!!

John Fortin,
fortinj AT ibm DOT net

Mumit Khan wrote:

> 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