This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: "Best" way to build a DLL?

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 [] 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: 
resolving...." messages.

> 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 might want to look 
into it.


Unsubscribe info:
Bug reporting:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]