Re: removing rpath from libtool
Hello Michel, * BRIAND, Michel M wrote on Tue, Oct 30, 2007 at 05:22:02PM CET: > > I would like to know why LD_LIBRARY_PATH is evil. > > Because, here, we have several thousand of applications (!) installed on > NFS shares that have each : > - a bin directory > - a lib directory > ... > - an environment file that set up PATH and LD_LIBRARY_PATH and an alias > for users to access/use the application. You just answered your own question, at least partly: if you have thousands of lib directories listed in LD_LIBRARY_PATH, then each and every exec of a non-statically-linked program will on average cause thousands of needless file lookups; just try for example LD_LIBRARY_PATH=/foo1:/foo2:/foo3 strace /bin/ls 2>&1 | grep foo (on GNU/Linux). That just trashes performance, more so if all lookups happen on NFS shares. There were lots more arguments listed in this thread, and the documents that were cited. It's not that LD_LIBRARY_PATH isn't helpful at times, but it has definite drawbacks. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: HP-UX shared lib detection (1.5.24)
Hi Ralf, Ok, I tried out the 2 recommendations : >Still, please try either (both) of > ./configure CC="cc +DA2.0W" > ./configure --host=hppa64-hp-hpux11.11 ... Using --host produced messages to the effect --build should be used unless doing a cross compile. I tried both, and both were successful, but --build didn't produce the --host warning. The CC="cc +DA2.0W" did NOT work, producing the same libtool error I reported earlier. So now the HPUX 64 build configure amounts to this: ./configure \ --build=hppa64-hp-hpux11.11 \ --prefix=$HOME/local \ --disable-static \ CPPFLAGS=-I$HOME/local/include \ LDFLAGS=-L$HOME/local/lib \ CPP="cc -E" \ CFLAGS="+DA2.0W" \ CC=cc I have to keep the CFLAGS="+DA2.0W" there otherwise the configure script will choke with: configure:2435: checking for C compiler default output file name configure:2438: cc -I/home/proghome/wgay/local/include -L/home/proghome/wgay/local/lib conftest.c >&5 /usr/ccs/bin/ld: /usr/lib/pa20_64/libc.sl: Mismatched ABI. 64-bit PA shared library found in 32-bit link. * Roger While wrote on Wed, Oct 31, 2007 at 08:13:45PM CET: > host='hppa2.0w-hp-hpux11.11' > host_alias='' > host_cpu='hppa2.0w' > host_os='hpux11.11' > > It's being passed +DA2.0W not +DD64 as documented by HP > for PA. > > AFAIK, DD64 was meant for IA64. Ah, ok I was looking at older documentation that listed +DD64 as "currently equivalent to +DA2.0W." Still, please try either (both) of ./configure CC="cc +DA2.0W" ./configure --host=hppa64-hp-hpux11.11 ... and report which helps to build the application correctly (both should). If either one fails, please send for it the output of ./libtool --config Thanks, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Windows DLLs from Unix with minimum effort
Jason Curl wrote: Brian Dessent wrote: Jason Curl wrote: ./configure CC="gcc -mno-cygwin" LDFLAGS="-Wl,--kill-at" --target=i586-pc-mingw32 --disable-static on Cygwin to generate the Windows DLL Target is not the right thing to use here. Target only has meaning in the context of building tools that themselves generate code, such as compilers, linkers, assemblers, etc. If you want to simply indicate that you are cross-compiling a library for a host different than the current one then you use --host. Also, if you're going to use Cygwin as a "Fake mingw" then you probably also should use --build=mingw as well. Thanks - all of my initial problems. My test code now compiles and links with the DLL. However, when I move the test program out into another folder and copy the DLL into the Windows System path, it doesn't execute. I haven't figured out how to run it without the "libtool" wrapper. When I observe the dependencies using Microsoft tools, I see there are none other than my library and MS libraries (e.g. Cygwin is not there). The library works correctly when I use say, Visual Basic 6. Please, could you prepare sample test case. I cannot reproduce described issue. I have also another subdirectory that tests the library but I can't link to it using mingw. First it doesn't recognise that the name was simplified (it looks for [EMAIL PROTECTED] for example instead of _my_func/my_func). You need to understand that the --kill-at is a linker option. It cannot change behavior of the compiler, and when gcc is told to use the stdcall calling convention for a function, it includes the normal stdcall decorations on the symbol. There is no way to change this AFAIK, unless you use __attribute__((alias)) or something. Ooh sounds horrible. So if you want to use these symbols without the stdcall decoration, then you have to get the linker to jump throuh hoops. --kill-at removes them from names that are exported, but that still doesn't change the fact that the compiler emits calls to the decorated names. For that you will have to use --enable-stdcall-fixup, which will link calls to [EMAIL PROTECTED] to _foo if there is no [EMAIL PROTECTED] found anywhere. Or, you could create an import library and link with that. But instead of all of that I think I would just simply use --add-stdcall-alias. This should result in both a decorated and undecorated alias of each symbol being exported, so you don't have to try to pretend that gcc isn't emitting calls to decorated names when it really is. I can probably live with that solution, I might look how to use export/import library definitions as it would also mean defining precisely the ordinals in the Windows DLLs. I'll take a deeper look at Erik's suggestion, it looks simple enough except I'm not entirely happy with the DEF file generation he uses. You could pass "def" file to the linker as example: http://svn.gnome.org/viewvc/xmlsec/trunk/configure.in?r1=982&r2=983 Roumen ___ http://lists.gnu.org/mailman/listinfo/libtool
RE: Re: HP-UX shared lib detection (1.5.24)
Hi Warren, Which exactly solves the prob? I think the --build but ? However why should this not be ato-determined? 2.0W is always 64-bit. Roger Hi Roger: I forgot to mention that +DA2.0W and +DD64 are treated as equivalent on our platform. Warren. -Original Message- From: Roger While [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 31, 2007 4:54 PM To: Gay, Warren Cc: [EMAIL PROTECTED] Subject: Fwd: Re: HP-UX shared lib detection (1.5.24) Hi Warren, Some more from libtool list - Can you try as suggested at the bottom. Roger >Date: Wed, 31 Oct 2007 20:25:30 +0100 >From: Ralf Wildenhues <[EMAIL PROTECTED]> >To: Roger While <[EMAIL PROTECTED]> >Cc: libtool@gnu.org >Subject: Re: HP-UX shared lib detection (1.5.24) >Mail-Followup-To: Roger While <[EMAIL PROTECTED]>, libtool@gnu.org >Organization: Department of Numerical Simulation, University of Bonn >User-Agent: Mutt/1.5.13 (2006-08-11) >X-Spam: [F=0.3685210354; heur=0.500(-16300); stat=0.368; >spamtraq-heur=0.500(2007101727)] >X-MAIL-FROM: <[EMAIL PROTECTED]> >X-SOURCE-IP: [131.220.223.13] >X-SF-Loop: 1 >X-SIMBasis-MailScanner-Information: Please contact the ISP for more >information >X-SIMBasis-MailScanner: Found to be clean >X-SIMBasis-MailScanner-SpamCheck: not spam, SpamAssassin (score=-2.599, > required 5, autolearn=not spam, BAYES_00 -2.60) >X-SIMBasis-MailScanner-From: [EMAIL PROTECTED] > >* Roger While wrote on Wed, Oct 31, 2007 at 08:13:45PM CET: > > host='hppa2.0w-hp-hpux11.11' > > host_alias='' > > host_cpu='hppa2.0w' > > host_os='hpux11.11' > > > > It's being passed +DA2.0W not +DD64 as documented by HP > > for PA. > > > > AFAIK, DD64 was meant for IA64. > >Ah, ok I was looking at older documentation that listed +DD64 as >"currently equivalent to +DA2.0W." > >Still, please try either (both) of > ./configure CC="cc +DA2.0W" > ./configure --host=hppa64-hp-hpux11.11 ... > >and report which helps to build the application correctly (both should). >If either one fails, please send for it the output of > ./libtool --config > >Thanks, >Ralf This e-mail and any attachments may contain confidential information. Any distributing, copying or reliance upon the contents of this e-mail by anyone other than the intended recipient is strictly prohibited. If you have received this e-mail accidentally, please delete it and notify the sender. Although this message has been screened for viruses, we cannot guarantee that our virus scanner will detect all viruses and take no responsibility for any damage or loss that may be caused by its contents. Ce courriel et toutes les pièces jointes peuvent contenir des renseignements confidentiels dont la diffusion, reproduction ou utilisation par quiconque autre que le destinataire est interdite. S'il vous a été transmis par erreur, veuillez en informer l'expéditeur et le supprimer. Ce courriel a été vérifié avec un logiciel de détection de virus mais nous ne pouvons pas garantir qu'il détecte tous les virus et déclinons toute responsabilité quant aux dommages ou pertes découlant de son contenu. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Windows DLLs from Unix with minimum effort
Roumen Petrov wrote: Jason Curl wrote: Brian Dessent wrote: Jason Curl wrote: ./configure CC="gcc -mno-cygwin" LDFLAGS="-Wl,--kill-at" --target=i586-pc-mingw32 --disable-static on Cygwin to generate the Windows DLL Target is not the right thing to use here. Target only has meaning in the context of building tools that themselves generate code, such as compilers, linkers, assemblers, etc. If you want to simply indicate that you are cross-compiling a library for a host different than the current one then you use --host. Also, if you're going to use Cygwin as a "Fake mingw" then you probably also should use --build=mingw as well. Thanks - all of my initial problems. My test code now compiles and links with the DLL. However, when I move the test program out into another folder and copy the DLL into the Windows System path, it doesn't execute. I haven't figured out how to run it without the "libtool" wrapper. When I observe the dependencies using Microsoft tools, I see there are none other than my library and MS libraries (e.g. Cygwin is not there). The library works correctly when I use say, Visual Basic 6. Please, could you prepare sample test case. I cannot reproduce described issue. Well, I think I've figured it out today (albeit I'm testing on a different machine, similar software though) and there are two executables. One in the build directory and one in .libs. e.g. src/ .libs/ libmofo-1.dll test/ libtest.exe <-- Doesn't seem to work? No idea what this is... libtest .libs/ libtest.exe<-- Will work when "libmofo-1.dll" is in the path, e.g. copied to this dir. Can anybody explain what libtool is doing?? It appears to do a lot of nifty stuff, but I don't see any dependencies on "libmofo" from "libtest.exe" in either case. I'll attach a minimal example when I'm back at work tomorrow. And the directory it runs from (.libs) indicates it is actually the source "lt-libtest.c" that relies on a shell, so as soon as I move the executable to a "virgin" computer without Cygwin, the program "libtest.exe" won't work. I have also another subdirectory that tests the library but I can't link to it using mingw. First it doesn't recognise that the name was simplified (it looks for [EMAIL PROTECTED] for example instead of _my_func/my_func). You need to understand that the --kill-at is a linker option. It cannot change behavior of the compiler, and when gcc is told to use the stdcall calling convention for a function, it includes the normal stdcall decorations on the symbol. There is no way to change this AFAIK, unless you use __attribute__((alias)) or something. Ooh sounds horrible. So if you want to use these symbols without the stdcall decoration, then you have to get the linker to jump throuh hoops. --kill-at removes them from names that are exported, but that still doesn't change the fact that the compiler emits calls to the decorated names. For that you will have to use --enable-stdcall-fixup, which will link calls to [EMAIL PROTECTED] to _foo if there is no [EMAIL PROTECTED] found anywhere. Or, you could create an import library and link with that. But instead of all of that I think I would just simply use --add-stdcall-alias. This should result in both a decorated and undecorated alias of each symbol being exported, so you don't have to try to pretend that gcc isn't emitting calls to decorated names when it really is. I can probably live with that solution, I might look how to use export/import library definitions as it would also mean defining precisely the ordinals in the Windows DLLs. I'll take a deeper look at Erik's suggestion, it looks simple enough except I'm not entirely happy with the DEF file generation he uses. You could pass "def" file to the linker as example: http://svn.gnome.org/viewvc/xmlsec/trunk/configure.in?r1=982&r2=983 Roumen Cool, sounds like something that Erik mentioned earlier in "libsndfile.dll" that I'll look into. I'd also like to generate .lib files (what is the .a file that is generated anyway? Is that the .lib import library?) Thanks, Jason. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Windows DLLs from Unix with minimum effort
Jason Curl wrote: > libtest.exe <-- Doesn't seem to work? No idea >what this is... > libtest > .libs/ > libtest.exe<-- Will work when "libmofo-1.dll" >is in the path, e.g. copied to >this dir. > > Can anybody explain what libtool is doing?? It appears to do a lot of > nifty stuff, but I don't see any dependencies on "libmofo" from > "libtest.exe" in either case. I'll attach a minimal example when I'm > back at work tomorrow. It is a wrapper to allow running the uninstalled binary in the build tree without having to mess with PATH or LD_LIBRARY_PATH or whatever. On a POSIX system this would be a shell script. I think that in libtool HEAD, it won't have such a confusing name. > And the directory it runs from (.libs) indicates it is actually the > source "lt-libtest.c" that relies on a shell, so as soon as I move the > executable to a "virgin" computer without Cygwin, the program > "libtest.exe" won't work. You shouldn't be manually mucking about like that, you use "make install" to get an installed copy and that will not be a wrapper. If you configured with CC="gcc -mno-cygwin" (i.e. used this "fake mingw" setup) then the Cygwin dependence should only be for the wrapper which isn't supposed to be installed or even moved out of the build directory for that matter. > I'd also like to generate .lib files (what is the .a file that is > generated anyway? Is that the .lib import library?) An import library can be named foo.lib, libfoo.a, or libfoo.dll.a; they are all the exact same thing just named differently. Don't confuse the libfoo.a name with a static library which has the same style name but is a totally different thing (and that's why it's considered deprecated to name an import library libfoo.a, but some are still done that way, e.g. all of w32api.) Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Moving .la files
I am experimenting a lot on my system. For example i compile pango into /usr prefix. Then i delete it, and compile pango anew into another prefix. The problem is, if i then i.e. compile gimp, gimp "thinks" that pango is still at that old place, even though it is at some other place now does anyone of you know a) why b) how to resolve on this? The real problem is that right now, gimp will stop to compile throwing an error due to the .la file no longer there, and it seems as if the locations of .la files are somewhere cached or hardcoded, and i dont know where. = Master in Business Administration Degree Fully accredited MBA programs in Paris, New York, Shanghai, and Tokyo. ISM's e-learning and direct MBA, DBA and Phd courses have high academic standards and flexible course curriculum. http://a8-asy.a8ww.net/a8-ads/adftrclick?redirectid=fbb1d6131ab95705b66cde3b29b4e59e -- Powered by Outblaze ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Moving .la files
On Nov 2, 2007, at 12:02 AM, Roebe XXX wrote: I am experimenting a lot on my system. For example i compile pango into /usr prefix. Then i delete it, and compile pango anew into another prefix. The problem is, if i then i.e. compile gimp, gimp "thinks" that pango is still at that old place, even though it is at some other place now does anyone of you know a) why b) how to resolve on this? The real problem is that right now, gimp will stop to compile throwing an error due to the .la file no longer there, and it seems as if the locations of .la files are somewhere cached or hardcoded, and i dont know where. Hi, the .la files are not relocatable out of the box. When you compile The Gimp, it will probably link with many libraries, some of which were linked against pango when it was still installed under /usr. In this case, these libraries will have dead references in their own .la files. Libtool has this very nifty feature that it will automagically link against dependent libraries of the libraries you use (which is normally automatically done by modern linkers on modern OSes, but since it's not portable, we can't rely on this, and Libtool does it for you). So basically, when you link against `libfoo' and there is a `libfoo.la', libtool will read it to find out what are the dependencies of `libfoo' and add them recursively to the linking command. In your case, you're probably using libraries whose .la files are still referencing pango from under /usr/lib, hence the problem (that's just an educated guess, there can be other reasons, of course). I hope I managed to make this clear :P Cheers, -- Benoit Sigoure aka Tsuna EPITA Research and Development Laboratory PGP.sig Description: This is a digitally signed message part ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Windows DLLs from Unix with minimum effort
> > > libtest.exe <-- Doesn't seem to work? No idea > >what this is... > > libtest > > .libs/ > > libtest.exe<-- Will work when "libmofo-1.dll" > >is in the path, e.g. copied to > >this dir. > > > > Can anybody explain what libtool is doing?? It appears to do a lot of > > nifty stuff, but I don't see any dependencies on "libmofo" from > > "libtest.exe" in either case. I'll attach a minimal example when I'm > > back at work tomorrow. > > It is a wrapper to allow running the uninstalled binary in the build > tree without having to mess with PATH or LD_LIBRARY_PATH or whatever. > On a POSIX system this would be a shell script. I think that in libtool > HEAD, it won't have such a confusing name. > > > And the directory it runs from (.libs) indicates it is actually the > > source "lt-libtest.c" that relies on a shell, so as soon as I move the > > executable to a "virgin" computer without Cygwin, the program > > "libtest.exe" won't work. > > You shouldn't be manually mucking about like that, you use "make > install" to get an installed copy and that will not be a wrapper. If > you configured with CC="gcc -mno-cygwin" (i.e. used this "fake mingw" > setup) then the Cygwin dependence should only be for the wrapper which > isn't supposed to be installed or even moved out of the build directory > for that matter. For Posix systems I agree (and I haven't had to care until now). It's an unnecessary burden for w32api however, especially for users that don't have any kind of sane build environment. I guess I'm saying I don't know how to package the result so that someone on w32 can use it on a standard cmd.exe console without having Cygwin, etc. installed. This environment is only necessary for the build. Or should I revert to a different build environment? This is my first attempt at using Autoconf to build something for native Windows (mostly because I want to use it on Linux, but other colleagues of mine benefit from it's use on Windows). > > > I'd also like to generate .lib files (what is the .a file that is > > generated anyway? Is that the .lib import library?) > > An import library can be named foo.lib, libfoo.a, or libfoo.dll.a; they > are all the exact same thing just named differently. Don't confuse the > libfoo.a name with a static library which has the same style name but is > a totally different thing (and that's why it's considered deprecated to > name an import library libfoo.a, but some are still done that way, e.g. > all of w32api.) > > Brian Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT FÜR ALLE NEUEINSTEIGER Jetzt bei Arcor: günstig und schnell mit DSL - das All-Inclusive-Paket für clevere Doppel-Sparer, nur 29,95 inkl. DSL- und ISDN-Grundgebühr! http://www.arcor.de/rd/emf-dsl-2 ___ http://lists.gnu.org/mailman/listinfo/libtool
