Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 66449 - gettext-$NEWVERSION libs and programs links against the old installed gettext-$OLDVERSION LIBS.
Summary: gettext-$NEWVERSION libs and programs links against the old installed gettext...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Development (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo's Team for Core System packages
URL:
Whiteboard:
Keywords:
: 66473 66527 66589 66637 66685 66862 66939 66951 66981 67119 67268 67465 67613 68191 68487 69146 69326 (view as bug list)
Depends on:
Blocks: 66951
  Show dependency tree
 
Reported: 2004-10-05 11:58 UTC by Simone Gotti (RETIRED)
Modified: 2004-11-04 19:10 UTC (History)
22 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
new ebuild with patch (gettext-0.14.1-r1.ebuild,2.80 KB, application/octet-stream)
2004-10-27 21:56 UTC, nobody
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Simone Gotti (RETIRED) gentoo-dev 2004-10-05 11:58:47 UTC
I upgraded to gettext-0.14.1 but it's program are linked against gettext-0.12.1-r1 (the previously installed)

For example:
xgettext: error while loading shared libraries: libgettextlib-0.12.1.so: cannot open shared object file: No such file or directory

So I had to reemerge again it, so it linked against the same right libs and it works.

Then to test it I emerged gettext-0.12.1 and again:

xgettext: error while loading shared libraries: libgettextlib-0.14.1.so: cannot open shared object file: No such file or directory

I can always reproduce it, so let me know what you need.

Reproducible: Always
Steps to Reproduce:


Actual Results:  
 


Portage 2.0.51_rc7 (default-x86-2004.0, gcc-3.4.2, glibc-2.3.4.20040808-r0, 
2.6.9-rc1-mm2 i686) 
================================================================= 
System uname: 2.6.9-rc1-mm2 i686 AMD Athlon(tm) XP 2000+ 
Gentoo Base System version 1.6.1 
Autoconf: sys-devel/autoconf-2.59-r4 
Automake: sys-devel/automake-1.8.5-r1 
Binutils: sys-devel/binutils-2.15.90.0.1.1-r3 
Headers:  sys-kernel/linux26-headers-2.6.8.1 
Libtools: sys-devel/libtool-1.5.2-r5 
ACCEPT_KEYWORDS="x86 ~x86" 
AUTOCLEAN="yes" 
CFLAGS="-mtune=i686 -O2" 
CHOST="i686-pc-linux-gnu" 
COMPILER="" 
CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3.3/share/config:/usr/kde/3.3/env:/usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" 
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" 
CXXFLAGS="-mtune=i686 -O2" 
DISTDIR="/usr/portage/distfiles" 
FEATURES="autoaddcvs buildpkg ccache collision-protect confcache distlocks 
keeptemp keepwork sandbox" 
GENTOO_MIRRORS="http://www.die.unipd.it/pub/Linux/distributions/gentoo-sources/" 
MAKEOPTS="-j1" 
PKGDIR="/usr/portage/packages" 
PORTAGE_TMPDIR="/var/tmp" 
PORTDIR="/usr/portage" 
PORTDIR_OVERLAY="/usr/local/portage /usr/local/bmg-main /usr/local/bmg-gnome-current" 
SYNC="rsync://rsync1.it.gentoo.org/gentoo-portage" 
USE="3dnow X acl acpi acpi4linux alsa apm arts atm audiofile avi berkdb 
bitmap-fonts bluetooth breakme cdr crypt cscope cups curl cvs dga doc dv dvd 
dvdr encode evo evolution fbcon ffmpeg flac foomaticdb freetype gdbm gif 
gimpprint gmp gpm gtk2 gtkhtml hal imlib ipv6 irmc java jpeg kakasi kde 
kerberos krb4 ldap libg++ libgda libwww mad mikmod mmx motif moznocompose 
moznoirc moznomail mozsvg mpeg ncurses nls nptl oggvorbis opengl opie oss pam 
pda pdflib perl png ppds python qt quicktime readline ruby samba sdl slang 
smime spell sse ssl svga tcpd tiff truetype usb wifi wmf x86xine xml xml2 xmms 
xprint xv xvid yv12 zlib"
Comment 1 SpanKY gentoo-dev 2004-10-05 21:30:35 UTC
run revdep-rebuild, the gettext authors seem to do this on purpose :/
Comment 2 Simone Gotti (RETIRED) gentoo-dev 2004-10-06 01:32:17 UTC
Of course, I ran revdep-rebuild, but I don't understand the author purpose. If it links against the oldgettext, then the old shouldn't be removed at least...
It will break any ebuild that need gettext, so I think that if this can't be fixed at least the user should be informed about this situation. or no?
Comment 3 SpanKY gentoo-dev 2004-10-06 05:55:31 UTC
very true ... i added a warning to the ebuild
Comment 4 Simone Gotti (RETIRED) gentoo-dev 2004-10-06 06:18:20 UTC
Thanks!
Comment 5 Simone Gotti (RETIRED) gentoo-dev 2004-10-06 06:31:32 UTC
mmm. Sorry again if I'm pedant... :D 
I don't know if the warning reported is correct, because the problem is inside gettext itself. The problem is that gettext links to the old gettext installed libraries instead its just compiled one. 
The other ebuilds reports error because during the build is called the xgettext (or other) program present in gettext that is badly linked. So only gettext need to be rebuilt.

Also looking in the gentoo's CVS I've found a commit from sejo 88 minutes ago:
 
 Revision 1.6 - (download), view (text) (markup) (annotate) - [select for diffs] 
Wed Oct 6 11:47:08 2004 UTC (88 minutes, 21 seconds ago) by sejo 
Branch: MAIN 
Changes since 1.5: +2 -2 lines 
Diff to previous 1.5 
back to unstable untill the linking error is fixed


Is this related to this problem?
Comment 6 Thomas Matthijs (RETIRED) gentoo-dev 2004-10-06 07:36:59 UTC
*** Bug 66527 has been marked as a duplicate of this bug. ***
Comment 7 Thomas Matthijs (RETIRED) gentoo-dev 2004-10-06 07:46:19 UTC
warning is wrong packages don't need to be rebuilds, its gettext itself that needs to be rebuild after just installed it ??
Comment 8 SpanKY gentoo-dev 2004-10-06 08:12:04 UTC
for some reason i thought 'xgettext' was provided by another package ...

sounds like the linking process is broken in gettext, i'll look
Comment 9 Simone Gotti (RETIRED) gentoo-dev 2004-10-06 08:18:00 UTC
I think that I've found the solution:

the problem is generated by the use of --without-included-gettext introduced from gettext-0.12.1-r1 to fix bug #40162

If I install gettext-0.12.1 instead of r1, it uses --with-included-gettext and the programs like xgettext (in gettext) are linked correctly.


THEN SOME instructions on how to test my assertions and reproduce it:

1) install gettext-0.14.1
2) install gettext-0.12.1-r1 (that uises --without-included-gettext)
3) run xgettext, you'll get the link error because it searches for the libraries from 0.14.1

4) Reinstall gettext-0.14.1
5) install gettext-0.12.1 (that uses --with-included-gettext)
6) run xgettext, it'll work because is linked to the right libraries from the current version and not from the already installed version.
Comment 10 Simone Gotti (RETIRED) gentoo-dev 2004-10-06 08:50:39 UTC
mmmm. 
I was wrong, the problem isn't caused by --without-included-gettext but from --disable-shared that was removed from 0.12.1-r1.
Comment 11 Simone Gotti (RETIRED) gentoo-dev 2004-10-06 09:35:15 UTC
but of course tt's not a solution restoring it (--disabled-shared) because it'll give a lot of problems with other packages... like I'm having now with media-sound/normalize
Comment 12 Travis Tilley (RETIRED) gentoo-dev 2004-10-06 16:04:28 UTC
*** Bug 66473 has been marked as a duplicate of this bug. ***
Comment 13 SpanKY gentoo-dev 2004-10-06 22:09:35 UTC
*** Bug 66589 has been marked as a duplicate of this bug. ***
Comment 14 SpanKY gentoo-dev 2004-10-06 22:10:06 UTC
0.14.1 is now masked
Comment 15 Nicolai Lissner 2004-10-07 09:25:54 UTC
downgrading to  0.12.1-r1 (caused by the hardmask of 0.14) reproduced this problem. As the headers of 0.14 were installed when it compiled 0.12.1 it linked against the 0.14 version - recompiling solved this - so it looks like compiling 0.14 twice helps, too 
Comment 16 Nicolai Lissner 2004-10-07 09:44:06 UTC
yes, that works - so it's the ebuild, not the gettext version that is broken - 
simply emerge gettext again links against the correct header,

however revdep-rebuild would have done the same, so the solution is already given in the ebuild-info ;)

Please, fix the ebuild to use the correct headers instead of hardmasking a working version of gettext.
Comment 17 Lars Wendler (Polynomial-C) (RETIRED) gentoo-dev 2004-10-07 09:59:12 UTC
Hi,

I can confirm that emerging gettext-0.14.1 twice links gettext against the correct libs.

Poly
Comment 18 Simone Gotti (RETIRED) gentoo-dev 2004-10-07 10:15:03 UTC
Sorry, But the fact that recompiling fixes it was already explained by me.
The problem is to found why it links against the installed library and not the compiled one.

Probably you are mixing the headers sense with the libraries.
Comment 19 Thomas Matthijs (RETIRED) gentoo-dev 2004-10-07 13:10:49 UTC
*** Bug 66685 has been marked as a duplicate of this bug. ***
Comment 20 SpanKY gentoo-dev 2004-10-07 15:58:36 UTC
*** Bug 66637 has been marked as a duplicate of this bug. ***
Comment 21 Guy 2004-10-07 19:17:27 UTC
Um guys ...

It's great that gettext-0.14.1 is now masked.

However, binutils-2.15.92.0.2 apparently depends on gettext-0.14.1 and won't build with gettext-0.12...

Perhaps the new version of binutils should be masked as well? And anything else which depends on gettext-0.14.1?

:-)

... error while loading chared libraries: libgettextlib-0.14.1.so: cannot open shared object: ...
Comment 22 SpanKY gentoo-dev 2004-10-07 19:24:08 UTC
no it doesnt (or i doubt it ... :x), rebuild gettext a few times until it works again, and then build binutils
Comment 23 Jory A. Pratt 2004-10-07 19:58:13 UTC
Spanky just so you know this is only a case if your updating from one version to another if this is a clean system build everything works fine .... if your bootstraping the system use package.unmask to use the latest wich does not break compatibility for all you other users sorry about your luck build a better system :p
Comment 24 SpanKY gentoo-dev 2004-10-07 20:03:32 UTC
yes, we know it's an upgrade path bug, the problem is the large majority of users are going to use that path and not bootstrap with 0.14.1 :P

until the upgrade path is clean, gettext-0.14.1 will stay masked
Comment 25 Mike Messmore 2004-10-07 21:38:06 UTC
binutils-2.15.92.0.2 is trying to link to libgettextlib-0.14.1.so.  Until a package that provides that file is unmasked, binutils-2.15.92.0.2 should be masked as well.  This seems (at least to my amateur eyes) to be a different issue from the one this bug was filed about.

I'm still at gettext-0.12.1-r1.  I did not install 0.14.1 and roll back to the older ebuild, nor do anything out of the oridinary.  This machine is running pretty much, straight up ~x86.  But new binutils is trying to link to 0.14.1.  So basically right now anyone running ~x86 would have to add binutils-2.15.92.0.2 (god, thats a rediculously long version string) to their package.mask file in order to be able to `emerge --update' world merrily or add gettext-0.14.1 to their package.unmask file and deal with the issues in that package that were deemed mask-worthy.

I don't feel like fooling with it and am just adding the binutils package to my package.mask until this gets straightened out.
Comment 26 SpanKY gentoo-dev 2004-10-07 21:46:31 UTC
> binutils-2.15.92.0.2 should be masked as well.  This seems (at least to my
> amateur eyes) to be a different issue from the one this bug was filed about.

it isnt ... the error you posted showed the gettext program trying to run and failing; re-emerge gettext in other words

> I did not install 0.14.1 and roll back to the older ebuild

you sure about that ? might want to review emerge.log in /var/log/

> So basically right now anyone running ~x86 would have to add 
> binutils-2.15.92.0.2 to their package.mask file in order to be able 

no, see above
do whatever you like on your box to make it happy, it doesnt change the facts about gettext/binutils
Comment 27 Guy 2004-10-08 04:31:06 UTC
Spanky is correct.

emerging gettext-12... twice solves thes problem with binutils.

Despite being counter-intuitive to this non-programmer, it works. So who am I to argue with success?

I've done this on two different systems now.

But it's still weird as heck.
Comment 28 SpanKY gentoo-dev 2004-10-09 16:38:09 UTC
*** Bug 66862 has been marked as a duplicate of this bug. ***
Comment 29 Thomas Matthijs (RETIRED) gentoo-dev 2004-10-10 07:37:07 UTC
*** Bug 66981 has been marked as a duplicate of this bug. ***
Comment 30 foser (RETIRED) gentoo-dev 2004-10-10 09:13:50 UTC
*** Bug 66939 has been marked as a duplicate of this bug. ***
Comment 31 Travis Tilley (RETIRED) gentoo-dev 2004-10-11 00:26:35 UTC
*** Bug 66951 has been marked as a duplicate of this bug. ***
Comment 32 Travis Tilley (RETIRED) gentoo-dev 2004-10-12 03:55:12 UTC
*** Bug 67119 has been marked as a duplicate of this bug. ***
Comment 33 Scott Taylor (RETIRED) gentoo-dev 2004-10-14 14:47:13 UTC
*** Bug 67268 has been marked as a duplicate of this bug. ***
Comment 34 Travis Tilley (RETIRED) gentoo-dev 2004-10-16 06:19:09 UTC
*** Bug 67613 has been marked as a duplicate of this bug. ***
Comment 35 Ciaran McCreesh 2004-10-17 10:04:12 UTC
*** Bug 67465 has been marked as a duplicate of this bug. ***
Comment 36 Sven Wegener gentoo-dev 2004-10-19 13:12:14 UTC
*** Bug 68191 has been marked as a duplicate of this bug. ***
Comment 37 SpanKY gentoo-dev 2004-10-22 05:33:35 UTC
*** Bug 68487 has been marked as a duplicate of this bug. ***
Comment 38 SpanKY gentoo-dev 2004-10-27 11:46:24 UTC
*** Bug 69146 has been marked as a duplicate of this bug. ***
Comment 39 nobody 2004-10-27 20:55:09 UTC
I really think it's a bug related to gettext (not really gentoo)
Library link is to libgettextlib-0.x.x.so but a symlink from libgettextlib.so exist, so wrong linking?

But anyway here's a quick solve:

>emerge gettext
>xgettext
xgettext: error while loading shared libraries: libgettextlib-0.12.1.so: cannot open shared object file: No such file or directory
>ln -s /usr/lib/libgettextlib-0.14.1.so /usr/lib/libgettextlib-0.12.1.so
>ln -s /usr/lib/libgettextsrc-0.14.1.so /usr/lib/libgettextsrc-0.12.1.so
>xgettext
xgettext: no input file given
Try `xgettext --help' for more information.

i have just try with xgettext, try with others programs to be sure, but i just think the link is to the "old 0.12.1" lib but must use the new lib, so it's safe to symlink the new to old ones...

Ah and also! downgrading from 0.14.1 to 0.12.1 and you will get the same problem (with the same solve of course)
Comment 40 nobody 2004-10-27 21:56:28 UTC
Created attachment 42744 [details]
new ebuild with patch

diff gettext-0.14.1-r1.ebuild gettext-0.14.1.ebuild
14c14
< KEYWORDS="~x86"
---
> KEYWORDS="-*"
89,91d88
<	# to close bug #66449
<	ln -s ${D}/usr/lib/libgettextlib-0.14.1.so
${D}/usr/lib/libgettextlib-0.12.1.so
<	ln -s ${D}/usr/lib/libgettextsrc-0.14.1.so
${D}/usr/lib/libgettextsrc-0.12.1.so
Comment 41 ivo welch 2004-10-28 06:00:52 UTC
should this become the standard?  emerge search gettext on amd64 still tells me that 0.12.1-r2 is the current version, which of course blocks some other installs.
Comment 42 Martin Holzer (RETIRED) gentoo-dev 2004-10-28 08:32:40 UTC
don't use #ln -s
man 5 ebuild and see the dosym command
Comment 43 nobody 2004-10-28 17:04:52 UTC
Well, test the workaround if it's ok (seems ok here), just do a good ebuild to help stop that bug...
see impact of masking it http://bugs.gentoo.org/show_bug.cgi?id=69326
Comment 44 SpanKY gentoo-dev 2004-10-28 17:10:10 UTC
*** Bug 69326 has been marked as a duplicate of this bug. ***
Comment 45 SpanKY gentoo-dev 2004-10-28 17:10:40 UTC
just so you guys know, that isnt an acceptable 'fix'
Comment 46 nobody 2004-10-29 08:17:05 UTC
dosym /usr/lib/libgettextlib-0.14.1.so /usr/lib/libgettextlib-0.12.1.so
dosym /usr/lib/libgettextsrc-0.14.1.so /usr/lib/libgettextsrc-0.12.1.so
Change to that ?

Ah and why it isn't acceptable ?
The fix just create a sym link to old libs, if the symlinks isn't need, then you have only a symlink for nothing...
I think it far more acceptable than asking everyone to compile it twice! Sure compiling twice is easy to do, but not if gettext is emerge from an "emerge world"...

And if i look at gettext-0.14.1.ebuild, a symlink to correct a bug is something that should be acceptable...
>cat gettext-0.14.1.ebuild | grep 43
dosym msgfmt /usr/bin/gmsgfmt #43435

Anyway a "clean" and conventional fix should be force gettext to link against libgettextlib.so and libgettextsrc.so (cause they are present in both the 0.14 and 0.12 and are symlinks to correct libs).
But this will not correct the problem if someone downgrade to 0.12.1 because the 0.12.1 ebuild is also bug and have the same problem

So if you mask the 0.14 cause of that bug, you should also mask 0.12.1-r* for the same reason.
Note that this bug was introduce in the 0.12.1-r1 ebuild (i don't have it anymore after rsync), the 0.12.1 itself was working fine...

So i suppose the fix introduce to the 0.12.1-r1 to correct bug #40162 is the problem and i think it's that part (comment #6)
"Also should be built with shared libs for it to have preloadable_libintl.so.  Anyhow, added -r1 of gettext
and commited your ebuild with dep on gettext if nls in USE."

So: after removing to gettext the --disable-share, this gives that bug we are speaking about

Now you have choices:
- do the symlink as i say
- put --disable-share but might reopen but #40162

now i hope you understand not only 0.14.1 is affect but all ebuild for gettext that didn't include the --disable-share in it... (i think it's 0.12.1-r1, r2 and 0.14.1)
Comment 47 SpanKY gentoo-dev 2004-10-29 08:31:44 UTC
actually, i'm going with option (3) fix libtool

like i said, the symlinks arent going to be added to portage

comparing it to the gmsgfmt symlinks is completely unrelated and not applicable
Comment 48 nobody 2004-10-29 08:37:06 UTC
maybe re-enable --disable-share and see if a better fix could be found for #40162 ?

Comment 49 nobody 2004-10-29 08:44:27 UTC
actually your option 3 seems the best
Comment 50 Simone Gotti (RETIRED) gentoo-dev 2004-10-29 08:46:18 UTC
Like I've said in comment #11, reanabling --disable-share gave me problems with some ebuilds.
Comment 51 SpanKY gentoo-dev 2004-10-31 01:53:44 UTC
if someone feels so inclined to break their system, `emerge sync` and try out gettext-0.14.1 ...

to see if you have the version i want you to try, the unpack phase should apply a bunch of patches to ltmain.sh
Comment 52 Simone Gotti (RETIRED) gentoo-dev 2004-10-31 03:06:23 UTC
Thanks vapier, I had the gettext-0.12.1-r2 installed, and upgrading to your new version didn't get any linking problem. xgettext and all the other program seems to works weel.

Probably this need also some other testing emerging programs that uses gettext but I'm fiducious :D .
Comment 53 SpanKY gentoo-dev 2004-11-04 19:10:43 UTC
ok, seems to be resolved now ... moved 0.14.1 to unstable ;)