Re: Getting executable to link to libtool-built library
David Bruce writes: > OK, I can get it to work post-installation with either LD_LIBRARY_PATH > or the ldconfig+/etc/ld.so.conf mechanism. What I want to learn is > the "right" way to do this as a programmer/packager from an autotools > perspective so that a user can do "./configure; make; sudo make > install" on my lib package (libt4kcommon)and on my executable package > (tuxmath) and have it work. This is user responsibility; if the user installs a library in some directory, the user has also to tell its system to look for libraries there. For example, in my Debian system, /usr/local/lib is included by default in the directories' list to be looked at when searching libs. > Ideally, I would like to be able build a tarball that has both the lib > and executable for standalone installation, but have them be > packagable separately for e.g. Debian. Perhaps this is where nested > packages fit in? Maybe I should move this to the Autoconf list? Debian packagers can split the tarball compilation results in as many packages as they wish, so I think only one tarball is fine unless the program or the library are going to have a wildly different rate of development. -- Alberto _______ http://lists.gnu.org/mailman/listinfo/libtool
Re: Getting executable to link to libtool-built library
Hello, On Mon, Dec 28, 2009 at 3:22 AM, Alberto Luaces wrote: > David Bruce writes: > >> Hello, >> >> I have two related programs (tuxmath and tuxtype) that share a lot of >> code in a human-maintained, copy-and-past fashion. We have been >> working on moving the overlapping code into a separate library >> package, libt4kcommon. All the programs use Autoconf, Automake, and >> Gettext where needed. > Does anyone have any suggestions for the probably obvious step I'm missing? > > Can you try > > configure LDFLAGS="-L/usr/local/lib" > > ? Also check that /usr/local/lib is present in your /etc/ld.so.conf or > your LD_LIBRARY_PATH environment variable. > OK, I can get it to work post-installation with either LD_LIBRARY_PATH or the ldconfig+/etc/ld.so.conf mechanism. What I want to learn is the "right" way to do this as a programmer/packager from an autotools perspective so that a user can do "./configure; make; sudo make install" on my lib package (libt4kcommon)and on my executable package (tuxmath) and have it work. Ideally, I would like to be able build a tarball that has both the lib and executable for standalone installation, but have them be packagable separately for e.g. Debian. Perhaps this is where nested packages fit in? Maybe I should move this to the Autoconf list? Thanks, David Bruce ___ http://lists.gnu.org/mailman/listinfo/libtool
Getting executable to link to libtool-built library
Hello, I have two related programs (tuxmath and tuxtype) that share a lot of code in a human-maintained, copy-and-past fashion. We have been working on moving the overlapping code into a separate library package, libt4kcommon. All the programs use Autoconf, Automake, and Gettext where needed. I have been able to build libt4kcommon using lib_LTLIBRARIES = libt4kcommon.la in the relevant Makefile.am. The library builds a tarball successfully with make distcheck, and installs under /usr/local/lib with make install. So far so good. I'm running into trouble, however, when I try to use the library in e.g. tuxmath. Since the library is being built separately from tuxmath, I believe I need to use AC_CHECK_LIB in tuxmath's configure.ac. However, the configure script fails to find it, even thought the library files are present. I also tried using LDADD = /usr/local/lib/libt4kcommon.la in tuxmath's Makefile.am, which fails with "no rule to make libt4kcommon.la needed by tuxmath". However, I don't think LDADD is the correct approach here anyway. Anyone have any suggestions for the probably obvious step I'm missing? Thanks, David Bruce ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Getting executable to link to libtool-built library
Hello again, > I'm running into trouble, however, when I try to use the library in > e.g. tuxmath. Since the library is being built separately from > tuxmath, I believe I need to use AC_CHECK_LIB in tuxmath's > configure.ac. However, the configure script fails to find it, even > thought the library files are present. Looking through config.log, I found the library had two small undefined functions that generated errors when tuxmath's configure tried the test program. It seems puzzling that they didn't generate errors when I compiled the library itself. Anyway, after I supplied the definitions and rebuilt the library, I can link tuxmath to it. Anyway, if someone would confirm that AC_CHECK_LIB is the right way to do this, I would be a most appreciative libtool newbie. Thanks, David Bruce ___ http://lists.gnu.org/mailman/listinfo/libtool
libtool changes argv[0]
Now that I am using libtool's .la objects when build our apps we notice that the executables in the build tree becomes a script that run the binary form the .libs subdir. This has the side effect that out apps notices a change in argv[0] when we run them from within the build tree. Previously argv[0] was x/y/z, now it becomes x/y/.libs/z and our apps does not like that. Is it possible to do something about the change of argv[0]? libtool version 2.2.6b, gentoo Jocke ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool 2.2.6 on HP-UX, with DESTDIR, installs lt wrapper instead of real binary
River Tarnell: > > We've had proposed patches to get libtool with DESTDIR to work on > > HP-UX but they were problematic in some respect (see the archives of > > the libtool-patches list); I don't recall however if the issues were > > the same as what you are seeing. > Thanks. I'll have a look at these and see if any of them help. Okay, so I took libtool from git, and applied this patch: <http://lists.gnu.org/archive/html/libtool-patches/2009-07/msg9.html> libtool now seems to work correctly: the real binary is installed, and it's linked with the right library, which has the correct soname from the real installation path. It would be very nice to have this patch in the next libtool release. While it might not be complete, it's a lot better than the current situation on HP-UX (where I would say libtool is almost useless, since $DESTDIR is a pretty important feature for building packages). - river. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool 2.2.6 on HP-UX, with DESTDIR, installs lt wrapper instead of real binary
Ralf Wildenhues: > Please post a link to a tarball that shows this problem. Thanks. http://switch.dl.sourceforge.net/project/expat/expat/2.0.1/expat-2.0.1.tar.gz > Is this only a problem with DESTDIR? Yes. If I build like this: % ./configure --prefix=$HOME/expat % make % make install Then the resulting xmlwf is the real binary, not a wrapper script. > We've had proposed patches to get libtool with DESTDIR to work on > HP-UX but they were problematic in some respect (see the archives of > the libtool-patches list); I don't recall however if the issues were > the same as what you are seeing. Thanks. I'll have a look at these and see if any of them help. - river. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool 2.2.6 on HP-UX, with DESTDIR, installs lt wrapper instead of real binary
Hello River, * River Tarnell wrote on Thu, Dec 17, 2009 at 05:02:14AM CET: > I'm using libtool 2.2.6 on HP-UX 11.11 to build Expat (an XML parser). > Expat is a fairly simple project: it has one library (libexpat) and an > executable (xmlwf) that links to this library. I've already updated the > libtool that comes with Expat to 2.2.6 to fix this problem, but it > didn't help. Please post a link to a tarball that shows this problem. Thanks. Is this only a problem with DESTDIR? We've had proposed patches to get libtool with DESTDIR to work on HP-UX but they were problematic in some respect (see the archives of the libtool-patches list); I don't recall however if the issues were the same as what you are seeing. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
libtool 2.2.6 on HP-UX, with DESTDIR, installs lt wrapper instead of real binary
Hi,
I'm using libtool 2.2.6 on HP-UX 11.11 to build Expat (an XML parser).
Expat is a fairly simple project: it has one library (libexpat) and an
executable (xmlwf) that links to this library. I've already updated the
libtool that comes with Expat to 2.2.6 to fix this problem, but it
didn't help.
I'm building a standard package, like this:
% ./configure --prefix=/opt/rt
% make
% make install DESTDIR=$HOME/expat
However, libtool refuses to install the real xmlwf binary into $DESTDIR, and
instead installs the wrapper script:
/bin/sh ./libtool --mode=install conftools/install-sh -c xmlwf/xmlwf
/home/river/expat/opt/rt/bin/xmlwf
libtool: install: warning: `libexpat.la' has not been installed in `/opt/rt/lib'
libtool: install: warning: cannot relink `xmlwf/xmlwf'
libtool: install: conftools/install-sh -c xmlwf/xmlwf
/home/river/expat/opt/rt/bin/xmlwf
% file ~/expat/opt/rt/bin/xmlwf
/home/river/expat/opt/rt/bin/xmlwf: commands text
I understand what libtool is trying to do here, but I don't *want* it to
relink the binary; when I produce a package from the $DESTDIR staging
area, the library will be installed in /opt/rt/lib as expected. The
fact that the binary won't work when run from $DESTDIR is a non-issue.
I'm about to just remove libtool entirely and put native commands to
build the library in Expat's Makefile, but before I do that, is this a
known issue, and if so, is there a fix or workaround?
I've seen a few references to this issue on Google (mostly on HP-UX),
but no actual solutions.
Thanks,
River.
_______
http://lists.gnu.org/mailman/listinfo/libtool
Re: autoreconf always calling libtool with --copy option on Ubuntu 9.10
On Tue, Dec 15, 2009 at 02:31, Paolo Bonzini wrote: > It's an Ubuntu-specific (maybe Debian-specific) patch. Thanks I'll follow this up with them. Cheers Adam ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: autoreconf always calling libtool with --copy option on Ubuntu 9.10
On 12/14/2009 07:25 PM, Adam Mercer wrote: cd /us On Mon, Dec 14, 2009 at 12:13, Paolo Bonzini wrote: I only have this problem with Ubuntu 9.10, does anyone know what could be causing this? What is the output of autoreconf --version? It reports itself as 2.64 Can you attach your /usr/bin/autoreconf so that we can look for Canonical patches? Attached, the source package is available from the following location: <http://packages.ubuntu.com/source/karmic/autoconf> It's an Ubuntu-specific (maybe Debian-specific) patch. Paolo ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: autoreconf always calling libtool with --copy option on Ubuntu 9.10
cd /us On Mon, Dec 14, 2009 at 12:13, Paolo Bonzini wrote: >> I only have this problem with Ubuntu 9.10, does anyone know what could >> be causing this? > > What is the output of autoreconf --version? It reports itself as 2.64 > Can you attach your > /usr/bin/autoreconf so that we can look for Canonical patches? Attached, the source package is available from the following location: <http://packages.ubuntu.com/source/karmic/autoconf> Cheers Adam autoreconf.bz2 Description: BZip2 compressed data ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: autoreconf always calling libtool with --copy option on Ubuntu 9.10
I only have this problem with Ubuntu 9.10, does anyone know what could be causing this? What is the output of autoreconf --version? Can you attach your /usr/bin/autoreconf so that we can look for Canonical patches? Thanks! Paolo ___ http://lists.gnu.org/mailman/listinfo/libtool
autoreconf always calling libtool with --copy option on Ubuntu 9.10
Hi I'm running into a strange problem with libtool when running autoreconf on one of my projects under Ubuntu 9.10. autoreconf always seem to run libtoolize with the copy option, even though there in no need for it to: $ autoreconf -v autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal -I misc autoreconf: configure.ac: tracing autoreconf: running: libtoolize --copy libtoolize: putting macros in `misc'. libtoolize: copying file `misc/ltoptions.m4' libtoolize: You should add the contents of `misc/ltoptions.m4' to `aclocal.m4'. libtoolize: copying file `misc/ltsugar.m4' libtoolize: You should add the contents of `misc/ltsugar.m4' to `aclocal.m4'. libtoolize: copying file `misc/ltversion.m4' libtoolize: copying file `misc/lt~obsolete.m4' libtoolize: You should add the contents of `misc/lt~obsolete.m4' to `aclocal.m4'. libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree. autoreconf: running: /usr/bin/autoconf autoreconf: running: /usr/bin/autoheader autoreconf: running: automake --no-force autoreconf: Leaving directory `.' $ The project is currently using a very old version of libtool (1.4.2) which I am in the process of updating, however even when it is updated to the latest version (2.2.6b) libtoolize is still called with the --copy option: $ autoreconf -v autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal -I misc autoreconf: configure.ac: tracing autoreconf: running: libtoolize --copy libtoolize: `misc/ltmain.sh' is newer: use `--force' to overwrite libtoolize: `misc/ltversion.m4' is newer: use `--force' to overwrite autoreconf: running: /usr/bin/autoconf autoreconf: running: /usr/bin/autoheader autoreconf: running: automake --no-force autoreconf: Leaving directory `.' $ I only have this problem with Ubuntu 9.10, does anyone know what could be causing this? Cheers Adam ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: new libtool version makes troble
Ralf Wildenhues wrote on 08/12/2009 20:57:17: > > Hello Joakim, > > * Joakim Tjernlund wrote on Tue, Dec 08, 2009 at 03:23:39PM CET: > > > > We just upgraded libtool from 1.5.26 to 2.2.6 and our build > > broke. Our host requires 2.2.6 so keeping the old appears difficult. > > > > Even though we only run autoreconf manually in our project, the new libtool > > slipped into the project and the build broke. > > I can fix this by rerunning autoreconf -i -f in the current trunk but > > I cannot do that in already released SW. > > I had the impression that the libtool files installed by libtoolize -f > > should contain everything needed by libtool, that is, there would not be > > any dependencies of the host libtool. > > That is normally the case. > > Note that with Libtool 2.2.x, you can also use the following strategy: > add AC_CONFIG_MACRO_DIR([m4]) to configure.ac, add > ACLOCAL_AMFLAGS = -I m4 > to Makefile.am, and run 'libtoolize -f --install' to have the Libtool > macro files be copied into your tree. That way, aclocal.m4 will refer > to them (rather than carry around a copy of their contents). > > > How can I prevent the new host libtool from slipping into > > the project? > > I'm afraid I can't tell you with the information that you have given. > Please show, not describe, how the host Libtool gets into your project; > i.e., cut and paste the commands you enter and their output that shows > something goes wrong. If your project is open source, don't refrain to > link to a tarball or repository. Sorry for the somewhat vague description, but I have gotten somewhat further. > > > > I would like to be able to run autoreconf even after upgrading the > > host libtool too, if possible. > > Ah, if all you're after is to prevent autoreconf from running > libtoolize, then try > LIBTOOLIZE=true autoreconf I did add a m4 dir and copied the old libtool.m4 there. Now I can run configure and all is well but I think I might have misunderstood libtoolize. I figured libtoolize didn't install new files over the old ones unless -f was given. Is this how it is supposed to be? LIBTOOLIZE=true autoreconf appears to work, however I would like some way for autoreconf to pick this up automatically, if possible. I do have the impression that configure/make sometimes reruns libtoolize automatically, maybe I am just seeing things that aren't there? > > Another issue may be that aclocal fails to find the in-tree libtool > macros, but finds some installed ones. That can typically be found out > by passing --verbose to aclocal (passing --verbose to autoreconf will do > that). What happens are that aclocal somehow triggers and install a new aclocal.m4 with the new libtool macros. The old ltmain.sh does not understand these and dies. Adding the m4 dir keeps the old macros and ltmain.sh works again Jocke ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: new libtool version makes troble
Hello Joakim, * Joakim Tjernlund wrote on Tue, Dec 08, 2009 at 03:23:39PM CET: > > We just upgraded libtool from 1.5.26 to 2.2.6 and our build > broke. Our host requires 2.2.6 so keeping the old appears difficult. > > Even though we only run autoreconf manually in our project, the new libtool > slipped into the project and the build broke. > I can fix this by rerunning autoreconf -i -f in the current trunk but > I cannot do that in already released SW. > I had the impression that the libtool files installed by libtoolize -f > should contain everything needed by libtool, that is, there would not be > any dependencies of the host libtool. That is normally the case. Note that with Libtool 2.2.x, you can also use the following strategy: add AC_CONFIG_MACRO_DIR([m4]) to configure.ac, add ACLOCAL_AMFLAGS = -I m4 to Makefile.am, and run 'libtoolize -f --install' to have the Libtool macro files be copied into your tree. That way, aclocal.m4 will refer to them (rather than carry around a copy of their contents). > How can I prevent the new host libtool from slipping into > the project? I'm afraid I can't tell you with the information that you have given. Please show, not describe, how the host Libtool gets into your project; i.e., cut and paste the commands you enter and their output that shows something goes wrong. If your project is open source, don't refrain to link to a tarball or repository. > I would like to be able to run autoreconf even after upgrading the > host libtool too, if possible. Ah, if all you're after is to prevent autoreconf from running libtoolize, then try LIBTOOLIZE=true autoreconf Another issue may be that aclocal fails to find the in-tree libtool macros, but finds some installed ones. That can typically be found out by passing --verbose to aclocal (passing --verbose to autoreconf will do that). Hope that helps. Cheers, Ralf _______ http://lists.gnu.org/mailman/listinfo/libtool
new libtool version makes troble
We just upgraded libtool from 1.5.26 to 2.2.6 and our build broke. Our host requires 2.2.6 so keeping the old appears difficult. Even though we only run autoreconf manually in our project, the new libtool slipped into the project and the build broke. I can fix this by rerunning autoreconf -i -f in the current trunk but I cannot do that in already released SW. I had the impression that the libtool files installed by libtoolize -f should contain everything needed by libtool, that is, there would not be any dependencies of the host libtool. How can I prevent the new host libtool from slipping into the project? I would like to be able to run autoreconf even after upgrading the host libtool too, if possible. Jocke ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: MacOSX module linking with static archive libtool problem
> On 12/01/2009 06:04 PM, Jonas Thiem wrote: > > This topic is rather old, and I'm referring to a particular post which > > can be found here: > > http://www.mail-archive.com/libtool@gnu.org/msg03642.html > > Obviously it isn't possible to link a static lib from a shared lib > > compiled in libtool as libtool blocks it (technically it would be > > possible on many, but not all platforms). This affects all platforms > > including Windows, not just Mac OS X. > > > > Robert Boehne suggested some solutions to this: > > > Suggestion 1, you could link to shared libraries rather than archives. > > >Suggestion 2, if you're building it yourself, make the static libs > > >convenience libraries, this will have the same effect as linking to > > static libs, but is portable. > > This should work, we changed the dep libs check method to pass_all, if > you are using libtool-1.5 (April 2003) or later, you shouldn't see a > problem on Mac OS X. > > Peter > -- > Peter O'Gorman > http://pogma.com > For windows targets it doesn't work at all (compiling on a linux machine with i486-mignw32. I'm also pretty sure my libtool version is newer, but I need to recheck when I'm at home and having access to the machine. The only way to link a static lib for a windows target seems to be not to use libtool (given you cannot move to a convenience lib or a shared lib which is the case for a plugin that references back to the main app's symbol file). ___ Preisknaller: WEB.DE DSL Flatrate für nur 16,99 Euro/mtl.! http://produkte.web.de/go/02/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: -fpic support in libtool?
On 12/03/2009 08:20 AM, Ralf Wildenhues wrote: We should probably change the code so that the override can be done before AC_PROG_LIBTOOL, so that at least -DPIC is added consistently, and that the compile test uses the right flag. Using a "real" cache variable will do. I'll give it a shot. Paolo ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: -fpic support in libtool?
Ralf Wildenhues wrote on 03/12/2009 08:20:22: > From: Ralf Wildenhues > To: Joakim Tjernlund > Cc: Bob Friesenhahn , libtool@gnu.org > Date: 03/12/2009 08:20 > Subject: Re: -fpic support in libtool? > > * Joakim Tjernlund wrote on Thu, Dec 03, 2009 at 08:06:25AM CET: > > > Libtool can be influenced by the configure script by influencing this > > > definition which gets output in the libtool script: > > > > > > # Additional compiler flags for building library objects. > > > pic_flag=" -fPIC -DPIC" > > > > > > This seems to be controlled by the lt_prog_compiler_pic configure > > > script variable. > > > > hmm, not sure what/if you are suggesting. Should I just try override the > > definition of pic_flag? In my configure.ac or somewhere else? > > You can probably get away with overriding lt_prog_compiler_pic, > lt_prog_compiler_pic_CXX, ..., in configure.ac, when doing it *after* > the AC_PROG_LIBTOOL aka LT_INIT invocation, and before either of > AC_OUTPUT or LT_OUTPUT. However, this is not recommended, doing this > will let configure test the wrong pic_flag (i.e., the one it sets rather > than your override), and if this breaks now or in a later release you > get to keep the pieces. > > We should probably change the code so that the override can be done > before AC_PROG_LIBTOOL, so that at least -DPIC is added consistently, > and that the compile test uses the right flag. Would it be possible to write something in acinclude.m4 that will override the -fPIC flag? Jocke ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: -fpic support in libtool?
Ralf Wildenhues wrote on 03/12/2009 08:20:22: > > * Joakim Tjernlund wrote on Thu, Dec 03, 2009 at 08:06:25AM CET: > > > Libtool can be influenced by the configure script by influencing this > > > definition which gets output in the libtool script: > > > > > > # Additional compiler flags for building library objects. > > > pic_flag=" -fPIC -DPIC" > > > > > > This seems to be controlled by the lt_prog_compiler_pic configure > > > script variable. > > > > hmm, not sure what/if you are suggesting. Should I just try override the > > definition of pic_flag? In my configure.ac or somewhere else? > > You can probably get away with overriding lt_prog_compiler_pic, > lt_prog_compiler_pic_CXX, ..., in configure.ac, when doing it *after* > the AC_PROG_LIBTOOL aka LT_INIT invocation, and before either of > AC_OUTPUT or LT_OUTPUT. However, this is not recommended, doing this > will let configure test the wrong pic_flag (i.e., the one it sets rather > than your override), and if this breaks now or in a later release you > get to keep the pieces. Thanks, I will try that instead. > > We should probably change the code so that the override can be done > before AC_PROG_LIBTOOL, so that at least -DPIC is added consistently, > and that the compile test uses the right flag. This is far beyond my expertise. I do wish you would consider some way of specifying -fpic to libtool. It is useful for some arch's and embedded targets. Jocke ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: -fpic support in libtool?
* Joakim Tjernlund wrote on Thu, Dec 03, 2009 at 08:06:25AM CET: > > Libtool can be influenced by the configure script by influencing this > > definition which gets output in the libtool script: > > > > # Additional compiler flags for building library objects. > > pic_flag=" -fPIC -DPIC" > > > > This seems to be controlled by the lt_prog_compiler_pic configure > > script variable. > > hmm, not sure what/if you are suggesting. Should I just try override the > definition of pic_flag? In my configure.ac or somewhere else? You can probably get away with overriding lt_prog_compiler_pic, lt_prog_compiler_pic_CXX, ..., in configure.ac, when doing it *after* the AC_PROG_LIBTOOL aka LT_INIT invocation, and before either of AC_OUTPUT or LT_OUTPUT. However, this is not recommended, doing this will let configure test the wrong pic_flag (i.e., the one it sets rather than your override), and if this breaks now or in a later release you get to keep the pieces. We should probably change the code so that the override can be done before AC_PROG_LIBTOOL, so that at least -DPIC is added consistently, and that the compile test uses the right flag. Cheers, Ralf _______ http://lists.gnu.org/mailman/listinfo/libtool
Re: -fpic support in libtool?
On Wednesday 02 December 2009 21:27:55 Bob Friesenhahn wrote: > On Thu, 3 Dec 2009, Joakim Tjernlund wrote: > > Several years ago I asked libtool to support -fpic too but > > I don't see it in never libtool(s). I guess it isn't > > impl.? > > > > The simplest fix for adding -fpic I can come up with is > > doing sed -i 's/-fPIC/-fpic/' aclocal.m4 > > This is a bit clumsy as one can easily forget > > to do this when running aclocal manually. > > Is there a simpler way? One that will work both with 1.5 and 2.x > > versions of libtool? > > How would libtool know which PIC variant will work? Note that some > targets (e.g. PowerPC & SPARC) offer many reduced PIC variants. > These don't really work unless the developer is able to validate the > application/library on many kinds of targets and somehow specify the > correct variant which works for the target. > > Libtool can be influenced by the configure script by influencing this > definition which gets output in the libtool script: > > # Additional compiler flags for building library objects. > pic_flag=" -fPIC -DPIC" > > This seems to be controlled by the lt_prog_compiler_pic configure > script variable. > > Note that many compilers use something quite different from -fPIC to > mean the same thing but don't accept -fpic so just > substituting/inserting -fpic is likely to cause failure. it isnt just a target-specific issue. it's package specific too. for smaller libraries, people can get away with -fpic. but you really have no way of knowing until you try and compile something and it fails due to exceeding the smaller space. -mike signature.asc Description: This is a digitally signed message part. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: -fpic support in libtool?
Bob Friesenhahn wrote on 03/12/2009 03:27:55: > > On Thu, 3 Dec 2009, Joakim Tjernlund wrote: > > > Several years ago I asked libtool to support -fpic too but > > I don't see it in never libtool(s). I guess it isn't > > impl.? > > > > The simplest fix for adding -fpic I can come up with is > > doing sed -i 's/-fPIC/-fpic/' aclocal.m4 > > This is a bit clumsy as one can easily forget > > to do this when running aclocal manually. > > Is there a simpler way? One that will work both with 1.5 and 2.x > > versions of libtool? > > How would libtool know which PIC variant will work? Note that some > targets (e.g. PowerPC & SPARC) offer many reduced PIC variants. > These don't really work unless the developer is able to validate the > application/library on many kinds of targets and somehow specify the > correct variant which works for the target. We use auto*, libtool for an internal embedded project. This SW will always be built in a controlled env.(powerpc, linux). Since powerpc can deal with -fpic, I want to use it. > > Libtool can be influenced by the configure script by influencing this > definition which gets output in the libtool script: > > # Additional compiler flags for building library objects. > pic_flag=" -fPIC -DPIC" > > This seems to be controlled by the lt_prog_compiler_pic configure > script variable. hmm, not sure what/if you are suggesting. Should I just try override the definition of pic_flag? In my configure.ac or somewhere else? > > Note that many compilers use something quite different from -fPIC to > mean the same thing but don't accept -fpic so just > substituting/inserting -fpic is likely to cause failure. Yes, but not in our case. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: -fpic support in libtool?
On Thu, 3 Dec 2009, Joakim Tjernlund wrote: Several years ago I asked libtool to support -fpic too but I don't see it in never libtool(s). I guess it isn't impl.? The simplest fix for adding -fpic I can come up with is doing sed -i 's/-fPIC/-fpic/' aclocal.m4 This is a bit clumsy as one can easily forget to do this when running aclocal manually. Is there a simpler way? One that will work both with 1.5 and 2.x versions of libtool? How would libtool know which PIC variant will work? Note that some targets (e.g. PowerPC & SPARC) offer many reduced PIC variants. These don't really work unless the developer is able to validate the application/library on many kinds of targets and somehow specify the correct variant which works for the target. Libtool can be influenced by the configure script by influencing this definition which gets output in the libtool script: # Additional compiler flags for building library objects. pic_flag=" -fPIC -DPIC" This seems to be controlled by the lt_prog_compiler_pic configure script variable. Note that many compilers use something quite different from -fPIC to mean the same thing but don't accept -fpic so just substituting/inserting -fpic is likely to cause failure. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: MacOSX module linking with static archive libtool problem
On 12/01/2009 06:04 PM, Jonas Thiem wrote: This topic is rather old, and I'm referring to a particular post which can be found here: http://www.mail-archive.com/libtool@gnu.org/msg03642.html Obviously it isn't possible to link a static lib from a shared lib compiled in libtool as libtool blocks it (technically it would be possible on many, but not all platforms). This affects all platforms including Windows, not just Mac OS X. Robert Boehne suggested some solutions to this: > Suggestion 1, you could link to shared libraries rather than archives. >Suggestion 2, if you're building it yourself, make the static libs >convenience libraries, this will have the same effect as linking to static libs, but is portable. This should work, we changed the dep libs check method to pass_all, if you are using libtool-1.5 (April 2003) or later, you shouldn't see a problem on Mac OS X. Peter -- Peter O'Gorman http://pogma.com ___ http://lists.gnu.org/mailman/listinfo/libtool
-fpic support in libtool?
Several years ago I asked libtool to support -fpic too but I don't see it in never libtool(s). I guess it isn't impl.? The simplest fix for adding -fpic I can come up with is doing sed -i 's/-fPIC/-fpic/' aclocal.m4 This is a bit clumsy as one can easily forget to do this when running aclocal manually. Is there a simpler way? One that will work both with 1.5 and 2.x versions of libtool? Jocke ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: MacOSX module linking with static archive libtool problem
This topic is rather old, and I'm referring to a particular post which can be found here: http://www.mail-archive.com/libtool@gnu.org/msg03642.html Obviously it isn't possible to link a static lib from a shared lib compiled in libtool as libtool blocks it (technically it would be possible on many, but not all platforms). This affects all platforms including Windows, not just Mac OS X. Robert Boehne suggested some solutions to this: > Suggestion 1, you could link to shared libraries rather than archives. >Suggestion 2, if you're building it yourself, make the static libs >convenience libraries, this will have the same effect as linking to static libs, but is portable. This doesn't cover a special case though which I heard isn't *that* uncommon and which wasn't mentioned in the discussion at all: Sometimes you create plugins/modules which refer back to functions in the main program. On Unix, you can simply do this by unresolved symbols that get resolved to the main program itself at the point when it loads the shared libs. On Windows, where unresolved symbols aren't allowed, I am myself commonly generating a .a symbol file from the main program's symbols and linking it statically from my dlls, which works fine with mingw and also generates perfectly usable dlls. Now with libtool this isn't possible. In my project, that led me to an ugly hack where I'm simply not using libtool for my modules at all when compiling for a windows target. That's a rather unsatisfying solution. It works, but the condition in every Makefile.am of every module that contains both libtool code and manual code just for the windows platform to get it compiled seems rather ugly compared to a much simplier solution: It could much easier be solved by libtool providing a switch to override the blocking of static linking out of shared libs. In my case, that also wouldn't impose a problem to Unix systems not supporting it, as I'd simply use it solely for the Windows platform where the .a link is needed to avoid unresolved symbols. As the problem seems, after 6 years, still unresolved (if I'm wrong please correct me, I'm by no way an expert or even an advanced libtool user), it would be really great if such a flag got introduced: people may use or not use it depending on the target platforms they want to support, or they may even use it only through an optional condition for individual target platforms of which they know that they support static linking out of shared libs to achieve specific things - in my case avoidance of unresolved symbols. This wouldn't cause a loss of compatibility for the average libtool user and provide a considerable amount of less pain in this specific special case. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: revisiting condor and libtool
On Tue, Dec 1, 2009 at 14:45, Ralf Wildenhues wrote: Ralf > As developer, add it to AM_LDFLAGS. You can AC_SUBST([AM_LDFLAGS]) from > configure.ac if you need it in multiple Makefile.am files. Note that > target_LDFLAGS override AM_LDFLAGS unless you add the latter to the > former. Fantastic, this works! Thanks a lot for your help! I just need to integrate the same changes into the main code now. Cheers Adam ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: revisiting condor and libtool
* Adam Mercer wrote on Tue, Dec 01, 2009 at 09:27:33PM CET: > On Tue, Dec 1, 2009 at 12:54, Ralf Wildenhues wrote: > > --disable-shared does not disable linking against shared libraries, > > it only disables creating shared libraries. To disable dynamic linking > > against uninstalled libtool libraries, use -static in the link flags, to > > disable dynamic linking against any libtool libraries, use > > -static-libtool-libs, and to disable dynamic linking against all > > libraries, use -all-static; e.g., > > foo_LDFLAGS = $(AM_LDFLAGS) -all-static > > Thanks, adding the above to src/Makefile.am results in a successful > build, so it looks like I need to ensure that -all-static is passed to > each program when linking. Is there a way I can ensure that this is > done without adding it to _LDFLAGS for every program? As developer, add it to AM_LDFLAGS. You can AC_SUBST([AM_LDFLAGS]) from configure.ac if you need it in multiple Makefile.am files. Note that target_LDFLAGS override AM_LDFLAGS unless you add the latter to the former. As user, you probably need something like make LDFLAGS=-all-static (specifying it at configure time doesn't work, unfortunately). Cheers, Ralf _______ http://lists.gnu.org/mailman/listinfo/libtool
Re: revisiting condor and libtool
On Tue, Dec 1, 2009 at 12:54, Ralf Wildenhues wrote: Ralf > please trim stuff that you don't refer to from replies, thanks. Sorry, I usually do but forgot last time. > BTW, you should usually include config.h as very first header, > because it can influence the behavior of system headers. good point. > You didn't state whether you built this with --disable-static or some > other interesting flags, and whether both static and shared versions of > libbar were created and installed. sorry I should have mentioned this. I just used --prefix, both shared and static libraries are built. > BTW, the -lbar usually goes in LIBS, so that it comes after the stuff > that links against libbar. Whether you put -L$HOME/tmp/lib in LDFLAGS > or LIBS depends on whether it should be used for other deplibs too. I > usually leave it it LDFLAGS. Not sure whether this would make a > difference for your issue, though. no it doesn't make a difference. > --disable-shared does not disable linking against shared libraries, > it only disables creating shared libraries. To disable dynamic linking > against uninstalled libtool libraries, use -static in the link flags, to > disable dynamic linking against any libtool libraries, use > -static-libtool-libs, and to disable dynamic linking against all > libraries, use -all-static; e.g., > foo_LDFLAGS = $(AM_LDFLAGS) -all-static Thanks, adding the above to src/Makefile.am results in a successful build, so it looks like I need to ensure that -all-static is passed to each program when linking. Is there a way I can ensure that this is done without adding it to _LDFLAGS for every program? Cheers Adam _______ http://lists.gnu.org/mailman/listinfo/libtool
Re: revisiting condor and libtool
Hello Adam,
please trim stuff that you don't refer to from replies, thanks.
* Adam Mercer wrote on Tue, Dec 01, 2009 at 05:48:46PM CET:
> src/bar.c
>
> #include
> #include "config.h"
BTW, you should usually include config.h as very first header,
because it can influence the behavior of system headers.
> int bar(void)
> {
> fprintf(stdout, "Hello world, from libbar.bar()!\n");
> return 0;
> }
[...]
> which builds, and installs to $HOME/tmp, successfully,
You didn't state whether you built this with --disable-static or some
other interesting flags, and whether both static and shared versions of
libbar were created and installed.
> I then modified
> the condor_libtool example to link against this by adding:
>
> AC_CHECK_LIB([bar],[bar],,[AC_MSG_ERROR([cannot find bar library])])
> AC_CHECK_HEADERS([bar.h],,[AC_MSG_ERROR([cannot find headers from libbar])])
>
> and then configured this new code with
>
> $ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$HOME/tmp/lib
> $ CPPFLAGS=-I$HOME/tmp/include LDFLAGS="-L$HOME/tmp/lib -lbar"
BTW, the -lbar usually goes in LIBS, so that it comes after the stuff
that links against libbar. Whether you put -L$HOME/tmp/lib in LDFLAGS
or LIBS depends on whether it should be used for other deplibs too. I
usually leave it it LDFLAGS. Not sure whether this would make a
difference for your issue, though.
> ./configure --enable-condor LD=/opt/condor/lib/ld
>
> which results in a successful configure, but now make fails with:
>
> /bin/sh ../libtool --tag=CC --mode=link condor_compile gcc
> -std=gnu99 -g -O2 -L/home/ram/tmp/lib -lbar -o foo foo.o -lbar
> libtool: link: condor_compile gcc -std=gnu99 -g -O2 -o foo foo.o
> -L/home/ram/tmp/lib /home/ram/tmp/lib/libbar.so -Wl,-rpath
> -Wl,/home/ram/tmp/lib -Wl,-rpath -Wl,/home/ram/tmp/lib
> LINKING FOR CONDOR : /usr/bin/ld -L/opt/condor/lib -Bstatic
> --eh-frame-hdr -m elf_x86_64 --hash-style=gnu -dynamic-linker
> /lib64/ld-linux-x86-64.so.2 -o foo /opt/condor/lib/condor_rt0.o
> /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/crti.o
> /usr/lib/gcc/x86_64-redhat-linux/4.1.2/crtbeginT.o -L/home/ram/tmp/lib
> -L/opt/condor/lib -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2
> -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2
> -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64
> -L/lib/../lib64 -L/usr/lib/../lib64 foo.o /home/ram/tmp/lib/libbar.so
> -rpath /home/ram/tmp/lib -rpath /home/ram/tmp/lib
> /opt/condor/lib/libcondorsyscall.a /opt/condor/lib/libcondor_z.a
> /opt/condor/lib/libcomp_libstdc++.a /opt/condor/lib/libcomp_libgcc.a
> /opt/condor/lib/libcomp_libgcc_eh.a --as-needed --no-as-needed
> -lcondor_c -lcondor_nss_files -lcondor_nss_dns -lcondor_resolv
> -lcondor_c -lcondor_nss_files -lcondor_nss_dns -lcondor_resolv
> -lcondor_c /opt/condor/lib/libcomp_libgcc.a
> /opt/condor/lib/libcomp_libgcc_eh.a --as-needed --no-as-needed
> /usr/lib/gcc/x86_64-redhat-linux/4.1.2/crtend.o
> /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/crtn.o
> /usr/bin/ld: attempted static link of dynamic object
> `/home/ram/tmp/lib/libbar.so'
> collect2: ld returned 1 exit status
>
> which is a similar error to what I am getting with the main code, ie
> condor_compile is wanting to link a shared library into a static
> executable.
Well, the -Bstatic seems to be added by condor_compile, because it is
not part of the libtool output.
> I reconfigured adding the --disable-shared option to
> configure results in exactly the same error.
--disable-shared does not disable linking against shared libraries,
it only disables creating shared libraries. To disable dynamic linking
against uninstalled libtool libraries, use -static in the link flags, to
disable dynamic linking against any libtool libraries, use
-static-libtool-libs, and to disable dynamic linking against all
libraries, use -all-static; e.g.,
foo_LDFLAGS = $(AM_LDFLAGS) -all-static
libtool does not currently support linking only some libraries static,
but there is a proposed patch to add this functionality.
Cheers,
Ralf
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: revisiting condor and libtool
On Tue, Dec 1, 2009 at 00:26, Ralf Wildenhues wrote:
> Yes, the condor_compile script puts the quotes all in the wrong places.
> To work around it, use AC_CONFIG_HEADERS([config.h]) and include that
> from your code. Your build setup looks ok otherwise.
Thanks, using AC_CONFIG_HEADERS results in a sucessfull build. But the
main code uses config.h for defines so this is not the main error I
have been running in. In order to make this example more like the main
code I created a very small library to link against, libbar which has
the following configure.ac:
AC_INIT([libbar],[0.1],[adam.mer...@ligo.org])
AC_CONFIG_HEADERS([src/config.h])
AC_CONFIG_AUX_DIR([gnuscripts])
AC_CONFIG_MACRO_DIR([gnuscripts])
AC_CONFIG_FILES([ \
Makefile \
gnuscripts/Makefile
src/Makefile
])
AM_INIT_AUTOMAKE([foreign])
AC_CANONICAL_HOST
AC_PROG_CC_STDC
LT_INIT
AC_OUTPUT
with src/Makefile.am
INCLUDES = -I$(top_builddir)/src
libbarincludedir = $(includedir)
libbarinclude_HEADERS = bar.h
lib_LTLIBRARIES = libbar.la
libbar_la_SOURCES = bar.c
src/bar.c
#include
#include "config.h"
int bar(void)
{
fprintf(stdout, "Hello world, from libbar.bar()!\n");
return 0;
}
src/bar.h
#include
int bar(void);
which builds, and installs to $HOME/tmp, successfully, I then modified
the condor_libtool example to link against this by adding:
AC_CHECK_LIB([bar],[bar],,[AC_MSG_ERROR([cannot find bar library])])
AC_CHECK_HEADERS([bar.h],,[AC_MSG_ERROR([cannot find headers from libbar])])
and then configured this new code with
$ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$HOME/tmp/lib
$ CPPFLAGS=-I$HOME/tmp/include LDFLAGS="-L$HOME/tmp/lib -lbar"
./configure --enable-condor LD=/opt/condor/lib/ld
which results in a successful configure, but now make fails with:
/bin/sh ../libtool --tag=CC --mode=link condor_compile gcc
-std=gnu99 -g -O2 -L/home/ram/tmp/lib -lbar -o foo foo.o -lbar
libtool: link: condor_compile gcc -std=gnu99 -g -O2 -o foo foo.o
-L/home/ram/tmp/lib /home/ram/tmp/lib/libbar.so -Wl,-rpath
-Wl,/home/ram/tmp/lib -Wl,-rpath -Wl,/home/ram/tmp/lib
LINKING FOR CONDOR : /usr/bin/ld -L/opt/condor/lib -Bstatic
--eh-frame-hdr -m elf_x86_64 --hash-style=gnu -dynamic-linker
/lib64/ld-linux-x86-64.so.2 -o foo /opt/condor/lib/condor_rt0.o
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/crti.o
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/crtbeginT.o -L/home/ram/tmp/lib
-L/opt/condor/lib -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2
-L/usr/lib/gcc/x86_64-redhat-linux/4.1.2
-L/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64
-L/lib/../lib64 -L/usr/lib/../lib64 foo.o /home/ram/tmp/lib/libbar.so
-rpath /home/ram/tmp/lib -rpath /home/ram/tmp/lib
/opt/condor/lib/libcondorsyscall.a /opt/condor/lib/libcondor_z.a
/opt/condor/lib/libcomp_libstdc++.a /opt/condor/lib/libcomp_libgcc.a
/opt/condor/lib/libcomp_libgcc_eh.a --as-needed --no-as-needed
-lcondor_c -lcondor_nss_files -lcondor_nss_dns -lcondor_resolv
-lcondor_c -lcondor_nss_files -lcondor_nss_dns -lcondor_resolv
-lcondor_c /opt/condor/lib/libcomp_libgcc.a
/opt/condor/lib/libcomp_libgcc_eh.a --as-needed --no-as-needed
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/crtend.o
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/crtn.o
/usr/bin/ld: attempted static link of dynamic object
`/home/ram/tmp/lib/libbar.so'
collect2: ld returned 1 exit status
which is a similar error to what I am getting with the main code, ie
condor_compile is wanting to link a shared library into a static
executable. I reconfigured adding the --disable-shared option to
configure results in exactly the same error.
Can anyone see anything in my configure.ac that could explain this, or
is this another problem with condor_compile?
Cheers
Adam
> Below's a completely untested patch for condor_compile, to fix the worst
> quoting issues I found upon inspection. The patch is completely
> untested, but if you could test it, I'd like to ask you to send it
> upstream, too. Thanks.
>
> Cheers,
> Ralf
>
>
> --- ./src/condor_scripts/condor_compile.orig 2009-12-01 07:14:37.0
> +0100
> +++ ./src/condor_scripts/condor_compile 2009-12-01 07:22:29.0 +0100
> @@ -134,35 +134,35 @@
> fi
>
>
> - if [ $1 = "-condor_syscall_lib" ]; then
> + if [ "$1" = "-condor_syscall_lib" ]; then
> shift
> CONDOR_SPECIAL_CLIB=$1
> shift
> continue
> fi
>
> - if [ $1 = "-condor_rt0" ]; then
> + if [ "$1" = "-condor_rt0" ]; then
> shift
> CONDOR_RT0=$1
> shift
> continue
> fi
>
> - if [ $1 = "-condor_c++_support" ]; then
> + if [ "$1" = "-condor_c++_support" ]; then
> shift
>
Re: revisiting condor and libtool
On Tue, Dec 1, 2009 at 00:26, Ralf Wildenhues wrote: > Yes, the condor_compile script puts the quotes all in the wrong places. > To work around it, use AC_CONFIG_HEADERS([config.h]) and include that > from your code. Your build setup looks ok otherwise. Thought so. > Below's a completely untested patch for condor_compile, to fix the worst > quoting issues I found upon inspection. The patch is completely > untested, but if you could test it, I'd like to ask you to send it > upstream, too. Thanks. Thanks a lot Ralf, I'll pass you patch upstream. Cheers Adam ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: revisiting condor and libtool
-tl -h$CONDOR_LD_DIR -B + invoke_linker "$@" -tl -h$CONDOR_LD_DIR -B fi if [ $myname = "c89" ]; then - invoke_linker $ARGS -tl -h$CONDOR_LD_DIR -B + invoke_linker "$@" -tl -h$CONDOR_LD_DIR -B fi if [ $myname = "f77" ]; then - invoke_linker $ARGS -tl -h$CONDOR_LD_DIR -B + invoke_linker "$@" -tl -h$CONDOR_LD_DIR -B fi if [ $myname = "f90" ]; then - invoke_linker $ARGS -tl -h$CONDOR_LD_DIR -B + invoke_linker "$@" -tl -h$CONDOR_LD_DIR -B fi if [ $myname = "KCC" ]; then - invoke_linker $ARGS --backend -tl --backend \ + invoke_linker "$@" --backend -tl --backend \ -h$CONDOR_LD_DIR --backend -B fi @@ -481,27 +476,27 @@ HP-UX ) if [ $myname = "cc" ]; then - invoke_linker $ARGS -tl,$CONDOR_LD_DIR/ld + invoke_linker "$@" -tl,$CONDOR_LD_DIR/ld fi if [ $myname = "CC" ]; then - invoke_linker $ARGS +A -tl,$CONDOR_LD_DIR/ld + invoke_linker "$@" +A -tl,$CONDOR_LD_DIR/ld fi if [ $myname = "aCC" ]; then - invoke_linker $ARGS +A -tl,$CONDOR_LD_DIR/ld + invoke_linker "$@" +A -tl,$CONDOR_LD_DIR/ld fi if [ $myname = "c89" ]; then - invoke_linker $ARGS -tl,$CONDOR_LD_DIR/ld + invoke_linker "$@" -tl,$CONDOR_LD_DIR/ld fi if [ $myname = "f77" ]; then - invoke_linker $ARGS -tl,$CONDOR_LD_DIR/ld + invoke_linker "$@" -tl,$CONDOR_LD_DIR/ld fi if [ $myname = "fort77" ]; then - invoke_linker $ARGS -tl,$CONDOR_LD_DIR/ld + invoke_linker "$@" -tl,$CONDOR_LD_DIR/ld fi ;; @@ -509,26 +504,26 @@ SunOS ) use_qpath=`cc -help -flags | grep Qpath | wc -l` if [ $myname = "cc" -a $use_qpath = 0 ]; then - invoke_linker $ARGS -Yl,$CONDOR_LD_DIR + invoke_linker "$@" -Yl,$CONDOR_LD_DIR fi if [ $myname = "cc" -a $use_qpath != 0 ]; then - invoke_linker $ARGS -Qpath $CONDOR_LD_DIR + invoke_linker "$@" -Qpath $CONDOR_LD_DIR fi if [ $myname = "acc" ]; then - invoke_linker $ARGS -Qpath $CONDOR_LD_DIR + invoke_linker "$@" -Qpath $CONDOR_LD_DIR fi if [ $myname = "CC" ]; then - invoke_linker $ARGS -Qpath $CONDOR_LD_DIR + invoke_linker "$@" -Qpath $CONDOR_LD_DIR fi if [ $myname = "f77" ]; then - invoke_linker $ARGS -Qpath $CONDOR_LD_DIR + invoke_linker "$@" -Qpath $CONDOR_LD_DIR fi if [ $myname = "f90" ]; then - invoke_linker $ARGS -Qpath $CONDOR_LD_DIR + invoke_linker "$@" -Qpath $CONDOR_LD_DIR fi ;; @@ -536,23 +531,23 @@ Linux ) # Linux's system compilers are GNU if [ $myname = "cc" ]; then - invoke_linker $ARGS -B$CONDOR_LD_DIR/ + invoke_linker "$@" -B$CONDOR_LD_DIR/ fi if [ $myname = "CC" ]; then - invoke_linker $ARGS -B$CONDOR_LD_DIR/ + invoke_linker "$@" -B$CONDOR_LD_DIR/ fi if [ $myname = "c++" ]; then - invoke_linker $ARGS -B$CONDOR_LD_DIR/ + invoke_linker "$@" -B$CONDOR_LD_DIR/ fi if [ $myname = "f77" ]; then - invoke_linker $ARGS -B$CONDOR_LD_DIR/ + invoke_linker "$@" -B$CONDOR_LD_DIR/ fi if [ $myname = "gfortran" ]; then - invoke_linker $ARGS -B$CONDOR_LD_DIR/ + invoke_linker "$@" -B$CONDOR_LD_DIR/ fi ;; ___ http://lists.gnu.org/mailman/listinfo/libtool
revisiting condor and libtool
Hi
A while ago I posted a question regarding problems I was having with
updating a project, that is built for the condor workflow management
system (http://www.cs.wisc.edu/condor/), to the latest version of
libtool:
<http://lists.gnu.org/archive/html/libtool/2009-05/msg00023.html>
unfortunately I got swamped with other tasks and wasn't able to spend
any more time of this at the time, this now has changed so I have
started looking again. To make this easier I've written a very simple
example in order to debug the problem. This example has a configure.ac
as follows:
AC_INIT([condor_libtool],[0.1],[adam.mer...@ligo.org])
AC_CONFIG_AUX_DIR([gnuscripts])
AC_CONFIG_MACRO_DIR([gnuscripts])
AC_CONFIG_FILES([ \
Makefile \
gnuscripts/Makefile
src/Makefile
])
AM_INIT_AUTOMAKE([foreign])
AC_CANONICAL_HOST
AC_ARG_ENABLE(
[condor],
AC_HELP_STRING([--enable-condor],[compile for use with condor, default=no]),
[ case "${enableval}" in
yes) condor=true;;
no) condor=false;;
*) AC_MSG_ERROR([bad value ${enableval} for --enable-condor]);;
esac
],[condor=false]
)
AC_PROG_CC_STDC
if test "x$condor" = "xtrue"; then
AC_CHECK_PROGS([CONDOR_COMPILE],[condor_compile])
CC="$CONDOR_COMPILE $CC"
AC_DISABLE_SHARED
fi
LT_INIT
AC_OUTPUT
with src/Makefile.am
bin_PROGRAMS = foo
foo_SOURCES = foo.c
and src/foo.c
#include
int main(void)
{
fprintf(stdout, "Hello world!\n");
return 0;
}
which I then configure using the --enable-condor option to build using
the condor_compile wrapper script. This results the the following
being displayed during configure:
$ ./configure --enable-condor
checking whether the condor_compile gcc -std=gnu99 linker
(/opt/condor/lib/ld
ERROR: Internal ld was not invoked!
ERROR: Executable may not be linked properly for Condor!
ERROR: For users of Condor on Linux, we highly recommend
ERROR: using the default compiler that came with the
ERROR: distribution. Usually placing /usr/bin first in
ERROR: your path will remedy this error.
ERROR: To learn more about this error, visit this web page:
ERROR: http://www.cs.wisc.edu/condor/manual/faq.html
ERROR: and read the FAQ entry about this problem for your
ERROR: revision of Condor. -m elf_x86_64) supports shared libraries... yes
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... no
checking whether to build static libraries... yes
configure: WARNING: cache variable lt_cv_path_LD contains a newline
configure: creating ./config.status
config.status: creating Makefile
config.status: creating gnuscripts/Makefile
config.status: creating src/Makefile
config.status: executing depfiles commands
config.status: executing libtool commands
configure: WARNING: cache variable lt_cv_path_LD contains a newline
$ make
Makefile:143: *** multiple target patterns. Stop.
$
with line 143 of Makefile being one of the lines starting with ERROR below:
INSTALL_STRIP_PROGRAM = $(install_sh) -c -s
LD = /opt/condor/lib/ld
ERROR: Internal ld was not invoked!
ERROR: Executable may not be linked properly for Condor!
ERROR: For users of Condor on Linux, we highly recommend
ERROR: using the default compiler that came with the
ERROR: distribution. Usually placing /usr/bin first in
ERROR: your path will remedy this error.
ERROR: To learn more about this error, visit this web page:
ERROR: http://www.cs.wisc.edu/condor/manual/faq.html
ERROR: and read the FAQ entry about this problem for your
ERROR: revision of Condor. -m elf_x86_64
LDFLAGS =
following the advice of Ralf, in the last thread, I configured using
$ ./configure --enable-condor LD=/opt/condor/lib/ld
which resulted in no warnings displayed during configure, but the
following during make:
Making all in src
make[1]: Entering directory `/home/ram/condor_libtool-0.1/src'
condor_compile gcc -std=gnu99 -DPACKAGE_NAME=\"condor_libtool\"
-DPACKAGE_TARNAME=\"condor_libtool\" -DPACKAGE_VERSION=\"0.1\"
-DPACKAGE_STRING=\"condor_libtool\ 0.1\"
-DPACKAGE_BUGREPORT=\"adam.mer...@ligo.org\" -DPACKAGE_URL=\"\"
-DPACKAGE=\"condor_libtool\" -DVERSION=\"0.1\" -DSTDC_HEADERS=1
-DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1
-DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1
-DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1
-DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -I. -g -O2 -MT foo.o -MD
-MP -MF .deps/foo.Tpo -c -o foo.o foo.c
/opt/condor/bin/condor_compile: line 331: [: too many arguments
gcc: 0.1": No such file or directory
make[1]: *** [foo.o] Error 1
make[1]: Leaving directory `/home/ram/condor_libtool-0.1/src'
make: *** [all-recursive] Error 1
which to me looks like condor_compile is c
Re: Security fix for libtool
* Bob Friesenhahn (bfrie...@simple.dallas.tx.us) [20091124 18:34]: > >I'm maintaining libtool for SuSE/Novell and have a problem where I would > >need help from upstreams. You just released 2.2.6a to fix the local load > >problem. > > You need 2.2.6b (not 'a'!) to fix the problem. Sorry, I did mean 'b' not 'a'. > A patch for 1.5.26 does exist (see > "http://lists.gnu.org/archive/html/libtool/2009-11/msg00065.html";). That's very good news indeed. > There is no patch for 1.4.X versions. What I have are 1.5.2, 1.5.22 and 1.5.26 and at least for the last one a solution exists. That leaves only two to really care for. > perhaps late '99 have the issue so this is a good time to try to > upgrade libltdl to a consistent modern version. For released distributions, specially the server products this is out of the question, though I would prefer that too. > That said, there is cause for concern under Linux, but (usually) no > need for alarm. And thanks for your answer! Philipp ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Security fix for libtool
On Tue, 24 Nov 2009, Philipp Thomas wrote: I'm maintaining libtool for SuSE/Novell and have a problem where I would need help from upstreams. You just released 2.2.6a to fix the local load problem. You need 2.2.6b (not 'a'!) to fix the problem. If the local load problem does affect 1.5.x I need help in coming up with a patch as I can't do a version update for older released products. A patch for 1.5.26 does exist (see "http://lists.gnu.org/archive/html/libtool/2009-11/msg00065.html";). There is no patch for 1.4.X versions. All versions of libltdl since perhaps late '99 have the issue so this is a good time to try to upgrade libltdl to a consistent modern version. 1.5.26 with the patch should be modern enough for existing distributions but of course updating to libtool 2.2.6b is preferred due to the huge number of libtool improvements. That said, there is cause for concern under Linux, but (usually) no need for alarm. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Security fix for libtool
I'm maintaining libtool for SuSE/Novell and have a problem where I would need help from upstreams. You just released 2.2.6a to fix the local load problem. The CVE says that libtool 1.x is also affected but sources have changed enough so that the fix for 2.x can't be applied. In particular the libtool 1.5.x source has a tryall_dlopen that only takes two parameters. If the local load problem does affect 1.5.x I need help in coming up with a patch as I can't do a version update for older released products. Philipp ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Understanding libtool on Windows / MinGW
Bob Friesenhahn writes: > I suggest that you look into the issue of throwing C++ exceptions past > DLL boundaries. This seems to be a complex issue for Windows with > several solutions, none of which are perfect. Due to these issues, it > is not unusual for a DLL version of libstdc++ to be missing. Well, the problem is not that there is no dynamic libstdc++ - as you say, that's a feature. The problem is that the .la file says there is. I suppose the maintainers built both static and shared versions of libstdc++, then removed the dynamic version before rolling the tarball. Older versions of MinGW have a .la file with an empty library_names, and that works fine. In the end, I had to downgrade MinGW anyway (for compatibility reasons), so my immediate problem is solved, and I understand libtool a little bit better, though still not as well as I'd like. DES -- Dag-Erling Smørgrav - d...@des.no ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Understanding libtool on Windows / MinGW
Bob Friesenhahn writes: > Dag-Erling Smørgrav writes: > > I never said I had trouble linking with libjpeg. I said I could not > > *build* libjpeg using the workaround I found floating around on the net, > > which convinced me that the workaround is wrong. > I am the developer of JPEG 7's autotools-based build so if there is a > problem with it, I would want to help get it fixed. There is no problem with jpeg7, there is a problem with incorrect advice I found floating on the net about how to fix the libstdc++ issue. It did fix libstdc++, but broke everything else (and jpeg7 more visibly than other things). These are not the droids you are looking for :) DES -- Dag-Erling Smørgrav - d...@des.no ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Understanding libtool on Windows / MinGW
On Wed, 18 Nov 2009, Dag-Erling Smørgrav wrote: I have libjpeg 7 installed as a shared library under MinGW and have not noticed any problems linking with it. I never said I had trouble linking with libjpeg. I said I could not *build* libjpeg using the workaround I found floating around on the net, which convinced me that the workaround is wrong. I am the developer of JPEG 7's autotools-based build so if there is a problem with it, I would want to help get it fixed. Unfortunately, I have not encountered a problem with building JPEG 7 under MinGW. The GCC 4.4.0 under MinGW seems suspect since it would be a "bleeding edge" version with a lot of zeros. I am using GCC 3.2.3 and 4.4.1 here. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Understanding libtool on Windows / MinGW
Dag-Erling Smørgrav writes: > I still wish someone would answer the questions I asked... I should amend that - Bob did answer one of them, plus another I hadn't asked because I didn't know it needed asking, and for that I'm grateful to him. I still need help with the other three, though. DES -- Dag-Erling Smørgrav - d...@des.no ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Understanding libtool on Windows / MinGW
Vincent Torri writes: > Dag-Erling Smørgrav writes: > > Bob Friesenhahn writes: > > > You did not mention the version of libtool you are using. > > 2.2.7a, that's what currently ships with MinGW. > 2.2.7a ? a git version ? Yep. I must admit I didn't pay much attention to the version number until Bob asked. I still wish someone would answer the questions I asked... DES -- Dag-Erling Smørgrav - d...@des.no ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Understanding libtool on Windows / MinGW
On Wed, 18 Nov 2009, Dag-Erling Smørgrav wrote: Bob Friesenhahn writes: You did not mention the version of libtool you are using. This may be obtained from 'libtool --version'. The current version is 2.2.6b. 2.2.7a, that's what currently ships with MinGW. 2.2.7a ? a git version ? Vincent Torri___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Understanding libtool on Windows / MinGW
Bob Friesenhahn writes: > You did not mention the version of libtool you are using. This may be > obtained from 'libtool --version'. The current version is 2.2.6b. 2.2.7a, that's what currently ships with MinGW. > I have libjpeg 7 installed as a shared library under MinGW and have > not noticed any problems linking with it. I never said I had trouble linking with libjpeg. I said I could not *build* libjpeg using the workaround I found floating around on the net, which convinced me that the workaround is wrong. DES -- Dag-Erling Smørgrav - d...@des.no ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Understanding libtool on Windows / MinGW
On Mon, 16 Nov 2009, Dag-Erling Smørgrav wrote: Fifth question: can someone give a concise explanation of what, exactly, -no-undefined does, and why it is required? This option is an indication that the application is fully prepared to resolve all symbols at link time. One requirement for this is that all libraries that the DLL depends on be specified at link time. This is a reason why libstdc++ also needs to be supplied at link time. Libtool normally refuses to a static library into a DLL since that would cause a lot of problems. You did not mention the version of libtool you are using. This may be obtained from 'libtool --version'. The current version is 2.2.6b. I have libjpeg 7 installed as a shared library under MinGW and have not noticed any problems linking with it. There are many versions of MinGW and many versions of libtool and some work better than others. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Understanding libtool on Windows / MinGW
On Mon, 16 Nov 2009, Dag-Erling Smørgrav wrote: Second question: there is no libstdc++.dll.a; is this a mistake on the part of the MinGW maintainers? I suggest that you look into the issue of throwing C++ exceptions past DLL boundaries. This seems to be a complex issue for Windows with several solutions, none of which are perfect. Due to these issues, it is not unusual for a DLL version of libstdc++ to be missing. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/___ http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 2.2.6b released
On Mon, 16 Nov 2009, Jeff Squyres wrote: Congrats on the release! I'm a little confused by the version number, though. 2.2.6a was explicitly billed as a packaging change vs. 2.2.6. This was also the rationale provided as to why the "a" suffix was not included in the directory name from the expanded tarball. This new release has the suffix "b" *and* includes "b" in the directory name. This is a departure from prior LT releases where bug fixes incremented the minor number -- I expected this release to be 2.2.7. I also noticed that the 'a' release was not propagated into the directory name. I am not sure if this is a bug according to FSF rules, but it seems like a defect if source packages can not be extracted to the same directory without overwriting each other, and for this instance it is quite useful if 'libtool --version' includes the 'b' so I tend to be happy with 'b'. We should thank Peter for donating his weekend to the task of cutting the release. What is done is done and the current focus from libtool 2.2.X users should be to make sure that any libltdl embedded in their own packages matches this version. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ _______ http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 2.2.6b released
On 11/16/2009 09:32 AM, Jeff Squyres wrote: On Nov 16, 2009, at 7:21 AM, Peter O'Gorman wrote: We are intending to release 2.2.8 sometime (hopefully soon) with all the new features and lots of bug fixes from git HEAD. So why not call this release 2.2.8 and bump the version number of the next one to 2.2.10? Is it technically difficult to do so? Because I never thought to do so. My only point is that the last 2 public releases of LT have had semantically different meanings of the version number. It is therefore VERY unclear that 2.2.6b is a significant security/bug fix release (even if the actual changes are minor). If I (a random user) saw that LT released 2.2.6b but didn't read anything in the notes, I'd assume that it was another packaging change, like 2.2.6a was. I certainly would not immediately grok that it contains a security update. I agree with your points, and had I put any thought at all into version numbering I would have done it differently. Apologies all around. Peter -- Peter O'Gorman http://pogma.com ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 2.2.6b released
On Nov 16, 2009, at 7:21 AM, Peter O'Gorman wrote: We are intending to release 2.2.8 sometime (hopefully soon) with all the new features and lots of bug fixes from git HEAD. So why not call this release 2.2.8 and bump the version number of the next one to 2.2.10? Is it technically difficult to do so? I ask because version numbers are primarily for users -- not developers. So a little developer discomfort to rename specific releases is (IMHO) acceptable in order to provide a clear, unambiguous meaning of the version number to users. This release only contains two bugfixes to libltdl that were deemed important enough to warrant a separate release from the "stable" 2.2.6 series. Understood. My only point is that the last 2 public releases of LT have had semantically different meanings of the version number. It is therefore VERY unclear that 2.2.6b is a significant security/bug fix release (even if the actual changes are minor). If I (a random user) saw that LT released 2.2.6b but didn't read anything in the notes, I'd assume that it was another packaging change, like 2.2.6a was. I certainly would not immediately grok that it contains a security update. OTOH, if the LT version number was bumped to 2.2.8 -- or even 2.4 -- I would assume that most users will think, "Something important must have changed. I should go a) read the release notes, and b) install this update." (all normal disclaimers on the word "assume", of course ;-) ). My $0.02: the version number of a package is a critical method of communication to the rest of the world. It needs to have clear, unambiguous meaning. The last 2 releases of LT have significantly muddied the waters as to what the 3rd field in the LT version number means. Can you clarify what exactly the minor number and suffix mean in the LT version number (for the purposes of understanding future releases)? Sidenote: it's easy for email threads like this to get sidetracked into flamewars. Please understand that I'm a long-time/loyal LT user and greatly appreciate all your efforts -- I'm *NOT* trying to start a flamewar. I sent this email (and the emails back when 2.2.6a was released) not to be a jerk, but rather to ask a genuine user- perspective question and hopefully get some clarity for the future. Thanks! -- Jeff Squyres jsquy...@cisco.com _______ http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 2.2.6b released
On 11/16/2009 09:18 AM, Jeff Squyres wrote: Congrats on the release! I'm a little confused by the version number, though. 2.2.6a was explicitly billed as a packaging change vs. 2.2.6. This was also the rationale provided as to why the "a" suffix was not included in the directory name from the expanded tarball. This new release has the suffix "b" *and* includes "b" in the directory name. We are intending to release 2.2.8 sometime (hopefully soon) with all the new features and lots of bug fixes from git HEAD. This release only contains two bugfixes to libltdl that were deemed important enough to warrant a separate release from the "stable" 2.2.6 series. Peter -- Peter O'Gorman http://pogma.com ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 2.2.6b released
Congrats on the release! I'm a little confused by the version number, though. 2.2.6a was explicitly billed as a packaging change vs. 2.2.6. This was also the rationale provided as to why the "a" suffix was not included in the directory name from the expanded tarball. This new release has the suffix "b" *and* includes "b" in the directory name. This is a departure from prior LT releases where bug fixes incremented the minor number -- I expected this release to be 2.2.7. Has LT changed its version numbering scheme? More specifically -- what exactly do the minor version number and suffix now represent? Thanks! On Nov 16, 2009, at 7:07 AM, Peter O'Gorman wrote: We are pleased to announce the release of GNU Libtool 2.2.6b. GNU Libtool hides the complexity of using shared libraries behind a consistent, portable interface. GNU Libtool ships with GNU libltdl, which hides the complexity of loading dynamic runtime libraries (modules) behind a consistent, portable interface. This release is a bug fix release for version 2.2.6. The following bugs are fixed: - Fixed libltdl to no longer attempt to dlopen() the old_library listed in the .la file. Now will use only the preopen loader to attempt to load it. This may be a security issue, all users are advised to upgrade. - Similarly, don't open module.la from the current directory, this changes the behavior of libltdl to match the documentation. libtool-2.2.6b is available now from ftp.gnu.org, along with diffs against libtool-2.2.6a. Please use a mirror to reduce stress on the main gnu machine: http://www.gnu.org/order/ftp.html Here are the compressed sources: ftp://ftp.gnu.org/gnu/libtool/libtool-2.2.6b.tar.gz ftp://ftp.gnu.org/gnu/libtool/libtool-2.2.6b.tar.lzma Here are the diffs against libtool-2.2.6a: ftp://ftp.gnu.org/gnu/libtool/libtool-2.2.6a-2.2.6b.diff.gz The MD5 and SHA1 checksums are: libtool-2.2.6b.tar.gz 07da460450490148c6d2df0f21481a25 libtool-2.2.6b.tar.lzma a4b36980765003b47dd75ac9429f4f11 libtool-2.2.6a-2.2.6b.diff.gz a485788eb8fac09f7bb19b9f471ecf16 libtool-2.2.6b.tar.gz 5afa73c8ef9ebe64bbb438a0f8779c9036e43c55 libtool-2.2.6b.tar.lzma 18baaac89eed8be7bd2af2d2181598e176029cc6 libtool-2.2.6a-2.2.6b.diff.gz 161b4f775d2e17890a25fd791c2deb3a69dcf293 This release was bootstrapped with automake-1.11 and autoconf-2.64. You can fetch the unbootstrapped source code with git by using the following commands: $ git clone git://git.savannah.gnu.org/libtool.git $ cd libtool $ git checkout v2.2.6b Please report bugs to , along with the verbose output of any failed test groups, and the output from `./libtool --config.' The README file explains how to capture the verbose test output. -- Jeff Squyres jsquy...@cisco.com ___ http://lists.gnu.org/mailman/listinfo/libtool
GNU Libtool 2.2.6b released
We are pleased to announce the release of GNU Libtool 2.2.6b. GNU Libtool hides the complexity of using shared libraries behind a consistent, portable interface. GNU Libtool ships with GNU libltdl, which hides the complexity of loading dynamic runtime libraries (modules) behind a consistent, portable interface. This release is a bug fix release for version 2.2.6. The following bugs are fixed: - Fixed libltdl to no longer attempt to dlopen() the old_library listed in the .la file. Now will use only the preopen loader to attempt to load it. This may be a security issue, all users are advised to upgrade. - Similarly, don't open module.la from the current directory, this changes the behavior of libltdl to match the documentation. libtool-2.2.6b is available now from ftp.gnu.org, along with diffs against libtool-2.2.6a. Please use a mirror to reduce stress on the main gnu machine: http://www.gnu.org/order/ftp.html Here are the compressed sources: ftp://ftp.gnu.org/gnu/libtool/libtool-2.2.6b.tar.gz ftp://ftp.gnu.org/gnu/libtool/libtool-2.2.6b.tar.lzma Here are the diffs against libtool-2.2.6a: ftp://ftp.gnu.org/gnu/libtool/libtool-2.2.6a-2.2.6b.diff.gz The MD5 and SHA1 checksums are: libtool-2.2.6b.tar.gz 07da460450490148c6d2df0f21481a25 libtool-2.2.6b.tar.lzma a4b36980765003b47dd75ac9429f4f11 libtool-2.2.6a-2.2.6b.diff.gz a485788eb8fac09f7bb19b9f471ecf16 libtool-2.2.6b.tar.gz 5afa73c8ef9ebe64bbb438a0f8779c9036e43c55 libtool-2.2.6b.tar.lzma 18baaac89eed8be7bd2af2d2181598e176029cc6 libtool-2.2.6a-2.2.6b.diff.gz 161b4f775d2e17890a25fd791c2deb3a69dcf293 This release was bootstrapped with automake-1.11 and autoconf-2.64. You can fetch the unbootstrapped source code with git by using the following commands: $ git clone git://git.savannah.gnu.org/libtool.git $ cd libtool $ git checkout v2.2.6b Please report bugs to , along with the verbose output of any failed test groups, and the output from `./libtool --config.' The README file explains how to capture the verbose test output. ___ http://lists.gnu.org/mailman/listinfo/libtool
Understanding libtool on Windows / MinGW
I am currently porting a largish piece of software from Linux to Windows, and I'm having trouble compiling some of the third-party libraries it requires. (before you ask: yes, I have to compile most of these libraries myself; this is not the issue here.) I realize that this comes up regularly, but I haven't found a unified, coherent explanation or solution. I am asking these questions not just to find a solution to my immediate problem, but to find the *correct* solution (as opposed to all the wrong ones Google dug up for me), and to truly *understand* why it is the correct one. Let's start with the first indication I had that something was not as it should be. While building the C++ bindings for HDF5 (after fixing a few other bugs), I got this: libtool: link: g++ -o .libs/dsets.exe dsets.o h5cpputil.o ../../test/.libs/libh5test.a ../../c++/src/.libs/libhdf5_cpp.a /mingw/lib/gcc/mingw32/4.4.0/libstdc++.dll.a ../../src/.libs/libhdf5.a -lws2_32 -L/mingw/lib/gcc/mingw32/4.4.0 g++.exe: C:/MinGW/lib/gcc/mingw32/4.4.0/libstdc++.dll.a: No such file or directory First question: why is libtool linking *explicitly* against libstdc++? I noticed that configure decided that this was necessary, but the first thing I did after installing MinGW was compile "hello world" programs in C, C++ and Fortran, and gcc / g++ / gfortran had no trouble linking them without explicit references to libc / libstdc++ / libgfortran. Second question: there is no libstdc++.dll.a; is this a mistake on the part of the MinGW maintainers? Third question: what are the expected library names when building with the GNU toolchain on Windows? I expected ".a" for the static library, ".dll" for the shared library and ".lib" for the import library. Apparently, I was wrong. (I probably knew this at some point, but it's been ten years since I did any serious development work on Windows, and back then, I used an IDE that did it all for me) Fourth question: when I googled for solutions to this problem, what I found (again and again) was "replace library_names='whatever.dll.a' in the .la file with library_names=''". Somehow, I don't think libtool would consistently set library_names to an incorrect value; if it had at some point, surely it would have been fixed by now. Therefore, that advice must be incorrect. This hypothesis was strengthened when I found that jpeg7 won't link with this hack (not as in "libtool fails to link programs that use libjpeg", but as in: libtool fails to link libjpeg") Fifth question: can someone give a concise explanation of what, exactly, -no-undefined does, and why it is required? DES -- Dag-Erling Smørgrav - d...@des.no ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool option to build both static and shared?
On Thu, 12 Nov 2009, Stepan Kasal wrote: This is the solution which currently does work, as long as the OS, tools, and libraries are capable of it. Note that using --disable-static is not portable so attempting to force only a shared build decreases portability. [...] I understand that building shared library only is something that is not portable, because it is not possible. Sometimes it is due to limitations in the language run-time environment. For example, it has been a common problem that the C++ standard library provided with GCC is static under Windows due a problem with throwing exceptions across DLL boundaries. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool option to build both static and shared?
Hi Stepan, * Stepan Kasal wrote on Thu, Nov 12, 2009 at 05:11:00PM CET: > A project contains sources for several libraries. Most of them > should be built as shared libraries only, but one of them is to be > built both as a shared library and as a static one. > > The user would like to use LT_INIT([disable-static]) That won't work portably. If you disable one of the types here, then possibly some (system-dependent) configure tests may be omitted, which means you may run into trouble enabling the type later. This remark definitely holds for disable-shared. With disable-static I'm not sure without checking the sources, but it's prudent to assume the same. Instead, I'd suggest to just add --tag=disable-static to AM_LIBTOOLFLAGS or the per-target special (such as libfoo_la_LIBTOOLFLAGS). > and then > override the *FLAGS in the subdirectory containing the library that > needs to be available in both forms. He tried to use -static and > -shared together, but it did not work. (This is the documented > behaviour; though an error message from libtool might help to get > this obvious.) > Is there an option that would tell libtool to "build both", even > though it was configured with --disable-static? Not portably; see above. > I invented a solution that should work: configure with > --enable-static and then use -shared in CFLAGS or AM_CFLAGS for all > but libraries but that one. I could recommend this solution to the > user, but I feel that the solution outlined above would be more > comfortable. Yeah, something like this seems necessary. Cheers, Ralf _______ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool option to build both static and shared?
Hello Bob, thank you for your answer. On Thu, Nov 12, 2009 at 10:50:03AM -0600, Bob Friesenhahn wrote: > On Thu, 12 Nov 2009, Stepan Kasal wrote: >> >> Is there an option that would tell libtool to "build both", even >> though it was configured with --disable-static? >> >> I invented a solution that should work: configure with >> --enable-static and then use -shared in CFLAGS or AM_CFLAGS for all >> but libraries but that one. I could recommend this solution to the >> user, but I feel that the solution outlined above would be more >> comfortable. > > This is the solution which currently does work, as long as the OS, > tools, and libraries are capable of it. Note that using > --disable-static is not portable so attempting to force only a shared > build decreases portability. [...] I understand that building shared library only is something that is not portable, because it is not possible. > You may encounter similar issues on Unix system if > there is dependence on an installed library which does not have a shared > version available. This is a twofold example. When building a package for a GNU/Linux distribution, the --disable-static behaviour is always desirable. If a build of shared library fails, it is always necessary to fix the build environment so that dynamic linking is possible. It would be really evil if the build silently falled back to static linking. Anyway, back to the problem: Though the original reporter probably does not care, the solution should not compromise portability of the generated tarball. From that point of view, it is not desirable to set AM_CFLAGS=-shared in most subdirs of the project. It is better to override CFLAGS at build time. But the dreamed of solution would still be better, even from the portability angle: The library that needs to be built also as static one, say libfoo, would have: libfoo_la_CFLAGS = -static-and-shared With that, even if the project were configured as --disable-static, this one library would fall back to the previous default, which is to build both staic and shared if possible. Would it make sense to add this type of option to libtool? Or is it more consistent to keep things as they are and shoft the problem to the user, so that README would instruct him how to manipulate CFLAGS during the build? Actually is it wise to try to encode this static/shared combination into the tarball? Can it be understood as a property of the package (libfoo is a compatibility one, should be available as static lib on most platforms), or is it a platform specific issue, so that shifting the problem to the user of the tarball is the right thing to do? Happy hacking, Stepan ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool option to build both static and shared?
On Thu, 12 Nov 2009, Stepan Kasal wrote: Is there an option that would tell libtool to "build both", even though it was configured with --disable-static? I invented a solution that should work: configure with --enable-static and then use -shared in CFLAGS or AM_CFLAGS for all but libraries but that one. I could recommend this solution to the user, but I feel that the solution outlined above would be more comfortable. This is the solution which currently does work, as long as the OS, tools, and libraries are capable of it. Note that using --disable-static is not portable so attempting to force only a shared build decreases portability. One place I have observed failures with --disable-static is under Microsoft Windows since the necessary DLLs are not always available. You may encounter similar issues on Unix system if there is dependence on an installed library which does not have a shared version available. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
libtool option to build both static and shared?
Hello, I'd like to ask you to help with the following problem: A project contains sources for several libraries. Most of them should be built as shared libraries only, but one of them is to be built both as a shared library and as a static one. The user would like to use LT_INIT([disable-static]) and then override the *FLAGS in the subdirectory containing the library that needs to be available in both forms. He tried to use -static and -shared together, but it did not work. (This is the documented behaviour; though an error message from libtool might help to get this obvious.) Is there an option that would tell libtool to "build both", even though it was configured with --disable-static? I invented a solution that should work: configure with --enable-static and then use -shared in CFLAGS or AM_CFLAGS for all but libraries but that one. I could recommend this solution to the user, but I feel that the solution outlined above would be more comfortable. Thank you for any help, Stepan Kasal ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool-2 problem: Building a QT3 Designer plugin
I'm learning more about libtool, but maybe I should have mentioned that this source tree is a bit old and made for libtool-1. Still works Ok with LT2, except this one pesky widgets problem. I hate to remove something that worked, even if it's just a plugin for QT3... Thanks. Tim. On Thursday 05 November 2009 10:12:47 pm you wrote: > On Thu, 5 Nov 2009, Tim wrote: > > With libtool-1, no problem, the single .so file > > is built and works with QT3 Designer. > > > > libtool-2, however, insists on linking the runtime > > library (-lrt) with the .so, hence we get an > > error that main() is not found in the .so > > Where does the -lrt come into play? When you compile, two lines are > printed for each linking action; the first is an invocation of libtool, > the second is where libtool invokes the linker/compiler with link flags. > > Does -lrt appear in both lines or just the second? That should help us > bisect the problem. > > Later, > Daniel _______ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool-2 problem: Building a QT3 Designer plugin
Unless my eyesight is going, it's in the second section only. Attached output of the two stages. Thanks. Tim. On Thursday 05 November 2009 10:12:47 pm you wrote: > On Thu, 5 Nov 2009, Tim wrote: > > With libtool-1, no problem, the single .so file > > is built and works with QT3 Designer. > > > > libtool-2, however, insists on linking the runtime > > library (-lrt) with the .so, hence we get an > > error that main() is not found in the .so > > Where does the -lrt come into play? When you compile, two lines are > printed for each linking action; the first is an invocation of libtool, > the second is where libtool invokes the linker/compiler with link flags. > > Does -lrt appear in both lines or just the second? That should help us > bisect the problem. > > Later, > Daniel /bin/sh ../../libtool --tag=CXX --mode=link g++ -g -fno-exceptions -Wall -W -D_GNU_SOURCE -D_REENTRANT -DQT_CLEAN_NAMESPACE -DQT_NO_COMPAT -I../.. -I../../muse/widgets -I/usr/lib/qt3/include -O3 -fomit-frame-pointer -ffast-math -fstrength-reduce -funroll-loops -mtune=pentium4 -march=pentium4 -I.. -I../../synti -I../../muse/widgets -DQT_SHARED -DQT_THREAD_SUPPORT -DQT_PLUGIN -g --whole-archive -fno-exceptions -shared -Wl,-soname,libmusewidgetsplugin.so.1 -L/usr/lib/qt3/lib -lqt-mt -lqui -lasound -o musewidgetsplugin.so musewidgetsplugin_so-musewidgetsplug.o musewidgetsplugin_so-xml.o musewidgetsplugin_so-tempo.o musewidgetsplugin_so-sig.o musewidgetsplugin_so-pos.o musewidgetsplugin_so-moc_posedit.non-libtool.o musewidgetsplugin_so-moc_poslabel.non-libtool.o musewidgetsplugin_so-moc_sigedit.non-libtool.o musewidgetsplugin_so-moc_pitchedit.non-libtool.o musewidgetsplugin_so-moc_pitchlabel.non-libtool.o musewidgetsplugin_so-moc_tempolabel.non-libtool.o musewidgetsplugin_so-posedit.non-libtool.o musewidgetsplugin_so-poslabel.non-libtool.o musewidgetsplugin_so-pitchedit.non-libtool.o musewidgetsplugin_so-pitchlabel.non-libtool.o musewidgetsplugin_so-sigedit.non-libtool.o musewidgetsplugin_so-tempolabel.non-libtool.o musewidgetsplugin_so-slider.non-libtool.o musewidgetsplugin_so-moc_slider.non-libtool.o musewidgetsplugin_so-sliderbase.non-libtool.o musewidgetsplugin_so-moc_sliderbase.non-libtool.o musewidgetsplugin_so-sclif.non-libtool.o musewidgetsplugin_so-scldiv.non-libtool.o musewidgetsplugin_so-mmath.non-libtool.o musewidgetsplugin_so-scldraw.non-libtool.o musewidgetsplugin_so-dimap.non-libtool.o musewidgetsplugin_so-drange.non-libtool.o musewidgetsplugin_so-doublelabel.non-libtool.o musewidgetsplugin_so-moc_doublelabel.non-libtool.o musewidgetsplugin_so-dentry.non-libtool.o musewidgetsplugin_so-moc_dentry.non-libtool.o musewidgetsplugin_so-checkbox.non-libtool.o musewidgetsplugin_so-moc_checkbox.non-libtool.o musewidgetsplugin_so-combobox.non-libtool.o musewidgetsplugin_so-moc_combobox.non-libtool.o -lasound -lm -ldl -L/usr/lib/qt3/lib -lqt-mt -lqui libtool: link: g++ -g -fno-exceptions -Wall -W -D_GNU_SOURCE -D_REENTRANT -DQT_CLEAN_NAMESPACE -DQT_NO_COMPAT -I../.. -I../../muse/widgets -I/usr/lib/qt3/include -O3 -fomit-frame-pointer -ffast-math -fstrength-reduce -funroll-loops -mtune=pentium4 -march=pentium4 -I.. -I../../synti -I../../muse/widgets -DQT_SHARED -DQT_THREAD_SUPPORT -DQT_PLUGIN -g --whole-archive -fno-exceptions -Wl,-soname -Wl,libmusewidgetsplugin.so.1 -o musewidgetsplugin.so musewidgetsplugin_so-musewidgetsplug.o musewidgetsplugin_so-xml.o musewidgetsplugin_so-tempo.o musewidgetsplugin_so-sig.o musewidgetsplugin_so-pos.o musewidgetsplugin_so-moc_posedit.non-libtool.o musewidgetsplugin_so-moc_poslabel.non-libtool.o musewidgetsplugin_so-moc_sigedit.non-libtool.o musewidgetsplugin_so-moc_pitchedit.non-libtool.o musewidgetsplugin_so-moc_pitchlabel.non-libtool.o musewidgetsplugin_so-moc_tempolabel.non-libtool.o musewidgetsplugin_so-posedit.non-libtool.o musewidgetsplugin_so-poslabel.non-libtool.o musewidgetsplugin_so-pitchedit.non-libtool.o musewidgetsplugin_so-pitchlabel.non-libtool.o musewidgetsplugin_so-sigedit.non-libtool.o musewidgetsplugin_so-tempolabel.non-libtool.o musewidgetsplugin_so-slider.non-libtool.o musewidgetsplugin_so-moc_slider.non-libtool.o musewidgetsplugin_so-sliderbase.non-libtool.o musewidgetsplugin_so-moc_sliderbase.non-libtool.o musewidgetsplugin_so-sclif.non-libtool.o musewidgetsplugin_so-scldiv.non-libtool.o musewidgetsplugin_so-mmath.non-libtool.o musewidgetsplugin_so-scldraw.non-libtool.o musewidgetsplugin_so-dimap.non-libtool.o musewidgetsplugin_so-drange.non-libtool.o musewidgetsplugin_so-doublelabel.non-libtool.o musewidgetsplugin_so-moc_doublelabel.non-libtool.o musewidgetsplugin_so-dentry.non-libtool.o musewidgetsplugin_so-moc_dentry.non-libtool.o musewidgetsplugin_so-checkbox.non-libtool.o musewidgetsplugin_so-moc_checkbox.non-libtool.o musewidgetsplugin_so-combobox.non-libtool.o musewidgetsplugin_so-moc_combobox.non-libtool.o -L/usr/lib/qt
Re: libtool-2 problem: Building a QT3 Designer plugin
On Thu, 5 Nov 2009, Tim wrote: With libtool-1, no problem, the single .so file is built and works with QT3 Designer. libtool-2, however, insists on linking the runtime library (-lrt) with the .so, hence we get an error that main() is not found in the .so Where does the -lrt come into play? When you compile, two lines are printed for each linking action; the first is an invocation of libtool, the second is where libtool invokes the linker/compiler with link flags. Does -lrt appear in both lines or just the second? That should help us bisect the problem. Later, Daniel ___ http://lists.gnu.org/mailman/listinfo/libtool
libtool-2 problem: Building a QT3 Designer plugin
Hello, hope I'm asking the right list... In muse (the audio/midi recording app), we have an .am file which is to build a single standalone musewidgetsplugin.so file, which can makes muse widgets available to QT3 Designer. With libtool-1, no problem, the single .so file is built and works with QT3 Designer. libtool-2, however, insists on linking the runtime library (-lrt) with the .so, hence we get an error that main() is not found in the .so I have tried to rework the .am file to make a LT library instead. What I end up with is an .so, an .la, and .a, and QT3 doesn't recognize them even if I dump them all into QT3's plugin/designer directory. When I compare the original libtool-1 generated .so with the one I tried to make with libtool-2 and my re-worked .am file, they are quite different sizes and contents. Can anyone help me out here? I have attached the original .am file, and my attempted rework .am file. You will see two 'sections'. One builds a convenience library libwidgets.a (no trouble there). The other section builds the .so plugin library. In my attempted rework, I have renamed the plugin from musewidgetsplugin to libmusewidgetsplugin, to satisfy naming conventions. Thanks kindly. Tim. include $(top_srcdir)/common.am # musewidgetsplugin_so_CPPFLAGS = $(MUSECXXFLAGS) -fPIC -I.. -I$(top_srcdir)/synti \ # -DQT_THREAD_SUPPORT -DQT_SHARED -DQT_PLUGIN #libmusewidgetsplugin_la_CPPFLAGS = $(MUSECXXFLAGS) -fPIC -I.. -I$(top_srcdir)/synti \ # -DQT_THREAD_SUPPORT -DQT_SHARED -DQT_PLUGIN libwidgets_a_CPPFLAGS = $(MUSECXXFLAGS) -I.. -I$(top_srcdir)/synti if PCH libwidgets_a_CPPFLAGS += -include $(top_srcdir)/all.h ## musewidgetsplugin_so_CPPFLAGS += -include $(top_srcdir)/all-pic.h ##libmusewidgetsplugin_la_CPPFLAGS += -include $(top_srcdir)/all-pic.h endif noinst_LIBRARIES = libwidgets.a dist_libwidgets_a_SOURCES = \ utils.cpp utils.h \ citem.cpp citem.h \ vscale.cpp vscale.h \ drange.cpp drange.h \ sclif.cpp sclif.h \ dimap.cpp dimap.h \ scldiv.cpp scldiv.h \ mmath.cpp mmath.h \ scldraw.cpp scldraw.h \ action.h \ \ scrollscale.cpp scrollscale.h \ view.cpp view.h \ nentry.cpp nentry.h \ mtscale.cpp mtscale.h \ sigscale.cpp sigscale.h \ hitscale.cpp hitscale.h \ intlabel.cpp intlabel.h \ doublelabel.cpp doublelabel.h \ canvas.cpp canvas.h \ noteinfo.cpp noteinfo.h \ dentry.cpp dentry.h \ siglabel.cpp siglabel.h \ ttoolbar.cpp ttoolbar.h \ ttoolbutton.cpp ttoolbutton.h \ tb1.cpp tb1.h \ lcombo.cpp lcombo.h \ swidget.cpp swidget.h \ tempolabel.cpp tempolabel.h \ tools.cpp tools.h \ fontsel.cpp fontsel.h \ ctrlcombo.cpp ctrlcombo.h \ sliderbase.cpp sliderbase.h \ slider.cpp slider.h \ midisyncimpl.cpp midisyncimpl.h \ header.cpp header.h \ knob.cpp knob.h \ mlabel.cpp mlabel.h \ genset.cpp genset.h \ mixdowndialog.cpp mixdowndialog.h \ spinboxFP.cpp spinboxFP.h \ spinbox.cpp spinbox.h \ comboQuant.cpp comboQuant.h \ bigtime.cpp bigtime.h \ comment.cpp comment.h \ splitter.cpp splitter.h \ gatetime.cpp gatetime.h \ velocity.cpp velocity.h \ metronome.cpp metronome.h \ posedit.cpp posedit.h section.h \ pitchedit.cpp pitchedit.h \ pitchlabel.cpp pitchlabel.h \ poslabel.cpp poslabel.h \ filedialog.cpp filedialog.h \ sigedit.cpp sigedit.h \ shortcutconfig.cpp shortcutconfig.h \ shortcutcapturedialog.cpp shortcutcapturedialog.h \ combobox.cpp combobox.h \ checkbox.cpp checkbox.h \ listitem.h menutitleitem.h \ \ midisync.ui \ gensetbase.ui \ mixdowndialogbase.ui \ transposebase.ui \ transformbase.ui \ appearancebase.ui \ itransformbase.ui \ commentbase.ui \ synthconfigbase.ui \ gatetimebase.ui \ velocitybase.ui \ metronomebase.ui \ mtrackinfobase.ui \ wtrackinfobase.ui \ editctrl7dialogbase.ui \ editmetadialogbase.ui \ editnotedialogbase.ui \ editsysexdialogbase.ui \ cliplisteditorbase.ui \ mittransposebase.ui \ fdialogbuttons.ui \ shortcutconfigbase.ui \ shortcutcapturedialogbase.ui \ aboutbox.ui \ configmidifilebase.ui nodist_libwidgets_a_SOURCES = \ moc_scrollscale.cpp \ moc_view.cpp \ moc_nentry.cpp \ moc_mtscale.cpp \ moc_sigscale.cpp \ moc_hitscale.cpp \ moc_intlabel.cpp \ moc_doublelabel.cpp \ moc_canvas.cpp \ moc_noteinfo.cpp \ moc_dentry.cpp \ moc_siglabel.cpp \ moc_ttoolbar.cpp \ moc_ttoolbutton.cpp \ moc_tb1.cpp \ moc_lcombo.cpp \ moc_swidget.cpp \ moc_tempolabel.cpp \ moc_tools.cpp \ moc_fontsel.cpp \ moc_ctrlcombo.cpp \ moc_sliderbase.cpp \ moc_slider.cpp \ moc_midisyncimpl.cpp \ moc_header.cpp \ moc_knob.cpp \ moc_mlabel.cpp \ moc_genset.cpp \ moc_mixdowndialog.cpp \ moc_spinboxFP.cpp \ moc_spinbox.cpp \ moc_comboQuant.cpp \ moc_bigtime.cpp \ moc_comment.cpp \ moc_splitter.cpp \ moc_gatetime.cpp \ moc_velocity.cpp \ moc_metronome.cpp \ moc_posedit.cpp \ moc_pitchedit.cpp \ moc_pitchlabel.cpp \ moc_poslabel.cpp \ moc_filedialog.cpp \ moc_sigedit.cpp \ moc_shortcutconfig.cpp \ moc_
[OT] Re: One year since last libtool release
Oops, please elide the i...@new-millenniuminc.com address from future replies on this thread. Seems I've misconfigured my mailer somehow, and it's using a bogus From address :( Cheers, Gary -- Gary V. Vaughan ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: One year since last libtool release
Looking at the code in ltdo.c:try_dlopen(), I see that there is a 'try_preload_only' advise flag. If this flag is set while invoking try_dlopen() with the archive extension in lt_dlopenadvise(), then the spurious dlopens with the archive extension should be gone. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: One year since last libtool release
On Wed, 4 Nov 2009, Ralf Wildenhues wrote: * Bob Friesenhahn wrote on Wed, Nov 04, 2009 at 07:45:56PM CET: I am not sure how one would test for this in an automated fashion since the only effect is a performance reduction. It requires system-dependent tools in order to watch the system calls and see what is actually going on. Well, as a first approximation, both the measuring and the portability aspects can simply be ignored. Just having something that reliably shows the issue for some setup already helps. You can even require root rights; that may prevent most users from ever running the test (which is good!) but will still enable developers to try it out in their sandbox. I really hate to hijack this discussion thread since there were already two discussion threads on this topic. Regardless, what we should expect to see when loading a module which has no additional dependencies is: 1) read somepath/module.la 2) stat somepath/module.so (or whatever dlname was parsed from module.la) 3) dlopen somepath/module.so (or supporting OS calls like open, mmap, etc.) but instead between steps 1 & 2, we see 'stat lostsapaths/module.a' for every path in the system's shared library search path. The reason for this is pretty clear, since libltdl speculatively tries searching for a preloaded module first (necessary for security), but unfortunately, supplies the same argument to all of the available module loaders. Using an existing test case like lt_dlopen.at, when we are loading "./good-plugin.la", the output of a tool like 'truss' (SVR4, Solaris, FreeBSD) or 'strace' (Linux) should not show any attempt to access a file called "good-plugin.a", except for possibly on AIX where a loadable library or module might use the .a extension. It is not normally necessary to require root access to run tools like 'truss' or 'strace' on a process that you own, but special access might be required to run a DTrace-based tool like dtruss. The alternative to the fancy fragile test is to simply fix the problem, which should not be difficult since it is a simple problem. The solution may be to add a flag which indicates that the desired load should be static linkage so that only the preloader processes the request. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ _______ http://lists.gnu.org/mailman/listinfo/libtool
Re: One year since last libtool release
* Bob Friesenhahn wrote on Wed, Nov 04, 2009 at 07:45:56PM CET: > I am not sure how one would test for this in an automated fashion > since the only effect is a performance reduction. It requires > system-dependent tools in order to watch the system calls and see > what is actually going on. Well, as a first approximation, both the measuring and the portability aspects can simply be ignored. Just having something that reliably shows the issue for some setup already helps. You can even require root rights; that may prevent most users from ever running the test (which is good!) but will still enable developers to try it out in their sandbox. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: One year since last libtool release
On Wed, 4 Nov 2009, Ralf Wildenhues wrote: * Bob Friesenhahn wrote on Wed, Nov 04, 2009 at 06:25:26PM CET: We should fix the libltdl performance problem (attempting to dlopen a .a file due to the preloader) before making a release. This is something I am pretty interested in (it causes a HUGE performance hit) so I will be looking into a fix eventually if no one else gets to it first. Will you please write a testcase for this issue first thing you do? If Autotest is too complicated, then just any kind of small reproducible example, but we *need* a test case, and you are in the best position to write it. I am not sure how one would test for this in an automated fashion since the only effect is a performance reduction. It requires system-dependent tools in order to watch the system calls and see what is actually going on. From what I have observed, the minimal run-time for a program which loads and unloads two modules differs by a factor of 5-6X between loading via the .so files, or loading via the .la files. This means that the actual timing difference must be far larger. These slow-down factors are observed under Solaris and FreeBSD, but are likely less under Linux since Linux glibc seems to cache and filter dlopen requests. I am not sure what fraction of the time is wasted due to passing dlopen requests for .a archive files to dlopen, but it is surely large since this is done for all the dependency libraries (e.g. libc) as well. Besides performance, there may be minor security implications since an illicit .a can be inserted anywhere the system searches for libraries, including in LD_LIBRARY_PATH. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: One year since last libtool release
Hi Gary, Bob, all, * Gary V. Vaughan wrote on Wed, Nov 04, 2009 at 05:47:31PM CET: > On 11 Oct 2009, at 07:14, Ralf Wildenhues wrote: > >* Gary V. Vaughan wrote on Fri, Sep 25, 2009 at 01:35:39PM CEST: > >> > >>Not good news I'm afraid. The old testsuite has half a dozen > >>failures > >>or more on several machines, and the new testsuite gets stuck in an > >>infinite loop on some of the others :( I have started doing some regression tests for Libtool in the mean time; first thing I'm primarily looking for regressions over 2.2.6 and issues outside of libltdl, as GCC needs some Libtool fixes pretty soon if they are to make it for 4.5. Things I see don't look all that bad. Several of the failures I see are due to new tests or otherwise better testsuite exposure, and some are due to libltdl only. I'll eventually post what I won't/can't fix. Which brings me to one other point: we need to get libltdl coverage data, and then we desperately need to increase its test coverage. Can you look into the infinite loop, and confirm that it's not just one of those recursive tests that themselves invoke the testsuite and merely take pretty long? * Bob Friesenhahn wrote on Wed, Nov 04, 2009 at 06:25:26PM CET: > We should fix the libltdl performance problem (attempting to dlopen > a .a file due to the preloader) before making a release. This is > something I am pretty interested in (it causes a HUGE performance > hit) so I will be looking into a fix eventually if no one else gets > to it first. Will you please write a testcase for this issue first thing you do? If Autotest is too complicated, then just any kind of small reproducible example, but we *need* a test case, and you are in the best position to write it. Thanks, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: One year since last libtool release
On Wed, 4 Nov 2009, Gary V. Vaughan wrote: Sorry, I temporarily lost access to the machines due to disk failures and then went on holiday for almost 2 weeks. For shame! We should fix the libltdl performance problem (attempting to dlopen a .a file due to the preloader) before making a release. This is something I am pretty interested in (it causes a HUGE performance hit) so I will be looking into a fix eventually if no one else gets to it first. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: One year since last libtool release
Hallo Ralf, On 11 Oct 2009, at 07:14, Ralf Wildenhues wrote: * Gary V. Vaughan wrote on Fri, Sep 25, 2009 at 01:35:39PM CEST: Not good news I'm afraid. The old testsuite has half a dozen failures or more on several machines, and the new testsuite gets stuck in an infinite loop on some of the others :( Rather that do a comprehensive breakdown in one email, I'll get logs of the common failure cases in separate threads presently, and rerun the whole testsuite on a newer snapshot when we've tackled the worst of those. Any chance you could just post the testsuite.log files with failures, even without doing any further analysis, to bug-libtool? That shouldn't be too much work. Sorry, I temporarily lost access to the machines due to disk failures and then went on holiday for almost 2 weeks. I didn't keep the logfiles last time around (I ran everything in GNU screen shells, and when the disks failed my GNU screen died), but I'll find time next weekend to redo and start posting the logs. Cheers, Gary -- Gary V. Vaughan (g...@gnu.org) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Running into cross-compilation issues with libtool (and autoconf) with libusb-0.1.12
In regard to: Re: Running into cross-compilation issues with libtool (and...: On 10/30/2009 01:53 PM, Nick Bowler wrote: On 13:19 Fri 30 Oct , Philip A. Prindeville wrote: The problem is that this is an early linkage on the build host, where the eventual DESTDIR hasn't yet been specified, but the resultant libusbpp.la ends up looking like: I suspect that you have two libtool libraries in the same source tree, with one linked against the other. Chances are, the compiled binaries in the .libs directory are perfectly fine, and libtool is destroying them when you run 'make DESTDIR=/path/to/staging/dir install'. So we have libfoo.la and libbar.la, libbar links with libfoo and. Furthermore, you have a version of libfoo already installed on the host system, in /usr/lib. You cross-compile the package, using --prefix=/usr/lib (since that is where it will finally end up). Then you do 'make DESTDIR=/path/to/staging/dir install', and libtool decides to re-link the libraries against the libraries in the final installed location. In this case, it is /usr/lib. The problem is that the libfoo in /usr/lib is the wrong one, since the cross-compiled libfoo never got installed there! The workaround here is to manually copy the libraries from .libs into your staging directory. IMHO the fix is to make libtool not re-link anything if DESTDIR is set -- correct me if I'm wrong, but it seems to me that the current behaviour cannot possibly be correct on any platform, even on the ones that require re-linking. That sounds about right, actually. Nick *is* right, at least about the scenario that triggers the problem. I've observed this behavior and asked about it on the list in the past. I run into this problem on a regular basis when building software for packaging on Solaris (not cross-compiling, just installing into DESTDIR for packaging). I'm not certain if skipping the relink if DESTDIR is being used is the right fix for all platforms. My guess was that libtool's -inst-prefix-dir option needs to be augmented so that it correctly re-links against the library that it just installed in DESTDIR even though the .la file it will generate should *not* include the DESTDIR part of any paths (it should have the final destination, not the temporary area used for staging). This problem has been with libtool since the -inst-prefix-dir option was added, which I believe happened early in the 1.5.x series. Tim -- Tim Mooney moo...@dogbert.cc.ndsu.nodak.edu Enterprise Computing & Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 _______ http://lists.gnu.org/mailman/listinfo/libtool
Re: Running into cross-compilation issues with libtool (and autoconf) with libusb-0.1.12
On 10/30/2009 01:19 PM, Philip A. Prindeville wrote:
> Howdy.
>
> I'm new to the list, and a bit of a neophyte to using libtool (save your
> groans). I'm the lead developer on the Astlinux distro, so I get to
> dabble in a lot of OSS projects, unfortunately.
>
> I'm trying to fix the somewhat dated package libusb-0.1.12 (it can be
> found at http://sourceforge.net/projects/libusb/files/).
>
> We're doing a modified buildroot cross-compilation under Linux (FC11
> x86_64 in my case) to build an image for a different version of Linux
> (astlinux on an i586 Geode).
>
> The issue is this.
>
> When I build libusb, using a cross-compiler and telling gcc to use an
> alternate prefix, sysroot, etc. libtool is invoked with -rpath /usr/lib
> by the Makefile.am:
>
> http://libusb.svn.sourceforge.net/viewvc/libusb/tags/0.1.12/libusb/Makefile.am?view=markup
>
>
>
> as (in the generated Makefile):
>
> ...
> exec_prefix = ${prefix}
> ...
> libdir = ${exec_prefix}/lib
> ...
>
> libusb.la: $(libusb_la_OBJECTS) $(libusb_la_DEPENDENCIES)
> $(LINK) -rpath $(libdir) $(libusb_la_LDFLAGS) $(libusb_la_OBJECTS)
> $(libusb_la_LIBADD) $(LIBS)
> libusbpp.la: $(libusbpp_la_OBJECTS) $(libusbpp_la_DEPENDENCIES)
> $(CXXLINK) -rpath $(libdir) $(libusbpp_la_LDFLAGS)
> $(libusbpp_la_OBJECTS) $(libusbpp_la_LIBADD) $(LIBS)
>
>
>
> The problem is that this is an early linkage on the build host, where
> the eventual DESTDIR hasn't yet been specified, but the resultant
> libusbpp.la ends up looking like:
>
> ...
> # Directory that this library needs to be installed in:
> libdir='/usr/lib'
> relink_command="(cd /home/philipp/kernel/build_i586/libusb-0.1.12; /bin/sh
> ./libtool --mode=relink
> /home/philipp/kernel/build_i586/staging_dir/bin/i586-linux-uclibc-g++ -Os
> -pipe -fomit-frame-pointer -march=k6-2 -fno-align-functions -fno-align-loops
> -fno-align-jumps -fno-align-labels -iwithprefix /include -iwithprefix
> /usr/include --sysroot=/home/philipp/kernel/build_i586/root
> --sysroot=/home/philipp/kernel/build_i586/staging_dir -o libusbpp.la -rpath
> /usr/lib -version-info 8:4:4 -release 0.1 -export-dynamic -lusb usbpp.lo
> @inst_prefix_dir@)"
>
>
>
> Oddly, the resultant libusb.la doesn't have this same issue, even though
> it also has the same -rpath ... sequence:
>
> ...
> # Directory that this library needs to be installed in:
> libdir='/usr/lib'
>
>
>
> Note the absence of the relink_command definition.
>
> And indeed, when the cross-compiled files are installed on the target
> system, I get:
>
> pbx ~ # ldd /usr/lib/libusbpp-0.1.so.4.4.4 /usr/lib/libusb-0.1.so.4.4.4
> /usr/lib/libusbpp-0.1.so.4.4.4:
> libusb-0.1.so.4 => /usr/lib/libusb-0.1.so.4 (0x)
> libstdc++.so.6 => /lib/libstdc++.so.6 (0x)
> libm.so.6 => not found (0x)
> libc.so.0 => /lib/libc.so.0 (0x)
> libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x)
> libm.so.0 => /lib/libm.so.0 (0x)
> /lib/ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x)
> /usr/lib/libusb-0.1.so.4.4.4:
> libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x)
> libc.so.0 => /lib/libc.so.0 (0x)
> /lib/ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x)
> pbx ~ #
>
>
> So I'm not sure why the libusbpp.so contains references to host file:
>
> libm.so.6
>
> and why libusb.so doesn't.
>
> Running ldconfig ... generates the following output:
>
> ldconfig: /usr/lib/libusbpp-0.1.so.4 appears to be for multiple libc's:
> Invalid argument
> ldconfig: /usr/lib/libusbpp-0.1.so.4.4.4 appears to be for multiple libc's:
> Invalid argument
> ldconfig: /usr/lib/libusbpp.so appears to be for multiple libc's: Invalid
> argument
> ldconfig: /usr/lib/libusbpp-0.1.so.4 appears to be for multiple libc's:
> Invalid argument
> ldconfig: /usr/lib/libusbpp-0.1.so.4.4.4 appears to be for multiple libc's:
> Invalid argument
> ldconfig: /usr/lib/libusbpp.so appears to be for multiple libc's: Invalid
> argument
>
>
>
> I've been chasing this a couple of weeks, but frankly I'm no further
> along and don't know where I should be looking.
>
> Any assistance is appreciated, and I can give out access to the build
> host via .ssh DSA/RSA key.
>
> I'm attaching a trace of the entire build session.
>
> Thanks,
>
> -Philip
>
>
Ok, since this didn't elicit a response, I'll start with a couple of
easier questions:
(1) are there known issues with cross-compilation when it comes to the
link vs. final relink?
(2) why (in this case) are C and C++ programs being handled differently?
Thanks,
-Philip
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Running into cross-compilation issues with libtool (and autoconf) with libusb-0.1.12
On 10/30/2009 01:53 PM, Nick Bowler wrote: > On 13:19 Fri 30 Oct , Philip A. Prindeville wrote: >> The problem is that this is an early linkage on the build host, where >> the eventual DESTDIR hasn't yet been specified, but the resultant >> libusbpp.la ends up looking like: > > I suspect that you have two libtool libraries in the same source tree, > with one linked against the other. Chances are, the compiled binaries > in the .libs directory are perfectly fine, and libtool is destroying > them when you run 'make DESTDIR=/path/to/staging/dir install'. > > So we have libfoo.la and libbar.la, libbar links with libfoo and. > Furthermore, you have a version of libfoo already installed on the host > system, in /usr/lib. You cross-compile the package, using > --prefix=/usr/lib (since that is where it will finally end up). > > Then you do 'make DESTDIR=/path/to/staging/dir install', and libtool > decides to re-link the libraries against the libraries in the final > installed location. In this case, it is /usr/lib. The problem is that > the libfoo in /usr/lib is the wrong one, since the cross-compiled libfoo > never got installed there! > > The workaround here is to manually copy the libraries from .libs into > your staging directory. IMHO the fix is to make libtool not re-link > anything if DESTDIR is set -- correct me if I'm wrong, but it seems to > me that the current behaviour cannot possibly be correct on any > platform, even on the ones that require re-linking. That sounds about right, actually. So what would be a good fix to have libtool do the right think when DESTDIR is set? Anyone want to come up with a patch for this that I can try? Thanks, -Philip ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Running into cross-compilation issues with libtool (and autoconf) with libusb-0.1.12
On 13:19 Fri 30 Oct , Philip A. Prindeville wrote: > The problem is that this is an early linkage on the build host, where > the eventual DESTDIR hasn't yet been specified, but the resultant > libusbpp.la ends up looking like: I suspect that you have two libtool libraries in the same source tree, with one linked against the other. Chances are, the compiled binaries in the .libs directory are perfectly fine, and libtool is destroying them when you run 'make DESTDIR=/path/to/staging/dir install'. So we have libfoo.la and libbar.la, libbar links with libfoo and. Furthermore, you have a version of libfoo already installed on the host system, in /usr/lib. You cross-compile the package, using --prefix=/usr/lib (since that is where it will finally end up). Then you do 'make DESTDIR=/path/to/staging/dir install', and libtool decides to re-link the libraries against the libraries in the final installed location. In this case, it is /usr/lib. The problem is that the libfoo in /usr/lib is the wrong one, since the cross-compiled libfoo never got installed there! The workaround here is to manually copy the libraries from .libs into your staging directory. IMHO the fix is to make libtool not re-link anything if DESTDIR is set -- correct me if I'm wrong, but it seems to me that the current behaviour cannot possibly be correct on any platform, even on the ones that require re-linking. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: One year since last libtool release
Hi Gary, * Gary V. Vaughan wrote on Fri, Sep 25, 2009 at 01:35:39PM CEST: > > Not good news I'm afraid. The old testsuite has half a dozen failures > or more on several machines, and the new testsuite gets stuck in an > infinite loop on some of the others :( > > Rather that do a comprehensive breakdown in one email, I'll get logs > of the common failure cases in separate threads presently, and rerun > the whole testsuite on a newer snapshot when we've tackled the worst > of those. Any chance you could just post the testsuite.log files with failures, even without doing any further analysis, to bug-libtool? That shouldn't be too much work. Thanks, Ralf _______ http://lists.gnu.org/mailman/listinfo/libtool
Re: Avoid installing .la files with libtool
On Thursday 08 October 2009 12:11:41 Ali Abdallah wrote: > I'm using libtool 2.2.6a, and i want to avoid installing the .la files, > however i spend a lot of time trying to figure out how but i couldn't > manage, please help. there is no hook for it. you'd have to add an automake post hook to rm it yourself. > What i'm a building is a loadable module by a specific program, so the > .la file is completely useless. that's incorrect. if someone is using libltdl to load the plugin, the .la file would be checked. -mike signature.asc Description: This is a digitally signed message part. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Avoid installing .la files with libtool
On Thu, 8 Oct 2009, Ali Abdallah wrote: libfoo_la_LIBTOOLFLAGS = --tag=disable-static What i'm a building is a loadable module by a specific program, so the .la file is completely useless. I suggest that you read the libtool documentation regarding modules. Then you can decide if the .la file is completely useless. My package uses modules yet it finds the per-module .la files to be quite useful. Your use of --tag=disable-static bewilders me but it suggests that you need to read the libtool documenation rather than trying things at random. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Avoid installing .la files with libtool
Hi, I'm using libtool 2.2.6a, and i want to avoid installing the .la files, however i spend a lot of time trying to figure out how but i couldn't manage, please help. configure.ac AC_DISABLE_STATIC() AC_PROG_LIBTOOL() Makefile.am libfoo_la_LIBTOOLFLAGS = --tag=disable-static What i'm a building is a loadable module by a specific program, so the .la file is completely useless. Many thanks, Best Regards, Ali. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: One year since last libtool release
Howdy,
2009/9/19 Gary V. Vaughan :
> 2009/9/18 Bob Friesenhahn :
>> On Fri, 18 Sep 2009, Gary V. Vaughan wrote:
>>> Well, since no-one else seems to want the job, I'll delurk and roll a
>>> prerelease as soon as you'd like.
>>
>> it is not clear what condition libtool is actually in. It seems time for a
>> concerted effort to test libtool on the many targets to see if anything got
>> busted.
>
> To get the ball rolling, I have access to about 35 flavors of Unix,
> with a couple of different compiler on many of them, plus the latest
> Mac OS... so I'll take one of Peter's snapshots and see what the
> testsuite shows us.
Not good news I'm afraid. The old testsuite has half a dozen failures
or more on several machines, and the new testsuite gets stuck in an
infinite loop on some of the others :(
Rather that do a comprehensive breakdown in one email, I'll get logs
of the common failure cases in separate threads presently, and rerun
the whole testsuite on a newer snapshot when we've tackled the worst
of those.
Cheers,
Gary
--
Email me: g...@gnu.org(\(\
Read my blog: http://blog.azazil.net ( o.O)
And my other blog: http://www.machaxor.net (uu )o
...and my book:http://sources.redhat.com/autobook ("("_)
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Libtool attempts to link 64-bit lib on a -m32 compile (using Pathscale C++)
I'm running into a similar problem, but the -L/usr/lib workaround doesn't help in this case. Same pathCC, but on SuSE 10 (not SuSE 9). The error is basically this: $ make ... libtool: link: pathCC ... -lpscrt /usr/lib64/gcc/x86_64-suse-linux/4.1.2/libstdc++.so -m32 ... /usr/lib64/gcc/x86_64-suse-linux/4.1.2/libstdc++.so: could not read symbols: File in wrong format collect2: ld returned 1 exit status $ file -L /usr/lib64/gcc/x86_64-suse-linux/4.1.2/libstdc++.so /usr/lib64/gcc/x86_64-suse-linux/4.1.2/libstdc++.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), stripped I'm considering this LDFLAGS setting as a workaround, but overriding LDFLAGS seems like too big a hammer: LDFLAGS="-L/usr/lib64/gcc/x86_64-suse-linux/4.1.2/32" Any suggestions? Thanks, Ethan ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: One year since last libtool release
2009/9/18 Bob Friesenhahn :
> On Fri, 18 Sep 2009, Gary V. Vaughan wrote:
>
>> Howdy Ralf, Bob,
>>
>> Was that a tumbleweed?
>
> It seems that you have been out west ...
...and east.
>> Well, since no-one else seems to want the job, I'll delurk and roll a
>> prerelease as soon as you'd like.
>
> From which continent (or island)?
I'm in Florida for a few months, with a side trip to Vegas for a
school buddies 40th :-o After that: London, Bangkok, Manila and
Hawaii.
> While I have been following all of the libtool mails (the best that I can)
Well, your doing better than me. I drop in a couple of times a week
and scan the subject lines, and read the interesting looking threads,
depending how much time I have, is all.
> it is not clear what condition libtool is actually in. It seems time for a
> concerted effort to test libtool on the many targets to see if anything got
> busted.
To get the ball rolling, I have access to about 35 flavors of Unix,
with a couple of different compiler on many of them, plus the latest
Mac OS... so I'll take one of Peter's snapshots and see what the
testsuite shows us.
Cheers,
Gary
--
Email me: g...@gnu.org(\(\
Read my blog: http://blog.azazil.net ( o.O)
And my other blog: http://www.machaxor.net (uu )o
...and my book:http://sources.redhat.com/autobook ("("_)
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: One year since last libtool release
Howdy Ralf, Bob,
Was that a tumbleweed?
2009/9/6 Ralf Wildenhues :
> Yeah, we should strive to make one soonish. However, another pass over
> the many unapplied patches and some bug reports is prudent. Let's try
> to push that through in the next couple of weeks. Do we have volunteers
> to do prerelease testing or cut a release after that?
Well, since no-one else seems to want the job, I'll delurk and roll a prerelease
as soon as you'd like.
Cheers,
Gary
--
Email me: g...@gnu.org(\(\
Read my blog: http://blog.azazil.net ( o.O)
And my other blog: http://www.machaxor.net (uu )o
...and my book:http://sources.redhat.com/autobook ("("_)
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: One year since last libtool release
On Fri, 18 Sep 2009, Gary V. Vaughan wrote: Howdy Ralf, Bob, Was that a tumbleweed? It seems that you have been out west ... Well, since no-one else seems to want the job, I'll delurk and roll a prerelease as soon as you'd like. From which continent (or island)? While I have been following all of the libtool mails (the best that I can) it is not clear what condition libtool is actually in. It seems time for a concerted effort to test libtool on the many targets to see if anything got busted. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: One year since last libtool release
Hi Bob, * Bob Friesenhahn wrote on Sun, Sep 06, 2009 at 04:52:33PM CEST: > On September 8th, it will have been one year since the last libtool > release. Are there any outstanding technical issues which should > delay the preparation of a new libtool release? Yeah, we should strive to make one soonish. However, another pass over the many unapplied patches and some bug reports is prudent. Let's try to push that through in the next couple of weeks. Do we have volunteers to do prerelease testing or cut a release after that? Thanks, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
One year since last libtool release
On September 8th, it will have been one year since the last libtool release. Are there any outstanding technical issues which should delay the preparation of a new libtool release? Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
RE: extra exports with libtool (pr-msvc-support)
> > I just tried this by adding
> >
> > libfoo_la_LDFLAGS += -export-symbols symfile
> >
> > and manually creating an empty file named symfile in the
> > example I posted earlier. Now the only symbol that gets
> > exported is the one decorated with dllexport. Thanks
> > for the workaround.
One more snag here. It works well with msvc, but not so well on linux/gcc:
/bin/sh ./libtool --tag=CC --mode=link gcc -fvisibility=hidden -g -O2
-export-symbols symfile -o libfoo.la -rpath /usr/local/lib
libfoo_la-public.lo libfoo_la-private.lo
libtool: link: echo "{ global:" > .libs/libfoo.ver
libtool: link: cat symfile | sed -e "s/\(.*\)/\1;/" >> .libs/libfoo.ver
libtool: link: echo "local: *; };" >> .libs/libfoo.ver
libtool: link: gcc -shared .libs/libfoo_la-public.o
.libs/libfoo_la-private.o -Wl,-soname -Wl,libfoo.so.0
-Wl,-version-script -Wl,.libs/libfoo.ver -o .libs/libfoo.so.0.0.0
/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
.libs/libfoo.ver:2: syntax error in VERSION script
collect2: ld returned 1 exit status
make[1]: *** [libfoo.la] Error 1
$ cat .libs/libfoo.ver
{ global:
local: *; };
I can use the -export-symbols symfile option when using msvc only, but it
seemed like it would work with gcc as well, though it's unnecessary there.
> That said, what you can do is compare testsuite results from the
> branch on non-msvc-setups with results from the master branch.
>
> In particular I think Linux (and other "big" platforms) would
> be interresting as well as a Linux->mingw cross. Since it's been
> a while it would perhaps also be interesting to check for
> regressions with mingw and cygwin. And the upcoming cygwin 1.7
> would also be interesting.
I'm inches away from switching to the pr-msvc-support branch on linux but at
the moment I've got:
$ libtool --version
libtool (GNU libtool 1.3105 2009-06-19) 2.2.7a
-DB
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem
On Tuesday 01 September 2009 12:33:09 Kurt Roeckx wrote: > On Mon, Aug 31, 2009 at 04:38:04PM -0400, Mike Frysinger wrote: > > On Monday 31 August 2009 15:56:06 Kurt Roeckx wrote: > > > On Mon, Aug 31, 2009 at 08:55:21PM +0200, Ralf Wildenhues wrote: > > > > * Kurt Roeckx wrote on Sun, Aug 30, 2009 at 10:31:39PM CEST: > > > > > I've mailed about this issue before. What I think needs to > > > > > happen, and have proposed before, is: > > > > > - The .la file should only contain the libraries the current > > > > > library links to > > > > > > > > That will make it impossible to support static linking against > > > > libraries which do not themselves provide .la files. We cannot do > > > > this upstream. > > > > > > I don't see how it's different than what we have now. > > > > > > If I understand what you're trying to say is: > > > - The lib we're making now, liba, links to libb > > > - libb itself does not have a .la file > > > - to link to libb staticly, you also need to link to other > > > libraries. > > > > > > Either you provided libb's depedencies when linking liba or > > > not, what is going to be in liba.la is going to be the same. > > > > > > And if you really want static linking to work properly, > > > you need some way to find out what libraries libb requires, > > > be that with a libb.la or libb.pc file. > > > > and Ralf is pointing out that by trimming dependency_libs, you're > > breaking libb.la when linking libb statically via libtool. if there is > > no libb.la, then the issue is irrelevant because we arent talking about > > libtool scripts. > > You mean that if liba.la was created when there was a libb.la that > did contain the needed info? In that case trying to use liba.la > now already fails, because it's looking for libb.la. if you delete .la files that were recorded already in other .la files and dont clean up the mess, then that's a fault in your process > In case liba.la never knew about a libb.la, or libb.a never existed, > I can't see any difference. if libb.la didnt exist, then this discussion is completely irrelevant because you're no longer talking about libtool -mike signature.asc Description: This is a digitally signed message part. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem
libxcb version 1.0 installed: /usr/lib/libxcb-xlib.la /usr/lib/libxcb-xlib.so /usr/lib/libxcb-xlib.so.0 /usr/lib/libxcb-xlib.so.0.0.0 However, libxcb version 1.4 did not install the above mentioned files. libX11 version 1.1.3 linked using /usr/lib/libxcb-xlib.la. All software linked with libX11 by using the information provided in libX11.la also links with libxcb-xlib Consequently, that software, if it is a library, also installs libtool archive files that contained a reference to /usr/lib/libxcb-xlib.la However, installed software that does not directly use libxcb-xlib does not need to be explicitly linked with libxcb-xlib. If such software was linked with libX11 and libX11 was linked with libxcb-xlib then the libxcb-xlib library would also be loaded when libX11 is loaded. The software that links with libX11 does not have a need to know about libxcb-xlib as long as libX11 was correctly linked. The important question is, "Why does it matter?" In order to correct this problem following the update of libxcb from version 1.0 to version 1.4 the only software that should be required to recompile is libX11. However, due to much installed software be linked with the now missing libxcb-xlib library and also the many .la files that reference libxcb-xlib.la all those software projects must also be recompiled, relinked, and reinstalled. That will amount to over 100 software projects on some boxes. This is a real example of something that is really happening and not a hypothetical libA libB conjecture. I hope the elaboration would demystify one of the more troublesome aspects about libtool. While I prefer to not do all that compiling, merely sediting libtool archive files will not solve the problem. Fortunately, I use a distribution that automatically detects and corrects problems due to library updates. Consequently, I am care free. However, if I used a pre-compiled binary based distro then I would instead be downloading hundreds of replacement packages instead of merely recompiling sources that my boxes previously acquired. Something like that might give maintainers of a pre-compiled binary based distro cause to carefully reconsider both the use and content of libtool archive files, because such changes could avoid a +100 megabyte download update. I agree that this topic of conversation is worthy of the libtool mail list and should not be confined to a distribution's email list. >From one point of view this type of problem is caused due to something libtool is doing rather than something that distribution maintainers and software authors are intentionally doing. Furthermore, I do not know the situation with Debian maintainers. I do not care if anything is done about this type of problem. However, if I deployed a pre-compiled binary based distro then I would probably have an opinion. Yet it would seem that if this is a problem worthy of being fixed then it should be fixed by libtool authors instead of the maintainers of pre-compiled binary distribution. I apologize if the information that I provided is not congruent with the subject. As I wrote above I do not what Debian maintainers are doing nor why. However, if I were to make a wild guess then I would speculate that an update such as the one I described above might be sufficient to provoke the ire of Debian maintainers. On Tue, Sep 1, 2009 at 9:33 AM, Kurt Roeckx wrote: > On Mon, Aug 31, 2009 at 04:38:04PM -0400, Mike Frysinger wrote: >> On Monday 31 August 2009 15:56:06 Kurt Roeckx wrote: >> > On Mon, Aug 31, 2009 at 08:55:21PM +0200, Ralf Wildenhues wrote: >> > > * Kurt Roeckx wrote on Sun, Aug 30, 2009 at 10:31:39PM CEST: >> > > > I've mailed about this issue before. What I think needs to >> > > > happen, and have proposed before, is: >> > > > - The .la file should only contain the libraries the current >> > > > library links to >> > > >> > > That will make it impossible to support static linking against libraries >> > > which do not themselves provide .la files. We cannot do this upstream. >> > >> > I don't see how it's different than what we have now. >> > >> > If I understand what you're trying to say is: >> > - The lib we're making now, liba, links to libb >> > - libb itself does not have a .la file >> > - to link to libb staticly, you also need to link to other >> > libraries. >> > >> > Either you provided libb's depedencies when linking liba or >> > not, what is going to be in liba.la is going to be the same. >> > >> > And if you really want static linking to work properly, >> > you need some way to find out what libraries libb requires, >> > be that with a libb.la or libb.pc file. >> >> and Ralf is pointing out that b
Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem
On Mon, Aug 31, 2009 at 04:38:04PM -0400, Mike Frysinger wrote: > On Monday 31 August 2009 15:56:06 Kurt Roeckx wrote: > > On Mon, Aug 31, 2009 at 08:55:21PM +0200, Ralf Wildenhues wrote: > > > * Kurt Roeckx wrote on Sun, Aug 30, 2009 at 10:31:39PM CEST: > > > > I've mailed about this issue before. What I think needs to > > > > happen, and have proposed before, is: > > > > - The .la file should only contain the libraries the current > > > > library links to > > > > > > That will make it impossible to support static linking against libraries > > > which do not themselves provide .la files. We cannot do this upstream. > > > > I don't see how it's different than what we have now. > > > > If I understand what you're trying to say is: > > - The lib we're making now, liba, links to libb > > - libb itself does not have a .la file > > - to link to libb staticly, you also need to link to other > > libraries. > > > > Either you provided libb's depedencies when linking liba or > > not, what is going to be in liba.la is going to be the same. > > > > And if you really want static linking to work properly, > > you need some way to find out what libraries libb requires, > > be that with a libb.la or libb.pc file. > > and Ralf is pointing out that by trimming dependency_libs, you're breaking > libb.la when linking libb statically via libtool. if there is no libb.la, > then the issue is irrelevant because we arent talking about libtool scripts. - > mike You mean that if liba.la was created when there was a libb.la that did contain the needed info? In that case trying to use liba.la now already fails, because it's looking for libb.la. In case liba.la never knew about a libb.la, or libb.a never existed, I can't see any difference. Kurt ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem
On Monday 31 August 2009 15:56:06 Kurt Roeckx wrote: > On Mon, Aug 31, 2009 at 08:55:21PM +0200, Ralf Wildenhues wrote: > > * Kurt Roeckx wrote on Sun, Aug 30, 2009 at 10:31:39PM CEST: > > > I've mailed about this issue before. What I think needs to > > > happen, and have proposed before, is: > > > - The .la file should only contain the libraries the current > > > library links to > > > > That will make it impossible to support static linking against libraries > > which do not themselves provide .la files. We cannot do this upstream. > > I don't see how it's different than what we have now. > > If I understand what you're trying to say is: > - The lib we're making now, liba, links to libb > - libb itself does not have a .la file > - to link to libb staticly, you also need to link to other > libraries. > > Either you provided libb's depedencies when linking liba or > not, what is going to be in liba.la is going to be the same. > > And if you really want static linking to work properly, > you need some way to find out what libraries libb requires, > be that with a libb.la or libb.pc file. and Ralf is pointing out that by trimming dependency_libs, you're breaking libb.la when linking libb statically via libtool. if there is no libb.la, then the issue is irrelevant because we arent talking about libtool scripts. - mike signature.asc Description: This is a digitally signed message part. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem
On Mon, Aug 31, 2009 at 08:55:21PM +0200, Ralf Wildenhues wrote: > Hello Kurt, > > * Kurt Roeckx wrote on Sun, Aug 30, 2009 at 10:31:39PM CEST: > > > > I've mailed about this issue before. What I think needs to > > happen, and have proposed before, is: > > - The .la file should only contain the libraries the current > > library links to > > That will make it impossible to support static linking against libraries > which do not themselves provide .la files. We cannot do this upstream. I don't see how it's different than what we have now. If I understand what you're trying to say is: - The lib we're making now, liba, links to libb - libb itself does not have a .la file - to link to libb staticly, you also need to link to other libraries. Either you provided libb's depedencies when linking liba or not, what is going to be in liba.la is going to be the same. And if you really want static linking to work properly, you need some way to find out what libraries libb requires, be that with a libb.la or libb.pc file. > > - Libtool should recursively read all the .la files in > > the .la file. > > Again, this implies that all libraries of interest provide .la files. > But Debian itself contributes to making that assumption be false. And the main reason Debian currently doesn't want to ship .la files is because they currently cause more problems than they solve. We want to link as much as possible shared. But it would be nice if we could make it easier for our users to link something staticly if they want to do that. > Besides, another issue that we currently have, and whose effect would be > worsened by this change, is that deplib searches in staging directories > need to take the staging prefix into account. I'm not sure I really understand your point here. But I think it has to do with finding the right library at link time, and that it makes things harder. It's not because it's harder that we shouldn't be doing it. > > With that change only one .la file would need to be updated. > > Well, for that you do not need that the .la file only contains the > libraries the current library links to. What you need is the following. > > Assuming there is a deplibs and a private_deplibs (for static linking). > Then, when your dependency walker is smart enough (and correct) to > recurse .la files, then you can omit references to .la files which you > only link against indirectly. However, references to indirect > non-libtool deplibs still need to be added to private_deplibs. So you're saying that for the example above, you want to specify libb's depedencies, and make them end up in liba.la's private_deplibs, and that private_deplibs should only be used for cases where the libraries we're linking to do not provide the dependency info? Kurt ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem
Hello Kurt, * Kurt Roeckx wrote on Sun, Aug 30, 2009 at 10:31:39PM CEST: > > I've mailed about this issue before. What I think needs to > happen, and have proposed before, is: > - The .la file should only contain the libraries the current > library links to That will make it impossible to support static linking against libraries which do not themselves provide .la files. We cannot do this upstream. > - Libtool should recursively read all the .la files in > the .la file. Again, this implies that all libraries of interest provide .la files. But Debian itself contributes to making that assumption be false. Besides, another issue that we currently have, and whose effect would be worsened by this change, is that deplib searches in staging directories need to take the staging prefix into account. > With that change only one .la file would need to be updated. Well, for that you do not need that the .la file only contains the libraries the current library links to. What you need is the following. Assuming there is a deplibs and a private_deplibs (for static linking). Then, when your dependency walker is smart enough (and correct) to recurse .la files, then you can omit references to .la files which you only link against indirectly. However, references to indirect non-libtool deplibs still need to be added to private_deplibs. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem
On Tue, Aug 25, 2009 at 05:46:12PM +0300, Anssi Hannula wrote: > > dependency_libs contains the dependencies of a library. These are needed > when linking statically. These are also needed when linking dynamically, > but only on certain systems (they are not needed on normal linux systems). > > I think the proper way to solve this is to not link to dependency_libs > when linking dynamically on systems where it is not needed to link to > those. I haven't seen any correctly working patches that implement this. Debian already ships a version that has link_all_deplibs set to no, which already solves _some_ of the problems we have. (It also has it's issues.) The reason we still have a problem is that the .la file contains all the shared files that this lib, and recursively all the libs they depends on, link to. And when somewhere in the chain something no longer links to a library we have to go and fix all the libraries in between to get rid of the broken .la files. So it currently seems to be easier to ship .la files with dependency_libs set to an empty string. I've mailed about this issue before. What I think needs to happen, and have proposed before, is: - The .la file should only contain the libraries the current library links to - Libtool should recursively read all the .la files in the .la file. With that change only one .la file would need to be updated. I have an implementation (in C) that does this. And it atleast finds some issues in the test suite that I've mailed about and didn't get resolved yet. I should probably also keep working on my version. Kurt _______ http://lists.gnu.org/mailman/listinfo/libtool
Re: extra exports with libtool (pr-msvc-support)
Den 2009-08-28 19:02 skrev David Byron:
Indeed, good to know. Your input made me realize that it
should be possible to work around the extra exports with
something like -export-symbols-regex=probably_not_a_match
or with an empty SYMFILE and -export-symbols=SYMFILE
Untested though, but the linker should then pick up the
symbols to export from the directives in the object files,
and libtool will not add any more exports.
I just tried this by adding
libfoo_la_LDFLAGS += -export-symbols symfile
and manually creating an empty file named symfile in the example I posted
earlier. Now the only symbol that gets exported is the one decorated with
dllexport. Thanks for the workaround.
You're welcome :-)
This does raise the question of what to do when the symbol file is in
conflict with the decorations...Need to think about this some more.
There is not much to do, I think. The decorations may export symbols
and the -export-* options may export symbols, and I don't think there
is any way to stop the decorated symbols from being exported. I think
it is perfectly fine to export all symbols which has been *either*
decorated or singled out with the -export-* options.
The only thing that needs to change is what to do if there are
no -export-* options. In that case, all symbols should be exported
if there are *no* decorations (after all, what point is it to create
a dll w/o any exported symbols?), but if there are at least one
decorated symbol, only the decorated symbols should be exported.
So, in other words, what's needed is some check that is only
effective when there are no -export-* option. The check should
detect if there are any decorated symbols in any of the objects,
and if there are it should stop libtool from digging through
the objects for (more) symbols to export.
But you better only add the above options if you are indeed
using MSVC and have decorated the symbols, or else you risk
ending up with a severly crippled library...
Or if using a version of gcc that supports
__attribute__((__visibility__("default"))) and have decorated the symbols
with that, yes?
Probably, but I wouldn't know. The pr-msvc-support branch should
(hopefully) not change anything wrt to gcc...
#if BUILDING_LIBFOO && HAVE_VISIBILITY
#define LIBFOO_DLL_EXPORTED
__attribute__((__visibility__("default")))
#elif BUILDING_LIBFOO && defined _MSC_VER
#define LIBFOO_DLL_EXPORTED __declspec(dllexport)
#elif defined _MSC_VER
#define LIBFOO_DLL_EXPORTED __declspec(dllimport)
#else
#define LIBFOO_DLL_EXPORTED
#endif
Extending gnulib with this can only be done after pr-msvc-support has
been merged, methinks. Until then, I don't know if it's worth spending
time on it.
I agree that merging pr-msvc-support should come first...which of course
begs the question, what can I do to help get pr-msvc-support merged?
There is concern that the patches will interfere with other
platforms, but I think the main showstopper is that libtool 2.2.8
has to be released. Until then, the window is firmly closed IIUC.
A while back some people stated that it was perhaps time to simply
merge the branch and see what probelms crop up. Knock wood...
That said, what you can do is compare testsuite results from the
branch on non-msvc-setups with results from the master branch.
In particular I think Linux (and other "big" platforms) would
be interresting as well as a Linux->mingw cross. Since it's been
a while it would perhaps also be interesting to check for
regressions with mingw and cygwin. And the upcoming cygwin 1.7
would also be interesting.
But there's still the unresolved issue that
__declspec(dllimport) is wrong if you are linking with a static
library, so the above isn't entirely correct anyway.
So far preprocessor logic looks like this:
#if defined(BUILDING_LIBFOO) && HAVE_VISIBILITY
# define LIBFOO_DLL_EXPORTED __attribute__((__visibility__("default")))
#elif defined _MSC_VER
# if BUILDING_LIBFOO
#if defined(PIC)
# if defined(LIBFOO_STATIC)
#error "LIBFOO_STATIC conflicts with PIC"
# else
#define LIBFOO_DLL_EXPORTED __declspec(dllexport)
# endif
#else
# define LIBFOO_DLL_EXPORTED
#endif
# else
#if defined(LIBFOO_STATIC)
# define LIBFOO_DLL_EXPORTED
#else
# define LIBFOO_DLL_EXPORTED __declspec(dllimport)
#endif
# endif
#else
# define LIBFOO_DLL_EXPORTED
#endif
The _MSC_VER part of this is supposed to read:
1. If building a shared lib: __declspec(dllexport)
2. else if building a static lib: nothing
3. else if linking against a static lib: nothing
4. else (linking with a shared lib): __declspec(dllimport)
The trick is figuring out each of these things is happening. Distinguishing
1 + 2 from 3 + 4 is easy:
libfoo_la_CPPFLAGS += -DBUILDING_UTILS
Distinguishing 1 from 2 relies on -DPIC from lib
RE: extra exports with libtool (pr-msvc-support)
> Indeed, good to know. Your input made me realize that it
> should be possible to work around the extra exports with
> something like -export-symbols-regex=probably_not_a_match
> or with an empty SYMFILE and -export-symbols=SYMFILE
>
> Untested though, but the linker should then pick up the
> symbols to export from the directives in the object files,
> and libtool will not add any more exports.
I just tried this by adding
libfoo_la_LDFLAGS += -export-symbols symfile
and manually creating an empty file named symfile in the example I posted
earlier. Now the only symbol that gets exported is the one decorated with
dllexport. Thanks for the workaround.
This does raise the question of what to do when the symbol file is in
conflict with the decorations...Need to think about this some more.
> But you better only add the above options if you are indeed
> using MSVC and have decorated the symbols, or else you risk
> ending up with a severly crippled library...
Or if using a version of gcc that supports
__attribute__((__visibility__("default"))) and have decorated the symbols
with that, yes?
> An automatic solution has this additional requirements (if
> you ask me):
>
> If you specify neither -export-symbols nor
> -export-symbols-regex and do use at least one
> dllexport decoration, only the dllexport
> decorated symbols should be exported.
I agree with this.
> So, if the use -export-symbols or -export-symbols-regex or if
> you don't have any dllexport decorations at all, the current
> behaviour is the desired behaviour.
I also agree with this in spirit but considering -export-symbols with an
empty file makes the language to specify this precisely more complex I
think.
> But before you do anything major, make sure you are
> prepared to assign the copyrights of the new code to the
> FSF...
Thanks for the pointer. Yes, I'm prepared to assign copyright.
> > #if BUILDING_LIBFOO && HAVE_VISIBILITY
> > #define LIBFOO_DLL_EXPORTED
> __attribute__((__visibility__("default")))
> > #elif BUILDING_LIBFOO && defined _MSC_VER
> > #define LIBFOO_DLL_EXPORTED __declspec(dllexport)
> > #elif defined _MSC_VER
> > #define LIBFOO_DLL_EXPORTED __declspec(dllimport)
> > #else
> > #define LIBFOO_DLL_EXPORTED
> > #endif
> >
> Extending gnulib with this can only be done after pr-msvc-support has
> been merged, methinks. Until then, I don't know if it's worth spending
> time on it.
I agree that merging pr-msvc-support should come first...which of course
begs the question, what can I do to help get pr-msvc-support merged?
> But there's still the unresolved issue that
> __declspec(dllimport) is wrong if you are linking with a static
> library, so the above isn't entirely correct anyway.
So far preprocessor logic looks like this:
#if defined(BUILDING_LIBFOO) && HAVE_VISIBILITY
# define LIBFOO_DLL_EXPORTED __attribute__((__visibility__("default")))
#elif defined _MSC_VER
# if BUILDING_LIBFOO
#if defined(PIC)
# if defined(LIBFOO_STATIC)
#error "LIBFOO_STATIC conflicts with PIC"
# else
#define LIBFOO_DLL_EXPORTED __declspec(dllexport)
# endif
#else
# define LIBFOO_DLL_EXPORTED
#endif
# else
#if defined(LIBFOO_STATIC)
# define LIBFOO_DLL_EXPORTED
#else
# define LIBFOO_DLL_EXPORTED __declspec(dllimport)
#endif
# endif
#else
# define LIBFOO_DLL_EXPORTED
#endif
The _MSC_VER part of this is supposed to read:
1. If building a shared lib: __declspec(dllexport)
2. else if building a static lib: nothing
3. else if linking against a static lib: nothing
4. else (linking with a shared lib): __declspec(dllimport)
The trick is figuring out each of these things is happening. Distinguishing
1 + 2 from 3 + 4 is easy:
libfoo_la_CPPFLAGS += -DBUILDING_UTILS
Distinguishing 1 from 2 relies on -DPIC from libtool.
so all that remains is distinguishing 3 from 4 which depends on
LIBFOO_STATIC. At the moment I have some configure-time logic that helps in
my environment, but it's not a general solution. Basically, if someone
wants to link against a static libfoo, define LIBFOO_STATIC and hope that at
link time the static lib is available. It's not ideal but I couldn't come
up with anything better. Definitely open to suggestions here.
-DB
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: extra exports with libtool (pr-msvc-support)
Den 2009-08-27 18:40 skrev David Byron:
The portable way to specify which symbols you want to be
visible (with libtool) is to use -export-symbols or
-export-symbols-regex, IIUC. So, assuming you have some
visibility requirements you are better off using those
options anyway.
Lightbulb goes on a bit. Whatever happens with __declspec(dllexport) and
msvc and -fvisibility/gcc, I still need to do something with -export-symbols
if I want to be portable to non-msvc/non-gcc platforms.
Given that, and the fact that I have found no way to
detect which symbols have been dllexport-decorated, it
seemed best to export everything unless any of the above
options are given.
I don't claim this is a proper solution, but there must be a way if the msvc
linker does it. I tried compiling two different versions of this:
*snip interesting dumpbin -directives stuff*
So there is a difference. I don't know what's involved in teaching libtool
about it, but if someone points me in the right direction I'll take a look.
Indeed, good to know. Your input made me realize that it
should be possible to work around the extra exports with
something like -export-symbols-regex=probably_not_a_match
or with an empty SYMFILE and -export-symbols=SYMFILE
Untested though, but the linker should then pick up the
symbols to export from the directives in the object files,
and libtool will not add any more exports.
But you better only add the above options if you are indeed
using MSVC and have decorated the symbols, or else you risk
ending up with a severly crippled library...
An automatic solution has this additional requirements (if
you ask me):
If you specify neither -export-symbols nor
-export-symbols-regex and do use at least one
dllexport decoration, only the dllexport
decorated symbols should be exported.
So, if the use -export-symbols or -export-symbols-regex or if
you don't have any dllexport decorations at all, the current
behaviour is the desired behaviour.
Regarding pointers into hacking libtool to do the above, I'm
probably not the best source. But look in libltdl/m4/libtool.m4
and libltdl/config/ltmain.m4sh near the use of the variable
export_symbols_cmds. But before you do anything major, make
sure you are prepared to assign the copyrights of the new
code to the FSF...
gcc/ld does something equivalent if there are no dllexport
decorations at all, at least with the options libtool is
using (I think so anyway, but I may be wrong here too). So,
I suspect that fewer and fewer packages will have the
dllexport decorations and rely on auto-export instead.
My only comment to this is here:
http://www.gnu.org/software/gnulib/manual/html_node/Exported-Symbols-of-Shar
ed-Libraries.html
This page mentions that libtool uses a programmer-specified list of symbols
to define what's exported but then goes on to describe the gnulib method
that uses symbol decoration (my term). And then at the end it says:
---
Note about other compilers: MSVC support can be added easily, by extending
the definition of the macro mentioned above, to something like this:
#if BUILDING_LIBFOO && HAVE_VISIBILITY
#define LIBFOO_DLL_EXPORTED __attribute__((__visibility__("default")))
#elif BUILDING_LIBFOO && defined _MSC_VER
#define LIBFOO_DLL_EXPORTED __declspec(dllexport)
#elif defined _MSC_VER
#define LIBFOO_DLL_EXPORTED __declspec(dllimport)
#else
#define LIBFOO_DLL_EXPORTED
#endif
---
Maybe I should have a discussion on the gnulib-list to add some
clarification to this page, but if people use a combination of gnulib and
libtool (or this gnulib mechanism and libtool), adding support for msvc
means more than adjusting this macro.
Extending gnulib with this can only be done after pr-msvc-support has
been merged, methinks. Until then, I don't know if it's worth spending
time on it. But there's still the unresolved issue that
__declspec(dllimport) is wrong if you are linking with a static
library, so the above isn't entirely correct anyway.
Cheers,
Peter
_______
http://lists.gnu.org/mailman/listinfo/libtool
RE: extra exports with libtool (pr-msvc-support)
> The portable way to specify which symbols you want to be
> visible (with libtool) is to use -export-symbols or
> -export-symbols-regex, IIUC. So, assuming you have some
> visibility requirements you are better off using those
> options anyway.
Lightbulb goes on a bit. Whatever happens with __declspec(dllexport) and
msvc and -fvisibility/gcc, I still need to do something with -export-symbols
if I want to be portable to non-msvc/non-gcc platforms.
> Given that, and the fact that I have found no way to
> detect which symbols have been dllexport-decorated, it
> seemed best to export everything unless any of the above
> options are given.
I don't claim this is a proper solution, but there must be a way if the msvc
linker does it. I tried compiling two different versions of this:
int foo ( const char *bar );
int
foo ( const char *bar)
{
printf("%s: %s\n",__FUNCTION__,bar);
return 1;
}
and then again with __declspec(dllexport) in front of the declaration.
$ dumpbin /directives no_dllexport.obj
Microsoft (R) COFF/PE Dumper Version 8.00.50727.762
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file no_dllexport.obj
File Type: COFF OBJECT
Linker Directives
-
/DEFAULTLIB:"LIBCMT"
/DEFAULTLIB:"OLDNAMES"
Summary
C .data
8D .debug$S
2F .drectve
20 .text
$ dumpbin /directives with_dllexport.obj
Microsoft (R) COFF/PE Dumper Version 8.00.50727.762
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file with_dllexport.obj
File Type: COFF OBJECT
Linker Directives
-
/DEFAULTLIB:"LIBCMT"
/DEFAULTLIB:"OLDNAMES"
/EXPORT:_foo
Summary
C .data
8D .debug$S
3C .drectve
20 .text
So there is a difference. I don't know what's involved in teaching libtool
about it, but if someone points me in the right direction I'll take a look.
> gcc/ld does something equivalent if there are no dllexport
> decorations at all, at least with the options libtool is
> using (I think so anyway, but I may be wrong here too). So,
> I suspect that fewer and fewer packages will have the
> dllexport decorations and rely on auto-export instead.
My only comment to this is here:
http://www.gnu.org/software/gnulib/manual/html_node/Exported-Symbols-of-Shar
ed-Libraries.html
This page mentions that libtool uses a programmer-specified list of symbols
to define what's exported but then goes on to describe the gnulib method
that uses symbol decoration (my term). And then at the end it says:
---
Note about other compilers: MSVC support can be added easily, by extending
the definition of the macro mentioned above, to something like this:
#if BUILDING_LIBFOO && HAVE_VISIBILITY
#define LIBFOO_DLL_EXPORTED __attribute__((__visibility__("default")))
#elif BUILDING_LIBFOO && defined _MSC_VER
#define LIBFOO_DLL_EXPORTED __declspec(dllexport)
#elif defined _MSC_VER
#define LIBFOO_DLL_EXPORTED __declspec(dllimport)
#else
#define LIBFOO_DLL_EXPORTED
#endif
---
Maybe I should have a discussion on the gnulib-list to add some
clarification to this page, but if people use a combination of gnulib and
libtool (or this gnulib mechanism and libtool), adding support for msvc
means more than adjusting this macro.
-DB
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: extra exports with libtool (pr-msvc-support)
Den 2009-08-25 22:54 skrev David Byron: Re-ordering paragraphs... Not on all systems, but I think that will happen with gcc/ld though. I think they will only export dllexported symbols if at least one such symbol exist. However, this causes some trouble if you e.g. have a library that is not decorated with dllexport and which uses ltdl as a convinience library. Since ltdl is decorated with dllexport, only the ltdl symbols are exported in that case, which of course is not what you generally want... Using ltdl seems like the more complicated case. Clearly I'm biased, but requiring extra work to prepare a library for ltdl seems more natural than the other way around. Which is more work depends on where you are coming from. The portable way to specify which symbols you want to be visible (with libtool) is to use -export-symbols or -export-symbols-regex, IIUC. So, assuming you have some visibility requirements you are better off using those options anyway. Given that, and the fact that I have found no way to detect which symbols have been dllexport-decorated, it seemed best to export everything unless any of the above options are given. This is by design. For the msvc branch, libtool digs through the object files to get all public symbols and exports those, regardless of any dllexport decorations. This is a bit surprising. If gcc/ld doesn't do it, and msvc doesn't do it, why does libtool do it by default? gcc/ld does something equivalent if there are no dllexport decorations at all, at least with the options libtool is using (I think so anyway, but I may be wrong here too). So, I suspect that fewer and fewer packages will have the dllexport decorations and rely on auto-export instead. What can I do to convince libtool to keep function foo hidden? Use one of the -export-symbols SYMFILE or -export-symbols-regex REGEX options. Whether it's the default or not, is there some way to convince libtool to look at the __declspec(export) decorations I've already got in place? Not that I know of, sorry... Cheers, Peter ___ http://lists.gnu.org/mailman/listinfo/libtool
