Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com Date: Thu, 16 Aug 2001 16:01:03 +0200 Message-Id: <200108161401.f7GE13622815@mailgate3.cinetic.de> MIME-Version: 1.0 Organization: http://freemail.web.de/ From: "Tim Bregulla" To: cygwin AT cygwin DOT com Subject: what I need to build a DLL Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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 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='. If specified, AND linking dynamically, then the dynamic library search order is modified from: current: lib.dll.a .dll.a lib.a lib.dll .dll new: lib.dll.a .dll.a lib.a >>> .dll lib.dll .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" 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 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 Date: Tue, 23 Mar 1999 09:50:31 +1100 On 22-Mar-1999, Gary V. Vaughan 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 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 | "I have always known that the pursuit WWW: | of excellence is a lethal habit" PGP: finger fjh AT 128 DOT 250 DOT 37 DOT 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 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 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 AT goodnet DOT 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 DOT Brun AT cern DOT 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 AT web DOT 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/