Re: Migrating existing libraries to libtool
Around 23 o'clock on Feb 17, Robert Boehne wrote: > Tough problem you've got here, I don't really see a way > around it without a new versioning flag other than > creating a libX??.la file for the last version of a library > you're attempting to install (which may or may not work anyway). Thanks for re-enforcing my understanding of how libtool works. > Send in the patch soon, and it could be in the 1.5 release. I'll put something together tomorrow and send it along. -keith ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Migrating existing libraries to libtool
Keith, Tough problem you've got here, I don't really see a way around it without a new versioning flag other than creating a libX??.la file for the last version of a library you're attempting to install (which may or may not work anyway). I would say that a patch to add this flag should warn the user that this flag is only for situations like yours, where some other versioning scheme must be supported for legacy reasons. Documentation would also need to reflect this. We wouldn't want new users to abuse this flag because the don't understand what Libtool is doing. Send in the patch soon, and it could be in the 1.5 release. Thanks, Robert Keith Packard wrote: > > Around 2 o'clock on Feb 18, Simon Richter wrote: > > > To remain binary compatible, it suffices to have the same major version, > > as programs are expected to link against the .so. file. Which > > file this actually symlinks to is irrelevant. So in fact you start off > > using -version-info :0:0 and then go on as in the libtool > > manual. > > No, that will give minor version 0 which would be seen as *older* than the > previous version of the library. I really need major and minor versions > to match so I can build replacement versions with the new tools that match > precisely with what's already installed. > > > Hrm, how is that solved currently with imake? > > Imake has all of the necessary system-dependent mechanisms to generate > correct link commands given the desired major and minor version numbers. > It doesn't modify the version numbers provided, it simply uses whatever > pieces are appropriate and ignores the low order values. This has worked > for some time now and developers have become comfortable with the > kind of version checking and compatibility issues related to the set of > platforms this is deployed on. > > I've tried to use automake for existing X libraries and eventually had to > give up and fall back to autoconf as libtool was unable to preserve the > correct major and minor versions on even Linux and BSD. I'd rather not be > forced to support yet another krufty set of build kludges for X just > because libtool has different ideas on library versioning schemes than > we've been using for X. automake is so close to working, let's close the > gap and let imake die a well deserved death (with apologies to Todd > Brunhoff) > > -keith > > ___ > Libtool mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/libtool ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Update for icc
Ok, looks reasonable to me, Approved with this ChangLog entry: 2003-02-17 Allan Sandfeld Jensen <[EMAIL PROTECTED]> * libtool.m4: Intel icc fixups for version 7.0. Thanks! Robert Allan Sandfeld Jensen wrote: > > Hi Robert > > Here's an update on my icc-patch > > I have checked how my patch works from CVS HEAD now against icc 7.0. It > finally seems Intel with version 7.0 has made a usefull standard C++ library. > I have even be able to compile at full working KDE-suite. > > Libtool CVS just need to following additional patch to compile KDE, it does 2 > things: > 1. Change ld-option flag from Qoption ld to GNU syntax -Wl. This is because > the first form does not expand inline, and that's needed for --whole-archive. > (icc 5.0 does not support -Wl, but since it doesnt compile libltdl anyway I > consider it unsupported) > 2. I have removed the -nostdlib option, since this prevents icpc from linking > with it's own C++ library (libcxa and libunwind) > > Patch attached. > > Greetings > `Allan > > > Name: icc-patch2.diff >icc-patch2.diffType: text/x-diff > Encoding: 7bit > > > ___ > Libtool mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/libtool ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Migrating existing libraries to libtool
Around 2 o'clock on Feb 18, Simon Richter wrote: > To remain binary compatible, it suffices to have the same major version, > as programs are expected to link against the .so. file. Which > file this actually symlinks to is irrelevant. So in fact you start off > using -version-info :0:0 and then go on as in the libtool > manual. No, that will give minor version 0 which would be seen as *older* than the previous version of the library. I really need major and minor versions to match so I can build replacement versions with the new tools that match precisely with what's already installed. > Hrm, how is that solved currently with imake? Imake has all of the necessary system-dependent mechanisms to generate correct link commands given the desired major and minor version numbers. It doesn't modify the version numbers provided, it simply uses whatever pieces are appropriate and ignores the low order values. This has worked for some time now and developers have become comfortable with the kind of version checking and compatibility issues related to the set of platforms this is deployed on. I've tried to use automake for existing X libraries and eventually had to give up and fall back to autoconf as libtool was unable to preserve the correct major and minor versions on even Linux and BSD. I'd rather not be forced to support yet another krufty set of build kludges for X just because libtool has different ideas on library versioning schemes than we've been using for X. automake is so close to working, let's close the gap and let imake die a well deserved death (with apologies to Todd Brunhoff) -keith ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Migrating existing libraries to libtool
Keith, > I maintain a few X libraries and would like to see about transitioning > them from imake to automake. The stumbling block is that I cannot change > the library version numbers across this transition on any operating system. To remain binary compatible, it suffices to have the same major version, as programs are expected to link against the .so. file. Which file this actually symlinks to is irrelevant. So in fact you start off using -version-info :0:0 and then go on as in the libtool manual. > libtool makes this transition system dependent as I must compute the > correct version-info string for each operating system to have the correct > library versions generated out the other end. This is contrary to the > desired goals of libtool. Hrm, how is that solved currently with imake? Simon -- GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD ADC6 18A0 CC8D 5706 A4B4 msg03618/pgp0.pgp Description: PGP signature ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Migrating existing libraries to libtool
I maintain a few X libraries and would like to see about transitioning them from imake to automake. The stumbling block is that I cannot change the library version numbers across this transition on any operating system. libtool makes this transition system dependent as I must compute the correct version-info string for each operating system to have the correct library versions generated out the other end. This is contrary to the desired goals of libtool. I understand the goals of libtools versioning scheme and how it helps people resolve library versioning issues on many systems. In this case, it's preventing me from using the tool as I have a few existing systems that I need to remain compatible with. I propose that libtool take a new command line option '-version-number' which explicitly sets the major/minor/revision number of the output library. This would permit projects to explicitly manage version numbers to remain compatible with pre-libtool releases. -keith ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Upgrading a project to libtool and maintaining old library version
A project wishes to upgrade to use libtool to build shared libraries but maintain compatibility with the old library versioning scheme. Is -version-info and -release *it* for how to tell libtool to handle library versions? Old (on Redhat Linux): libfontconfig.so -> libfontconfig.so.1 libfontconfig.so.1 -> libfontconfig.so.1.0 libfontconfig.so.1.0 SONAME: libfontconfig.so.1 Can I duplicate this with a libtool-generated libfontconfig shared library? -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Libtool compiled for HP-UX 11
Dear GNU ! Is there a precompiled version of libtool for HP-UX 11 that I can simply download. Thank you. Ion Filotti [[EMAIL PROTECTED]] Nova Software Labs - N.S.L. 8, rue de Hanovre 75002 Paris France Web: www.NovaSoftwareLabs.com www.nsl.fr E-mail: [EMAIL PROTECTED] Telephone: +33 1 58 18 61 62 Fax: +33 1 58 18 61 60 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: How is relinking with DESTDIR != installdir in newish libtool?
Do you ever have the problem that the libtool re-linker finds the old version of the thing you are building from /usr/lib before it finds the BUILDROOT one in /tmp/build-root/usr/lib? That's my fear pj Tim Mooney wrote: In regard to: How is relinking with DESTDIR != installdir in newish...: With libtool-1.4.2, I was using a patch (see below) that introduced DESTDIR that fixed the problems with relinking that happened when building RPMS. The problem was that when libraries were temporarily installed to /tmp/buildroot/usr/lib the re-linker would look in the final destination /usr/lib and fail. Has this problem been solved in the newer libtool such as 1.4.3 or 1.5? How? I just looked at ltmain.sh from 1.4.3 and there is no DESTDIR. 1.4.3 solved it in a different way, using a patch based either partially or fully on work done by Ossama Othman (I think). It adds an argument "-inst-prefix-dir" that gets passed to libtool during the relink that happens during install. It all happens automatically, so there's nothing new that a package builder needs to worry about. 1.4.3 has been working relatively well for me, for the majority of packages I've built with it. I use BuildRoot installs exclusively. Tim -- Paul E. Johnson email: [EMAIL PROTECTED] Dept. of Political Sciencehttp://lark.cc.ku.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
