This is the mail archive of the cygwin@sourceware.cygnus.com
mailing list for the Cygwin project. See the Cygwin
home page for more information.
[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index] [Subject Index] [Author Index] [Thread Index]
Re: ld, dlls, and windows libraries
- To: John Fortin <fortinj@ibm.net>
- Subject: Re: ld, dlls, and windows libraries
- From: Mumit Khan <khan@xraylith.wisc.edu>
- Date: Fri, 12 Feb 1999 11:56:49 -0600 (CST)
- cc: "'cygwin@sourceware.cygnus.com'" <cygwin@sourceware.cygnus.com>
- Delivered-To: listarch-cygwin@sourceware.cygnus.com
- Delivered-To: mailing list cygwin@sourceware.cygnus.com
- In-Reply-To: <36C4582C.A302D915@ibm.net>
- Mailing-List: contact cygwin-help@sourceware.cygnus.com; run by ezmlm
- Sender: cygwin-owner@sourceware.cygnus.com
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