Re: libtool not generating / installing .so, even tho config says it should
On 07/06/2011 01:54 AM, ScottLadd wrote: I've been writing configure.ac scripts for a long time, and now, unexpectedly, on a new Kubuntu 11.04 installation and on a Fedora 15 install, libtool not longer generates and installs shared objects. Same scripts I've used before, different behavior. I don't know if this had ever worked, but the culprit seems to be this part of your configure.ac: if test x$gccopt = xyes then CFLAGS=-std=gnu99 -pedantic -Wall -Wno-format -lpthread -lrt -O2 -g0 -march=native else CFLAGS=-std=gnu99 -pedantic -Wall -Wno-format -lpthread -lrt -g -O2 -static fi Besides this, this part overrides CFLAGS with hard-coded compiler- and system-specific CFLAGS - Not a good idea. Ralf ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: How does one specify linking to 64 bit libraries when there is a choice?
On 12/20/2010 08:02 PM, Bruce Korb wrote:
On 12/20/10 09:11, Nick Bowler wrote:
On 2010-12-20 08:54 -0800, Bruce Korb wrote:
If the default build is 64 bit, why does it make sense that the
default library directory is the 32 bit library?
As far as I know, the only reason for this design is to avoid breaking
32-bit proprietary software with /usr/lib paths hardcoded into their
binaries.
Which argues for keeping /usr/lib as a 32 bit library directory,
but not for making it the default directory.
Pardon, but I can not avoid having to reiterate my mantra:
/usr/lib and /usr/lib64 are just one random case of multilibs, which
happens to be popular on currently far spread and widely used targets.
However, there are _many_ more targets, which apply completely different
conventions. In particular, they are very wide spread on embedded
targets, where they often are being used for optimization purposes.
Perhaps all the stake holders need to be put into a virtual meeting
room and not allowed out until some way forward is chosen. ;)
Well,
a) Users should learn that autoconf's default are just arbitrary
defaults, which match their use-case or not.
This is nothing new. System integrators need to take care about this in
any case and for uneducated random users there a plenty of other
possiblities to shoot themselves into their own foot (e.g. by installing
to /usr/local)
b) The solution would be along the lines of
libdir='${exec_prefix}/lib/'$(${CC} ${CFLAGS} --print-multi-os-directory)
However, how to implement this into autoconf is far from being clear to
me, as well as I would expect the details could easily become ugly.
I do think that autoconf was conceived as the place where
inconsistencies between platforms get resolved. This is an
inconsistency that could really use a resolution that does not
require people to have to remember platform dependent tool use rules.
I wonder why this issue pops up now? It is around for probably more than
15 years and has never been a major issue. At least the first system I
personally tripped over, which was using multilibs was a Sun Sparc
Solaris system ca. in 1995 (Solaris 2.7/SunOS-5.7 or so). The oldest
piece of code I could find by brief look into GCC's source code dates
back to 1997.
Ralf
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: How does one specify linking to 64 bit libraries when there is a choice?
On 12/20/2010 03:59 PM, Bruce Korb wrote: Hi Andy, Ralf, et al., (With my Fedora Packaging Committee member hat on) In Fedora and RHEL, users are supposed to pass --libdir=/usr/lib64 to configure on x86_64 and It is unclear that you-all can do otherwise, without having OSX-style mixed word size combined libraries. Fedora + RHEL (and many other Linux distros) apply multilibs and multiarching instead of fat binaries. Autoconf does need to get involved and work with libtool to get the information passed through. Well, I am not sure what you are asking. --libdir (installation directory) and path to libraries to link to (linker's library path) actually are independent. The former is a user-/system-integrator provided setting, which may take arbitrary values. The latter is a system's internal implementation detail - If libtool can't avoid exposing these implicit details, it has to examine the tools being involved internal settings (In case of Fedora/RHEL: gcc). Correct me if I am wrong, but as far as I can tell libtool doesn't do so, so far. The same consideration applies to applications/application configure scripts who want to guess for a system's libdir. Wrt. autoconf: There have repeatedly been discussion on letting autoconf provide different defaults for libdir on 64bit targets, but ... ... besides that guessing on system defaults is difficult, do you realize that the setting autoconf provides are simply defaults, user will almost always have to change? Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: How does one specify linking to 64 bit libraries when there is a choice?
On 12/20/2010 04:05 PM, Eric Blake wrote: On 12/20/2010 07:59 AM, Bruce Korb wrote: Hi Andy, Ralf, et al., On Mon, Dec 20, 2010 at 6:23 AM, Andy Wingowi...@oblong.com wrote: How much understanding of the machinery should be expected of the hapless project builder? I'm not sure, but: . I am sure of this: It needs to be minimized. If there are insurmountable problems in figuring out that the lib directory is /usr/lib64, then the builder has to supply it. I really doubt it is that hard to figure out though. If a distro insists on shipping 64-bit libraries under /usr/lib64, then it would be in the distro's best interest to also ship a config.site variable that defaults --libdir to the appropriate /usr/lib64 location. This isn't of much help on multi-arched architectures (such as Fedora/RHEL x86_64 systems), because any such default would only match to one of its supported architectures and be wrong on all others. Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: How does one specify linking to 64 bit libraries when there is a choice?
On 12/20/2010 04:41 PM, Eric Blake wrote: On 12/20/2010 08:36 AM, Ralf Corsepius wrote: If a distro insists on shipping 64-bit libraries under /usr/lib64, then it would be in the distro's best interest to also ship a config.site variable that defaults --libdir to the appropriate /usr/lib64 location. This isn't of much help on multi-arched architectures (such as Fedora/RHEL x86_64 systems), because any such default would only match to one of its supported architectures and be wrong on all others. I disagree with your argument. config.site can be a full-powered shell script, OK, then it should be technically possible to implement this - Whether it's useful is a different matters (IMO it's not). Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: [PATCH] Add 64 bit directories to sys_lib_dlsearch_path_spec for Linux ELF
Dan Nicholson wrote: On Thu, Jan 29, 2009 at 11:26 PM, Ralf Corsepius rc040...@freenet.de wrote: Dan Nicholson wrote: On Wed, Jan 28, 2009 at 01:50:51PM -0600, Bob Friesenhahn wrote: On Wed, 28 Jan 2009, Dan Nicholson wrote: When the ABI is 64-bit on Linux ELF, add /lib64 and /usr/lib64 to the system library path so that an RPATH is not added when using libraries from these directories. Are these libraries consistently available for 64-bit Linux? If not, should they be explicitly tested for before depending on them? I got the impression that Linux systems which are completely 64-bit (i.e. don't support executing 32-bit binaries) don't use /lib64 and /usr/lib64. Well, actually, the search paths to system libs is hard coded into gcc. It may vary between architectures, vendors and OSes. I'm talking about the dynamic linker search path, which is determined by glibc. The dynamic linker's search path is not of much importance when linking. Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: [PATCH] Add 64 bit directories to sys_lib_dlsearch_path_spec for Linux ELF
Dan Nicholson wrote: On Wed, Jan 28, 2009 at 01:50:51PM -0600, Bob Friesenhahn wrote: On Wed, 28 Jan 2009, Dan Nicholson wrote: When the ABI is 64-bit on Linux ELF, add /lib64 and /usr/lib64 to the system library path so that an RPATH is not added when using libraries from these directories. Are these libraries consistently available for 64-bit Linux? If not, should they be explicitly tested for before depending on them? I got the impression that Linux systems which are completely 64-bit (i.e. don't support executing 32-bit binaries) don't use /lib64 and /usr/lib64. Well, actually, the search paths to system libs is hard coded into gcc. It may vary between architectures, vendors and OSes. Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool/ltmain.sh pulling in wrong stdc++
On Wed, 2005-08-03 at 13:57 +0200, Graham Leggett wrote: Hi all, What method needs to be used to tell libtool to link to stdc++ that belongs to the compiler being run? No method at all. libstdc++ is an internal library of g++ you are not supposed to specify explicitly. The issue you describe, indicates a miss-configured gcc or user setup. Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool/ltmain.sh pulling in wrong stdc++
On Wed, 2005-08-03 at 13:46 -0500, Bob Friesenhahn wrote: On Wed, 3 Aug 2005, Ralf Corsepius wrote: On Wed, 2005-08-03 at 13:57 +0200, Graham Leggett wrote: Hi all, What method needs to be used to tell libtool to link to stdc++ that belongs to the compiler being run? No method at all. libstdc++ is an internal library of g++ you are not supposed to specify explicitly. The issue you describe, indicates a miss-configured gcc or user setup. There is a long-standing GCC bug (ever since GCC started to use libtool) on the Solaris platform in which the paths to the uninstalled compiler libraries are recorded in the libstdc++.la file. That's not Solaris specific. AFAICT, it affects all platforms. With recent GCCs, however, using make DESTDIR=dir install instead of make prefix=installprefixprefix ... install works around this issue. These paths end up being used. So in order for a GCC install to be properly usable, the compiler build directory needs to be moved or removed. The cruft in the .la file remains. This seems to be a bug in the modified libtool that GCC uses. ACK. So from the get-go GCC is miss-configured under Solaris. :-( Another common trouble source is trying to install several g++'s to the same prefix in parallel. In this case, g++ (bogusly) tries to share several files (esp. its headers, runtime-libs) between these versions. A work-around is to configure gcc with --enable-version-specific-runtime-libs [I never understood why this isn't the default in GCC] Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: -DPIC - redundant?
On Wed, 2005-01-26 at 08:21 -0600, Bob Friesenhahn wrote: On Wed, 26 Jan 2005, Gary V. Vaughan wrote: Kevin F. Quinn wrote: Apologies if this is a stupid question, but please could someone explain to me why libtool sets '-DPIC' for shared libraries, while gcc reliably defines '__PIC__' when it generates PIC code? Setting '-DPIC' encourages people to do '#ifdef PIC' when surely '#ifdef __PIC__' would be more reliable. Libtool supports plenty more compilers than just gcc. I recall from discussions a couple of years ago that this define is even used from within some Fortran code. IIRC, -DPIC predates -D__PIC__. So I'd guess older code had used #ifdef PIC, while __PIC__ has been to add to gcc. I don't know how other compilers handle this issue. Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Fri, 2004-11-12 at 23:02 -0800, Jacob Meuser wrote: On Sat, Nov 13, 2004 at 04:27:28AM +0100, Ralf Corsepius wrote: On Fri, 2004-11-12 at 14:31 -0800, Jacob Meuser wrote: On Fri, Nov 12, 2004 at 03:33:02PM -0600, Albert Chin wrote: On Fri, Nov 12, 2004 at 11:20:13AM +, Gary V. Vaughan wrote: Albert Chin wrote: On Wed, Nov 10, 2004 at 03:43:48PM +, Scott James Remnant wrote: On Tue, 2004-11-09 at 14:24 +, Gary V. Vaughan wrote: 6. Absorb the functionality of the aberration called pkg-config. Libtool already has all the information it needs, we just need to teach it (or maybe a subsidiary script) to spit out link flags after poking around in a dependency chain of .la files. There's actually a couple of things pkg-config does that Libtool doesn't currently do. pkg-config's main job can be summed up simply as enabling parallel-installed -dev packages. since when does libtool care about CFLAGS It hardly can avoid doing so if wanting to support multilibs. of course, it cares about _some_ CFLAGS at build time. it does not care about where the headers are going to be installed though, or what CPPFLAGS need to be set either ... functionality you do get from pkg-config. Well, current libtool does not support multilibs. If multilibs should ever be able to support them, I'd expect libtool having to examine the whole command being used, comprising CFLAGS and CPPFLAGS (There exist targets where multilib variants are being triggered by preprocessor flags) or package versions? It doesn't care about package versions, but it has to care about library versions and paths to libraries. again, functionality provided by pkg-config. No. Like libtool, pkg-config only covers some parts of the whole picture. *.la's contain information pkg-config has not notion about, and *.pc's can contain information libtool has no notion about. (libtool-*.la's contain linker/library specific info. *.pc's basically are more or less a poor-man's registry/database and can contain arbitrary information). I am contesting the claim Libtool already has all the information it needs. Agreed, but neither has pkg-config. It's just that their functionality intersects and partially conflicts. Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 1.5.8 released.
On Fri, 2004-08-13 at 05:37, Daniel Reed wrote: ) On Fri, 13 Aug 2004, Ralf Corsepius wrote: ) However, you can not identify the multilib-variant and the multilib ) subdir being used from $host, because it is chosen depending upon the ) flags being passed to gcc: ) sparc-sun-solaris2.8-gcc .. - . (sparcv7) ) sparc-sun-solaris2.8-gcc -m64 .. - sparcv9 In the scheme we use, $host would be sparc64-sun-solaris2.8 . AFAIU, all'd you do here, is to invent a convention to be able to apply a similar hack to libtool addressing sparc-sun-solaris as the RH patch does. This does not solve the troubles libtool is facing with multilibs in general. Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 1.5.8 released.
On Thu, 2004-08-12 at 18:12, Peter O'Gorman wrote: Bob Friesenhahn wrote: On Thu, 12 Aug 2004, Tim Mooney wrote: Why just Linux? Isn't this essentially the same issue that the multi-ABI commercial UNIXes have? Seems like it to me. I am not sure. Solaris-gcc applies traditional multilibs, i.e. it is using multilib subdirs (A subdir of PREFIX/lib). I don't know how multiarchs are implemented in RH's ix86_64 gcc. /usr/lib64 is not a subdir of PREFIX/lib For example, Solaris puts 64-bit libraries in a 'sparcv9' subdirectory. The 'sparcv7' directory is used for libraries built for older SPARC processor types. Libraries optimized for 32-bit Ultrasparc are put in the traditional location. Well, the difference, in my little mind at least, is that the commercial unixes can all be identified in libtool using $host, Right, you can identify $host and in case of Solaris even the OS version as part of $host (solaris2.8). However, you can not identify the multilib-variant and the multilib subdir being used from $host, because it is chosen depending upon the flags being passed to gcc: sparc-sun-solaris2.8-gcc .. - . (sparcv7) sparc-sun-solaris2.8-gcc -m64 .. - sparcv9 = There is no fixed host to multilib subdir mapping. IMO, RH's multilib-patch is just a band-aid (read: hack) to help them keep libtool going on their systems, but is not a generalizable approach. How do other Linux vendors (Debian, SuSE etc.) handle this issue? I would expect them to be facing the same problems as RH and to have similar work-arounds applied to libtool. Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
autoreconf misses ltmain.sh
Am Mit, 2002-09-18 um 23.23 schrieb Alexandre Duret-Lutz: Please SHOUT LOUD if your package works with Automake 1.6.3 but doesn't with 1.6d. This bug has been present with previous versions of automake and autoconf (IIRC, it also has been reported several times before). Anyway, it is still present with automake-1.6d, autoconf-2.54 and libtool-1.4.2. # ls Makefile.am configure.ac hello.c # cat configure.ac AC_PREREQ(2.54) AC_INIT([lttest],[0.0]) AC_CONFIG_SRCDIR([hello.c]) AC_CONFIG_AUX_DIR(.) AM_INIT_AUTOMAKE AC_PROG_CC AM_PROG_LIBTOOL AC_CONFIG_FILES([Makefile]) AC_OUTPUT # cat Makefile.am noinst_LTLIBRARIES = libhello.la libhello_la_SOURCES = hello.c # autoreconf -f -i autoreconf: `aclocal.m4' is created You should update your `aclocal.m4' by running aclocal. Putting files in AC_CONFIG_AUX_DIR, `..'. autoreconf: `aclocal.m4' is unchanged configure.ac: installing `./install-sh' configure.ac: installing `./mkinstalldirs' configure.ac: installing `./missing' configure.ac:9: installing `./config.guess' configure.ac:9: installing `./config.sub' Makefile.am: installing `./COPYING' Makefile.am: installing `./INSTALL' Makefile.am: required file `./NEWS' not found Makefile.am: required file `./README' not found Makefile.am: required file `./AUTHORS' not found Makefile.am: required file `./ChangeLog' not found Makefile.am: installing `./depcomp' configure.ac:9: required file `./ltmain.sh' not found # ls COPYING Makefile.in config.guess configure.ac install-sh INSTALL aclocal.m4 config.subdepcomp missing Makefile.am autom4te.cache configure hello.c mkinstalldirs = ltmain.sh is missing Consequently, subsequent configure+make runs fail: # configure [..] # make if /bin/sh ./libtool --mode=compile gcc -DPACKAGE_NAME=\lttest\ -DPACKAGE_TARNAME=\lttest\ -DPACKAGE_VERSION=\0.0\ -DPACKAGE_STRING=\lttest\ 0.0\ -DPACKAGE_BUGREPORT=\\ -DPACKAGE=\lttest\ -DVERSION=\0.0\ -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 -I. -I. -g -O2 -MT hello.lo -MD -MP -MF .deps/hello.Tpo \ -c -o hello.lo `test -f 'hello.c' || echo './'`hello.c; \ then mv .deps/hello.Tpo .deps/hello.Plo; \ else rm -f .deps/hello.Tpo; exit 1; \ fi ./libtool: ./libtool: No such file or directory make: *** [hello.lo] Error 1 Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: autoreconf misses ltmain.sh
Am Don, 2002-09-19 um 11.36 schrieb Alexandre Duret-Lutz: Ralf == Ralf Corsepius [EMAIL PROTECTED] writes: Ralf This bug has been present with previous versions of automake and Ralf autoconf (IIRC, it also has been reported several times before). I think this is the same issue as http://mail.gnu.org/pipermail/libtool/2002-August/006640.html Following the link above points to this http://mail.gnu.org/pipermail/libtool-patches/2002-January/001659.html .. which seems to indicate that libtool is the culprit. = There doesn't exist any officially released version of libtool that is usable with autoconf-2.54 and automake-1.7 .. still nobody wanting to care to fix it? Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: building same source with different flags
Am Fre, 2001-12-21 um 06.00 schrieb Ted Irons: Am using autoconf-2.5.2, automake-1.4b, libtool-1.4b on an ix86 box run running Suse Linux with kernel-2.4.6. When I run make I get the following error: source='ascbin.cc' object='libhrnet_la-ascbin.lo' libtool=yes \ depfile='.deps/libhrnet_la-ascbin.Plo' tmpdepfile='.deps/libhrnet_la-ascbin.TPlo' \ depmode=gcc /bin/sh ../../../pipes-1.0/config/depcomp \ /bin/sh ../../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I../../../pipes-1.0/tma/hbp.lib -I../..-fpermissive -I../../../pipes-1.0/tma/util.lib -I../../../pipes-1.0/tma/trff.lib -g -O2 -c -o libhrnet_la-ascbin.lo `test -f ascbin.cc || echo '../../../pipes-1.0/tma/hbp.lib/'`ascbin.cc g++ -DHAVE_CONFIG_H -I. -I../../../pipes-1.0/tma/hbp.lib -I../.. -fpermissive -I../../../pipes-1.0/tma/util.lib -I../../../pipes-1.0/tma/trff.lib -g -O2 -c ../../../pipes-1.0/tma/hbp.lib/ascbin.cc -Wp,-MD,.deps/libhrnet_la-ascbin.TPlo -fPIC -DPIC mv -f libhrnet_la-ascbin.o .libs/libhrnet_la-ascbin.o mv: cannot stat `libhrnet_la-ascbin.o': No such file or directory make[3]: *** [libhrnet_la-ascbin.lo] Error 1 === Any ideas as to what I am doing wrong? Try automake-1.5 Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
libtool-1.4b vs. c++/gcj
Hi, Given this configure.in: AC_INIT(hello.cc) AM_INIT_AUTOMAKE(libcxx,0) AC_PROG_CXX AM_PROG_LIBTOOL AC_OUTPUT(Makefile) With autoconf-cvs and automake-cvs libtool-1.4b tries to add GCJ-support: # ./configure .. appending configuration tag CXX to libtool checking whether the g++ linker (/opt/gcc30/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... no checking whether the g++ linker (/opt/gcc30/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking dynamic linker characteristics... GNU/Linux ld.so appending configuration tag GCJ to libtool checking if gcj supports -fno-rtti -fno-exceptions... (cached) yes checking for gcj option to produce PIC... -fPIC checking if gcj PIC flag -fPIC works... no checking if gcj supports -c -o file.o... no checking whether the gcj linker (/opt/gcc30/bin/ld) supports shared libraries... yes .. I do not understand why this configure script triggers any check for GCJ, nor do I understand why these checks claim to successfully process gcj options. .. I don't have gcj installed at all! # which gcc /opt/gcc30/bin/gcc # which gcj # gcc -v Reading specs from /opt/gcc30/lib/gcc-lib/i486-suse-linux/3.0.1/specs Configured with: ../configure --enable-threads=posix --enable-long-long --prefix=/opt/gcc30 --mandir=/opt/gcc30/man --infodir=/opt/gcc30/info --with-local-prefix=/usr/local --enable-languages=c,c++ --disable-nls --enable-shared --with-system-zlib --host=i486-suse-linux --build=i486-suse-linux Thread model: posix gcc version 3.0.1 20010713 (prerelease) Am I missing something? What triggers these GCJ-checks? Are these auto+tools versions incompatible? Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
