This is the mail archive of the
mailing list for the Cygwin project.
Re: "Best" way to build a DLL?
- From: Charles Wilson <cwilson at ece dot gatech dot edu>
- To: "Gerald S. Williams" <gsw at agere dot com>
- Cc: cygwin at cygwin dot com
- Date: Mon, 11 Feb 2002 13:52:47 -0500
- Subject: Re: "Best" way to build a DLL?
- References: <GBEGLOMMCLDACBPKDIHFMEPFCGAA.email@example.com>
Gerald S. Williams wrote:
> Have I just been lucky, or is building and linking of
> DLLs now supported by GCC directly?
> It looks like Nousiainen [firstname.lastname@example.org] 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.
a) I never said ANYTHING about rebase
b) libtool makes life easy and cross-build compatible. But it is NOT
necessary -- see the OTHER examples in dllhelpers. Currently there are
8 -- only the four newest examples use the autotools. The older examples:
"C" "CXX" "F77" "C_AND_C++"
just use gcc(g++,g77).
> 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.
Wrong. Those "warnings" are really just informational messages. The
python library exports *variables* as well as functions. Your DLL
probably only exports funtions. DATA exports are very very tricky;
there is a lot of magic going on to enable Jason to buld python without
having to use a .def file or __declspec() declarations -- previously,
these were REQUIRED on exported variables.
Thanks the "auto-import" feature of new binutils, this isn't necessary
any more -- but when linking a client app that access those variables,
the "magic" generates those "warning" messages.
It's not a bug, it's a feature.
Also: if your dll doesn't export any variables -- or if your client apps
do not access those variables -- then you won't see these "Warning:
> 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.
Again, I never mentioned rebase. I use only official tools to build DLLs.
> 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?
No, it isn't necessary -- but there are other benefits to
autoconfiscating and libtoolizing your package...you might want to look
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html