Making DLL's.

Making DLL's.

[Serguei DACHIAN]

        Hi, there.

I find that the making of DLL's is a quite complicated and ennoying under
CygWin, so I decided to write a shell script to facilitate this task.  Below
you will find this script.  I would like much to hear from you about it.
I'm not a 'wizard' in things of such a kind, so I would be happy for any
comments and suggestions.  Especially, I would like to here about this from
CygWin mantainers/developpers: do there are plans to include such a tool in
CygWin in the future releases, etc., etc.

At the same time I have two questions about DLL's:

1) Is it possible to use DLL's made by CygWin in applications being
developped with MSVC++ (may be after rebuilding the import library)?  If
yes, how must I proceed for that (I am not at al specialist in MSVC++)?

2) The same questions in the case of C++ code. (I think that I have read
somewhere something about mangling scheme difference between CygWin g++ and
MSVC++, isn't it will be a problem?)

Well, that's all for the moment.  Here goes the script:


------------------------------------------
#!/bin/sh

CC=gcc
EXT=c

# This script generates automatically DLLs on CygWin systems.  By
# "generating DLL" I mean making the DLL itself (i.e., ".dll" file)
# and the import library for this dll (i.e., ".a" file).  The script
# needs only the source of the DLL in C or in C++ and makes the
# two above-mentioned files.
#
# The usage is:
#      makedll <xxx>
# where <xxx> is the name of the DLL you want to make without any
# extension.
#
# The source for the DLL is supposed to be in the file <xxx>.EXT,
# where the EXT can be set in the line 4 of this file (my default
# initial setting is c).
#
# This source file is also supposed to include windows.h
#      #include <windows.h>
# to contain an empty
#      int main(void){return 0;}
# function and a DLL entry function.  The latter should be called
# 'startup', should be defined using the WINAPI attribute, should
# return 1 and should take three arguments:
#      int WINAPI startup (HINSTANCE, DWORD, LPVOID)
# The minimum function looks like this:
#      int WINAPI startup(HINSTANCE h, DWORD r, LPVOID f){return 1;}
#
# This script needs the following tools (normaly present on CygWin
# systems):
#      echo, rm, nm, strip, dlltool.
# Clearly, it also needs the compiler (gcc or g++) for your (C or C++)
# code.  To chose between gcc and g++ code edit the line 3 of this
# file (my default initial setting is gcc).
#
# Now we start making:



# First we make an ".o" file:
#
$CC -c $1.$EXT

# Second we try to genrate a ".def" file.  For this we apply "nm" on
# the ".o" file, and then drop the useless (and may be even dangerous)
# main function:
#
echo EXPORTS > $1.def
nm $1.o | grep ' T _' | grep -v ' T _main$' | sed 's/.* T _//' >> $1.def

# Later we will also need to know the entry point of the dll.  So, now
# we try to find it out and to keep it in a ".ent" file.  For this we
# apply "nm" on the ".o" file, and then find in the output the line
# containing the entry point:
#
nm $1.o | grep ' T _startup.*@12$' | sed 's/.* T _/_/' | awk
'{printf"%s",$$1}' > $1.ent

# Now we have everything we need to make the ".dll" file.  We do it
# as described in CygWin User's Guide:
#
$CC -s -Wl,--base-file,$1.base -o $1.dll $1.o -Wl,-e,`cat $1.ent`
dlltool --base-file $1.base --def $1.def --output-exp $1.exp --dllname $1.dll
$CC -s -Wl,--base-file,$1.base,$1.exp -o $1.dll $1.o -Wl,-e,`cat $1.ent`
dlltool --base-file $1.base --def $1.def --output-exp $1.exp --dllname $1.dll
$CC -Wl,$1.exp -o $1.dll $1.o -Wl,-e,`cat $1.ent`

# Personally, I prefere to strip everything to save disk space, but if
# you don't like it, comment the following line:
#
strip $1.dll

# It remains to make the ".a" file.  We do it here as described in
# CygWin User's Guide:
#
dlltool --def $1.def --dllname $1.dll --output-lib $1.a

# Finally we clean out temporary files we have created:
#
rm -f $1.base $1.exp $1.o $1.def $1.ent

# That's all, Folks! :-)
------------------------------------------


Best regards,
                        Serguei.
___________________________________________________________________________
Serguei DACHIAN
Laboratoire de Statistique et Processus,
Universite du Maine, Av. Olivier Messiaen
72085 Le Mans CEDEX 9, FRANCE
Tel.   : +33 (0)2 43 83 37 18
Fax.   : +33 (0)2 43 83 35 79
E-mail : Serguei.Dachian@univ-lemans.fr
WWW    : http://www.univ-lemans.fr/sciences/statist/cvs/thesard.html#dachian


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Making DLL's.

[Paul Sokolovsky]

Hello Serguei,

Serguei DACHIAN <Serguei.Dachian@univ-lemans.fr> wrote:

SD>         Hi, there.

SD> I find that the making of DLL's is a quite complicated and ennoying under
SD> CygWin, so I decided to write a shell script to facilitate this task.  Below
SD> you will find this script.

    Why so complex? I just made makefile, which I include in main one,
http://www.infoservice.lg.ua/~paul/devel/dll_mk.html .

SD>   I would like much to hear from you about it.
SD> I'm not a 'wizard' in things of such a kind, so I would be happy for any
SD> comments and suggestions.  Especially, I would like to here about this from
SD> CygWin mantainers/developpers: do there are plans to include such a tool in
SD> CygWin in the future releases, etc., etc.

    DJ Delorie is making/have made support for usual 'gcc -shared',
it's in snapshots now and going to be in b21, AFAIU.

SD> At the same time I have two questions about DLL's:

SD> 1) Is it possible to use DLL's made by CygWin in applications being
SD> developped with MSVC++ (may be after rebuilding the import library)?  If
SD> yes, how must I proceed for that (I am not at al specialist in MSVC++)?

    Very easy with mingw32, for cygwin some magic required, it's
almost faq, see maillist archive. (Implib must be rebuilt, yes).

SD> 2) The same questions in the case of C++ code. (I think that I have read
SD> somewhere something about mangling scheme difference between CygWin g++ and
SD> MSVC++, isn't it will be a problem?)

    Of course, there's different mangling, but as egcs guys usually
say, mangling is not the biggest problem with C++.

SD> Well, that's all for the moment.  Here goes the script:

[]

SD> # Personally, I prefere to strip everything to save disk space, but if
SD> # you don't like it, comment the following line:
SD> #
SD> strip $1.dll

Beware of this, it cripples dlls, at least on win95.


SD> Best regards,
SD>                         Serguei.



Best regards,
 Paul                            mailto:paul-ml@is.lg.ua


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Making DLL's.

[Sebastien Carpe]

Can't anyone out there make "ld -b" produce dll (or may be some .so file, but
may be i'm dreaming awaken) so that we can have a real standard way to build
shared library ?
Actually, i've no idea of what is required for this (so far, i don't know the
windows shared library behavior, but i would be glad to have dlopen() and that
kinda stuff available).
Is it hard to do or may be impossible ?
Could someone at least explain me why this could not be done...

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Making DLL's.

[DJ Delorie]

> Can't anyone out there make "ld -b" produce dll (or may be some .so
> file, but may be i'm dreaming awaken) so that we can have a real
> standard way to build shared library ?

I've already done it, it just hasn't been released with cygwin yet.
Basically, "ld -shared *.o foo.def -o foo.dll" will work in the new
version (or gcc -Wl,-shared ...)

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Making DLL's.

[Gary V. Vaughan]

DJ Delorie <dj@delorie.com> writes:

> > Can't anyone out there make "ld -b" produce dll (or may be some .so
> > file, but may be i'm dreaming awaken) so that we can have a real
> > standard way to build shared library ?
> 
> I've already done it, it just hasn't been released with cygwin yet.
> Basically, "ld -shared *.o foo.def -o foo.dll" will work in the new
> version (or gcc -Wl,-shared ...)

First; another answer:

The upcoming libtool release, and to a marginally lesser extent, the most
recent alpha release ( ftp://alpha.gnu.org/pub/gnu/libtool/libtool-1.2f.tar.gz ),
make a pretty decent stab at both building dlls, and linking against them
in a cygwin environment.

Then a question:

The only fly in the ointment for libtool's dll support is handling the export
of data items from a dll.  Specifically, an object that will be linked into
an executable which will in turn be linked with a handful of libraries (some
static and some dll's, for argument's sake) needs to produce different code
depending on what particular combinations of dll and static libraries it will
ultimately be linked with.

That is I need to make sure that any data item that will be imported from a
dll has __attribute__((dllimport)), and any data item imported from a static
library cannot have this attribute.  Obviously, in a makefile driven build
environment there is no easy way to know which combination of libraries this
object will eventually be linked with... is there a way around this problem?
Or do I have to come up with some kind of makefile scanner to figure out
which attributes to attach to each symbol?

Actually, libtool compounds the problem, because it wants to produce both
static and dll libraries for each library object, and thus a given data symbol
may be:
        1) exported from this object if the object will be part of a dll
        2) imported from another dll
        3) imported from a static library
        4) externed in the tradition way if it will be part of a static lib

So, my question is:  do I really have to figure out whether this object is
destined to become part of a static library, a dll, or an executable, and
which libraries that destination will depend on and whether each of them will
be a dll or not in order to produce the correct code for each exported data
symbol?

My (flawed) best solution so far is:

        /* foo.h */
        #ifdef __CYGWIN__
        #  ifdef _COMPILING_FOO_DLL_
        #    define EXTERN __declspec(dllexport)
        #  else
        #    define EXTERN extern __declspec(dllimport)
        #  endif
        #else
        #  define EXTERN extern
        #endif

        EXTERN int foo;

When building the dll, I need:

        /* foo.c */
        #define _COMPILING_FOO_DLL_
        #include "foo.h"

When linking against the dll on cygwin or otherwise:

        /* bar.c */
        #include "foo.h"

Which works fine, until I try to build an equivalent static libfoo.a from the
foo sources on cygwin, when ofcourse I get `undefined __imp_foo' errors =(O|

What now?

Cheers,
        Gary.
-- 
  ___              _   ___   __              _             
 / __|__ _ _ ___ _| | / / | / /_ _ _  _ __ _| |_  __ _ ___ 
| (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \
 \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/
PGP Key from/___/                      /___/               
http://www.cl.cam.ac.uk/PGP/pks-commands.html#extract      
http://pgp.ai.mit.edu/~bal/pks-commands.html#extract       


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Making DLL's.

[John Mullee]

> That is I need to make sure that any data item that will be imported from a
> dll has __attribute__((dllimport)), and any data item imported from a static
> library cannot have this attribute.  Obviously, in a makefile driven build

Normally, in win32, this has to be specified manually - 
with default being 'not exported'.
RTFM for ".def" files:

=========
NAME [application][BASE=address]

LIBRARY [library][BASE=address]
This statement tells LINK to create a DLL. At the same time, LINK
creates an import library, unless an .EXP file is used in the build.

DESCRIPTION "text"

STACKSIZE reserve[,commit]

SECTIONS definitions
This statement sets attributes for one or more sections in the image
file. It can be used to override the default attributes for each type of
section.

SECTIONS marks the beginning of a list of section definitions. Each
definition must be on a separate line. The SECTIONS keyword can be on
the same line as the first definition or on a preceding line. The .DEF
file can contain one or more SECTIONS statements. The SEGMENTS keyword
is supported as a synonym for SECTIONS.
The syntax for a section definition is:
section [CLASS 'classname'] attributes
The section name is case sensitive. The CLASS keyword is supported for
compatibility, but is ignored. The attributes are one or more of the
following: EXECUTE, READ, SHARED, and WRITE.

EXPORTS definitions
This statement makes one or more definitions available as exports to
other programs.
EXPORTS marks the beginning of a list of export definitions. Each
definition must be on a separate line. The EXPORTS keyword can be on the
same line as the first definition or on a preceding line. The .DEF file
can contain one or more EXPORTS statements.
The syntax for an export definition is:
entryname[=internalname] [@ordinal[NONAME]] [DATA] [PRIVATE]
The optional keyword PRIVATE tells IMPLIB to ignore the definition.
PRIVATE prevents entryname from being placed in the import library. The
keyword has no effect on LINK.
There are three methods for exporting a definition, listed in
recommended order of use:
The __declspec(dllexport) keyword in the source code
An /EXPORT specification in a LINK command
An EXPORTS statement in a .DEF file 
All three methods can be used in the same program. When LINK builds a
program that contains exports, it also creates an import library, unless
an .EXP file is used in the build.

VERSION major[.minor]
This statement tells LINK to put a number in the header of the .EXE file
or DLL. The major and minor arguments are decimal numbers in the range 0
through 65,535. The default is version 0.0.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Making DLL's.

[Gary V. Vaughan]

John Mullee <jmullee@hotmail.com> writes:

> > That is I need to make sure that any data item that will be imported from a
> > dll has __attribute__((dllimport)), and any data item imported from a static
> > library cannot have this attribute.  Obviously, in a makefile driven build
> 
> Normally, in win32, this has to be specified manually - 
> with default being 'not exported'.
> RTFM for ".def" files:

Thanks for the reply, by this I know... perhaps a more concrete example:

I have two source files, lib.c and main.c, plus a header file lib.h.
I want to make a dll, `liblib.dll',  and an ar static archive, `liblib.a' from
the code in lib.c.  I will install both of these libraries plus the header
file, and can arrange for the linker to choose between the dll (for which I
will build an import library on the fly) and the static archive depending on
whether I ask for static linkage or not (gcc -static).

Obviously I need cpp to read lib.h when I build main.o (by adding #include
"lib.h").  I probably want cpp to read lib.h when I link lib.o (destined to be
included in liblib.a) and lib.lo (destined for liblib.dll) too, to get
function prototypes etc.

The difficult part is getting the correctly tagged declarations from the
header file to generate the correct assembly when I build main.lo (which I
will link against liblib.dll) and main.o (for liblib.a), otherwise I get
undefined _imp_foo errors at link time.

The really difficult part is designing a mechanism that allows someone else
to link liblib.dll or liblib.a by including lib.h...

The *really* difficult part is creating libdepend.h, whichdepends on
liblib.dll or liblib.a depending on whether I want to link a static executable
or not....

Is there a better solution to this than trying to find out the complete list
of libraries (and their types) against which each object will eventually be
linked so that I can tag data exports correctly when the asm code is
generated?

Cheers,
        Gary.
-- 
  ___              _   ___   __              _             
 / __|__ _ _ ___ _| | / / | / /_ _ _  _ __ _| |_  __ _ ___ 
| (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \
 \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/
PGP Key from/___/                      /___/               
http://www.cl.cam.ac.uk/PGP/pks-commands.html#extract      
http://pgp.ai.mit.edu/~bal/pks-commands.html#extract       


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re[2]: Making DLL's.

[Paul Sokolovsky]

Hello Gary,

Gary V. Vaughan <gvaughan@oranda.demon.co.uk> wrote:

[]

GVV> Is there a better solution to this than trying to find out the complete list
GVV> of libraries (and their types) against which each object will eventually be
GVV> linked so that I can tag data exports correctly when the asm code is
GVV> generated?

     To add more confusion (though maybe it not really matters in
practise), dlls can't be mutually dependent (tested on win95)

GVV> Cheers,
GVV>         Gary.


Best regards,
 Paul                            mailto:paul-ml@is.lg.ua


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Making DLL's.

[Fergus Henderson]

On 22-Mar-1999, Gary V. Vaughan <gvaughan@oranda.demon.co.uk> wrote:
> The only fly in the ointment for libtool's dll support is handling the export
> of data items from a dll.  Specifically, an object that will be linked into
> an executable which will in turn be linked with a handful of libraries (some
> static and some dll's, for argument's sake) needs to produce different code
> depending on what particular combinations of dll and static libraries it will
> ultimately be linked with.
> 
> That is I need to make sure that any data item that will be imported from a
> dll has __attribute__((dllimport)), and any data item imported from a static
> library cannot have this attribute.  Obviously, in a makefile driven build
> environment there is no easy way to know which combination of libraries this
> object will eventually be linked with... is there a way around this problem?
> Or do I have to come up with some kind of makefile scanner to figure out
> which attributes to attach to each symbol?
>
> Actually, libtool compounds the problem, because it wants to produce both
> static and dll libraries for each library object, and thus a given data symbol
> may be:
>         1) exported from this object if the object will be part of a dll
>         4) externed in the tradition way if it will be part of a static lib

The difference between 1) and 4) is already important on many Unix
systems, where you need to compile with `-fpic' in case 1),
but you don't need any special options in case 4).
So your Makefile ought to already be set up to handle this.
On Windows, just replace `-fpic' with `-DCOMPILING_FOO_DLL'
and then use the #ifdefs you mentioned.

(N.B. You should really use `COMPILING_FOO_DLL' rather than
`_COMPILING_FOO_DLL_', because according to ISO C and C++,
the latter is reserved for use by the implementation.)

>         2) imported from another dll
>         3) imported from a static library

This distinction is not present in Unix, and yes, it is
a real pain.  I have avoided it by either always using
a static library or always using a DLL for any given 
library.

> So, my question is:  do I really have to figure out whether this object is
> destined to become part of a static library, a dll, or an executable, and
> which libraries that destination will depend on and whether each of them will
> be a dll or not in order to produce the correct code for each exported data
> symbol?

Basically yes.  And it is a real pain.
But it's not _quite_ as bad as you make out.

> My (flawed) best solution so far is:
> 
>         /* foo.h */
>         #ifdef __CYGWIN__
>         #  ifdef _COMPILING_FOO_DLL_
>         #    define EXTERN __declspec(dllexport)
>         #  else
>         #    define EXTERN extern __declspec(dllimport)
>         #  endif
>         #else
>         #  define EXTERN extern
>         #endif
> 
>         EXTERN int foo;

A potentially better alternative is

         /* foo.h */
         #if defined(__CYGWIN__) && defined(DEFINE_FOO_DLL)
         #  define FOO_EXTERN __declspec(dllexport)
         #elif defined(__CYGWIN__) && defined(USE_FOO_DLL)
         #  define FOO_EXTERN extern __declspec(dllimport)
         #else
         #  define FOO_EXTERN extern
         #endif
 
         FOO_EXTERN int foo;

(I prefer the name DEFINE_FOO_DLL rather than COMPILING_FOO_DLL.)

Note that if you're using C rather than C++, then it is in fact
possible to simplify this a little, so that you don't need to add all
those FOO_EXTERN symbols to all the declarations in the header files. 
See < http://www.cs.mu.oz.au/~fjh/gnu-win32/how-to-build-dlls.html > for
details.  Note that the stuff there is fairly old; it dates back to
version b18 or thereabouts.  I haven't tested it with more recent versions.

> When building the dll, I need:
> 
>         /* foo.c */
>         #define _COMPILING_FOO_DLL_
>         #include "foo.h"
...
> Which works fine, until I try to build an equivalent static libfoo.a from the
> foo sources on cygwin, when ofcourse I get `undefined __imp_foo' errors =(O|

It's better to pass -D_COMPILING_FOO_DLL_ or -DDEFINE_FOO_DLL
on the command line via make, rather than hard-coding it
in your source file.  That way you can avoid passing it when you
build your static libraries.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: < http://www.cs.mu.oz.au/~fjh >  |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3        |     -- the last words of T. S. Garp.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Re[2]: Making DLL's.

[Mikey]

Who told you this, or how did you test it?
all you need to do for mutually dependant
.dll's is to create an implib from a .def file
before linking. see the msdn.

On Mon, 22 Mar 1999 21:17:24 +0200, you wrote:

>Hello Gary,
>
>Gary V. Vaughan <gvaughan@oranda.demon.co.uk> wrote:
>
>[]
>
>GVV> Is there a better solution to this than trying to find out the complete list
>GVV> of libraries (and their types) against which each object will eventually be
>GVV> linked so that I can tag data exports correctly when the asm code is
>GVV> generated?
>
>     To add more confusion (though maybe it not really matters in
>practise), dlls can't be mutually dependent (tested on win95)
>
>GVV> Cheers,
>GVV>         Gary.
>
>
>Best regards,
> Paul                            mailto:paul-ml@is.lg.ua


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Re[2]: Making DLL's.

[Gary V. Vaughan]

Paul Sokolovsky <paul-ml@is.lg.ua> writes:

> Hello Gary,
> 
> Gary V. Vaughan <gvaughan@oranda.demon.co.uk> wrote:
> 
> []
> 
> GVV> Is there a better solution to this than trying to find out the complete
> GVV> list of libraries (and their types) against which each object will
> GVV> eventually be linked so that I can tag data exports correctly when the
> GVV> asm code is generated?
> 
>      To add more confusion (though maybe it not really matters in
> practise), dlls can't be mutually dependent (tested on win95)

Indeed.  Dlls really are quite deficient by comparison with elf shared
libraries on unix (which is what I am trying to emulate -- more fool me!),
for example you cannot leave undefined symbols in a dll which will be
provided later when the library is linked, and you cannot override symbols
in a dll with symbols in the main source.

I am trying to ignore these problems for the moment until I can at least
make global data be well behaved.

Cheers,
        Gary.
-- 
  ___              _   ___   __              _             
 / __|__ _ _ ___ _| | / / | / /_ _ _  _ __ _| |_  __ _ ___ 
| (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \
 \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/
PGP Key from/___/                      /___/               
http://www.cl.cam.ac.uk/PGP/pks-commands.html#extract      
http://pgp.ai.mit.edu/~bal/pks-commands.html#extract       


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Making DLL's.

[Gary V. Vaughan]

Thanks for the response.

Fergus Henderson <fjh@cs.mu.OZ.AU> writes:

> On 22-Mar-1999, Gary V. Vaughan <gvaughan@oranda.demon.co.uk> wrote:
> > [[snip]] libtool compounds the problem, because it wants to produce both
> > static and dll libraries for each library object, and thus a given data
> > symbol may be:
> >         1) exported from this object if the object will be part of a dll
> >         4) externed in the tradition way if it will be part of a static lib
> 
> The difference between 1) and 4) is already important on many Unix
> systems, where you need to compile with `-fpic' in case 1),
> but you don't need any special options in case 4).
> So your Makefile ought to already be set up to handle this.
> On Windows, just replace `-fpic' with `-DCOMPILING_FOO_DLL'
> and then use the #ifdefs you mentioned.

Hmmm... well, we already pass -DPIC alongside -fpic, so it may be that
I can simply check for this cpp symbol when compiling the objects for a
dll that has no dependencies.  Now that you have mentioned this, it occurs
to me that since we already take pains not to make a shared library dependant
upon a static archive (is that a legal thing to do with win32? it certainly
fails on many unices), I can intuit that I need to __declspec(dllimport)
any data items which are imported from other libraries which this one
depends on, if PIC is defined (and I am thus building an object for a dll).

> (N.B. You should really use `COMPILING_FOO_DLL' rather than
> `_COMPILING_FOO_DLL_', because according to ISO C and C++,
> the latter is reserved for use by the implementation.)

Good point.  Thanks.

> >         2) imported from another dll
> >         3) imported from a static library
> 
> This distinction is not present in Unix, and yes, it is
> a real pain.  I have avoided it by either always using
> a static library or always using a DLL for any given 
> library.

Yes, that is what we do currently, forcing everything to be statically linked,
and although it works adequately, I would *really* like to offer the same
shared library facilities (within the limits of win32 dlls) that unix has.

> > So, my question is:  do I really have to figure out whether this object is
> > destined to become part of a static library, a dll, or an executable, and
> > which libraries that destination will depend on and whether each of them
> > will be a dll or not in order to produce the correct code for each
> > exported data symbol?
> 
> Basically yes.  And it is a real pain.

I had feared as much.  *sigh*

> But it's not _quite_ as bad as you make out.
> [[snip]]
> 
>          /* foo.h */
>          #if defined(__CYGWIN__) && defined(DEFINE_FOO_DLL)
>          #  define FOO_EXTERN __declspec(dllexport)
>          #elif defined(__CYGWIN__) && defined(USE_FOO_DLL)
>          #  define FOO_EXTERN extern __declspec(dllimport)
>          #else
>          #  define FOO_EXTERN extern
>          #endif
>  
>          FOO_EXTERN int foo;
> 
> (I prefer the name DEFINE_FOO_DLL rather than COMPILING_FOO_DLL.)
> 
> Note that if you're using C rather than C++, then it is in fact
> possible to simplify this a little, so that you don't need to add all
> those FOO_EXTERN symbols to all the declarations in the header files. 
> See < http://www.cs.mu.oz.au/~fjh/gnu-win32/how-to-build-dlls.html > for
> details.  Note that the stuff there is fairly old; it dates back to
> version b18 or thereabouts.  I haven't tested it with more recent versions.

This looks as though it may be exactly what I was looking for, in that I
would really like to be able to take virgin unix sources which already use
libtool (which is what I am working in), and have them automatically do
the right thing with respect to creating a dll on win32 where a shared lib
would have been created in an equivalent build on unix.

In time, that will hopefully mean that as libtool gets wider usage in
the GNU community, projects which use libtool will automatically have
a cygwin port in most cases.

> > When building the dll, I need:
> > 
> >         /* foo.c */
> >         #define _COMPILING_FOO_DLL_
> >         #include "foo.h"
> ...
> > Which works fine, until I try to build an equivalent static libfoo.a from
> > the foo sources on cygwin, when ofcourse I get `undefined __imp_foo'
> > errors =(O| 
> 
> It's better to pass -D_COMPILING_FOO_DLL_ or -DDEFINE_FOO_DLL
> on the command line via make, rather than hard-coding it
> in your source file.  That way you can avoid passing it when you
> build your static libraries.

Thanks, this was of great help to me.

        Gary.
-- 
  ___              _   ___   __              _             
 / __|__ _ _ ___ _| | / / | / /_ _ _  _ __ _| |_  __ _ ___ 
| (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \
 \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/
PGP Key from/___/                      /___/               
http://www.cl.cam.ac.uk/PGP/pks-commands.html#extract      
http://pgp.ai.mit.edu/~bal/pks-commands.html#extract       


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Re[2]: Making DLL's.

[Gary V. Vaughan]

jeffdbREMOVETHIS@goodnet.com (Mikey) writes:

> Who told you this, or how did you test it?
> all you need to do for mutually dependant
> .dll's is to create an implib from a .def file
> before linking.

Oh yes.  I hadn't thought of that.  More special cases for libtool to handle,
*mumble* *mumble* =/O|

> see the msdn.

Good news for people (like me) who won't register their email address with
Microsoft is that the registration requirement to access
http://msdn.microsoft.com/library/default.htm has been lifted!

Cheers,
        Gary

-- 
  ___              _   ___   __              _             
 / __|__ _ _ ___ _| | / / | / /_ _ _  _ __ _| |_  __ _ ___ 
| (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \
 \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/
PGP Key from/___/                      /___/               
http://www.cl.cam.ac.uk/PGP/pks-commands.html#extract      
http://pgp.ai.mit.edu/~bal/pks-commands.html#extract       


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re[4]: Making DLL's.

[Paul Sokolovsky]

Hello Mikey,

Mikey <jeffdbREMOVETHIS@goodnet.com> wrote:

M> Who told you this, or how did you test it?
M> all you need to do for mutually dependant
M> .dll's is to create an implib from a .def file
M> before linking. see the msdn.

   I tried to split large dll in two smaller, I build them but none of
them could be loaded. I just have tried make it with clean trivial
example and it works, so that probably was other (mine) bug. Problem
is that windoze doesn't explain clearly where's error - it doesn't
load at all with that stupid status 'A device attached to the system
is not functioning' %) . By the way, testing that, I found that
dlltool doesn't want to export one-character symbols %)

M> On Mon, 22 Mar 1999 21:17:24 +0200, you wrote:

>>
>>     To add more confusion (though maybe it not really matters in
>>practise), dlls can't be mutually dependent (tested on win95)
>>

Best regards,
 Paul                            mailto:paul-ml@is.lg.ua


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re[2]: Making DLL's.

[Paul Sokolovsky]

Hello Gary,

Gary V. Vaughan <gvaughan@oranda.demon.co.uk> wrote:

[]

GVV> Is there a better solution to this than trying to find out the complete list
GVV> of libraries (and their types) against which each object will eventually be
GVV> linked so that I can tag data exports correctly when the asm code is
GVV> generated?

     To add more confusion (though maybe it not really matters in
practise), dlls can't be mutually dependent (tested on win95)

GVV> Cheers,
GVV>         Gary.


Best regards,
 Paul                            mailto:paul-ml@is.lg.ua


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re[4]: Making DLL's.

[Paul Sokolovsky]

Hello Mikey,

Mikey <jeffdbREMOVETHIS@goodnet.com> wrote:

M> Who told you this, or how did you test it?
M> all you need to do for mutually dependant
M> .dll's is to create an implib from a .def file
M> before linking. see the msdn.

   I tried to split large dll in two smaller, I build them but none of
them could be loaded. I just have tried make it with clean trivial
example and it works, so that probably was other (mine) bug. Problem
is that windoze doesn't explain clearly where's error - it doesn't
load at all with that stupid status 'A device attached to the system
is not functioning' %) . By the way, testing that, I found that
dlltool doesn't want to export one-character symbols %)

M> On Mon, 22 Mar 1999 21:17:24 +0200, you wrote:

>>
>>     To add more confusion (though maybe it not really matters in
>>practise), dlls can't be mutually dependent (tested on win95)
>>

Best regards,
 Paul                            mailto:paul-ml@is.lg.ua


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Making DLL's.

[DJ Delorie]

> Can't anyone out there make "ld -b" produce dll (or may be some .so
> file, but may be i'm dreaming awaken) so that we can have a real
> standard way to build shared library ?

I've already done it, it just hasn't been released with cygwin yet.
Basically, "ld -shared *.o foo.def -o foo.dll" will work in the new
version (or gcc -Wl,-shared ...)

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Making DLL's.

[Serguei DACHIAN]

        Hi, there.

I find that the making of DLL's is a quite complicated and ennoying under
CygWin, so I decided to write a shell script to facilitate this task.  Below
you will find this script.  I would like much to hear from you about it.
I'm not a 'wizard' in things of such a kind, so I would be happy for any
comments and suggestions.  Especially, I would like to here about this from
CygWin mantainers/developpers: do there are plans to include such a tool in
CygWin in the future releases, etc., etc.

At the same time I have two questions about DLL's:

1) Is it possible to use DLL's made by CygWin in applications being
developped with MSVC++ (may be after rebuilding the import library)?  If
yes, how must I proceed for that (I am not at al specialist in MSVC++)?

2) The same questions in the case of C++ code. (I think that I have read
somewhere something about mangling scheme difference between CygWin g++ and
MSVC++, isn't it will be a problem?)

Well, that's all for the moment.  Here goes the script:


------------------------------------------
#!/bin/sh

CC=gcc
EXT=c

# This script generates automatically DLLs on CygWin systems.  By
# "generating DLL" I mean making the DLL itself (i.e., ".dll" file)
# and the import library for this dll (i.e., ".a" file).  The script
# needs only the source of the DLL in C or in C++ and makes the
# two above-mentioned files.
#
# The usage is:
#      makedll <xxx>
# where <xxx> is the name of the DLL you want to make without any
# extension.
#
# The source for the DLL is supposed to be in the file <xxx>.EXT,
# where the EXT can be set in the line 4 of this file (my default
# initial setting is c).
#
# This source file is also supposed to include windows.h
#      #include <windows.h>
# to contain an empty
#      int main(void){return 0;}
# function and a DLL entry function.  The latter should be called
# 'startup', should be defined using the WINAPI attribute, should
# return 1 and should take three arguments:
#      int WINAPI startup (HINSTANCE, DWORD, LPVOID)
# The minimum function looks like this:
#      int WINAPI startup(HINSTANCE h, DWORD r, LPVOID f){return 1;}
#
# This script needs the following tools (normaly present on CygWin
# systems):
#      echo, rm, nm, strip, dlltool.
# Clearly, it also needs the compiler (gcc or g++) for your (C or C++)
# code.  To chose between gcc and g++ code edit the line 3 of this
# file (my default initial setting is gcc).
#
# Now we start making:



# First we make an ".o" file:
#
$CC -c $1.$EXT

# Second we try to genrate a ".def" file.  For this we apply "nm" on
# the ".o" file, and then drop the useless (and may be even dangerous)
# main function:
#
echo EXPORTS > $1.def
nm $1.o | grep ' T _' | grep -v ' T _main$' | sed 's/.* T _//' >> $1.def

# Later we will also need to know the entry point of the dll.  So, now
# we try to find it out and to keep it in a ".ent" file.  For this we
# apply "nm" on the ".o" file, and then find in the output the line
# containing the entry point:
#
nm $1.o | grep ' T _startup.*@12$' | sed 's/.* T _/_/' | awk
'{printf"%s",$$1}' > $1.ent

# Now we have everything we need to make the ".dll" file.  We do it
# as described in CygWin User's Guide:
#
$CC -s -Wl,--base-file,$1.base -o $1.dll $1.o -Wl,-e,`cat $1.ent`
dlltool --base-file $1.base --def $1.def --output-exp $1.exp --dllname $1.dll
$CC -s -Wl,--base-file,$1.base,$1.exp -o $1.dll $1.o -Wl,-e,`cat $1.ent`
dlltool --base-file $1.base --def $1.def --output-exp $1.exp --dllname $1.dll
$CC -Wl,$1.exp -o $1.dll $1.o -Wl,-e,`cat $1.ent`

# Personally, I prefere to strip everything to save disk space, but if
# you don't like it, comment the following line:
#
strip $1.dll

# It remains to make the ".a" file.  We do it here as described in
# CygWin User's Guide:
#
dlltool --def $1.def --dllname $1.dll --output-lib $1.a

# Finally we clean out temporary files we have created:
#
rm -f $1.base $1.exp $1.o $1.def $1.ent

# That's all, Folks! :-)
------------------------------------------


Best regards,
                        Serguei.
___________________________________________________________________________
Serguei DACHIAN
Laboratoire de Statistique et Processus,
Universite du Maine, Av. Olivier Messiaen
72085 Le Mans CEDEX 9, FRANCE
Tel.   : +33 (0)2 43 83 37 18
Fax.   : +33 (0)2 43 83 35 79
E-mail : Serguei.Dachian@univ-lemans.fr
WWW    : http://www.univ-lemans.fr/sciences/statist/cvs/thesard.html#dachian


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Making DLL's.

[Gary V. Vaughan]

John Mullee <jmullee@hotmail.com> writes:

> > That is I need to make sure that any data item that will be imported from a
> > dll has __attribute__((dllimport)), and any data item imported from a static
> > library cannot have this attribute.  Obviously, in a makefile driven build
> 
> Normally, in win32, this has to be specified manually - 
> with default being 'not exported'.
> RTFM for ".def" files:

Thanks for the reply, by this I know... perhaps a more concrete example:

I have two source files, lib.c and main.c, plus a header file lib.h.
I want to make a dll, `liblib.dll',  and an ar static archive, `liblib.a' from
the code in lib.c.  I will install both of these libraries plus the header
file, and can arrange for the linker to choose between the dll (for which I
will build an import library on the fly) and the static archive depending on
whether I ask for static linkage or not (gcc -static).

Obviously I need cpp to read lib.h when I build main.o (by adding #include
"lib.h").  I probably want cpp to read lib.h when I link lib.o (destined to be
included in liblib.a) and lib.lo (destined for liblib.dll) too, to get
function prototypes etc.

The difficult part is getting the correctly tagged declarations from the
header file to generate the correct assembly when I build main.lo (which I
will link against liblib.dll) and main.o (for liblib.a), otherwise I get
undefined _imp_foo errors at link time.

The really difficult part is designing a mechanism that allows someone else
to link liblib.dll or liblib.a by including lib.h...

The *really* difficult part is creating libdepend.h, whichdepends on
liblib.dll or liblib.a depending on whether I want to link a static executable
or not....

Is there a better solution to this than trying to find out the complete list
of libraries (and their types) against which each object will eventually be
linked so that I can tag data exports correctly when the asm code is
generated?

Cheers,
        Gary.
-- 
  ___              _   ___   __              _             
 / __|__ _ _ ___ _| | / / | / /_ _ _  _ __ _| |_  __ _ ___ 
| (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \
 \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/
PGP Key from/___/                      /___/               
http://www.cl.cam.ac.uk/PGP/pks-commands.html#extract      
http://pgp.ai.mit.edu/~bal/pks-commands.html#extract       


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Re[2]: Making DLL's.

[Mikey]

Who told you this, or how did you test it?
all you need to do for mutually dependant
.dll's is to create an implib from a .def file
before linking. see the msdn.

On Mon, 22 Mar 1999 21:17:24 +0200, you wrote:

>Hello Gary,
>
>Gary V. Vaughan <gvaughan@oranda.demon.co.uk> wrote:
>
>[]
>
>GVV> Is there a better solution to this than trying to find out the complete list
>GVV> of libraries (and their types) against which each object will eventually be
>GVV> linked so that I can tag data exports correctly when the asm code is
>GVV> generated?
>
>     To add more confusion (though maybe it not really matters in
>practise), dlls can't be mutually dependent (tested on win95)
>
>GVV> Cheers,
>GVV>         Gary.
>
>
>Best regards,
> Paul                            mailto:paul-ml@is.lg.ua


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Making DLL's.

[Sebastien Carpe]

Can't anyone out there make "ld -b" produce dll (or may be some .so file, but
may be i'm dreaming awaken) so that we can have a real standard way to build
shared library ?
Actually, i've no idea of what is required for this (so far, i don't know the
windows shared library behavior, but i would be glad to have dlopen() and that
kinda stuff available).
Is it hard to do or may be impossible ?
Could someone at least explain me why this could not be done...

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Making DLL's.

[John Mullee]

> That is I need to make sure that any data item that will be imported from a
> dll has __attribute__((dllimport)), and any data item imported from a static
> library cannot have this attribute.  Obviously, in a makefile driven build

Normally, in win32, this has to be specified manually - 
with default being 'not exported'.
RTFM for ".def" files:

=========
NAME [application][BASE=address]

LIBRARY [library][BASE=address]
This statement tells LINK to create a DLL. At the same time, LINK
creates an import library, unless an .EXP file is used in the build.

DESCRIPTION "text"

STACKSIZE reserve[,commit]

SECTIONS definitions
This statement sets attributes for one or more sections in the image
file. It can be used to override the default attributes for each type of
section.

SECTIONS marks the beginning of a list of section definitions. Each
definition must be on a separate line. The SECTIONS keyword can be on
the same line as the first definition or on a preceding line. The .DEF
file can contain one or more SECTIONS statements. The SEGMENTS keyword
is supported as a synonym for SECTIONS.
The syntax for a section definition is:
section [CLASS 'classname'] attributes
The section name is case sensitive. The CLASS keyword is supported for
compatibility, but is ignored. The attributes are one or more of the
following: EXECUTE, READ, SHARED, and WRITE.

EXPORTS definitions
This statement makes one or more definitions available as exports to
other programs.
EXPORTS marks the beginning of a list of export definitions. Each
definition must be on a separate line. The EXPORTS keyword can be on the
same line as the first definition or on a preceding line. The .DEF file
can contain one or more EXPORTS statements.
The syntax for an export definition is:
entryname[=internalname] [@ordinal[NONAME]] [DATA] [PRIVATE]
The optional keyword PRIVATE tells IMPLIB to ignore the definition.
PRIVATE prevents entryname from being placed in the import library. The
keyword has no effect on LINK.
There are three methods for exporting a definition, listed in
recommended order of use:
The __declspec(dllexport) keyword in the source code
An /EXPORT specification in a LINK command
An EXPORTS statement in a .DEF file 
All three methods can be used in the same program. When LINK builds a
program that contains exports, it also creates an import library, unless
an .EXP file is used in the build.

VERSION major[.minor]
This statement tells LINK to put a number in the header of the .EXE file
or DLL. The major and minor arguments are decimal numbers in the range 0
through 65,535. The default is version 0.0.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Making DLL's.

[Paul Sokolovsky]

Hello Serguei,

Serguei DACHIAN <Serguei.Dachian@univ-lemans.fr> wrote:

SD>         Hi, there.

SD> I find that the making of DLL's is a quite complicated and ennoying under
SD> CygWin, so I decided to write a shell script to facilitate this task.  Below
SD> you will find this script.

    Why so complex? I just made makefile, which I include in main one,
http://www.infoservice.lg.ua/~paul/devel/dll_mk.html .

SD>   I would like much to hear from you about it.
SD> I'm not a 'wizard' in things of such a kind, so I would be happy for any
SD> comments and suggestions.  Especially, I would like to here about this from
SD> CygWin mantainers/developpers: do there are plans to include such a tool in
SD> CygWin in the future releases, etc., etc.

    DJ Delorie is making/have made support for usual 'gcc -shared',
it's in snapshots now and going to be in b21, AFAIU.

SD> At the same time I have two questions about DLL's:

SD> 1) Is it possible to use DLL's made by CygWin in applications being
SD> developped with MSVC++ (may be after rebuilding the import library)?  If
SD> yes, how must I proceed for that (I am not at al specialist in MSVC++)?

    Very easy with mingw32, for cygwin some magic required, it's
almost faq, see maillist archive. (Implib must be rebuilt, yes).

SD> 2) The same questions in the case of C++ code. (I think that I have read
SD> somewhere something about mangling scheme difference between CygWin g++ and
SD> MSVC++, isn't it will be a problem?)

    Of course, there's different mangling, but as egcs guys usually
say, mangling is not the biggest problem with C++.

SD> Well, that's all for the moment.  Here goes the script:

[]

SD> # Personally, I prefere to strip everything to save disk space, but if
SD> # you don't like it, comment the following line:
SD> #
SD> strip $1.dll

Beware of this, it cripples dlls, at least on win95.


SD> Best regards,
SD>                         Serguei.



Best regards,
 Paul                            mailto:paul-ml@is.lg.ua


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Re[2]: Making DLL's.

[Gary V. Vaughan]

Paul Sokolovsky <paul-ml@is.lg.ua> writes:

> Hello Gary,
> 
> Gary V. Vaughan <gvaughan@oranda.demon.co.uk> wrote:
> 
> []
> 
> GVV> Is there a better solution to this than trying to find out the complete
> GVV> list of libraries (and their types) against which each object will
> GVV> eventually be linked so that I can tag data exports correctly when the
> GVV> asm code is generated?
> 
>      To add more confusion (though maybe it not really matters in
> practise), dlls can't be mutually dependent (tested on win95)

Indeed.  Dlls really are quite deficient by comparison with elf shared
libraries on unix (which is what I am trying to emulate -- more fool me!),
for example you cannot leave undefined symbols in a dll which will be
provided later when the library is linked, and you cannot override symbols
in a dll with symbols in the main source.

I am trying to ignore these problems for the moment until I can at least
make global data be well behaved.

Cheers,
        Gary.
-- 
  ___              _   ___   __              _             
 / __|__ _ _ ___ _| | / / | / /_ _ _  _ __ _| |_  __ _ ___ 
| (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \
 \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/
PGP Key from/___/                      /___/               
http://www.cl.cam.ac.uk/PGP/pks-commands.html#extract      
http://pgp.ai.mit.edu/~bal/pks-commands.html#extract       


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Re[2]: Making DLL's.

[Gary V. Vaughan]

jeffdbREMOVETHIS@goodnet.com (Mikey) writes:

> Who told you this, or how did you test it?
> all you need to do for mutually dependant
> .dll's is to create an implib from a .def file
> before linking.

Oh yes.  I hadn't thought of that.  More special cases for libtool to handle,
*mumble* *mumble* =/O|

> see the msdn.

Good news for people (like me) who won't register their email address with
Microsoft is that the registration requirement to access
http://msdn.microsoft.com/library/default.htm has been lifted!

Cheers,
        Gary

-- 
  ___              _   ___   __              _             
 / __|__ _ _ ___ _| | / / | / /_ _ _  _ __ _| |_  __ _ ___ 
| (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \
 \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/
PGP Key from/___/                      /___/               
http://www.cl.cam.ac.uk/PGP/pks-commands.html#extract      
http://pgp.ai.mit.edu/~bal/pks-commands.html#extract       


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Making DLL's.

[Fergus Henderson]

On 22-Mar-1999, Gary V. Vaughan <gvaughan@oranda.demon.co.uk> wrote:
> The only fly in the ointment for libtool's dll support is handling the export
> of data items from a dll.  Specifically, an object that will be linked into
> an executable which will in turn be linked with a handful of libraries (some
> static and some dll's, for argument's sake) needs to produce different code
> depending on what particular combinations of dll and static libraries it will
> ultimately be linked with.
> 
> That is I need to make sure that any data item that will be imported from a
> dll has __attribute__((dllimport)), and any data item imported from a static
> library cannot have this attribute.  Obviously, in a makefile driven build
> environment there is no easy way to know which combination of libraries this
> object will eventually be linked with... is there a way around this problem?
> Or do I have to come up with some kind of makefile scanner to figure out
> which attributes to attach to each symbol?
>
> Actually, libtool compounds the problem, because it wants to produce both
> static and dll libraries for each library object, and thus a given data symbol
> may be:
>         1) exported from this object if the object will be part of a dll
>         4) externed in the tradition way if it will be part of a static lib

The difference between 1) and 4) is already important on many Unix
systems, where you need to compile with `-fpic' in case 1),
but you don't need any special options in case 4).
So your Makefile ought to already be set up to handle this.
On Windows, just replace `-fpic' with `-DCOMPILING_FOO_DLL'
and then use the #ifdefs you mentioned.

(N.B. You should really use `COMPILING_FOO_DLL' rather than
`_COMPILING_FOO_DLL_', because according to ISO C and C++,
the latter is reserved for use by the implementation.)

>         2) imported from another dll
>         3) imported from a static library

This distinction is not present in Unix, and yes, it is
a real pain.  I have avoided it by either always using
a static library or always using a DLL for any given 
library.

> So, my question is:  do I really have to figure out whether this object is
> destined to become part of a static library, a dll, or an executable, and
> which libraries that destination will depend on and whether each of them will
> be a dll or not in order to produce the correct code for each exported data
> symbol?

Basically yes.  And it is a real pain.
But it's not _quite_ as bad as you make out.

> My (flawed) best solution so far is:
> 
>         /* foo.h */
>         #ifdef __CYGWIN__
>         #  ifdef _COMPILING_FOO_DLL_
>         #    define EXTERN __declspec(dllexport)
>         #  else
>         #    define EXTERN extern __declspec(dllimport)
>         #  endif
>         #else
>         #  define EXTERN extern
>         #endif
> 
>         EXTERN int foo;

A potentially better alternative is

         /* foo.h */
         #if defined(__CYGWIN__) && defined(DEFINE_FOO_DLL)
         #  define FOO_EXTERN __declspec(dllexport)
         #elif defined(__CYGWIN__) && defined(USE_FOO_DLL)
         #  define FOO_EXTERN extern __declspec(dllimport)
         #else
         #  define FOO_EXTERN extern
         #endif
 
         FOO_EXTERN int foo;

(I prefer the name DEFINE_FOO_DLL rather than COMPILING_FOO_DLL.)

Note that if you're using C rather than C++, then it is in fact
possible to simplify this a little, so that you don't need to add all
those FOO_EXTERN symbols to all the declarations in the header files. 
See < http://www.cs.mu.oz.au/~fjh/gnu-win32/how-to-build-dlls.html > for
details.  Note that the stuff there is fairly old; it dates back to
version b18 or thereabouts.  I haven't tested it with more recent versions.

> When building the dll, I need:
> 
>         /* foo.c */
>         #define _COMPILING_FOO_DLL_
>         #include "foo.h"
...
> Which works fine, until I try to build an equivalent static libfoo.a from the
> foo sources on cygwin, when ofcourse I get `undefined __imp_foo' errors =(O|

It's better to pass -D_COMPILING_FOO_DLL_ or -DDEFINE_FOO_DLL
on the command line via make, rather than hard-coding it
in your source file.  That way you can avoid passing it when you
build your static libraries.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: < http://www.cs.mu.oz.au/~fjh >  |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3        |     -- the last words of T. S. Garp.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Making DLL's.

[Gary V. Vaughan]

Thanks for the response.

Fergus Henderson <fjh@cs.mu.OZ.AU> writes:

> On 22-Mar-1999, Gary V. Vaughan <gvaughan@oranda.demon.co.uk> wrote:
> > [[snip]] libtool compounds the problem, because it wants to produce both
> > static and dll libraries for each library object, and thus a given data
> > symbol may be:
> >         1) exported from this object if the object will be part of a dll
> >         4) externed in the tradition way if it will be part of a static lib
> 
> The difference between 1) and 4) is already important on many Unix
> systems, where you need to compile with `-fpic' in case 1),
> but you don't need any special options in case 4).
> So your Makefile ought to already be set up to handle this.
> On Windows, just replace `-fpic' with `-DCOMPILING_FOO_DLL'
> and then use the #ifdefs you mentioned.

Hmmm... well, we already pass -DPIC alongside -fpic, so it may be that
I can simply check for this cpp symbol when compiling the objects for a
dll that has no dependencies.  Now that you have mentioned this, it occurs
to me that since we already take pains not to make a shared library dependant
upon a static archive (is that a legal thing to do with win32? it certainly
fails on many unices), I can intuit that I need to __declspec(dllimport)
any data items which are imported from other libraries which this one
depends on, if PIC is defined (and I am thus building an object for a dll).

> (N.B. You should really use `COMPILING_FOO_DLL' rather than
> `_COMPILING_FOO_DLL_', because according to ISO C and C++,
> the latter is reserved for use by the implementation.)

Good point.  Thanks.

> >         2) imported from another dll
> >         3) imported from a static library
> 
> This distinction is not present in Unix, and yes, it is
> a real pain.  I have avoided it by either always using
> a static library or always using a DLL for any given 
> library.

Yes, that is what we do currently, forcing everything to be statically linked,
and although it works adequately, I would *really* like to offer the same
shared library facilities (within the limits of win32 dlls) that unix has.

> > So, my question is:  do I really have to figure out whether this object is
> > destined to become part of a static library, a dll, or an executable, and
> > which libraries that destination will depend on and whether each of them
> > will be a dll or not in order to produce the correct code for each
> > exported data symbol?
> 
> Basically yes.  And it is a real pain.

I had feared as much.  *sigh*

> But it's not _quite_ as bad as you make out.
> [[snip]]
> 
>          /* foo.h */
>          #if defined(__CYGWIN__) && defined(DEFINE_FOO_DLL)
>          #  define FOO_EXTERN __declspec(dllexport)
>          #elif defined(__CYGWIN__) && defined(USE_FOO_DLL)
>          #  define FOO_EXTERN extern __declspec(dllimport)
>          #else
>          #  define FOO_EXTERN extern
>          #endif
>  
>          FOO_EXTERN int foo;
> 
> (I prefer the name DEFINE_FOO_DLL rather than COMPILING_FOO_DLL.)
> 
> Note that if you're using C rather than C++, then it is in fact
> possible to simplify this a little, so that you don't need to add all
> those FOO_EXTERN symbols to all the declarations in the header files. 
> See < http://www.cs.mu.oz.au/~fjh/gnu-win32/how-to-build-dlls.html > for
> details.  Note that the stuff there is fairly old; it dates back to
> version b18 or thereabouts.  I haven't tested it with more recent versions.

This looks as though it may be exactly what I was looking for, in that I
would really like to be able to take virgin unix sources which already use
libtool (which is what I am working in), and have them automatically do
the right thing with respect to creating a dll on win32 where a shared lib
would have been created in an equivalent build on unix.

In time, that will hopefully mean that as libtool gets wider usage in
the GNU community, projects which use libtool will automatically have
a cygwin port in most cases.

> > When building the dll, I need:
> > 
> >         /* foo.c */
> >         #define _COMPILING_FOO_DLL_
> >         #include "foo.h"
> ...
> > Which works fine, until I try to build an equivalent static libfoo.a from
> > the foo sources on cygwin, when ofcourse I get `undefined __imp_foo'
> > errors =(O| 
> 
> It's better to pass -D_COMPILING_FOO_DLL_ or -DDEFINE_FOO_DLL
> on the command line via make, rather than hard-coding it
> in your source file.  That way you can avoid passing it when you
> build your static libraries.

Thanks, this was of great help to me.

        Gary.
-- 
  ___              _   ___   __              _             
 / __|__ _ _ ___ _| | / / | / /_ _ _  _ __ _| |_  __ _ ___ 
| (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \
 \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/
PGP Key from/___/                      /___/               
http://www.cl.cam.ac.uk/PGP/pks-commands.html#extract      
http://pgp.ai.mit.edu/~bal/pks-commands.html#extract       


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Making DLL's.

[Gary V. Vaughan]

DJ Delorie <dj@delorie.com> writes:

> > Can't anyone out there make "ld -b" produce dll (or may be some .so
> > file, but may be i'm dreaming awaken) so that we can have a real
> > standard way to build shared library ?
> 
> I've already done it, it just hasn't been released with cygwin yet.
> Basically, "ld -shared *.o foo.def -o foo.dll" will work in the new
> version (or gcc -Wl,-shared ...)

First; another answer:

The upcoming libtool release, and to a marginally lesser extent, the most
recent alpha release ( ftp://alpha.gnu.org/pub/gnu/libtool/libtool-1.2f.tar.gz ),
make a pretty decent stab at both building dlls, and linking against them
in a cygwin environment.

Then a question:

The only fly in the ointment for libtool's dll support is handling the export
of data items from a dll.  Specifically, an object that will be linked into
an executable which will in turn be linked with a handful of libraries (some
static and some dll's, for argument's sake) needs to produce different code
depending on what particular combinations of dll and static libraries it will
ultimately be linked with.

That is I need to make sure that any data item that will be imported from a
dll has __attribute__((dllimport)), and any data item imported from a static
library cannot have this attribute.  Obviously, in a makefile driven build
environment there is no easy way to know which combination of libraries this
object will eventually be linked with... is there a way around this problem?
Or do I have to come up with some kind of makefile scanner to figure out
which attributes to attach to each symbol?

Actually, libtool compounds the problem, because it wants to produce both
static and dll libraries for each library object, and thus a given data symbol
may be:
        1) exported from this object if the object will be part of a dll
        2) imported from another dll
        3) imported from a static library
        4) externed in the tradition way if it will be part of a static lib

So, my question is:  do I really have to figure out whether this object is
destined to become part of a static library, a dll, or an executable, and
which libraries that destination will depend on and whether each of them will
be a dll or not in order to produce the correct code for each exported data
symbol?

My (flawed) best solution so far is:

        /* foo.h */
        #ifdef __CYGWIN__
        #  ifdef _COMPILING_FOO_DLL_
        #    define EXTERN __declspec(dllexport)
        #  else
        #    define EXTERN extern __declspec(dllimport)
        #  endif
        #else
        #  define EXTERN extern
        #endif

        EXTERN int foo;

When building the dll, I need:

        /* foo.c */
        #define _COMPILING_FOO_DLL_
        #include "foo.h"

When linking against the dll on cygwin or otherwise:

        /* bar.c */
        #include "foo.h"

Which works fine, until I try to build an equivalent static libfoo.a from the
foo sources on cygwin, when ofcourse I get `undefined __imp_foo' errors =(O|

What now?

Cheers,
        Gary.
-- 
  ___              _   ___   __              _             
 / __|__ _ _ ___ _| | / / | / /_ _ _  _ __ _| |_  __ _ ___ 
| (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \
 \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/
PGP Key from/___/                      /___/               
http://www.cl.cam.ac.uk/PGP/pks-commands.html#extract      
http://pgp.ai.mit.edu/~bal/pks-commands.html#extract       


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com