Mail Archives: cygwin/2002/02/11/11:24:43
Have I just been lucky, or is building and linking of
DLLs now supported by GCC directly?
It looks like Nousiainen [am DOT nousiainen AT pp DOT inet DOT fi] has
had the same experience, although Chuck Wilson's reply
(and the FAQs, etc.) seem to indicate that you need to
use libtool, rebase, and/or other tools. I seem to be
getting along fine like this, though:
gcc -o bin/my.dll -shared obj/my.o
gcc -o bin/my.exe obj/main.o bin/my.dll
I verified that this uses the library dynamically--the
DLL is required at runtime.
In fact, this is much nicer since I don't have to worry
about those pesky .def files. And for some libraries, I
avoid warnings that way. For example, when I link with
libpython2.2.dll.a, I get warnings such as:
Warning: resolving __Py_NoneStruct by linking to \
__imp___Py_NoneStruct (auto-import)
Warning: resolving _PyInt_Type by linking to \
__imp__PyInt_Type (auto-import)
I don't get these when linking to the dll directly. It
sounds like some entries are missing in whatever .def
file is used to build that import library, but that is
just a guess.
I don't mind using tools where needed (e.g., if I want
to prevent some non-static symbols from being exported),
but I'd rather not use extra tools if I don't need them,
especially since some of the tools don't seem to be in
the normal Cygwin distributions. So for now my makefiles
just use GCC.
This has been working so far for me, but as I said it
could just be luck. Do I need to bite the bullet and
figure out how to make a DLL another way?
-Jerry
-O Gerald S. Williams, 22Y-103GA : mailto:gsw AT agere DOT com O-
-O AGERE SYSTEMS, 555 UNION BLVD : office:610-712-8661 O-
-O ALLENTOWN, PA, USA 18109-3286 : mobile:908-672-7592 O-
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -