Mail Archives: cygwin/2002/02/11/13:51:42
Gerald S. Williams wrote:
> Have I just been lucky, or is building and linking of
> DLLs now supported by GCC directly?
Yes.
>
> 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.
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 package...you might want to look
into it.
--Chuck
--
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 -