This is the mail archive of the
cygwin@cygwin.com
mailing list for the Cygwin project.
what I need to build a DLL
- To: cygwin at cygwin dot com
- Subject: what I need to build a DLL
- From: "Tim Bregulla" <tomtimtam at web dot de>
- Date: Thu, 16 Aug 2001 16:01:03 +0200
- Organization: http://freemail.web.de/
Big Hello
This posting is intended for all people that are very experienced in making
DLLs for Windows under CygWin.
I basically use the CygWin environment to make Win32 executables. This
means that I take little of POSIX and much of MinGW 1.0 . I did include MinGW on my own. And thanks to the mailings from the cygwin archive and all the FAQs I achieved a working -mno-cygwin switch for Cygwin GCC.
My first experience in making DLLs was wxWindows which went fully without harm.
Now I have to compile DLL's by myself since I'm participating in the ROOT
cross platform framework. I am the only person who wants to compile ROOT for
Win32 without the MSVC compiler, and only using Cygwin gcc for that.
I have no doubt that the ROOT framework is totally unfamiliar for many people here.
I just want to know the right compiler or linker strategy and new answers to DLLs.
I think I've touched a hot iron that's been on for a long time .. many found posting
even come from 1998.
Please help me if you know where I'm lost.
Regards
Tom Berg
My research comes to several tools:
dllwrap (much experience)
dlltool (inlcuded into above)
libtool (unknown)
g++ -shared (got linker problems in apps using the DLL)
a2dll (for conversion from .a files to .dll files, not my case)
So far, is g++ -shared fully compatible to dllwrap?
By now the process in ROOT is
-pre-generation of .c and .cxx files
-calculation header dependencies and writing results into .h files
-compilation of .c and .cxx files under a certain platform
-linking the objects to DLLs
-making further software using the DLLs
My problems in translating the Win32 platform for MSVisualC++ to the Win32
platform Cygwin are:
1 not to change or patch the sources, I can only provide a new Makefile
2 replacing cl from MS to dllwrap from GCC
3 keeping the right Defines (-D...) from MSVC for compiler and linker(?)
4 understanding the whole story about .exp, .def and .dll
Points 1 and 3 are done, next comes 4:
(the text continues after the box)
################################################################################
##>>>
http://sources.redhat.com/ml/binutils/2000-10/msg00040.html
Subject: [patch] ld [pei] add --dll-search-prefix option
From: Charles Wilson <cwilson at ece dot gatech dot edu>
Date: Sat, 07 Oct 2000 16:17:24 -0400
In an attempt to minimize dll naming conflicts (AKA 'dll hell') on the
various platforms that coexist simultaneously on Win32, the following
patch adds a new option '--dll-search-prefix=<prefix>'. If
specified, AND linking dynamically, then the dynamic library search
order is modified from:
current: lib<basename>.dll.a
<basename>.dll.a
lib<basename>.a
lib<basename>.dll
<basename>.dll
new: lib<basename>.dll.a
<basename>.dll.a
lib<basename>.a
>>> <prefix><basename>.dll
lib<basename>.dll
<basename>.dll
In this way, the various win32 platforms (cygwin, mingw, pw, uwin, etc)
can modify their spec file to use an appropriate prefix for dlls (e.g.
--dll-search-prefix=cyg for cygwin). This allows dlls to be uniquely
named for each platform, even for identical libraries, but still allows
ld to link directly to the given dll without the use of an import lib
when desired.
See the following thread on the cygwin mailing list (really long):
http://sources.redhat.com/ml/cygwin/2000-08/msg01128.html (DLL naming
conventions)
Also, many of the 'DLL naming conventions' messages were crossposted to
the libtool mailing list, and can be viewed on these three pages:
http://www.geocrawler.com/archives/3/404/2000/9/0
http://www.geocrawler.com/archives/3/404/2000/9/50
http://www.geocrawler.com/archives/3/404/2000/9/100
A related thread on the libtool list begins here: 'RE: libtool'
http://www.geocrawler.com/archives/3/404/2000/9/0/4321378/
--Charles Wilson
================================================================================
http://sources.redhat.com/ml/cygwin/2001-08/msg00159.html
Re: Symbol in DLL begin with _ (was: building Python extension modules)
From: "Peter Bienstman" <Peter dot Bienstman at rug dot ac dot be>
Date: Fri, 3 Aug 2001 16:57:42 +0200
I'm having similar problems, however the suggestions in this thread do not
solve my problems.
I'm trying to build a simple C++ extension module for Python using Boost.
In convert.cpp, the file containing the extension module, there is a macro
which expands to
extern "C" __attribute__(( dllexport )) void initconvert ()
{
...
}
This is the main entry point for the dll, so I assume I do not have to use
the def file approach.
Adapting the mkdll.sh script from this thread, I do the following to create
the dll:
dllwrap -o convert.dll convert.o
/users/pbienst/tmp/boost_cvs/libs/python/src/libboost_python.a -L/usr/lib/py
thon2.1/config -lpython2.1 -lstdc++ -Wl,--kill-at,--enable-stdcall-fixup
This fails because of underscores that are prepended to the symbols in
libboost_python.a and that the linker is unable to resolve.
I've also tried other approaches, like using a def-file, or another approach
which mirrors more closely what distutils is doing:
g++ -shared -Wl,--enable-auto-image-base convert.o
/users/pbienst/tmp/boost_cvs/libs/python/src/*.o -L/usr/lib/python2.1/config
-lpython2.1 -o convert.dll
Same problem...
Any help would be greatly appreciated.
================================================================================
http://sources.redhat.com/ml/cygwin/1999-12/msg00251.html
Re: [GCC BUG] -I switch not functioning correctly.
From: Mumit Khan <khan@NanoTech.Wisc.edu>
Date: Mon, 13 Dec 1999 19:06:54 -0600 (CST)
> I don't know if anyone has noticed that you may not need dllwrap as much
> in the CD release. DJ added functionality to ld which should make it
> a lot easier to build DLLs. Essentially you can say something like:
>
> ld -shared -o foo.dll --export-all-symbols foo.o bar.o
Actually, there's a very good reason why I never brought this up --
it's because the --shared support in v1 ld has certain known problems
that will generate lots of unnecessary bug reports. These problems
have been fixed in the sourceware tree, but v1 was cut before that
point.
================================================================================
http://sources.redhat.com/ml/cygwin/1999-03/msg00665.html
Re: Making DLL's.
From: Fergus Henderson <fjh@cs.mu.OZ.AU>
Date: Tue, 23 Mar 1999 09:50:31 +1100
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.
================================================================================
http://sources.redhat.com/ml/cygwin/1999-03/msg00089.html
How to handle variables (data, etc.) in DLLs?
From: DJ Delorie <dj@delorie.com>
Date: Wed, 3 Mar 1999 11:19:18 -0500
DLLs *can't* export "data". They can only export pointers to data,
which is what they do. In older gccs, you'll need to do something
like this:
extern int *__imp_foo;
#define foo (*__imp_foo)
In newer gccs, do something like this:
extern int foo __attribute__((dllimport));
These tell gcc to dereference the imported pointer, rather than
thinking it's the data itself.
================================================================================
http://sources.redhat.com/ml/cygwin/1999-02/msg00484.html
Re: __attribute__((dllimport)) problems with egcs
From: Mumit Khan <khan@xraylith.wisc.EDU>
Date: Mon, 15 Feb 1999 14:49:55 -0600
Here's a workaround until egcs-1.2.x:
typedef struct __attribute__((dllimport)) _object {
int ob_refcnt; struct _typeobject *ob_type;
} PyObject;
This is also the recommended way, even in MSVC, to tag whole structures
and classes as exported/imported.
This is what I do in headers (replace __IMPORT__ with something that
doesn't violate ANSI namespace):
#if BUILDING_DLL
# define __IMPORT__ __attribute__((dllexport))
#else
# define __IMPORT__ __attribute__((dllimport))
#endif
class __IMPORT__
foo
{
// ...
};
Regards,
Mumit
================================================================================
http://sources.redhat.com/ml/cygwin/1998-04/msg00452.html
Re: DLL's and Objective C
From: jeffdb@goodnet.com
...
to call functions in a dll you can just declare them as usual
to reference data in a dll you must call through the pointer
to the data, NOT the function thunk, like this
char **argc;
in an executable linking to a lib becomes
char **_imp__argc
#define __argc (*_imp__argc)
when linking to a dll
...
================================================================================
The closest information in RootTalk is:
http://root.cern.ch/cgi-bin/print_hit_bold.pl/root/roottalk/roottalk99/1180.html
Re: gDirectory, unresolved external
From: Rene Brun (Rene.Brun@cern.ch)
Date: Wed May 26 1999 - 18:37:28 MEST
...
Hi Chris,
gDirectory is defined in TDirectory.h
R__EXTERN TDirectory *gDirectory;
On NT, R__EXTERN defines a special linkage parameter used to build the
DLL.
I suggest you look an example in $ROOTSYS/test/Event or stress to see
how
a DLL is built on NT.
Rene Brun
chris garcia wrote:
>
> hi rooters!! the last two dll's i have tried to compile have been giving
> me errors on linking, saying:
>
> error LNK2001: unresolved external symbol
> "class TDirectory * gDirectory" (?gDirectory@@3PAVTDirectory@@A)
>
...
##<<<
################################################################################
(.. coming from intro)
With this knowlegde I have been able to make a DLL with classes and methods being
exported. I use
dllwrap --export-all --output-exp $R__LIBEXP --output-def $R__LIBDEF \
--output-lib $R__LIBSTATIC --mno-cygwin --target i386-mingw32 \
--driver-name $R__LD $R__LDFLAGS
where
$R__LIBEXP is a result .exp file
$R__LIBDEF is a result .def file (I did use --def for input too without good)
$R__LIBSTATIC is a result static library that is linked simultaniously
to the DLL ==> #
How does g++ as linker recognise in the on call coming from
dllwrap that 2 differents targets (static and DLL) are to be made at the same
time? This can be the place of all problems.
--mno-cygwin --target i386-mingw32 is the switch to pure Win32 DLLs
$R__LD $R__LDFLAGS is the g++ with all defines
What is strange: the --export-all flag really lets export ALL even
private class methods. Is that ok?
Everything should work if the sources are prepared for that:
That's why there are special macros under MSVC
__declspec( dllimport )
__declspec( dllexport )
Under GCC the two macros are also valid and correspond to the GCC attributes
__attribute__((dllimport));
__attribute__((dllexport));
Usually, the macros are further defined with a special name in a header file:
/* @(#)root/base:$Name: $:$Id: DllImport.h,v 1.1.1.1 2000/05/16 17:00:39 rdm Exp $ */
/*************************************************************************
* Copyright (C) 1995-2000, Rene Brun and Fons Rademakers. *
* All rights reserved. *
* *
* For the licensing terms see $ROOTSYS/LICENSE. *
* For the list of contributors see $ROOTSYS/README/CREDITS. *
*************************************************************************/
/*
This include file defines DllImport/DllExport macro
to build DLLs under Windows OS.
They are defined as dummy for UNIX's
*/
#ifndef ROOT_DllImport
#define ROOT_DllImport
#ifndef __CINT__
#if defined(WIN32)
# define DllImport __declspec( dllimport )
#else
# define DllImport
#endif
#if defined(_DLL)
# define DllExport __declspec( dllexport )
#else
# define DllExport
#endif
# define R__EXTERN DllImport extern
#endif
#endif
Effectively if __CINT__ is not defined and WIN32 and _DLL are defined,
then there are DllImport, DllEXport for methods and functions
and R__EXTERN for global variables resp. variable pointers.
This is what I set as -D flag for g++ in both compiling the DLL objects and
the client app objects using the DLL.
As result the methods and functions are really exported as they are.
And DLLs only having this do work.
The exported (?) variables are delared in the headers with
in TRoot.h as:
...
R__EXTERN TROOT *gROOT;
...
in TVirtualX.h as:
...
R__EXTERN TVirtualX *gVirtualX;
R__EXTERN TVirtualX *gGXBatch;
...
in other files ...
They are declared again in the belonging .cxx files
in TRoot.cxx as:
...
TROOT *gROOT; // The ROOT of EVERYTHING
...
You can see why there is extern used in the headers, it is an external reference to
the variables in the .cxx files. That is a nice trick.
However, variables cause errors in dllwrap and linker in calls like this:
... coming from compilation ...
gcc -mno-cygwin -DG__ANSI -O2 -DWIN32 --pipe -include /usr/include/mingw/ctype.h
-idirafter /usr/include/w32api -D_DLL -D_MSC_VER -Iinclude -o clib/src/strtok.o -c
clib/src/strtok.c
g++ -mno-cygwin -DG__ANSI -O2 -DWIN32 --pipe -fvtable-thunks
-include /usr/include/mingw/ctype.h -idirafter /usr/include/w32api -D_DLL -D_MSC_VER
-Iinclude -I. -o base/src/G__Base1.o -c base/src/G__Base1.cxx
...
clear to see: the defines WIN32 and _DLL which are needed in DLLImport.h
...
dllwrap --export-all --output-exp lib/libCore.exp --output-def lib/libCore.def
--output-lib lib/libCore.a --mno-cygwin --target i386-mingw32 --driver-name
/bin/g++ -L/usr/root//lib -mno-cygwin -DG__ANSI -O2 -DWIN32 -DLL -o bin/libCore.dll
base/src/InitGui.o base/src/Match.o base/src/Stringio.o base/src/TApplication.o
base/src/TApplicationImp.o base/src/TAtt3D.o base/src/TAttAxis.o
base/src/TAttFill.o base/src/TAttLine.o base/src/TAttMarker.o base/src/TAttPad.o
base/src/TAttText.o base/src/TBenchmark.o base/src/TBrowser.o
base/src/TBrowserImp.o base/src/TBuffer.o base/src/TCanvasImp.o base/src/TColor.o
base/src/TContextMenu.o base/src/TContextMenuImp.o base/src/TControlBarImp.o
base/src/TDatime.o base/src/TDirectory.o base/src/TEnv.o base/src/TError.o
base/src/TException.o base/src/TExec.o base/src/TFile.o base/src/TFolder.o
base/src/TFree.o base/src/TGuiFactory.o base/src/TInspectorImp.o base/src/TKey.o
base/src/TKeyMapFile.o base/src/TMapFile.o base/src/TMath.o base/src/TMemberInspector.o
base/src/TMessageHandler.o base/src/TNamed.o base/src/TObjPtr.o base/src/TObjString.o
base/src/TObject.o base/src/TPadView3D.o base/src/TQConnection.o base/src/TQObject.o
base/src/TROOT.o base/src/TRandom.o base/src/TRandom2.o base/src/TRandom3.o
base/src/TRealData.o base/src/TRefCnt.o base/src/TRegexp.o base/src/TStopwatch.o
base/src/TStorage.o base/src/TString.o base/src/TStringLong.o base/src/TStyle.o
base/src/TSysEvtHandler.o base/src/TSystem.o base/src/TSystemDirectory.o
base/src/TSystemFile.o base/src/TTask.o base/src/TTime.o base/src/TTimer.o
base/src/TView.o base/src/TVirtualFitter.o base/src/TVirtualGL.o base/src/TVirtualPS.o
base/src/TVirtualPad.o base/src/TVirtualX.o cont/src/TArray.o cont/src/TArrayC.o
cont/src/TArrayD.o cont/src/TArrayF.o cont/src/TArrayI.o cont/src/TArrayL.o
cont/src/TArrayS.o cont/src/TBits.o cont/src/TBtree.o cont/src/TClassTable.o
cont/src/TClonesArray.o cont/src/TCollection.o cont/src/TExMap.o cont/src/THashList.o
cont/src/THashTable.o cont/src/TIterator.o cont/src/TList.o cont/src/TMap.o
cont/src/TObjArray.o cont/src/TObjectTable.o cont/src/TOrdCollection.o
cont/src/TSeqCollection.o cont/src/TSortedList.o meta/src/TBaseClass.o meta/src/TCint.o
meta/src/TClass.o meta/src/TDataMember.o meta/src/TDataType.o meta/src/TDictionary.o
meta/src/TFunction.o meta/src/TGlobal.o meta/src/TInterpreter.o meta/src/TMethod.o
meta/src/TMethodArg.o meta/src/TMethodCall.o meta/src/TStreamerElement.o
meta/src/TStreamerInfo.o meta/src/TToggle.o meta/src/TToggleGroup.o
net/src/TAuthenticate.o net/src/TCache.o net/src/TFTP.o net/src/TInetAddress.o
net/src/TMessage.o net/src/TMonitor.o net/src/TNetFile.o net/src/TPServerSocket.o
net/src/TPSocket.o net/src/TSQLResult.o net/src/TSQLRow.o net/src/TSQLServer.o
net/src/TServerSocket.o net/src/TSocket.o net/src/TUrl.o net/src/TWebFile.o
winnt/src/TGWin32Command.o winnt/src/TWin32HookViaThread.o winnt/src/TWin32Timer.o
winnt/src/TWinNTInput.o winnt/src/TWinNTSystem.o zip/src/Bits.o zip/src/Deflate.o
zip/src/Inflate.o zip/src/Trees.o clib/src/Demangle.o clib/src/Getline.o
clib/src/attach.o clib/src/detach.o clib/src/getpagesize.o clib/src/keys.o
clib/src/mcalloc.o clib/src/mfree.o clib/src/mmalloc.o clib/src/mmapsup.o
clib/src/mmcheck.o clib/src/mmemalign.o clib/src/mmstats.o clib/src/mmtrace.o
clib/src/mrealloc.o clib/src/mvalloc.o clib/src/sbrksup.o clib/src/snprintf.o
clib/src/strtod.o clib/src/strtok.o base/src/G__Base1.o base/src/G__Base2.o
base/src/G__Base3.o cont/src/G__Cont.o meta/src/G__Meta.o net/src/G__Net.o
winnt/src/G__WinNT.o clib/src/G__Clib.o lib/libCint.a -lgdi32 -lcomdlg32 -luser32
-lkernel32 -ladvapi32 -lshell32 -lcomctl32 -lwsock32
base/src/TApplication.o(.text+0x719):TApplication.cxx: undefined reference to `_imp__gROOT'
base/src/TApplication.o(.text+0x738):TApplication.cxx: undefined reference to `_imp__gSystem'
base/src/TApplication.o(.text+0x765):TApplication.cxx: undefined reference to `_imp__gROOT'
base/src/TApplication.o(.text+0x770):TApplication.cxx: undefined reference to `_imp__gROOT'
base/src/TApplication.o(.text+0x83a):TApplication.cxx: undefined reference to `_imp__gSystem'
base/src/TApplication.o(.text+0x885):TApplication.cxx: undefined reference to `_imp__gGuiFactory'
base/src/TApplication.o(.text+0x8d9):TApplication.cxx: undefined reference to `_imp__gEnv'
The file TApplication.o belongs to the objects passed to dllwrap. The undefined
references are the global variables come from such DLL objects too.
Do the _imp prefixes mean anything important for me?
In MSVC there would be a similar messages like
"Re: gDirectory, unresolved external"
This situation is for me that the linker expects a library with references to variables
that is not there. I made the wrong static library or the wrong DLL or the .def and .exp
files are wrong!?
This is from a working DLL demo outside of ROOT. It is from Mumit Khan, this header is used in
both the DLL sources and the app sources:
#ifndef dllclass_h_included
#define dllclass_h_included
#if __GNUC__ && ! defined (__declspec)
# error This example needs newer egcs 1.1 or newer. Sorry.
#endif
#if BUILDING_DLL
# define DLLIMPORT __declspec (dllexport)
#else /* Not BUILDING_DLL */
# define DLLIMPORT __declspec (dllimport)
#endif /* Not BUILDING_DLL */
struct DLLIMPORT
DllClassBase {
virtual int virtual_method () const;
};
class DLLIMPORT
DllClass : public DllClassBase {
public:
DllClass (int i = 0);
~DllClass ();
int non_virtual_method () const;
virtual int virtual_method () const;
#ifdef __GNUC__
DLLIMPORT // work around an egcs-1.1 bug
#endif
static int instances;
private:
int i_;
};
#endif /* dllclass_h_included */
You can see another,easier strategy here, just one define BUILDING_DLL controls how
the exports/imports are made. This demo was easy to make for me ...
New is that the flag DLLIMPORT also comes before classes. This technique was
recommended in some mailings .. sorry, ROOT does not use it too.
And I cannot change it thanks to point 1.
This questions remains:
How did you solve a linker problem for global variables in DLLs and .a files under
Cygwin?
################################################################################
PS:
the script called from make
#! /bin/sh
# Script to generate a shared library (DLL) on Win32 for VC++.
# Called by main Makefile.
#
# Author: Fons Rademakers, 29/2/2000
# modified by me am 5.8.2001
# there is no make dependancy between the .def, the .dll and the needed .a files
# my new variables
R__PLATFORM=$1
R__LD="/bin/g++"
R__LDFLAGS=$3
R__SOFLAGS=$4
R__SONAME=$5
R__LIB=$6
R__OBJS=$7
R__EXTRA=$8
name=`basename $R__LIB .dll`
R__LIBSTATIC=lib/${name}.a
R__LIBDEF=lib/${name}.def
R__LIBEXP=lib/${name}.exp
R__LIBDEFB=lib/${name}b.def
R__LIBNAME=${name}.dll
R__LDFLAGS="--export-all --output-exp $R__LIBEXP --output-def $R__LIBDEF --output-lib $R__LIBSTATIC --mno-cygwin --target i386-mingw32 --driver-name $R__LD $R__LDFLAGS"
lastsyslib=-lcomctl32
extralibs=$lastsyslib
syslibs="-lgdi32 -lcomdlg32 -luser32 -lkernel32 -ladvapi32 -lshell32 $extralibs"
userlibs=lib/*.a
# bindexp is a tool to build the to be used .def from the objects, the result is
bindexp=bin/bindexplib
if [ "$R__PLATFORM" = "win32" ]; then
echo "$bindexp -o $R__LIBDEFB $name $R__OBJS"
$bindexp -o $R__LIBDEFB $name $R__OBJS
grep -v "LIBRARY lib" $R__LIBDEFB > lib/tmp.def
grep -v "EXETYPE WINDOWS" lib/tmp.def > $R__LIBDEFB
if [ "$R__LIBNAME" = "libCint.dll" ]; then
echo dllwrap $R__LDFLAGS $R__SOFLAGS -o bin/${name}.dll \
$R__OBJS $R__EXTRA $syslibs
dllwrap $R__LDFLAGS $R__SOFLAGS -o bin/${name}.dll \
$R__OBJS $R__EXTRA $syslibs
elif [ "$R__LIBNAME" = "libCore.dll" ]; then
echo dllwrap $R__LDFLAGS $R__SOFLAGS -o bin/${name}.dll \
$R__OBJS $R__EXTRA lib/libCint.a $syslibs -lwsock32
dllwrap $R__LDFLAGS $R__SOFLAGS -o bin/${name}.dll \
$R__OBJS $R__EXTRA lib/libCint.a $syslibs -lwsock32
else
echo dllwrap $R__LDFLAGS $R__SOFLAGS -o bin/${name}.dll \
$R__OBJS $R__EXTRA lib/libCore.a lib/libCint.a \
$syslibs
dllwrap $R__LDFLAGS $R__SOFLAGS -o bin/${name}.dll \
$R__OBJS $R__EXTRA lib/libCore.a lib/libCint.a \
$syslibs
fi
fi
linkstat=$?
if [ $linkstat -ne 0 ]; then
exit $linkstat
fi
# dummy dll (real one in in bin/) to prevent rebuilds of the dll
touch $R__LIB
echo "==> $R__LIB done"
exit 0
_______________________________________________________________________
1.000.000 DM gewinnen - kostenlos tippen - http://millionenklick.web.de
IhrName@web.de, 8MB Speicher, Verschluesselung - http://freemail.web.de
--
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/