a new version is available (1.5.2) and it resolves many bugs (such as the -pthread one) that are a pain when porting applications to bsd packaged on a gentoo system. thanks. Reproducible: Always Steps to Reproduce: 1. 2. 3.
*** Bug 23071 has been marked as a duplicate of this bug. ***
if you mean the -pthread thing with libsdl/kde that's been resolved by making sure the libsdl.la file has all the -pthread's sed-ed out of it
no, i'm not referring to any gentoo specific bug. I'm a developer and I make the tarball for my program on a gentoo machine, so the libtool provided within the tarball is 1.4.3. there are no problems with it on linux, but this is insufficient for MacOs or *BSD. On those systems a libtoolize command (with a 1.5.x version) is needed to fix some bugs like the -pthread issue under bsd and others compatibility problem for dynlib under macosx. it would be great to have libtool 1.5.x on my gentoo host to have this problem resolved. What are the cons of having it updated in portage ? bye
From taking a quick look at the ebuild it looks like quite a bit of re patching and testing would have to be done. Now seeing as your a developer you could really help speed this effort up if you did some testing yourself and were able to tell us the cons yourself. Feel free to submit an updated ebuild for this after you have tested. :)
Well, the big issue I guess is that supposidly it breaks compatibility across the board. I have not looked into this, yet due to other things taking up my time, so I cannot comment.
I'll test it for sure, but please if someone known it will break up my host... speak now ;) bye
does anyone have an ebuild to test or should I try the one proposed in #13493 ? if so, which one ?
Bit late now, but if you can wait, I'll do an masked ebuild tomorrow night.
Added.
I've emerged it and it seems to work. I've compiled some application. No issue found. My application now uses new autotools scripts and seems to work perfectly. is there any other test should I make to test libtool 1.5.2 ? bye
where's what i've emerged so far w/out problems: app-portage/mirrorselect-0.82-r3 dev-perl/Locale-gettext-1.01-r1 dev-tcltk/expect-5.37.1-r1 dev-util/cscope-15.5 dev-util/intltool-0.30 games-arcade/openmortal-0.5 games-emulation/dosbox-0.61 games-puzzle/neverball-1.1.0 games-roguelike/hengband-1.6.0 games-simulation/corewars-0.9.13-r1 kde-base/arts-1.2.0 kde-base/kdeaccessibility-3.2.0 kde-base/kdeaddons-3.2.0 kde-base/kdeadmin-3.2.0 kde-base/kdeartwork-3.2.0 kde-base/kdebase-3.2.0 kde-base/kdeedu-3.2.0 kde-base/kdegraphics-3.2.0 kde-base/kdelibs-3.2.0 kde-base/kdemultimedia-3.2.0 kde-base/kdenetwork-3.2.0 kde-base/kdepim-3.2.0 kde-base/kdepim-3.2.0-r1 kde-base/kdetoys-3.2.0 kde-base/kdeutils-3.2.0 media-fonts/corefonts-1-r1 media-gfx/gqview-1.3.9 media-libs/imlib-1.9.14-r1 media-libs/netpbm-10.20 net-dns/hesiod-3.0.2-r1 net-ftp/curl-7.11.0 net-ftp/ncftp-3.1.7 net-mail/courier-imap-2.1.2-r1 net-mail/qmail-1.03-r15 net-mail/vpopmail-5.4.0_rc1 net-misc/proxytunnel-1.1.3 net-wireless/kismet-3.0.1-r1 net-wireless/wireless-tools-27_pre7 sys-apps/busybox-1.00_pre6 sys-apps/help2man-1.33.1 sys-apps/ucspi-tcp-0.88-r8 sys-apps/xinetd-2.3.13 sys-boot/grub-0.94 sys-devel/automake-1.8.2 sys-devel/gcc-3.3.2-r6 sys-devel/libtool-1.5.2 sys-fs/udev-016 x11-base/opengl-update-1.6 x11-libs/evas-1.0.0.20040201_pre12
I dont know where I saw it but I think I've seen something about some sec risk with every libtool < 1.5.1 I'll keep my eye out.. Large scale testing is welcome.
Symlink Vulnerability in GNU libtool <1.5.2 http://marc.theaimsgroup.com/?l=bugtraq&w=2&r=1&s=%22libtool+%3C1.5.2%22&q=b Ok now it's largescale testing required and or a backport of the fix.
Uhm guys, if its already packaged, not much libtool will affect (or updated version in the tree). You rather have to test stuff like E17, etc that runs a autogen.sh to generate auto* and libtool scripts, etc ... these are the ones that will break (or projects developed on gentoo). Other I can think of, is cvs kde/gnome/etc.
well i used it on some of the kde packages because i did some from cvs myself and they didnt crash ... but i also just ran it on all my e17 apps and they all worked: app-sci/equate-0.0.4.20040124 dev-db/edb-1.0.4.20040117 dev-libs/eet-0.9.0.20040124 dev-libs/ewd-0.0.1.20040117 dev-libs/libedit-20040126 media-gfx/elicit-0.7.20040117 media-gfx/entice-0.9.0.20040201 media-libs/edje-0.0.1.20040201 media-libs/epsilon-0.0.2.20040117 media-libs/estyle-0.0.2.20040201 media-libs/etox-0.0.2.20040201 media-libs/imlib2-1.1.0.20040201 media-sound/eplayer-0.7.20040201 net-news/erss-0.0.2.20040201 x11-libs/ecore-1.0.0.20040201_pre4 x11-libs/esmart-0.0.2.20040201 x11-libs/evas-1.0.0.20040201_pre12 x11-libs/ewl-0.0.3.20040201 x11-misc/entrance-0.9.0.20040201 x11-misc/iconbar-0.5.20040124 app-misc/evidence-0.9.7.20040201
i just did a ppc bootstrap and the first thing i did was install libtool-1.5.2 ... the system finished `emerge system` just fine (~100 packages)
ok, perhaps we do have a show stopper here ... in a bunch of .la files on my system, i'm missing the libtool information ... which means when i try to link against them, i'll get the 'this aint a valid libtool archive' error glib-1.2.x is what caught my eye, but it seems i have a few borked ones on my system find attached examples of what i'm refering to
Created attachment 25118 [details] broken-libtool-archives a correct libtool archive would be of this form: # Generated by ltmain.sh - GNU libtool 1.4.1 (1.922.2.34 2001/09/03 01:22:13) the 'libtool <VERSION>' is what's missing in all these
a quick way to reproduce this is: ebuild /usr/portage/dev-libs/glib/glib-1.2.10-r5.ebuild clean unpack cd /var/tmp/portage/glib-1.2.10-r5/work/glib-1.2.10 libtoolize -c -f grep VERSION= ltmain.sh with libtool 1.4.x, you'll have VERSION=1.4.x, but with libtool 1.5.x, you get VERSION= which then produces a bunch of borked .la files ;(
just me talking to myself but it seems the bug lies in the file /usr/share/libtool/ltmain.sh in 1.4.x, it looks like this: # Constants. PROGRAM=ltmain.sh PACKAGE=libtool VERSION=1.4.3 TIMESTAMP=" (1.922.2.111 2002/10/23 02:54:36)" in 1.5.x, it looks like this: # Constants. PROGRAM=ltmain.sh PACKAGE= VERSION= TIMESTAMP=" (1.1220.2.60 2004/01/25 12:25:08)" filling in PACKAGE and VERSION and re-emerging the packages owning the broken .la files seems to be fixing stuff for me
month after month day after day SpanKY strikes again.. damn fine job your do at discovering bugs and offering resolutions. I tip my hat to you.
ok, here's the fix in the configure script, the VERSION= and PACKAGE= now have space padding in front of them which caused the eval/grep in gen_ltmain_sh in src_unpack to not match if we change the grep expressions like this we should be all set: eval `grep '^ *PACKAGE' configure` && \ eval `grep '^ *VERSION' configure` && \ the fix being the addtion of ' *' to optionally match leading whitespace
oh, and here's a wicked dirty one-liner to have portage re-emerge packages that have broken .la emerge `for f in $(head -n 2 *.la | grep -v libtool | grep ltmain -B 1 | grep ^== | awk '{print $2}') ; do qpkg -f $f -nc ; done | sort -u` it'll probably break when it tries to emerge a package that depends on a broken package so just remove the `emerge` to have it give you the list
*** Bug 40679 has been marked as a duplicate of this bug. ***
Yes, I thought this was it. I'll fix it tonight.
*** Bug 40691 has been marked as a duplicate of this bug. ***
Ok, please try -r1.
ok, i confirmed 1.5.2-r1 is working for me if we got Bug 40654 fixed i think we can release it upon stable (i've tested this guy out on x86/ppc/hppa and all are fine now afaict)
*** Bug 40857 has been marked as a duplicate of this bug. ***
libwww is breaking due a autoconf-2.5 vs autoconf-2.13 requirement. the autoconf-2.5 request is added by the newer libtool. the solution are either fix the libwww configure.in or put 2.13 instead of 2.5 in the libtool.am file installed.
*** Bug 41188 has been marked as a duplicate of this bug. ***
*** Bug 41050 has been marked as a duplicate of this bug. ***
*** Bug 42630 has been marked as a duplicate of this bug. ***
*** Bug 43258 has been marked as a duplicate of this bug. ***
*** Bug 49796 has been marked as a duplicate of this bug. ***
Any idea about how to fix this problem? I do not have libtool 1.5.2 -r1 in portage, where i can find it?
i got a dirty solution grep /var/tmp /usr/lib/*.la emerge -C broken-package ebuild broken-package clean unpack compile ebuild qmerge I really do not know what is wrong with my gentoo.
Sorry, correct is following: grep /var/tmp /usr/lib/*.la emerge -C broken-package ebuild broken-package clean unpack compile install vi the broken.la ebuild qmerge
dont use 1.5.2-r1, it is broken in many ways ... use the latest 1.5.2 available if you have broken .la files on your system, just re-emerge the package that owns it
*** Bug 50406 has been marked as a duplicate of this bug. ***
In response to: ------- Additional Comment #40 From Mr. Bones. 2004-05-07 14:24 PST ------- *** Bug 50406 has been marked as a duplicate of this bug. *** The solution was to DISABLE sandbox.
** (dia:15395): WARNING **: No builtin or dynamically loaded modules were found. Pango will not work correctly. This probably means there was an error in the creation of: '/var/tmp/portage/pango-1.4.0/image//etc/pango/pango.modules' You may be able to recreate this file by running pango-querymodules. (dia:15395): GLib-GObject-CRITICAL **: file gobject.c: line 1561 (g_object_ref): assertion `G_IS_OBJECT (object)' failed ** (dia:15395): CRITICAL **: file pango-engine.c: line 68 (_pango_engine_shape_shape): assertion `PANGO_IS_FONT (font)' failed ** ERROR **: file shape.c: line 75 (pango_shape): assertion failed: (glyphs->num_glyphs > 0) aborting... Aborted
