Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
libtool 1.5 was recently released and among other things includes support for icc on x86 and ecc in ia64. This is definately very important for anyone wanting to eventually compile their entire systems with the intel c/c++ compiler. Perhaps an option for icc will show up in gcc-config that uses icc and libtoolizes most packages?
Created an attachment (id=13493) [details] libtool 1.5 ebuild libtool 1.5 doesnt seem to need the relink patch. I also removed the setup function for causing problems and a few patches to 1.4 that caused problems. The portage patch still applies cleanly without modifications.
Nick, could you comment on known issues we should be looking out for with 1.5 ?
Just like to state that with libtool 1.5 i only know of icc support and the keywords for this build should likely be ~ or even - prefixed instead of the enthusiastic keywords i have in the ebuild. I havent given this much testing and after a reformat dont even have it installed at the moment.... got distracted with gcc 3.3 stuff which i find more interesting. :) but icc support in the core arch for gentoo would be very nice indeed, and in my experience libtool support has been one of the bigger annoyances. My comment on the relink patch is based on patch assuming i meant to specify -R on the commandline, implying the patch had made it upstream. :)
I stated this in a private email to Martin, so I'll post here. I definitely think there are other issues to considier, but this is what I'll say for now. >>>>>>>>>> Begin Quote As for libtool-1.5, there are a couple of gotcha's. First and foremost is the relibtoolize process. It now requires autoconf 2.5X explicitly, you cannot use 2.1 (it won't let you even if you tried). Also, aclocal is going to start pulling in the libtool-1.5 macros by default if the ebuild uses libtool (which won't work if the package was libtoolized with 1.4), so we must be careful when running it. We still need some of those patches in libtool.eclass, but they will need modification (I know the portage & relink for sure). Moreover, tags are handled differently in how they are passed to libtool now, so we'll need to watch out for non-automake ebuilds which explicitly set tags (libtool --tag). There times where it might be advantageous to maintain a dual libtool-1.4/libtool-1.5 setup in the same manner as autoconf-2.13/autoconf-2.5x. Things that would need to be different from the other wrappers is that we'd need to add some check to the automake/aclocal wrappers to determine which libtool to use and include the relevant libtool macro path. <<<<<<<<<< End Quote
*** Bug 20381 has been marked as a duplicate of this bug. ***
Anyone alive that handles libtool stuff and want to look at getting this into portage? I took a look at the attached ebuild, but the epatch lines are messed up, and I'm unsure why some patches are being applied twice. An error in the ebuild perhaps?
please update to 1.5. I'm a developer and I develop my prog on gentoo. I need the 1.5 version to use the new libtoolize to create a 'libtool' script to be added to my tarball. since 1.5 has much much better support for darwin, I really need it to make my application portable. thanks.
Created an attachment (id=21440) [details] ebuild for 1.5 You have to copy all the files in /usr/portage/sys-devel/libtool/files/1.4.3/libtool-1.* to files/1.5 in your local (custome) portage dir after you run ebuild libtool-1.5.ebuild digest for it to emerge.. it will look for the patches, and if it cannot find them it will fail.
(From update of attachment 21440 [details]) ># Copyright 1999-2003 Gentoo Technologies, Inc. ># Distributed under the terms of the GNU General Public License v2 > >IUSE= > >inherit eutils gnuconfig > ># NOTE: We install libltdl of libtool-1.3x for compat reasons ... > >OLD_PV="1.3.5" >S="${WORKDIR}/${P}" >OLD_S="${WORKDIR}/${PN}-${OLD_PV}" >DESCRIPTION="A shared library tool for developers" >SRC_URI="mirror://gnu/${PN}/${P}.tar.gz > mirror://gnu/${PN}/${PN}-${OLD_PV}.tar.gz" >HOMEPAGE="http://www.gnu.org/software/libtool/libtool.html" > >LICENSE="GPL-2" >SLOT="0" >KEYWORDS="~amd64 ~x86 ~ppc ~sparc ~alpha ~mips ~hppa ~arm ~ia64" > >DEPEND="virtual/glibc" > > >lt_setup() { > export WANT_AUTOCONF_2_5=1 > export WANT_AUTOMAKE_1_5=1 >} > >gen_ltmain_sh() { > local date= > local PACKAGE= > local VERSION= > > rm -f ltmain.shT > date=`./mkstamp < ./ChangeLog` && \ > eval `grep '^PACKAGE' configure` && \ > eval `grep '^VERSION' configure` && \ > sed -e "s/@PACKAGE@/${PACKAGE}/" -e "s/@VERSION@/${VERSION}/" \ > -e "s%@TIMESTAMP@%$date%" ./ltmain.in > ltmain.shT || return 1 > > mv -f ltmain.shT ltmain.sh || { > (rm -f ltmain.sh && cp ltmain.shT ltmain.sh && rm -f ltmain.shT) > return 1 > } > > return 0 >} > >src_unpack() { > lt_setup > > unpack ${A} > > cd ${OLD_S} > echo > # Install updated missing script > portageq has_version / "sys-devel/automake" && { > rm -f missing > automake --add-missing > } > > einfo "Patching ${OLD_S##*/} ..." > epatch ${FILESDIR}/${PV}/${PN}-1.2f-cache.patch > epatch ${FILESDIR}/${PV}/${PN}-1.3.5-nonneg.patch > epatch ${FILESDIR}/${PV}/${PN}-1.3.5-mktemp.patch > > use hppa && S="${OLD_S}" gnuconfig_update > use amd64 && S="${OLD_S}" gnuconfig_update > > cd ${S} > echo > # Install updated missing script > portageq has_version / "sys-devel/automake" && { > rm -f missing > automake --add-missing > } > > # Make sure non of the patches touch ltmain.sh, but rather ltmain.in > rm -f ltmain.sh* > > einfo "Patching ${S##*/} ..." > # Redhat patches > epatch ${FILESDIR}/${PV}/${PN}-1.3.5-mktemp.patch > epatch ${FILESDIR}/${PV}/${PN}-1.4-nonneg.patch ># epatch ${FILESDIR}/${PV}/${PN}-1.4.2-s390_x86_64.patch > # Fix the relink problem where the relinked libs do not get > # installed. It is *VERY* important that you get a updated > # 'libtool-${PV}-relink.patch' if you update this, as it > # fixes a very serious bug. Please not that this patch is > # included in 'libtool-${PV}-gentoo.patch' for this ebuild. > # > # NOTE: all affected apps should get a 'libtoolize --copy --force' > # added to upate libtool > # > #epatch ${FILESDIR}/${PV}/${PN}-1.4.2-relink-58664.patch > epatch ${FILESDIR}/${PV}/${PN}-1.4.2-multilib.patch > epatch ${FILESDIR}/${PV}/${PN}-1.4.2-demo.patch > # Mandrake patches > #epatch ${FILESDIR}/${PV}/${PN}-1.4.3-quotes.patch > epatch ${FILESDIR}/${PV}/${PN}-1.4.3-lib64.patch > #epatch ${FILESDIR}/${PV}/${PN}-1.4.2-add-x11r6-lib-in-ignores-for-rpath.patch > epatch ${FILESDIR}/${PV}/${PN}-1.4.2-fix-linkage-of-cxx-code-with-gcc.patch > epatch ${FILESDIR}/${PV}/${PN}-1.4.2-archive-shared.patch > epatch ${FILESDIR}/${PV}/${PN}-1.4.3-ltmain-SED.patch > epatch ${FILESDIR}/${PV}/${PN}-1.4.2-expsym-linux.patch > epatch ${FILESDIR}/${PV}/${PN}-1.4.3-amd64-alias.patch > epatch ${FILESDIR}/${PV}/${PN}-1.4.3-libtoolize--config-only.patch > epatch ${FILESDIR}/${PV}/${PN}-1.4.3-pass-thread-flags.patch > # Do not create bogus entries in $dependency_libs or $libdir > # with ${D} or ${S} in them. > # > # Azarah - 07 April 2002 > epatch ${FILESDIR}/${PV}/${PN}-1.4.2-portage.patch > > einfo "Generate ltmain.sh ..." > gen_ltmain_sh || die "Failed to generate ltmain.sh!" >} > >src_compile() { > lt_setup > > # > # ************ libtool-1.3x ************ > # > > cd ${OLD_S} > einfo "Configuring ${OLD_S##*/} ..." > ./configure --host=${CHOST} \ > --prefix=/usr \ > --infodir=/usr/share/info || die > > einfo "Building ${OLD_S##*/} ..." > emake || die > > # > # ************ libtool-1.4x ************ > # > > cd ${S} > einfo "Configuring ${S##*/} ..." > ./configure --host=${CHOST} \ > --prefix=/usr \ > --infodir=/usr/share/info || die > > einfo "Building ${S##*/} ..." > emake || die >} > >src_install() { > # > # ************ libtool-1.3x ************ > # > > einfo "Installing ${OLD_S##*/} ..." > cd ${OLD_S}/libltdl; make DESTDIR=${D} install || die > > # Remove stuff we are not going to use ... > for x in libltdl.a libltdl.la libltdl.so > do > [ -f ${x} ] && rm -f ${D}/usr/lib/${x} > done > rm -rf ${D}/usr/include > > # > # ************ libtool-1.4x ************ > # > > einfo "Installing ${S##*/} ..." > cd ${S}; make DESTDIR=${D} install || die > > dodoc AUTHORS COPYING ChangeLog* NEWS \ > README THANKS TODO doc/PLATFORMS >} >
when emergeing the ebuild from comment #9: emerge ./libtool-1.5.ebuild Calculating dependencies ...done! >>> emerge (1 of 1) sys-devel/libtool-1.5 to / >>> md5 src_uri ;-) libtool-1.5.tar.gz >>> md5 src_uri ;-) libtool-1.3.5.tar.gz >>> Unpacking source... >>> Unpacking libtool-1.5.tar.gz to /home/scratch/portage_tmpdir/portage/libtool-1.5/work >>> Unpacking libtool-1.3.5.tar.gz to /home/scratch/portage_tmpdir/portage/libtool-1.5/work automake-1.5: configure.in: installing `./missing' * Patching libtool-1.3.5 ... * Applying libtool-1.2f-cache.patch... [ ok ] * Applying libtool-1.3.5-nonneg.patch... [ ok ] * Applying libtool-1.3.5-mktemp.patch... [ ok ] configure.ac:55: version mismatch. This is Automake 1.7.5, configure.ac:55: but the definition used by this AM_INIT_AUTOMAKE configure.ac:55: comes from Automake 1.7.3. You should recreate configure.ac:55: aclocal.m4 with aclocal and run automake again. configure.ac: installing `./missing' * Patching libtool-1.5 ... Could somebody enlighten me as to what theis means?
I believe that this is somewhat related to a problem I had with autoconf && libwww: http://bugs.gentoo.org/show_bug.cgi?id=35327 (which might be of some use when/if libtool-1.5 is supported in portage).
*** This bug has been marked as a duplicate of 39576 ***
