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

Full Text Bug Listing

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"

run revdep-rebuild, the gettext authors seem to do this on purpose :/

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?

very true ... i added a warning to the ebuild

Thanks!

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?

*** Bug 66527 has been marked as a duplicate of this bug. ***

warning is wrong packages don't need to be rebuilds, its gettext itself that
needs to be rebuild after just installed it ??

for some reason i thought 'xgettext' was provided by another package ...

sounds like the linking process is broken in gettext, i'll look

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.

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.

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

*** Bug 66473 has been marked as a duplicate of this bug. ***

*** Bug 66589 has been marked as a duplicate of this bug. ***

0.14.1 is now masked

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 

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.

Hi,

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

Poly

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.

*** Bug 66685 has been marked as a duplicate of this bug. ***

*** Bug 66637 has been marked as a duplicate of this bug. ***

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: ...

no it doesnt (or i doubt it ... :x), rebuild gettext a few times until it works
again, and then build binutils

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

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

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.

> 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

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.

*** Bug 66862 has been marked as a duplicate of this bug. ***

*** Bug 66981 has been marked as a duplicate of this bug. ***

*** Bug 66939 has been marked as a duplicate of this bug. ***

*** Bug 66951 has been marked as a duplicate of this bug. ***

*** Bug 67119 has been marked as a duplicate of this bug. ***

*** Bug 67268 has been marked as a duplicate of this bug. ***

*** Bug 67613 has been marked as a duplicate of this bug. ***

*** Bug 67465 has been marked as a duplicate of this bug. ***

*** Bug 68191 has been marked as a duplicate of this bug. ***

*** Bug 68487 has been marked as a duplicate of this bug. ***

*** Bug 69146 has been marked as a duplicate of this bug. ***

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)

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

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.

don't use #ln -s
man 5 ebuild and see the dosym command

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

*** Bug 69326 has been marked as a duplicate of this bug. ***

just so you guys know, that isnt an acceptable 'fix'

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)

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

maybe re-enable --disable-share and see if a better fix could be found for
#40162 ?

actually your option 3 seems the best

Like I've said in comment #11, reanabling --disable-share gave me problems with
some ebuilds.

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

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 .

ok, seems to be resolved now ... moved 0.14.1 to unstable ;)