Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

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 an attachment (id=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