Re: "Best" way to build a DLL?

Re: "Best" way to build a DLL?

[Gerald S. Williams]

Have I just been lucky, or is building and linking of
DLLs now supported by GCC directly?

It looks like Nousiainen [am.nousiainen@pp.inet.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@agere.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/

Re: "Best" way to build a DLL?

[Gerald S. Williams]

>   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 poked around a bit and found out that those "Warnings"
were actually indicating that global variables were being
linked by the auto-importer.

When you link to the DLL directly, you get seg faults if
you refer to those variables. (I guess I *was* lucky--I
hadn't seen this since I hadn't executed the code making
those references). I had to change my builds to use the
import library in order to eliminate the seg faults when
referring to those variables.

It looks like you can use just GCC, though. Chuck Wilson's
C example in dllhelpers-0.40.0 bears this out, and shows
how to create an import library at the same time without
the need for a .def file (using -Wl,--out-implib and
-Wl,--export-all-symbols).

I'm not sure why those are reported as warnings. Is there
an easy way to disable them?

-Jerry

-O Gerald S. Williams, 22Y-103GA : mailto:gsw@agere.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/

Re: "Best" way to build a DLL?

[Charles Wilson]

Gerald S. Williams wrote:


> I'm not sure why those are reported as warnings. Is there
> an easy way to disable them?


No, short of recompiling binutils.  I'll look into getting the 
appropriate patches into binutils; it's been six months so it's probably 
time to turn off those "warnings".

--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/

Re: "Best" way to build a DLL?

[Charles Wilson]

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.nousiainen@pp.inet.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/

Re: "Best" way to build a DLL?

[Jason Tishler]

Chuck,

On Mon, Feb 11, 2002 at 01:52:47PM -0500, Charles Wilson wrote:
> 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.

Just to be clear, I'm building Cygwin Python the way that I always have
(at least since my shared extension patch was accepted).  I assume you
meant that I *could* build without __declspec() declarations if I desired.
Since the __declspec's are there for Win32, I might as well use them.

Now PostgreSQL on the other hand...

Jason

--
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/

RE: "Best" way to build a DLL?

[Gerald S. Williams]

Thanks for the nudge. After seeing your mail, I poked around
pyconfig.h and found the USE_DL_IMPORT define.

Anyway, if you're linking to Cygwin Python, -DUSE_DL_IMPORT
on the gcc line eliminates those informational "Warnings",
at least from the Python library. Presumably, the distutils
package sets this automatically, but we're not using it.

-Jerry

-O Gerald S. Williams, 22Y-103GA : mailto:gsw@agere.com O-
-O AGERE SYSTEMS, 555 UNION BLVD : office:610-712-8661  O-
-O ALLENTOWN, PA, USA 18109-3286 : mobile:908-672-7592  O-

Jason Tishler wrote:
> Just to be clear, I'm building Cygwin Python the way that I always have
> (at least since my shared extension patch was accepted).  I assume you
> meant that I *could* build without __declspec() declarations if I desired.
> Since the __declspec's are there for Win32, I might as well use them.


--
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/

Re: "Best" way to build a DLL?

[Jason Tishler]

Gerald,

On Fri, Feb 15, 2002 at 03:52:28PM -0500, Gerald S. Williams wrote:
> Presumably, the distutils package sets this automatically, ...

Yes it does.

Jason

--
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/

"Best" way to build a DLL?

[Nousiainen]

This seems to be the most complicated thing .. building a DLL file.
So, what is the best and recommended way to do the job using recent cygwin tools?

I've read autobook (http://sources.redhat.com/autobook/autobook/autobook_toc.html) and it gives some good advice (I'm using autotools in my project), though there are some problems 
I've encountered. It recommends using _LTLIBRARIES and libtool to build DLL, and as far as I know the building process of a DLL file is already integrated in gcc and ld, so is the document 
outdated? (I have to use both C and C++ code in my project, and when specifying AC_PROG_CXX in configure.in file the configure script doesn't succeed, because it tries to execute a file 
called ltconfig which doesn't exist. I really don't have a clue what to do here...)
Dllhelpers (http://www.neuro.gatech.edu/users/cwilson/cygutils/V1.1/index.html) show another, simple way (using the new dll features of ld) to build the file and it is the only way I have 
managed to build a working DLL. However, I don't have an idea how to get this working smoothly with autotools.

So, what should I do? I'd appreciate if someone gave me an example of the configuration files for autotools (Makefile.am and configure.in).




--
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/

Re: "Best" way to build a DLL?

[Charles Wilson]

Take a look at the new examples in the dllhelpers.  I've added four new 
examples for building DLLs using libtool and friends.

--Chuck

Nousiainen wrote:

 > This seems to be the most complicated thing .. building a DLL file. So,
 >  what is the best and recommended way to do the job using recent
 > cygwin tools?
 >
 > I've read autobook
 > (http://sources.redhat.com/autobook/autobook/autobook_toc.html) and
 >  it gives some good advice (I'm using autotools in my project),
 > though there are some problems  I've encountered. It recommends
 > using _LTLIBRARIES and libtool to build DLL, and as far as I know
 > the building process of a DLL file is already integrated in gcc and
 >  ld, so is the document  outdated? (I have to use both C and C++
 > code in my project, and when specifying AC_PROG_CXX in configure.in
 >  file the configure script doesn't succeed, because it tries to
 > execute a file  called ltconfig which doesn't exist. I really don't
 >  have a clue what to do here...) Dllhelpers
 > (http://www.neuro.gatech.edu/users/cwilson/cygutils/V1.1/index.html)
 >  show another, simple way (using the new dll features of ld) to
 > build the file and it is the only way I have  managed to build a
 > working DLL. However, I don't have an idea how to get this working
 > smoothly with autotools.
 >
 > So, what should I do? I'd appreciate if someone gave me an example
 > of the configuration files for autotools (Makefile.am and
 > configure.in).


--
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/