From ian@cygnus.com Tue Nov 3 23:23 EDT 1998 Received: from grande.dcc.unicamp.br (grande.dcc.unicamp.br [143.106.7.8]) by amazonas.dcc.unicamp.br (8.8.5/8.8.5) with ESMTP id XAA22373 for ; Tue, 3 Nov 1998 23:23:22 -0200 (EDT) Received: from tweedledumb.cygnus.com (tweedledumb.cygnus.com [192.80.44.1]) by grande.dcc.unicamp.br (8.8.5/8.8.5) with ESMTP id XAA20164 for ; Tue, 3 Nov 1998 23:23:18 -0200 (EDT) Received: from subrogation.cygnus.com (subrogation.cygnus.com [192.80.44.76]) by tweedledumb.cygnus.com (8.8.5/8.8.5) with ESMTP id UAA13699; Tue, 3 Nov 1998 20:25:28 -0500 (EST) Received: (ian@localhost) by subrogation.cygnus.com (950413.SGI.8.6.12/8.6.4) id UAA01678; Tue, 3 Nov 1998 20:25:28 -0500 Date: Tue, 3 Nov 1998 20:25:28 -0500 Message-Id: <199811040125.UAA01678@subrogation.cygnus.com> From: Ian Lance Taylor To: gvaughan@oranda.demon.co.uk CC: tanner@gmx.de, oliva@dcc.unicamp.br, gord@trick.fig.org, bug-libtool@gnu.org In-reply-to: <363F3F85.2B31574@oranda.demon.co.uk> (gvaughan@oranda.demon.co.uk) Subject: Re: Inter-library dependencies in libtool Content-Type: text X-Content-Length: 3237 Xref: araguaia.dcc.unicamp.br libtool-cygwin32:2 Lines: 69 X-Gnus-Article-Number: 2 Wed Nov 4 01:39:12 1998 Date: Tue, 03 Nov 1998 17:38:13 +0000 From: "Gary V. Vaughan" It would seem that the dll code has bitrotted =(O| Pity. Ian, do you have time/want to fix this, or do you want to pass the torch on? I no longer have access to a Windows machine, nor do I have all that much interest in the problem, so I'd say that somebody else had better pick up the torch. Incidentally, I believe that DJ Delorie is working on adding DLL support directly to ld, which will mean that dlltool is no longer required, and should make it possible to greatly simplify the win32 hacks in dlltool, perhaps even simply using the standard GNU ld code. Shouldn't libtool notice that it is running on cygwin32 and pass the -no-undefined option by itself? It seems to go against the raison d'etre for libtool to force the Makefile developer to figure this out... This kind of goes to the heart of libtool. libtool wants to present a particular interface for using shared libraries. In order to do this, it assumes that the system supports certain capabilities. One of those is that the system can support undefined symbols in shared libraries. That means that on systems which do not permit shared libraries to have undefined symbols--AIX and Windows--libtool doesn't really work. The --no-undefined option is a hack which tells libtool that the shared library has special characteristics which permit libtool to create a shared library on AIX or Windows, or any other supported platform. I think the general idea is that you should use the --no-undefined option whenever possible. If you do, you will be able to create shared libraries on AIX and Windows. If you do not or can not, you will not be able to create them. libtool should not add a --no-undefined option itself. If it used that option inappropriately, then building the shared library would fail. Instead, libtool users should always use --no-undefined if they can. Of course, there are problems. For example, in the GNU binutils, I can arrange matters such that --no-undefined will work on Windows, but to do so I have to link various libraries together and I have to link against special Windows system libraries. So I do that, which means that I have to change the options I pass to libtool based on the system. In other words, the interface which libtool presents is deficient. It does not successfully hide the system on which it is running, and it forces the code which calls libtool to make adjustments. I doubt there is any wholly acceptable solution here. The only workable one I can see would be to effectively enhance Windows and AIX shared libraries such that they support creating shared libraries with undefined symbols. On Windows, this could be done by doing the link once, checking for undefined symbols, creating little stub routines for those symbols which track down the symbols in some other open DLL, compiling those stubs, and linking them into the DLL. Perhaps something similar is possible on AIX. Of course even that will not make Windows DLLs identical to ELF shared libraries. ELF shared libraries permit the main program to override a symbol in the shared library, and Windows DLLs do not. Ian When libtool links DLLs, it strips some command line switches. It's probably the case that this is ok for most situations. However, this potentially breaks Mingw32 support in the Cygwin environment. In order to get Mingw32 support in Cygwin, the compiler must be invoked with the -mno-cygwin switch. If libtool strips this switch out during the link process, the resulting binary will get linked with the wrong import libraries. The following is a small example. I've edited the output a bit for readability. When I send this email, long lines will get broken up, so it still might be a bit difficult to read. ------------------------- $ libtool --version ltmain.sh (GNU libtool) 1.3.3 (1.385.2.181 1999/07/02 15:49:11) $ cat xx.c extern __declspec(dllexport) int func(void); int func() { } $ libtool --mode=compile gcc -mno-cygwin -c xx.c mkdir .libs gcc -mno-cygwin -c -DPIC xx.c -o .libs/xx.lo mv -f .libs/xx.lo xx.o ln -s xx.o xx.lo $ libtool --mode=link gcc -mno-cygwin -o libxx.la xx.lo \ -version-info 0:0:0 -no-undefined -rpath /usr/local/lib rm -fr .libs/libxx.la .libs/libxx.* .libs/libxx.* generating symbol list for `libxx.la' test -f .libs/libxx-0-0-0.dll-ltdll.c || sed -e "/^# \/\* ltdll\.c starts here \*\//,/^# \/\* ltdll.c ends here \*\// { s/^# //; p; }" -e d < /usr/local/bin/libtool > .libs/libxx-0-0-0.dll-ltdll.c test -f .libs/libxx-0-0-0.dll-ltdll.o || (cd .libs && gcc -c libxx-0-0-0.dll-ltdll.c) dlltool --export-all --exclude-symbols DllMain@12,_cygwin_dll_entry@12,_cygwin_noncygwin_dll_entry@12 --output-def .libs/libxx-0-0-0.dll-def .libs/libxx-0-0-0.dll-ltdll.o xx.o sed -e "1,/EXPORTS/d" -e "s/ @ [0-9]* ; *//" < .libs/libxx-0-0-0.dll-def > .libs/libxx.exp echo EXPORTS > .libs/libxx-0-0-0.dll-def _lt_hint=1; for symbol in `cat .libs/libxx.exp`; do echo " $symbol @ $_lt_hint; " >> .libs/libxx-0-0-0.dll-def; _lt_hint=`expr 1 + $_lt_hint`; done test -f .libs/libxx-0-0-0.dll-ltdll.c || sed -e "/^# \/\* ltdll\.c starts here\*\//,/^# \/\* ltdll.c ends here \*\// { s/^# //; p; }" -e d < /usr/local/bin/libtool > .libs/libxx-0-0-0.dll-ltdll.c test -f .libs/libxx-0-0-0.dll-ltdll.o || (cd .libs && gcc -c libxx-0-0-0.dll-ltdll.c) gcc -Wl,--base-file,.libs/libxx-0-0-0.dll-base -Wl,--dll -nostartfiles -Wl,-e, __cygwin_dll_entry@12 -o .libs/libxx-0-0-0.dll .libs/libxx-0-0-0.dll-ltdll.o xx.o dlltool --as=as --dllname libxx-0-0-0.dll --exclude-symbols DllMain@12,_cygwin_dll_entry@12,_cygwin_noncygwin_dll_entry@12 --def .libs/libxx-0-0-0.dll-def --base-file .libs/libxx-0-0-0.dll-base --output-exp .libs/libxx-0-0-0.dll-exp gcc -Wl,--base-file,.libs/libxx-0-0-0.dll-base .libs/libxx-0-0-0.dll-exp -Wl,--dll -nostartfiles -Wl,-e,__cygwin_dll_entry@12 -o .libs/libxx-0-0-0.dll .libs/libxx-0-0-0.dll-ltdll.o xx.o dlltool --as=as --dllname libxx-0-0-0.dll --exclude-symbols DllMain@12,_cygwin_dll_entry@12,_cygwin_noncygwin_dll_entry@12 --def .libs/libxx-0-0-0.dll-def --base-file .libs/libxx-0-0-0.dll-base --output-exp .libs/libxx-0-0-0.dll-exp gcc .libs/libxx-0-0-0.dll-exp -Wl,--dll -nostartfiles -Wl,-e,__cygwin_dll_entry@12 -o .libs/libxx-0-0-0.dll .libs/libxx-0-0-0.dll-ltdll.o xx.o (cd .libs && rm -f libxx.a && ln -s libxx-0-0-0.dll libxx.a) dlltool --as=as --dllname libxx-0-0-0.dll --def .libs/libxx-0-0-0.dll-def --output-lib .libs/libxx.a creating libxx.la (cd .libs && rm -f libxx.la && ln -s ../libxx.la libxx.la) --------------- Notice how the 'gcc' lines do not contain the -mno-cygwin switch. This switch should not get stripped. Jon Leichter jon@symas.com "Gary V. Vaughan" wrote: > > On Wed, Aug 30, 2000 at 10:51:36AM -0400, Charles Wilson wrote: > > No, it can't. Currently, libtool itself doesn't support *building* > > dlls. > > Ouch. Yes it does. I added support around Christmas 1998, and have > been maintaining it ever since. Thanks for the correction. > > Yes it does. And provided your libraries don't trip over the stupid > dll limitation of "to export a non-function symbol you must edit your > sources", it works easily. Even if you do export data symbols, > libtool woll build and link against a dll for you (even generating an > import lib along the way). > > Unfortunately libtool was developed for Unix and assumes a featureful > shared library architecture, which doesn't map very easily onto win32 > dll's. > > I will be able to simplify the dll build process a little when DJ's > patches to binutils arrive in a cygwin release (did this happen in > 1.1? I have been so busy with m4 that I only upgraded from b20.1 a few > weeks ago). They landed in binutils-20000625, and were finetuned/tweaked to a fairly stable point by binutils-20000722 (the current version in /latest). Also, there were a few additions that changed ld's default search order for libraries: -Bstatic -lfoo : looks for libfoo.a -Bdynamic -lfoo : looks for libfoo.dll.a (default name for an import lib) then foo.dll.a (alt. name for an import lib) then libfoo.dll (link directly to a dll) then foo.dll (ditto, alt. name) finally, libfoo.a (fall back to static lib) The spec file for gcc (as of 2.95.2-2) changed so that: gcc -static calls 'ld -Bstatic' gcc calls 'ld -Bdynamic' Finally, 'gcc -shared' will build a dll, but you need to pass linker options like '-Wl,--out-implib=libfoo.dll.a' explicitly. FWIW, all of the (non-libtool) libraries I've dll-ized do not use dlltool at all, and rely only on gcc (and ld, indirectly). --Chuck -- Want to unsubscribe from this list? Send a message to cygwin-unsubscribe@sourceware.cygnus.com From gary Tue Oct 3 18:51:55 2000 Return-Path: Received: from pop3.mail.demon.net by localhost with POP3 (fetchmail-5.3.4) for gary@localhost (single-drop); Tue, 03 Oct 2000 18:51:55 +0100 (BST) Received: from punt-2.mail.demon.net by mailstore for gvaughan@oranda.demon.co.uk id 970581289:20:22249:24; Tue, 03 Oct 2000 13:54:49 GMT Received: from sourceware.cygnus.com ([205.180.83.71]) by punt-2.mail.demon.net id aa2022220; 3 Oct 2000 13:54 GMT Received: (qmail 29977 invoked by alias); 3 Oct 2000 13:52:38 -0000 Mailing-List: contact cygwin-help@sourceware.cygnus.com; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@sources.redhat.com Delivered-To: mailing list cygwin@sources.redhat.com Received: (qmail 29933 invoked from network); 3 Oct 2000 13:52:34 -0000 Received: from mumnunah.cs.mu.oz.au (203.19.244.130) by sourceware.cygnus.com with SMTP; 3 Oct 2000 13:52:34 -0000 Received: from murlibobo.cs.mu.OZ.AU (murlibobo.cs.mu.OZ.AU [128.250.29.17]) by mumnunah.cs.mu.OZ.AU with ESMTP id AAA23121; Wed, 4 Oct 2000 00:52:14 +1100 (EST) Received: (from fjh@localhost) by murlibobo.cs.mu.OZ.AU (8.8.5/8.7.3) id AAA11289; Wed, 4 Oct 2000 00:52:13 +1100 (EST) Date: Wed, 4 Oct 2000 00:52:13 +1100 From: Fergus Henderson To: "Gary V. Vaughan" , cygwin@sources.redhat.com, cgf@cygnus.com Subject: Re: linking against shared libraries Message-ID: <20001004005212.A9274@murlibobo.cs.mu.OZ.AU> References: <012a01c02033$936effc0$f7c723cb@lifelesswks> <20000917010735.G606@demon.co.uk> <20000916234420.A23827@cygnus.com> <20000917122440.I606@demon.co.uk> <20000917122837.A24997@cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <20000917122837.A24997@cygnus.com>; from Chris Faylor on Sun, Sep 17, 2000 at 12:28:37PM -0400 Status: RO Content-Length: 2625 Lines: 51 On 17-Sep-2000, Chris Faylor wrote: > On Sun, Sep 17, 2000 at 12:24:40PM +0100, Gary V. Vaughan wrote: > >If you are interested, I will add an entry to my TODO list to see if I > >can take some of the nicities from the libtldl LoadLibrary wrapper > >code and apply them to the Cygwin LoadLibrary wrapper? (Automatic `_' > >prefixing for example). > > Is this a characteristic of normal linux/UNIX dlsym? AFAIK, Unix systems that support dlopen() don't prefix C symbol names with `_' when compiling them to assembler in the first place, so the issue is moot. At least this is the case on Solaris (2.7), Linux (>= libc6), and OSF1 (3.2 ), which are the systems that I have easily available right now. dlopen() originated on Solaris, according to the Linux man page. On systems such as Cygwin which do prefix C names with `_' when compiling to assembler, whether dlopen() should prefix the name with an underscore depends on whether the name that the user is trying to look up is an assembly name or a C name. If it's a C name, then it's right for dlopen() to prefix the name with an underscore, to match what the C compiler does, but if it's an assembly name, then doing that would be wrong. Unfortunately the interface to dlopen() provides the dlopen() implementation with no clues as to which one the user meant. The documentation for dlopen() says that the argument is the "symbol name", which is ambiguous, but could be read as implying that it is supposed to be the assembly name. However, in practice most uses of dlopen() tend to be passing C names rather than assembler names. Probably most uses of dlopen() are for C names, and so inserting the prefix would work well in most cases. However, inserting the prefix would also make it impossible to look up assember names that don't start with underscore using dlopen(). It's a bit like the issue of text-versus-binary: the original unix-only interface didn't need to distinguish between the different cases (text/binary or C/asm/whatever), but in the Windows environment, you do need to make such distinctions. So some programs will need source modifications. The best you can do is to choose the default carefully, and make it easy to override the default for programs for which the default is not appropriate. -- Fergus Henderson | "I have always known that the pursuit WWW: | 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 On Sun, Sep 03, 2000 at 01:34:23AM -0400, Charles Wilson wrote: > "Gary V. Vaughan" wrote: > > > > Now, suppose that the png folks release a newer version, say png-2.1.x > > > that exposes some additional features, but is backwards compatible with > > > png-2.0.x. Great. You build it, but create: > > > > > > libpng31.dll.a (embeds the name libpng31.dll.a) > > > libpng.dll.a -> libpng31.dll.a > > > libpng3.dll (replaces the old version (*)) > > > > I don't think we need anything more than > > > > a replacement libpng3.dll > > Not so. Remember, libpng-2.1.x can include additional functions that > were not included by libpng-2.0.x, as long as it includes all of the > 'old' functions/vars without modification. So, you need to update the > import lib as well as the dll, so that new packages that use the > additional functions will work. Oops. I hadn't thought of that. Good point. > > Otherwise we are still in violent agreement. > > I agree. =)O| > > > > Maybe Cygwin should put all of it's libtool built libraries (or any > > > > others that are correctly versioned w.r.t the runtime loader) into a > > > > single directory that is near the front of the default path. /usr/lib > > > > seems like a good place. > > > > > > That's part of my 'easy' solution above. It may fix the cygwin problem, > > > but the requirement is not nice to native apps or other unix-on-win > > > emulations that the user may have. > > > > > > Relying on 'get dll's from same dir as .exe' works -- but only if EVERY > > > cygwin exe and EVERY cygwin dll are piled into the same dir. > > > > Can't we assume that the native dll's we rely on are outside cygwin's > > control and can be relied upon to be managed by the operating system > > (I'm thinking of stuff in the SYSTEM directory), and that non-cygwin > > libraries (such as Pauls pw dlls) will not be installed into the > > cygwin binary search path? In which case I think it is okay to > > install all cygwin dlls and import libs to /usr/lib, making sure that > > cygwin.bat (or any other cygwin startup methods) put /usr/lib first in > > $PATH. > > this works for the 'sandbox user' -- Michael Ring's 'user 1' in this > message: > http://sources.redhat.com/ml/cygwin/2000-08/msg01241.html > > It doesn't work for Michael's 'user 2' -- the guy who normally runs in > cmd.exe/command.com, but relies on cygwin commands every once in a > while. He doesn't use bash, but likes the cygwin-perl or grep every > once and a while. User 2 will have the cygwin directories somewhere in > her path -- but not necessarily first. We could tell these people to put C:/cygwin/usr/bin at the front of their PATH... > > Does cygwin ld use -rpath yet? > > I don't think so. -rpath is something that ld.so uses; Windows doesn't > have ld.so. Windows *always* loads dll's according to the following > search order: > current directory > app's load directory > global executable search path > > The only two exceptions I know of are: > > 1) In Win2K, if there is a file called 'app.exe.local' in the same > directory as app.exe, then all dll's will be loaded from the app's load > directory -- even if explicitly dlopened() with an absolute path that > points elsewhere. the .local. may also override the 'current directory' > part of the search order listed above, but I'm not sure. Holy cr@p! What happened to simplicity? If Bill has decided that he can't understand how to write a decent shared library system, and want's to relegate dll's to LoadLibrary() objects, why doesn't he just say so? Wouldn't it be easier to statically link a Win2k program that twiddle about with all this .local mess? > 2) You can put something called 'AppPath' in the registry, which will > influence the directories that are searched. I don't know where in the > list above that the directories listed in the 'AppPath' key are > inserted. This sounds promising. I'll see if I can find any details on it. > > I am prepared to work on having libtool do the right thing as far > > as possible. > > What was the right thing, again? :-) Based on our conversation so far: * When building a libtool (.la) library, create libfoo.la, libfoo.dll, libfoo.dll.a and libfoo.a, where: - is the earliest fully supported interface number - libfoo.dll.a is the import library for libfoo.dll * When installing a libtool (.la) library: - libfoo.la goes to $prefix/lib - libfoo.dll goes to $prefix/bin - libfoo.dll.a goes to $prefix/lib - libfoo.a goes to $prefix/lib * When linking against libfoo.la - use libfoo.dll.a unless -static or -all-static - otherwise use libfoo.a * When linking against -lfoo - if libfoo.la is found, behave as above - else let ld (or gcc) do its thing Which is especially cool, because I don't think I need to worry about dealing with direct linkage to dlls (I can just punt and let gcc/ld do the hard work) which removes a whole pile of spaghetti where I had to cope with compiling the impgen code correctly in cross compilation environments! > > By default libtool always searches for a dll to link against and > > generates the implib on the fly if a suitable one is found. This won't be necessary under the new scheme =)O| > There are occaisions where you want to link to an import lib in > preference to a dll -- for instance, libcygwin.a is an import lib, but > contains initializer code and actual function implementations for some > functions that are not included in the dll itself. If you attempt to > link directly to cygwin1.dll, the link fails because those things are > missing from the virtual on-the-fly implib. I didn't know about that. Thanks. > But where do you put the dll? It has to go into the executable PATH so > that the windows loader can find it. Do you copy it into /usr/lib, so > that the default ld search path will find it? Do you add /usr/bin to > the linktime library search path (-L/usr/bin)? Perhaps a symlink in > /usr/lib, pointing to /usr/bin/libfoo.dll is all you need. > > However!!! Ld uses the following library name search order when hunting > for -lfoo: > > libfoo.dll.a > foo.dll.a > libfoo.a <<<< NOTE!! > libfoo.dll > foo.dll Or that. Thanks again! Libtool already provides --disable-static if the user wants to build and install only the dll parts of the library. For this to work (that is, in order for me to be able to punt to gcc/ld in the majority of cases) I must generate dll names that will be found, so the cygfoo.dll idea is out (Sorry Paul!). Although this doesn't help ``User 2'' very much, he is no worse off than before if I change libtool's behaviour in this way. Here's a thought: For each dll using application linked, I could have libtool install a .bat script to C:/cygwin/launch (or similar) which would set the PATH environment correctly for that application. As long as ``User 2'' has the launch directory higher in his PATH than the actual binary directory, this would guarantee correct dll selection. This would give ``User 1'' many of the advantages shared libraries offer on Unix, without sinking into DLL Hell. Assuming that everyone buys into it. The only reason shared libraries work properly on Unix is that everyone has to agree to conform to the runtime loader's versioning scheme -- so don't give some excuse about ``if we don't want to change the core cygwin dll's to conform this won't work''. On my linux box, I can move my libc around or drop several incompatible versions of libc into my filesystem, and my applications will stop loading the intended libraries too. No surprises there! Cheers, Gary. -- ___ _ ___ __ _ mailto: gvv@techie.com / __|__ _ _ ___ _| | / / | / /_ _ _ _ __ _| |_ __ _ ___ gary@gnu.org | (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \ \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/ home page: /___/ /___/ gpg public key: http://www.oranda.demon.co.uk http://www.oranda.demon.co.uk/key.asc -- Want to unsubscribe from this list? Send a message to cygwin-unsubscribe@sourceware.cygnus.com On Sun, Sep 03, 2000 at 04:39:51PM -0300, Alexandre Oliva wrote: > On Sep 3, 2000, "Gary V. Vaughan" wrote: > > > * When installing a libtool (.la) library: > > - libfoo.la goes to $prefix/lib > > - libfoo.dll goes to $prefix/bin > > - libfoo.dll.a goes to $prefix/lib > > - libfoo.a goes to $prefix/lib > > Nope. libfoo.la goes wherever -rpath specified when the library was > created; it should be the same directory that is specified at install > time. This is often $(libdir), but it doesn't have to be. > > I don't know how to arrange for an additional directory (bindir) to > be specifiable without introducing an additional command-line option. > Remember, libtool doesn't know about prefix, libdir or bindir, it just > knows about what it's given in the command line. Hmm. I hadn't thought of that. Still, at least the principle of the thing is right now, I think... Cheers, Gary. -- ___ _ ___ __ _ mailto: gvv@techie.com / __|__ _ _ ___ _| | / / | / /_ _ _ _ __ _| |_ __ _ ___ gary@gnu.org | (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \ \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/ home page: /___/ /___/ gpg public key: http://www.oranda.demon.co.uk http://www.oranda.demon.co.uk/key.asc There's an easier way -- one command! 'gcc -shared' will create a dll for you. Just do: $(BASE)=foo gcc -shared -o cyg$(BASE).dll -Wl,--out-implib=lib$(BASE).dll.a \ -Wl,--export-all -Wl,--enable-auto-image-base \ -Wl,--output-def=cyg$(BASE).def $(OBJS) Grab any of the packages in the 'contrib' directory and look an the makefiles (you might need to do a minimal 'configure' first, to customize the Makefile for cygwin before using it as a model) --Chuck Jrgen Schuck wrote: > > I'm not sure about the kind of object that 'gcc -shared' > produces. But I think it won't be what you might expect. > In Windows shared sobjects are DLL's. You probably will > have to convert your Makefiles to cproduce DLL's instead > of UNIX-style .so files. > > I did the same task when porting a TCL-extension from > UNIX to Cygwin. The Makefile (SVR4) changes from > > libTclDM20.so: > ld -G -o $@ $(OBJS) > > to > > LOAD = TclDM20 > DEF = $(LOAD).def > BAS = $(LOAD).base > EXP = $(LOAD).exp > $(DLL): $(OBJS) > echo EXPORTS >$(DEF) > nm $+ | grep '^........ [T] _' | sed 's/[^_]*_//' >>$(DEF) > $(LD) --base-file $(BAS) -dll -o $@ $+ -e _dll_entry@12 \ > -L`dirname \`gcc -print-file-name=libgcc.a\`` \ > $(LIBS) -lgcc -lcygwin -lkernel32 -lgcc > dlltool --as=as -dllname $@ --def $(DEF) \ > --base-file $(BAS) --output-exp $(EXP) > $(LD) --base-file $(BAS) $(EXP) -dll -o $@ $+ -e _dll_entry@12 \ > -L`dirname \`gcc -print-file-name=libgcc.a\`` \ > $(LIBS) -lgcc -lcygwin -lkernel32 -lgcc > dlltool --as=as -dllname $@ --def $(DEF) \ > --base-file $(BAS) --output-exp $(EXP) > $(LD) $(EXP) -dll -o $@ $+ -e _dll_entry@12 \ > -L`dirname \`gcc -print-file-name=libgcc.a\`` \ > $(LIBS) -lgcc -lcygwin -lkernel32 -lgcc > > For further information see > http://sources.redhat.com/cygwin/docs.html, > section "Writing DLLs". Reading these docs you > will find two further modules: dll_init.c and > dll_fixup.c. I didn't put them into my DLL because > the resulting DLL crashes the TCL-interpreter. > > Furthermore I found it very helpful to take a > look into the Makefiles of the DLL-generating > packages of the Cygwin-distribution: tcl, wish > and tix. > > Jrgen Schuck > PCM-Kundenbetreuung > Business Unit Information > _________________________________________________ > MATERNA GmbH Information & Communications > Vosskuhle 37 * 44141 Dortmund > Tel.: 0231 - 5599 - 191 * Fax: -272 > Handy: 0172 - 23 70 148 * http://www.materna.de > > -- > Want to unsubscribe from this list? > Send a message to cygwin-unsubscribe@sourceware.cygnus.com -- Want to unsubscribe from this list? Send a message to cygwin-unsubscribe@sourceware.cygnus.com From gary Tue Oct 10 18:50:22 2000 Return-Path: Received: from pop3.mail.demon.net by localhost with POP3 (fetchmail-5.3.4) for gary@localhost (single-drop); Tue, 10 Oct 2000 18:50:22 +0100 (BST) Received: from punt-2.mail.demon.net by mailstore for gvaughan@oranda.demon.co.uk id 971135226:20:06380:2; Mon, 09 Oct 2000 23:47:06 GMT Received: from sourceware.cygnus.com ([205.180.83.71]) by punt-2.mail.demon.net id aa2005552; 9 Oct 2000 23:46 GMT Received: (qmail 16236 invoked by alias); 9 Oct 2000 23:46:45 -0000 Mailing-List: contact cygwin-help@sourceware.cygnus.com; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@sources.redhat.com Delivered-To: mailing list cygwin@sources.redhat.com Received: (qmail 16211 invoked from network); 9 Oct 2000 23:46:43 -0000 Received: from mail.ee.gatech.edu (130.207.230.10) by sourceware.cygnus.com with SMTP; 9 Oct 2000 23:46:43 -0000 Received: from ece.gatech.edu (s02-pm03.gatech.campuscwix.net [168.14.1.69]) by mail.ee.gatech.edu (8.11.0/8.11.0) with ESMTP id e99NkTO15440; Mon, 9 Oct 2000 19:46:30 -0400 (EDT) Message-ID: <39E259A7.CBAD325F@ece.gatech.edu> Date: Mon, 09 Oct 2000 19:49:59 -0400 From: Charles Wilson X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: cygwin@sourceware.cygnus.com Subject: Re: AW: Linking Dynamic Libraries References: <004501c031f0$10478ad0$0d33028b@zapperlot.materna.de> <39E1CC08.F475851F@ece.gatech.edu> <39E2468B.BFDD3AB7@ihug.co.nz> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO Content-Length: 5252 Lines: 189 You still need to worry about things like __declspec(dllexport) and __declspec(dllimport). Here's a patch for your files. (Yes, you are correct; the option is '--export-all-symbols' not '--export-all') As far as documentation, there's the mailing list, and 'ld --help' and Mumit's (really out-of-date) dll-helpers packaqe at http://www.xraylith.wisc.edu/~khan/software/gnu-win32/dllhelpers.html. Would you like to update that package for the current capabilities of ld/gcc ? Mumit's tutorial is heavily 'dlltool' based, rather than 'gcc -shared' or 'ld' based. NOTE 1: I had to remove "-Wl,--export-all-symbols" from the options; with export-all I got a stack dump even with my other changes. I'm not sure why. NOTE 2: I used the extension '.dll.a' for the import library; cygwin's linker will search for 'libfoo.dll.a' in preference to 'libfoo.a'; libfoo.a is assumed to be a static library (although the linker will use libfoo.a if .dll.a is not found) --Chuck diff -u demo-orig/Makefile demo/Makefile --- demo-orig/Makefile Mon Oct 9 19:34:15 2000 +++ demo/Makefile Mon Oct 9 19:45:10 2000 @@ -3,7 +3,7 @@ EXENAME = demo EXEOBJ = demo.o CPLUS = g++ -W -Wall -Werror -LINKDLL = g++ -shared -Wl,--export-all -Wl,--enable-auto-image-base +LINKDLL = g++ -shared -Wl,--enable-auto-image-base LINKEXE = g++ -L. .DELETE_ON_ERROR: @@ -13,13 +13,16 @@ all: $(DLLNAME).dll $(EXENAME) clean: - rm -f $(DLLOBJ) $(DLLNAME).dll lib$(DLLNAME).a $(EXEOBJ) $(EXENAME).exe + rm -f $(DLLOBJ) $(DLLNAME).dll lib$(DLLNAME).dll.a $(EXEOBJ) $(EXENAME).exe %.o: %.cpp $(CPLUS) -c $< -o $@ +$(DLLOBJ): $(DLLOBJ:.o=.cpp) + $(CPLUS) -DBUILD_DLL -c $< -o $@ + $(DLLNAME).dll: $(DLLOBJ) - $(LINKDLL) $(DLLOBJ) -o $(DLLNAME).dll -Wl,--out-implib=lib$(DLLNAME).a + $(LINKDLL) $(DLLOBJ) -o $(DLLNAME).dll -Wl,--out-implib=lib$(DLLNAME).dll.a $(EXENAME): $(EXEOBJ) $(DLLNAME).dll $(LINKEXE) $(EXEOBJ) -l$(DLLNAME) -o $(EXENAME) diff -u demo-orig/foo.hpp demo/foo.hpp --- demo-orig/foo.hpp Mon Oct 9 19:35:58 2000 +++ demo/foo.hpp Mon Oct 9 19:35:50 2000 @@ -3,7 +3,12 @@ #include -extern std::string global_mangle(const std::string& source); - +#ifdef BUILD_DLL +#define FOO_EXPORT __declspec(dllexport) +#else +#define FOO_EXPORT __declspec(dllimport) #endif +extern FOO_EXPORT std::string global_mangle(const std::string& source); + +#endif Ross Smith wrote: > > "Charles S. Wilson" wrote: > > > > There's an easier way -- one command! 'gcc -shared' will create a dll > > for you. Just do: > > > > $(BASE)=foo > > > > gcc -shared -o cyg$(BASE).dll -Wl,--out-implib=lib$(BASE).dll.a \ > > -Wl,--export-all -Wl,--enable-auto-image-base \ > > -Wl,--output-def=cyg$(BASE).def $(OBJS) > > I can't get this to work. Whenever I link with the import lib produced > this way, the resulting program crashes with a STATUS_ACCESS_VIOLATION. > (See attached code.) I don't even need to call any of the DLL functions > to trigger it -- just linking with -lfoo makes it unworkable. What am I > doing wrong? > > And where is all this stuff documented anyway? The ld docs mention > --export-all-symbols (not --export-all), but not any of the others. > > -------------------- cut here -------------------- > > // demo.cpp > > #include "foo.hpp" > #include > #include > > int main() { > std::string thing("thing"); > std::cout << thing << std::endl; > // std::cout << global_mangle(thing) << std::endl; > return 0; > } > > -------------------- cut here -------------------- > > // foo.hpp > > #ifndef FOO_HEADER > #define FOO_HEADER > > #include > > extern std::string global_mangle(const std::string& source); > > #endif > > -------------------- cut here -------------------- > > // foo.cpp > > #include "foo.hpp" > > std::string global_mangle(const std::string& source) { > return source + "_global"; > } > > -------------------- cut here -------------------- > > // Makefile > > DLLNAME = foo > DLLOBJ = foo.o > EXENAME = demo > EXEOBJ = demo.o > CPLUS = g++ -W -Wall -Werror > LINKDLL = g++ -shared -Wl,--export-all -Wl,--enable-auto-image-base > LINKEXE = g++ -L. > > .DELETE_ON_ERROR: > > .PHONY: all clean > > all: $(DLLNAME).dll $(EXENAME) > > clean: > rm -f $(DLLOBJ) $(DLLNAME).dll lib$(DLLNAME).a $(EXEOBJ) > $(EXENAME).exe > > %.o: %.cpp > $(CPLUS) -c $< -o $@ > > $(DLLNAME).dll: $(DLLOBJ) > $(LINKDLL) $(DLLOBJ) -o $(DLLNAME).dll > -Wl,--out-implib=lib$(DLLNAME).a > > $(EXENAME): $(EXEOBJ) $(DLLNAME).dll > $(LINKEXE) $(EXEOBJ) -l$(DLLNAME) -o $(EXENAME) > > demo.o: demo.cpp foo.hpp > foo.o: foo.cpp foo.hpp > > -------------------- cut here -------------------- > > -- > Ross Smith The Internet Group, Auckland, New Zealand > ======================================================================== > "C++ is to programming as sex is to reproduction. Better ways might > technically exist but they're not nearly as much fun." -- Nikolai Irgens > > -- > Want to unsubscribe from this list? > Send a message to cygwin-unsubscribe@sourceware.cygnus.com -- Want to unsubscribe from this list? Send a message to cygwin-unsubscribe@sourceware.cygnus.com From gary Wed Oct 11 18:38:50 2000 Return-Path: Received: from pop3.mail.demon.net by localhost with POP3 (fetchmail-5.3.4) for gary@localhost (single-drop); Wed, 11 Oct 2000 18:38:50 +0100 (BST) Received: from punt-1.mail.demon.net by mailstore for gvaughan@oranda.demon.co.uk id 971256552:10:18423:4; Wed, 11 Oct 2000 09:29:12 GMT Received: from sourceware.cygnus.com ([205.180.83.71]) by punt-1.mail.demon.net id aa1018296; 11 Oct 2000 9:29 GMT Received: (qmail 10937 invoked by alias); 11 Oct 2000 09:28:33 -0000 Mailing-List: contact cygwin-help@sourceware.cygnus.com; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@sources.redhat.com Delivered-To: mailing list cygwin@sources.redhat.com Received: (qmail 10909 invoked from network); 11 Oct 2000 09:28:30 -0000 Received: from web6405.mail.yahoo.com (128.11.22.153) by sourceware.cygnus.com with SMTP; 11 Oct 2000 09:28:30 -0000 Message-ID: <20001011092829.19377.qmail@web6405.mail.yahoo.com> Received: from [203.97.2.247] by web6405.mail.yahoo.com; Wed, 11 Oct 2000 22:28:29 NZDT Date: Wed, 11 Oct 2000 22:28:29 +1300 (NZDT) From: =?iso-8859-1?q?Danny=20Smith?= Subject: Re: AW: Linking Dynamic Libraries To: cygwin@sources.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Status: RO Content-Length: 1133 Lines: 38 Ross Smith wrote: > > Charles Wilson wrote: > > > > You still need to worry about things like __declspec(dllexport) and > > __declspec(dllimport). > > What's the point of --export-all-symbols then? I was under the > impression that it was intended to duplicate the Unix convention, where > all external symbols are automatically exported from a .so. (Actually, > the help refers to "global" symbols, not "external", but I assumed that > just meant that whoever wrote the help didn't know C++.) If you really want to --export-all in C++, this is a workaround. Create a def with dlltool: dlltool --export-all --output-def foo_.def --dllname foo.dll *.o Then look at the def file. Do you still really want to export-all? To use that def file with ld -shared you need to get rid of the comments (demangled names) cut does the job: cut -d ';' -f 1 foo_.def >foo.def Cheers _____________________________________________________________________________ http://clubs.yahoo.com.au - Yahoo! Clubs - Join a club or build your own! -- Want to unsubscribe from this list? Send a message to cygwin-unsubscribe@sourceware.cygnus.com