Re: libtool doesn't allow "make DESTDIR=`pwd`/foo install" anymore.
I thought I had posted to the list earlier, but must have sent this to a specific person. This libtool issue is a known and fixed problem in libtool cvs. I built rpms of that snapshot of libtool and I've tested it and it does work. If you want to try the RPMS, I stashed them in here http://lark.cc.ukans.edu/~pauljohn/software I do now know what patch is required to make libtool-1.4.2 work as it is currently released, I've been asking about. My understanding is that the Debian packager of libtool has a patch which fixes the problem. I have tried taking the patch which was applied in cvs and applying it to libtool-1-4.2, but that caused segfaults when running programs that use libtool, so for the moment I'm running the libtool cvs snapshot from 2001-11-21. http://lark.cc.ukans.edu/~pauljohn/software/libtool-20011121-1pj.i386.rpm I have no idea if this edition introduces new bugs or not, I wish I could run a minimally modified 1.4.2 Martin Norbäck wrote: > tis 2001-11-27 klockan 15.54 skrev Rob Browning: > >>If you build a package with --prefix=/usr and that package has >>interdependencies among it's shared libraries (like guile and >>heimdal), libtool will no longer allow you to install to a temporary >>directory via >> >> make DESTDIR=`pwd`/foo install >> >>libtool 1.4 allowed this, but as of at least 1.4.2, it doesn't. This >>makes it very difficult, if not impossible to package programs using >>libtool for systems like debian that require creating a local install >>from which the package is generated. >> > > We have this problem with our package ogle as well. Libtool 1.4 allowed > this, but didn't do it correctly. I haven't tried libtool 1.4.2 yet. > > See my mail to this list: > http://mail.gnu.org/pipermail/libtool/2001-October/005646.html > > >>See http://bugs.debian.org/libtool, bugs 57087 and 98342. >> > > This seems to be the problem we have too. > > >>I also wanted to see if anyone had suggestions for a fix, even a >>temporary one. There's a patch in the debian package that seems to >>fix the problem for some people, but still doesn't work for other >>package like guile and heimdal. >> > > No, I have not found a solution to this problem. Our current approach > when building RPMS is to build the package twice, the second time with > the package partially installed. Not very good. > > Regards, > > Martin > > -- Paul E. Johnson email: [EMAIL PROTECTED] Dept. of Political Sciencehttp://lark.cc.ukans.edu/~pauljohn University of Kansas Office: (785) 864-9086 Lawrence, Kansas 66045FAX: (785) 864-5700 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool doesn't allow "make DESTDIR=`pwd`/foo install" anymore.
Obviously, I can't invest the time to bugshoot all these applications that won't compile, about which I have been emailed by many people in this list during the past 2 hours. I can add this information, however. I achieved this success with the newer automake and autoconf, $ rpm -q automake automake-1.5-1pj [pauljohn@valinux fs]$ rpm -q autoconf autoconf-2.52-1pj which are also in my software directory. I did not try to rebuild an SRPM file with this libtool, instead I started from a source tree and did the automake/autoconf ritual to create the tarball, and built the RPM from there. It easily could be true that tarballs or SRPMS that were built with old versions of libtool and automake/autoconf do not rebuild with the current libtool. Maybe some libtool maintainers will enter this thread and tell us their expectations. Other than to say "this worked in the case I tested" I am not making any claims about the setup. It seems to me that if you want to rebuild an RPM from an SRPM that was compiled with the old libtool, your easiest path is to stick to the old libtool. pj Martin Norbäck wrote: > tis 2001-11-27 klockan 17.38 skrev Paul E Johnson: > >>This libtool issue is a known and fixed problem in libtool cvs. I built >>rpms of that snapshot of libtool and I've tested it and it does work. >>If you want to try the RPMS, I stashed them in here >>http://lark.cc.ukans.edu/~pauljohn/software >> > > I tried rebuilding the ogle RPM with your new version of libtool > (libtool-20011121-1pj), and got the errors shown in the attached file. > > There are still things like > > libtool: install: warning: `../ogle/libmsgevents.la' has not been > installed in `/usr/lib/ogle' > > Regards, > > Martin > -- Paul E. Johnson email: [EMAIL PROTECTED] Dept. of Political Sciencehttp://lark.cc.ukans.edu/~pauljohn University of Kansas Office: (785) 864-9086 Lawrence, Kansas 66045FAX: (785) 864-5700 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: library relocation
I think the DESTDIR patch for ltmain.sh fixes that. At least it did for me. I had the problem that relinking was failing with "make prefix=/blah install" so I retooled with DESTDIR and with this patch everything seems OK. I found this through a bugs page for libtool, but I can't find that page now. But I do still have the patch address: http://mail.gnu.org/pipermail/bug-libtool/2002-February/003019.html Frederic Gobry wrote: Hello, I'm working on linux based embedded platforms. To build a complete platform, we usually compile and install our software packages in a directory that is specific to each developer, say: /home/fred/frozen/usr/lib/... Then, the compiled libraries and executables that must be actually available on the final platform are manipulated so that they finally appear in /usr/lib/... ...when the platform has booted. Here comes the problem: - Scenario 1: a library (let say glib) is configured with the final prefix (/usr) and installed for instance with a make install DESTDIR=/home/fred/ Then, a program that uses the library will link with sth like -L/home/fred/frozen/lib -lglib Unfortunately, libtool (1.4.2a) will transform this into... /usr/lib/libglib.so Grr. This is not a library compiled for the same architecture. - Scenario 2: the library is directly configured to get installed in /home/fred/... Then, the linking will be performed correctly, but a wrong rpath will be added in the executable... Do you know a better method ? Thank, Frédéric -- Paul E. Johnson email: [EMAIL PROTECTED] Dept. of Political Sciencehttp://lark.cc.ku.edu/~pauljohn 1541 Lilac Lane, Rm 504 University of Kansas Office: (785) 864-9086 Lawrence, Kansas 66044-3177 FAX: (785) 864-5700 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
libtool: make prefix install fails
ory `/home/pauljohn/LinuxDownloads/redhat/BUILD/swarm-2.1.140.20020514/=with-hdf/src' /bin/sh /home/pauljohn/LinuxDownloads/redhat/BUILD/swarm-2.1.140.20020514/mkinstalldirs /tmp/swarm-root/usr/lib/swarm /bin/sh ../libtool --mode=install /usr/bin/install -c libswarm.la /tmp/swarm-root/usr/lib/swarm/libswarm.la libtool: install: warning: relinking `libswarm.la' cd /home/pauljohn/LinuxDownloads/redhat/BUILD/swarm-2.1.140.20020514/=with-hdf/src; /bin/sh ../libtool --mode=relink gcc -g - O2 -march=i386 -mcpu=i686 -Wall -Wno-import -Wno-protocol -Werror -Wno-unknown-pragmas -o libswarm.la -version-info 0:0:0 -rp ath /usr/lib/swarm -Lspace -Lanalysis -Lsimtoolsgui -Lsimtools -Lrandom -Ltkobjc -Ltclobjc -Lobjectbase -Lactivity -Ldefobj - Lcollections -Lmisc -L../libobjc -L/usr/lib -R /usr/lib -L/usr/lib -R /usr/lib -L/usr/lib -R /usr/lib -L/usr/lib -R /usr/lib -L/usr/X11R6/lib -R /usr/X11R6/lib -L/usr/X11R6/lib SwarmEnvironment.lo -lspace -lanalysis -lsimtoolsgui -lsimtools -lrandom -ltkobjc -ltclobjc -lobjectbase -lactivity -ldefobj -lcollections -lmisc -lobjc -lBLT24 -ltk8.3 -ltcl8.3 -lXpm -lpng -lhdf5 - lz ../avcall/libavcall.la -lX11 -lm -ldl gcc -shared SwarmEnvironment.lo -Wl,--whole-archive ../avcall/.libs/libavcall.al -Wl,--no-whole-archive -Wl,--rpath -Wl,/us r/lib/swarm -Wl,--rpath -Wl,/usr/lib -Wl,--rpath -Wl,/usr/X11R6/lib -L/home/pauljohn/LinuxDownloads/redhat/BUILD/swarm-2.1.1 40.20020514/=with-hdf/src/space -L/home/pauljohn/LinuxDownloads/redhat/BUILD/swarm-2.1.140.20020514/=with-hdf/src/analysis -L/home/pauljohn/LinuxDownloads/redhat/BUILD/swarm-2.1.140.20020514/=with-hdf/src/simtoolsgui -L/home/pauljohn/LinuxDownloads/redhat/BUILD/swarm-2.1.140.20020514/=with-hdf/src/simtools -L/home/pauljohn/LinuxDownloads/redhat/BUILD/swarm-2.1.140.20020514 /=with-hdf/src/random -L/home/pauljohn/LinuxDownloads/redhat/BUILD/swarm-2.1.140.20020514/=with-hdf/src/tkobjc -L/home/pauljohn/LinuxDownloads/redhat/BUILD/swarm-2.1.140.20020514/=with-hdf/src/tclobjc -L/home/pauljohn/LinuxDownloads/redhat/BUILD/swarm-2.1.140.20020514/=with-hdf/src/objectbase -L/home/pauljohn/LinuxDownloads/redhat/BUILD/swarm-2.1.140.20020514/=with-hdf/src /activity -L/home/pauljohn/LinuxDownloads/redhat/BUILD/swarm-2.1.140.20020514/=with-hdf/src/defobj -L/home/pauljohn/LinuxDownloads/redhat/BUILD/swarm-2.1.140.20020514/=with-hdf/src/collections -L/home/pauljohn/LinuxDownloads/redhat/BUILD/swarm-2.1.140.20020514/=with-hdf/src/misc -L/home/pauljohn/LinuxDownloads/redhat/BUILD/swarm-2.1.140.20020514/=with-hdf/libobjc -L/usr/lib -L/usr/X11R6/lib -L/usr/lib/swarm -lspace -lanalysis -lsimtoolsgui -lsimtools -lrandom -ltkobjc -ltclobjc -lobjectbase -lac tivity -ldefobj -lcollections -lmisc -lobjc -lBLT24 -ltk8.3 -ltcl8.3 -lXpm -lpng -lhdf5 -lz ../avcall/.libs/libavcall.al -lX1 1 -lm -ldl-Wl,-soname -Wl,libswarm.so.0 -o .libs/libswarm.so.0.0.0 /usr/bin/ld: cannot find -lspace collect2: ld returned 1 exit status libtool: install: error: relink `libswarm.la' with the above command before installing it libtool: install: warning: remember to run `libtool --finish /usr/lib/swarm' I'm completely bewildered, and would beg for any help anybody can give. There is an even more ghastly aspect of this problem that was just brought to my attention. If an old version of Swarm is installed on the system, then libtool will find it and relink against that, thus defeating the purpose of building the new library. That's really awful! -- Paul E. Johnson email: [EMAIL PROTECTED] Dept. of Political Sciencehttp://lark.cc.ku.edu/~pauljohn 1541 Lilac Lane, Rm 504 University of Kansas Office: (785) 864-9086 Lawrence, Kansas 66044-3177 FAX: (785) 864-5700 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
