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
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 ;)
