This is the mail archive of the firstname.lastname@example.org
mailing list for the Cygwin project. See the Cygwin
home page for more information.
[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index] [Subject Index] [Author Index] [Thread Index]
Re: Making DLL's.
- To: DJ Delorie <email@example.com>
- Subject: Re: Making DLL's.
- From: firstname.lastname@example.org (Gary V. Vaughan)
- Date: 22 Mar 1999 10:31:32 +0000
- Cc: email@example.com, firstname.lastname@example.org
- Delivered-To: email@example.com
- Delivered-To: mailing list firstname.lastname@example.org
- In-Reply-To: DJ Delorie's message of "Fri, 19 Mar 1999 10:30:55 -0500"
- Mailing-List: contact email@example.com; run by ezmlm
- References: <firstname.lastname@example.org> <email@example.com> <36F258AB.CC1A1788@atos-group.com> <199903191530.KAA01054@envy.delorie.com>
- Sender: firstname.lastname@example.org
- User-Agent: Gnus/5.070079 (Pterodactyl Gnus v0.79) Emacs/20.3
DJ Delorie <email@example.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
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
My (flawed) best solution so far is:
/* foo.h */
# ifdef _COMPILING_FOO_DLL_
# define EXTERN __declspec(dllexport)
# define EXTERN extern __declspec(dllimport)
# define EXTERN extern
EXTERN int foo;
When building the dll, I need:
/* foo.c */
When linking against the dll on cygwin or otherwise:
/* bar.c */
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|
___ _ ___ __ _
/ __|__ _ _ ___ _| | / / | / /_ _ _ _ __ _| |_ __ _ ___
| (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \
\___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/
PGP Key from/___/ /___/
Want to unsubscribe from this list?
Send a message to firstname.lastname@example.org