Hi, As i run all ~x86 system, recently installed gentoolkit-0.2.2_pre3. When running it for the first time it reported the following: ...BEGIN... # revdep-rebuild --ignore -p Configuring search environment for revdep-rebuild Checking reverse dependencies... Packages containing binaries and libraries broken by a package update will be emerged. Collecting system binaries and libraries... done. (/root/.revdep-rebuild.1_files) Collecting complete LD_LIBRARY_PATH... done. (/root/.revdep-rebuild.2_ldpath) Checking dynamic linking consistency... broken /usr/lib/bmp/Input/libmpg123.la (requires /usr/lib/libbeep.la) broken /usr/lib/gcc/i686-pc-linux-gnu/3.4.5/lib-org-w3c-dom.la (requires /usr/lib/libgcj.la) broken /usr/lib/gcc/i686-pc-linux-gnu/3.4.5/lib-org-xml-sax.la (requires /usr/lib/libgcj.la) broken /usr/lib/libreiser4.la (requires /lib/libaal.la) broken /usr/lib/libreiser4-minimal.la (requires /lib/libaal-minimal.la) broken /usr/lib/librepair.la (requires /lib/libaal.la) done. (/root/.revdep-rebuild.3_rebuild) Assigning files to ebuilds... done. (/root/.revdep-rebuild.4_ebuilds) Evaluating package order... done. (/root/.revdep-rebuild.5_order) All prepared. Starting rebuild... emerge --oneshot -p =sys-devel/gcc-3.4.5-r1 =sys-fs/reiser4progs-1.0.5 These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] sys-devel/gcc-3.4.5-r1 [ebuild R ] sys-fs/reiser4progs-1.0.5 Now you can remove -p (or --pretend) from arguments and re-run revdep-rebuild. ...END... W/o checking the files i remerged GCC & reiser4progs - all good. But on the next run of gentoolkit it reported the same two packages. Thanks.Rumen emerge --info: Gentoo Base System version 1.12.0_pre16 Portage 2821-svn (!/usr/portage/profiles/default-linux/x86/2006.0, gcc-3.4.5, glibc-2.3.6-r3, 2.6.15-gentoo-r7 i686) ================================================================= System uname: 2.6.15-gentoo-r7 i686 AMD Athlon(tm) XP 2200+ dev-lang/python: 2.4.2 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1-r2 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r3 ACCEPT_KEYWORDS="x86 ~x86" ACCEPT_LICENSE="" ALSA_CARDS="ens1371" ARCH="x86" AUTOCLEAN="yes" BASH_ENV="/etc/spork/is/not/valid/profile.env" CBUILD="i686-pc-linux-gnu" CCACHE_DIR="/var/tmp/ccache" CCACHE_SIZE="2G" CFLAGS="-O2 -march=athlon-xp -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CLEAN_DELAY="5" COLORTERM="" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/alias /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/init.d /etc/revdep-rebuild /etc/splash /etc/terminfo /etc/texmf/web2c /etc/env.d" CVS_RSH="ssh" CXXFLAGS="-O2 -march=athlon-xp -pipe -fomit-frame-pointer" DCCC_PATH="/usr/lib/distcc/bin" DISPLAY=":0.0" DISTCC_LOG="" DISTCC_VERBOSE="0" DISTDIR="/var/portage/distfiles" EDITOR="/bin/nano" ELIBC="glibc" EMERGE_DEFAULT_OPTS="--verbose" EMERGE_WARNING_DELAY="10" FEATURES="autoconfig buildpkg ccache collision-protect confcache distlocks enotice gpg metadata-transfer parallel-fetch sandbox sfperms userpriv usersandbox" FETCHCOMMAND="/usr/bin/wget -t 5 --passive-ftp -P ${DISTDIR} ${URI}" FLTK_DOCDIR="/usr/share/doc/fltk-1.1.7/html" GCC_SPECS="" GDK_USE_XFT="1" GENTOO_MIRRORS="http://gentoo.ITDNet.net/gentoo http://ftp.uni-erlangen.de/pub/mirrors/gentoo ftp://files.gentoo.gr http://mirror.etf.bg.ac.yu/gentoo http://mirror.datapipe.net/gentoo" GPG_AGENT_INFO="/tmp/gpg-7HGyz7/S.gpg-agent:12940:1" GS_LIB="/home/gentoo/.fonts" GTK2_RC_FILES="/home/gentoo/.gtkrc-2.0" GTK_RC_FILES="/etc/gtk/gtkrc:/home/gentoo/.gtkrc:/home/gentoo/.kde/share/config/gtkrc" G_BROKEN_FILENAMES="1" HOME="/root" HOSTNAME="mach" HUSHLOGIN="FALSE" INFOPATH="/usr/share/info:/usr/share/binutils-data/i686-pc-linux-gnu/2.16.1/info:/usr/share/gcc-data/i686-pc-linux-gnu/3.4.5/info" KDEDIRS="/usr" KDE_FULL_SESSION="true" KDE_MULTIHEAD="false" KERNEL="linux" KONSOLE_DCOP="DCOPRef(konsole-13019,konsole)" KONSOLE_DCOP_SESSION="DCOPRef(konsole-13019,session-1)" LADSPA_PATH="/usr/lib/ladspa" LANG="bg_BG.UTF8" LC_ALL="en_US.UTF8" LC_MESSAGES="en" LESS="-R -M --shift 5" LESSOPEN="|lesspipe.sh %s" LOGNAME="root" LS_COLORS="no=00:fi=00:di=01;34:ln=01;36:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=01;05;37;41:mi=01;05;37;41:su=37;41:sg=30;43:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.gz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.rar=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.qt=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.pdf=00;32:*.ps=00;32:*.txt=00;32:*.patch=00;32:*.diff=00;32:*.log=00;32:*.tex=00;32:*.doc=00;32:*.flac=01;35:*.mp3=01;35:*.mpc=00;36:*.ogg=00;36:*.wav=00;36:*.mid=00;36:*.midi=00;36:*.au=00;36:*.flac=00;36:*.aac=00;36:" MAKEOPTS="-j2" MANPATH="/usr/local/share/man:/usr/share/man:/usr/share/binutils-data/i686-pc-linux-gnu/2.16.1/man:/usr/share/gcc-data/i686-pc-linux-gnu/3.4.5/man:/usr/qt/3/doc/man" MOZILLA_FIVE_HOME="/usr/lib/mozilla" OPENGL_PROFILE="nvidia" PAGER="/usr/bin/less" PATH="/sbin:/bin:/usr/sbin:/usr/bin" PKGDIR="/var/portage/packages" PORTAGE_ARCHLIST="ppc s390 amd64 ppc64 m68k arm sparc sh mips ia64 alpha ppc-macos hppa x86" PORTAGE_BINHOST_CHUNKSIZE="3000" PORTAGE_CALLER="emerge" PORTAGE_ELOG_CLASSES="info warn error log" PORTAGE_ELOG_MAILFROM="portage@qrypto.org" PORTAGE_ELOG_MAILURI="gentoo@mach.qrypto.org localhost" PORTAGE_ELOG_SYSTEM="save mail" PORTAGE_GID="250" PORTAGE_GPG_DIR="/etc/portage/gpg" PORTAGE_MASTER_PID="30448" PORTAGE_TMPDIR="/var/tmp" PORTAGE_TMPFS="/dev/shm" PORTDIR="/var/portage" PORTDIR_OVERLAY="/usr/local/portage" PORT_ENOTICE_DIR="/var/enotice/" PORT_LOGDIR="/var/log/portage" PRELINK_PATH="" PRELINK_PATH_MASK="/usr/lib/gstreamer-0.10:/usr/lib/gstreamer-0.8:/usr/lib/klibc" PWD="/root" PYTHONDOCS="/usr/share/doc/python-docs-2.4.2/html" PYTHONPATH="/usr/lib/portage/pym" QMAILIDHOST="connectioncable-084.headoff.net" QMAIL_CONTROLDIR="/var/qmail/control" QMAKESPEC="linux-g++" QTDIR="/usr/qt/3" RESUMECOMMAND="/usr/bin/wget -c -t 5 --passive-ftp -P ${DISTDIR} ${URI}" RPMDIR="/usr/portage/rpm" RSYNC_RETRIES="3" RSYNC_TIMEOUT="180" RUBYOPT="-rauto_gem" SEARCH_DIRS_MASK="/usr/lib/openoffice" SESSION_MANAGER="local/mach:/tmp/.ICE-unix/12979" SHELL="/bin/bash" SHLVL="6" SSH_AGENT_PID="12560" SSH_AUTH_SOCK="/tmp/ssh-kMLqe12559/agent.12559" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" TERM="xterm" TMAKEPATH="/usr/lib/tmake/linux-g++" USE="x86 3dnow X X509 a52 aac acl acpi alsa apache2 avi bash-completion berkdb bitmap-fonts caps cdb cdr crypt cups curl dri dvd dvdr eds encode esd evo exif ffmpeg flac foomaticdb freetype gd gif gnutls gstreamer gtk gtk2 gtkhtml hal iconv imap imlib ipv6 ithreads javascript jpeg kdexdeltas lcms libg++ libwww mad maildir matroska mikmod mime mmx motif mp3 mpeg ncurses nls nptl nvidia ogg opengl oss pam pdflib perl png posix ppds prelude python quicktime readline sdl skey speex spell sse ssl svg symlink tcpd theora threads transcode truetype truetype-fonts type1-fonts udev unicode usb vorbis win32codecs xine xml xsl xv xvid zlib elibc_glibc kernel_linux userland_GNU" USER="root" USERLAND="GNU" USE_EXPAND="DVB_CARDS ELIBC FCDSL_CARDS FRITZCAPI_CARDS INPUT_DEVICES KERNEL LINGUAS USERLAND VIDEO_CARDS" USE_EXPAND_HIDDEN="" USE_ORDER="env:pkg:conf:defaults" WINDOWID="4194309" XARGS="xargs -r" XAUTHORITY="/root/.xauthfcfw6x" XCURSOR_THEME="default" XDG_CONFIG_DIRS="/usr/kde/3.5/etc/xdg" XDG_DATA_DIRS="/usr/kde/3.5/share:/usr/share" XINITRC="/etc/X11/xinit/xinitrc" _="/usr/bin/emerge"
Please run revdep-rebuild --ignore --pretend --verbose and attach the output along with the .la files that it considers to be broken.
Hi, Here comes the output part: ...BEGIN... # revdep-rebuild --ignore --pretend --verbose Configuring search environment for revdep-rebuild Checking reverse dependencies... Packages containing binaries and libraries broken by a package update will be emerged. Collecting system binaries and libraries... done. (/root/.revdep-rebuild.1_files) Collecting complete LD_LIBRARY_PATH... done. (/root/.revdep-rebuild.2_ldpath) Checking dynamic linking consistency... broken /usr/lib/bmp/Input/libmpg123.la (requires /usr/lib/libbeep.la) broken /usr/lib/gcc/i686-pc-linux-gnu/3.4.5/lib-org-w3c-dom.la (requires /usr/lib/libgcj.la) broken /usr/lib/gcc/i686-pc-linux-gnu/3.4.5/lib-org-xml-sax.la (requires /usr/lib/libgcj.la) broken /usr/lib/libreiser4-minimal.la (requires /lib/libaal-minimal.la) broken /usr/lib/libreiser4.la (requires /lib/libaal.la) broken /usr/lib/librepair.la (requires /lib/libaal.la) done. (/root/.revdep-rebuild.3_rebuild) Assigning files to ebuilds... done. (/root/.revdep-rebuild.4_ebuilds) Evaluating package order... done. (/root/.revdep-rebuild.5_order) All prepared. Starting rebuild... emerge --oneshot --pretend --verbose =sys-devel/gcc-3.4.5-r1 =sys-fs/reiser4progs-1.0.5 These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] sys-devel/gcc-3.4.5-r1 USE="boundschecking gcj gtk nls objc -bootstrap -build -fortran -hardened -ip28 -multislot -nocxx -nopie -nossp -vanilla" 0 kB [ebuild R ] sys-fs/reiser4progs-1.0.5 USE="readline -debug -static" 0 kB Total size of downloads: 0 kB Now you can remove -p (or --pretend) from arguments and re-run revdep-rebuild. ...END... Next will attach a concatenated file (of all reported *.la files). Thanks.Rumen
Created attachment 81892 [details] contents-la-files.txt
(In reply to comment #2) I'm going to ignore gcc for the moment, since I need to recompile it with the same use flags to see what is going on. As far as I can tell, the .la files are broken, I'm not understanding why recompiling is not fixing them. > broken /usr/lib/bmp/Input/libmpg123.la (requires /usr/lib/libbeep.la) This one is an orphan, you can safely remove it. > broken /usr/lib/gcc/i686-pc-linux-gnu/3.4.5/lib-org-w3c-dom.la (requires /usr/lib/libgcj.la) > broken /usr/lib/gcc/i686-pc-linux-gnu/3.4.5/lib-org-xml-sax.la (requires /usr/lib/libgcj.la) I'll look at these once I recompile gcc > broken /usr/lib/libreiser4-minimal.la (requires /lib/libaal-minimal.la) > broken /usr/lib/libreiser4.la (requires /lib/libaal.la) > broken /usr/lib/librepair.la (requires /lib/libaal.la) When I installed reiser4progs, it pulled in libaal which was placed in /usr/lib. From your copy of /usr/lib/libreiser4.la it shows: # Libraries that this one depends upon. dependency_libs=' /lib/libaal.la' My copy of /usr/lib/libreiser4.la shows: # Libraries that this one depends upon. dependency_libs=' /usr/lib/libaal.la' What does an ls -l /lib/libaal.la and ls -l /usr/lib/libaal.la show?
Hi, Yeah, really is an orphan so removed it, thanks. Skipping GCC - OK. Yes i *don't* have such file: /lib/libaal.la, instead it's /usr/lib/libaal.la as in your case. $ qlist libaal | grep libaal.la /usr/lib/libaal.la So far so good ;) # ls -l /lib/libaal.la ls: /lib/libaal.la: No such file or directory # ls -l /usr/lib/libaal.la -rwxr-xr-x 1 root root 786 2005-11-11 07:27 /usr/lib/libaal.la This confirms the above info. Now recompiling 'reiser4progs'- same error /usr/lib/libreiser4.la is below: ...BEGIN... # libreiser4.la - a libtool library file # Generated by ltmain.sh - GNU libtool 1.5.22 (1.1220.2.365 2005/12/18 22:14:06) # # Please DO NOT delete this file! # It is necessary for linking the library. # The name that we can dlopen(3). dlname='libreiser4-1.0.so.5' # Names of this library. library_names='libreiser4-1.0.so.5.0.0 libreiser4-1.0.so.5 libreiser4.so' # The name of the static archive. old_library='libreiser4.a' # Libraries that this one depends upon. dependency_libs=' /lib/libaal.la' -----------------^ # Version information for libreiser4. current=5 age=0 revision=0 # Is this an already installed library? installed=yes # Should we warn about portability when linking against -modules? shouldnotlink=no # Files to dlopen/dlpreopen dlopen='' dlpreopen='' # Directory that this library needs to be installed in: libdir='/usr/lib' ...END... There's a space before /lib/libaal.la, might be an error in 'sed'/'gawk'. IMO manually editing it will temporary fix this, as at least to not show in "revdep-rebuild" every time. PS: also had to edit two more libs: /usr/lib/libreiser4-minimal.la & /usr/lib/librepair.la This manual work fixed "reiser4progs", but not the cause ;) Thanks.Rumen
As I said earlier, I don't understand why the recompile doesn't fix the problem. Just as an experiment, try recompiling libaal, followed by reiser4progs and look at the .la files and see if they are still broken.
Hi, The recompile (libaal first) fixed 'reiser4progs' (by looking at *.la files only). Later checked (for sed etc. things) no such stuff, so assume it's an issue with autotools (seems all of them are used here). Also manually fixed the GCC thingy, so not to annoy me. We're making progress, thanks. Rumen
I've duplicated the problem with gcc. I think that it is either a bug with autotools or the ebuild, but I'm going to have to do more research.
*** Bug 126200 has been marked as a duplicate of this bug. ***
*** Bug 126440 has been marked as a duplicate of this bug. ***
toolchain: It appears to me that the following libtool files are broken as installed by the gcc-3.4.5 ebuild with the gcj USE flag turned on: /usr/lib/gcc/i686-pc-linux-gnu/3.4.5/lib-org-w3c-dom.la (requires /usr/lib/libgcj.la) /usr/lib/gcc/i686-pc-linux-gnu/3.4.5/lib-org-xml-sax.la (requires /usr/lib/libgcj.la) libgcj.la is installed as /usr/lib/gcc/i686-pc-linux-gnu/3.4.5/libgcj.la and not /usr/lib/libgcj.la for my system. When I compiled and installed gcc-3.4.5 manually, the above libtool files were correct and pointed to the location that libgcj.la was actually installed.
*** Bug 126701 has been marked as a duplicate of this bug. ***
(In reply to comment #11) > toolchain: > > It appears to me that the following libtool files are broken as installed by > the gcc-3.4.5 ebuild with the gcj USE flag turned on: > > /usr/lib/gcc/i686-pc-linux-gnu/3.4.5/lib-org-w3c-dom.la (requires > /usr/lib/libgcj.la) > /usr/lib/gcc/i686-pc-linux-gnu/3.4.5/lib-org-xml-sax.la (requires > /usr/lib/libgcj.la) > > libgcj.la is installed as /usr/lib/gcc/i686-pc-linux-gnu/3.4.5/libgcj.la and > not /usr/lib/libgcj.la for my system. > gcc4 has a similar problem (partial revdep-rebuild output): broken /usr/lib/gcc/i686-pc-linux-gnu/3.4.5/lib-org-w3c-dom.la (requires /usr/lib/libgcj.la) broken /usr/lib/gcc/i686-pc-linux-gnu/3.4.5/lib-org-xml-sax.la (requires /usr/lib/libgcj.la) broken /usr/lib/gcc/i686-pc-linux-gnu/4.1.0/libgcjawt.la (requires /usr/lib/lib-gnu-java-awt-peer-gtk.la) broken /usr/lib/gcc/i686-pc-linux-gnu/4.1.0/libgij.la (requires /usr/lib/libgcj.la)
*** Bug 127535 has been marked as a duplicate of this bug. ***
(In reply to comment #11) > When I compiled and installed gcc-3.4.5 manually What do you mean with 'manually'? Also gcc-3.4.6 suffers the same problem. Fixed linking /usr/lib/libgcj.la to the one of used gcc version. Thanks.
I've recompiled gcc-4.1.0 adding the "--enable-version-specific-runtime-libs" option to gcc_do_configure(), and it seems to have fixed this issue. The point is that, with this option, $toolexeclibdir is set to "$libdir/gcc/$target_noncanonical/$gcc_version" instead of simply "$libdir" (aka "/usr/lib"). Seen that in libjava/configure.ac. It is then this variable which is used as libtool -rpath argument when linking the gcj libs, hence the fix (at least, that's my understanding). I did a diff beetween my original gcc-4.0.1 (from its .tbz2) and the recompiled one (image/ directory), and appart the .la files which are now correct, the only other difference on text files is that /usr/lib/pkgconfig/libgcj.pc which is now weirdly broken : prefix=/usr exec_prefix=${prefix} libdir=${exec_prefix}/lib -includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.1.0/include +includedir=$(libdir)/gcc/$(target_noncanonical)/$(gcc_version)/include/ But the original one was broken too (wrong libdir), so i guess installation of this file needs to be reworked anyway. As for the files installation paths, there was not a single difference beetween the two versions (with USE "-bootstrap -build doc fortran gcj gtk -hardened -ip28 -mudflap -multislot nls -nocxx -objc -objc++ -objc-gc -vanilla", so i can't speak for ObjC for instance). And talking about installation paths, the above mentioned .pc file does not seem much SLOTing-friendly (that, and /usr/lib/classpath/* too). Maybe they should be moved, and then handled by gcc-config? But i guess it's a different issue. Note that i've not yet installed this recompiled gcc (will do soon), so i don't say it works, but just that .la files are better wrt libgcj.
(In reply to comment #16) > I did a diff beetween my original gcc-4.0.1 4.1.0 i meant --------------------------^ > Note that i've not yet installed this recompiled gcc (will do soon), so i don't > say it works, but just that .la files are better wrt libgcj. > So far so good, after recompiling various C/C++/Java packages. But it won't work change anything for version 3.4.6 (the option is not taken into account by libjava/configure.in).
Hi, Many *thanks* to TGL - seems he's hit the jackpot ;) The procedure in comment#16 worked for me too (checked through 'revdep-rebuild' only). This using GCC-4.0.3, now i have three versions of GCC ;) Thanks for 3.4.5/6 info too so i won't bother to recompile it (manually fixed though). Rumen
*** Bug 128093 has been marked as a duplicate of this bug. ***
Hi, Please *toolchain* fix the toolchain.eclass (just one more line >=GCC-4.X only). It works for me & others, using custom eclass in Overlay is bad as i miss the new eclass additions, or have to check/update manually. PS: gcc-4.X is still unstable but many people already use it ;) Thanks.Rumen
*** Bug 134920 has been marked as a duplicate of this bug. ***
*** Bug 136463 has been marked as a duplicate of this bug. ***
Now this is affecting the current unmasked version of gcc-3.4.6-r1. The big change in my systems was the upgrade to portage-2.1. Until the portage upgrade, revdep-rebuild didn't see any problems with gcc, now it does. I don't know if the portage upgrade caused the problem, or if it was one of the 20 or so packages that were built as a side effect of the portage upgrade.
(In reply to comment #23) > Now this is affecting the current unmasked version of gcc-3.4.6-r1. > > The big change in my systems was the upgrade to portage-2.1. Until the portage > upgrade, revdep-rebuild didn't see any problems with gcc, now it does. I don't > know if the portage upgrade caused the problem, or if it was one of the 20 or > so packages that were built as a side effect of the portage upgrade. > (In reply to comment #23) > Now this is affecting the current unmasked version of gcc-3.4.6-r1. > > The big change in my systems was the upgrade to portage-2.1. Until the portage > upgrade, revdep-rebuild didn't see any problems with gcc, now it does. I don't > know if the portage upgrade caused the problem, or if it was one of the 20 or > so packages that were built as a side effect of the portage upgrade. > I didn't build any packages after updating to portage-2.1, but I still got the same problem. In my case I couldn't recompile GCC due to what appears to be problem with the locale. Downgrading to former version of portage do not resolve this issue, that didn't exist before upgrading portage. However, one can at least compile GCC-3.4.x.
@ John and Kristian: Probably you are seeing this problem only now because you have also updated to gentoolkit-0.2.2 (the 0.2.1 branch is not compatible with portage-2.1, and 0.2.2 has been unmasked at the same time). IIRC, the revdep-rebuild script from gentoolkit-0.2.1 was not checking libtool files, so the bug was hidden with that version.
Just to add that I'm seeing this issue with gcc-4.1.1, as well. For now, I think I'll just add a symlink to work around it.
gcc-3.4.6-r1 on amd64 has the same problem.
Why not simply nuke all the la-s in gcc, as we already did with libstdc++.la. I have already commented about this issue in bug #90744 because I didn't know of this bug. I don't see anything that prevents us from doing this for gcc.
(In reply to comment #15) > (In reply to comment #11) > > When I compiled and installed gcc-3.4.5 manually > What do you mean with 'manually'? > Also gcc-3.4.6 suffers the same problem. Fixed linking /usr/lib/libgcj.la to > the one of used gcc version. > Thanks. I found two solutions to this problem. One is to symlink /usr/lib/libgcj.la to /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/libgcj.la (in my case, obviously change i686-pc-linux-gnu to your target). The other is to edit the two .la files that revdep is complaining about and change the reference to /usr/lib/libgcj.la to /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/libgcj.la. The way I see it, all 3 files are installed with the gcc ebuild, and two of the .la files point to the wrong location for libgcj.la, so I think changing those files is better than making a symlink.
(In reply to comment #29) > (In reply to comment #15) > > (In reply to comment #11) > > > When I compiled and installed gcc-3.4.5 manually > > What do you mean with 'manually'? > > Also gcc-3.4.6 suffers the same problem. Fixed linking /usr/lib/libgcj.la to > > the one of used gcc version. > > Thanks. > > I found two solutions to this problem. One is to symlink /usr/lib/libgcj.la to > /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/libgcj.la (in my case, obviously change > i686-pc-linux-gnu to your target). The other is to edit the two .la files that > revdep is complaining about and change the reference to /usr/lib/libgcj.la to > /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/libgcj.la. The way I see it, all 3 files > are installed with the gcc ebuild, and two of the .la files point to the wrong > location for libgcj.la, so I think changing those files is better than making a > symlink. > The second of these two solutions worked for me. The .la files for lib-org-w3c-dom and lib-org-xml-sax.la didn't get updated with the new location for libgcj during the gcc 3.4 update.
*** Bug 138390 has been marked as a duplicate of this bug. ***
*** Bug 139345 has been marked as a duplicate of this bug. ***
*** Bug 139513 has been marked as a duplicate of this bug. ***
*** Bug 139881 has been marked as a duplicate of this bug. ***
*** Bug 140317 has been marked as a duplicate of this bug. ***
*** Bug 141467 has been marked as a duplicate of this bug. ***
*** Bug 142069 has been marked as a duplicate of this bug. ***
*** Bug 142762 has been marked as a duplicate of this bug. ***
Hi, Since GCC-4.1.1 went 'stable' now, can't we change toolchain.eclass according to solution given in comment#16 (TGL) and close this Bug? Thanks.Rumen
*** Bug 146183 has been marked as a duplicate of this bug. ***
*** Bug 147962 has been marked as a duplicate of this bug. ***
*** Bug 148535 has been marked as a duplicate of this bug. ***
Strange situation, that this bug is still there... for such a long time. I've had this bug for half a year now. I just ignore it since I always manually re-emerge my packages (I run "revdep-rebuild -- -pv" and thereafter decide what to emerge with "emerge -pv [list of packages]" followed by "emerge -1 [list of packages]"). Today I updated to sys-devel/gcc-4.1.1-r1 ("emerge --sync && emerge -pDuv world"). I also updated dev-db/mysql-5.0.26-r1 recently which broke a few dependences, so revdep-rebuild was showing me what to *manually* re-emerge. I'm happy to say that amarok is working again... After eight months, the gcc issue is still here. Is it really necessary to manually alter the .la files to prevent revdep-rebuild from showing gcc every time you upgrade it? sys-devel/gcc-4.1.1-r1 USE="fortran gcj gtk nls objc objc++ objc-gc (-altivec) -bootstrap -build -doc (-hardened) -ip28 -ip32r10k -mudflap (-multilib) -multislot (-n32) (-n64) -nocxx -test -vanilla" Anyway, thanks for working on it though...
Please fix this, several working solutions seem to be known.
Did someone submit a bug report upstream?
*** Bug 156461 has been marked as a duplicate of this bug. ***
*** Bug 156792 has been marked as a duplicate of this bug. ***
I don't want to offend anyone, but this bug exists since more than half a year, there are some solutions posted here and many duplicates. So can't this bug be fixed and closed? Or in other words. Why isn't it already fixed and what is the development status?
at the very least, can someone please let us know what the recommended work-around solution is, that is least likely to break other things?
(In reply to comment #49) > at the very least, can someone please let us know what the recommended > work-around > solution is, that is least likely to break other things? Symlinking is a harmless solution. ln -s /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/lib-gnu-java-awt-peer-gtk.la lib-gnu-java-awt-peer-gtk.la ln -s /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/libgcj.la libgcj.la For me, I had problems with revdep-rebuild and those two files.
*** Bug 157907 has been marked as a duplicate of this bug. ***
When will this bug be fixed? Thanks
Joining CC list.
*** Bug 166645 has been marked as a duplicate of this bug. ***
Hi, just hoping that this gets fixed soon too. Thanks.
Happy Birthday bug 125728!
(In reply to comment #56) > Happy Birthday bug 125728! And next up is a funeral, for Toolchain who hasn't been heard from on this and should be presumed dead. As mentioned before, there are several workarounds/fixes for this, so Toolchain, why haven't you at least given us word on which workaround we should be using until you can issue a permanent fix? /me is half expecting another funeral, for Jakub who is probably sick to death of marking dupes.
*** Bug 170718 has been marked as a duplicate of this bug. ***
This bug has the longest CC: list I've ever seen.
*** Bug 171497 has been marked as a duplicate of this bug. ***
"--enable-version-specific-runtime-libs" is not an option as it breaks other aspects of the toolchain and in general, does not fit into our methodology of managing gcc paths also, if you have nothing to add to the bug, do not post pointless comments
*** Bug 176504 has been marked as a duplicate of this bug. ***
amd64 is also having the same problem with gcc-4.1.1-r3
Problem still exists in gcc-4.1.2 at least on x86 and amd64.
(In reply to comment #64) > Problem still exists in gcc-4.1.2 at least on x86 and amd64. Yeap, I confirm (x86).
This problem still exists in gcc-4.1.2, though with different .la files: broken /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgcjawt.la (requires /usr/lib/lib-gnu-java-awt-peer-gtk.la) broken /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgij.la (requires /usr/lib/libgcj.la) My workaround is to edit the .la files and replace the /usr/lib paths with /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/ - and this fixes the problem, at least in the eyes of revdep-rebuild. (However, when I installed 4.1.2, 4.1.1 broke - and some files seem to have moved.) Any ideas about a fix for this?
*** Bug 179239 has been marked as a duplicate of this bug. ***
(In reply to comment #66) > This problem still exists in gcc-4.1.2, though with different .la files: > > broken /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgcjawt.la (requires > /usr/lib/lib-gnu-java-awt-peer-gtk.la) > broken /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgij.la (requires > /usr/lib/libgcj.la) > > My workaround is to edit the .la files and replace the /usr/lib paths with > /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/ - and this fixes the problem, at least in > the eyes of revdep-rebuild. (However, when I installed 4.1.2, 4.1.1 broke - > and some files seem to have moved.) > > Any ideas about a fix for this? > May be add /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/ in SEARCH_MASK_DIR under /etc/revdep-rebuild ?
(In reply to comment #68) > May be add /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/ in SEARCH_MASK_DIR under > /etc/revdep-rebuild ? This is only a workaround for revdep-rebuild. The problem, instead, may be worse than the only 'revdep-rebuild issue'. So, fixing the problem is *the* solution, IMHO (btw, I use to edit the .la files to correct the path to the libraries). Cheers.
*** Bug 179259 has been marked as a duplicate of this bug. ***
I can confirm this bug on x86_64 after upgrading to gcc 4.1.2. revdep-rebuild output: broken /usr/lib64/gcc/x86_64-pc-linux-gnu/4.1.2/libgcjawt.la (requires /usr/lib/../lib64/lib-gnu-java-awt-peer-gtk.la) broken /usr/lib64/gcc/x86_64-pc-linux-gnu/4.1.2/libgij.la (requires /usr/lib/../lib64/libgcj.la) broken /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/libgcjawt.la (requires /usr/lib/../lib64/lib-gnu-java-awt-peer-gtk.la) broken /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/libgij.la (requires /usr/lib/../lib64/libgcj.la) done. I am going to symlink the files (is this the "right" workaround?).
> > I am going to symlink the files (is this the "right" workaround?). > It's a better workaround than editing the SEARCH_MASK_DIR for revdep-rebuild. I did not have problems with this solution for a few month. But I don't know whether gcc follows the symlinks; normally programs are able to do that.
*** Bug 179311 has been marked as a duplicate of this bug. ***
*** Bug 185962 has been marked as a duplicate of this bug. ***
The new rewrite of revdep-rebuild doesn't seem to complain about gcc. Is this a problem outside of revdep-rebuild? If not, can this be closed now?
(In reply to comment #75) > Is this a problem outside of revdep-rebuild? If not, can this be closed now? I'm sure that the problem is in gcc or gcc's ebuild because paths in gcj related .la files are really wrong.
(In reply to comment #75) > The new rewrite of revdep-rebuild doesn't seem to complain about gcc. > > Is this a problem outside of revdep-rebuild? If not, can this be closed now? If the new version of revdep-rebuild doesn't complain about this still unfixed problem, it's a bug in revdep-rebuild.
Is it that the newest version of gcc doesn't have the problem anymore or is it that the newest version of revdep-rebuild misses the problem? As stated in a previous comment, when I've edited the files manually to fix the problem, I have seen that the problem is very real. (Someone might want to check the latest version of revdep-rebuild to make sure it isn't buggy...)
It is the new revdep-rebuild, please file a bug against revdep-rebuild. You can verify by running the old version at /usr/lib/gentoolkit/revdep-rebuild
Sorry for the noise, the path to the older revdep-rebuild is /usr/lib/gentoolkit/bin/revdep-rebuild
dear experts---if I understand correctly, the recommended interim fix accdg to comment #50 for this problem is # cd /usr/lib/ ## not sure about this one # ln -s /usr/lib/gcc/*/*/lib-gnu-java-awt-peer-gtk.la . # ln -s /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/libgcj.la . or do I misunderstand this bug and the recommended fix? sincerely, /iaw
(In reply to comment #61) > "--enable-version-specific-runtime-libs" is not an option as it breaks other > aspects of the toolchain and in general, does not fit into our methodology of > managing gcc paths > > also, if you have nothing to add to the bug, do not post pointless comments > Then how about gcc-config creating the required symlinks?
*** Bug 194524 has been marked as a duplicate of this bug. ***
# revdep-rebuild WARNING WARNING *** This is a rewritten version of revdep-rebuild *** WARNING WARNING WARNING Please report any bugs to http://bugs.gentoo.org WARNING WARNING In the bug report please include the following information: WARNING emerge --info WARNING A copy of the output from the revdep-rebuild command WARNING A copy of the .revdep-rebuild* files as an attachment WARNING WARNING If the bug is severe, the previous version of revdep-rebuild is located WARNING at: /usr/lib/gentoolkit/bin/revdep-rebuild WARNING WARNING WARNING *** This is a rewritten version of revdep-rebuild *** WARNING * Configuring search environment for revdep-rebuild * Checking reverse dependencies * Packages containing binaries and libraries broken by a package update * will be emerged. * Collecting system binaries and libraries * Generated new /root/.revdep-rebuild.1_files * Collecting complete LD_LIBRARY_PATH * Generated new /root/.revdep-rebuild.2_ldpath * Checking dynamic linking consistency [ 38% ] * broken /usr/lib/R/library/RCurl/libs/RCurl.so (requires libcurl.so.3) * broken /usr/lib/R/library/Rgraphviz/libs/Rgraphviz.so (requires libdotneato.so.0) [ 47% ] * broken /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/lib-org-w3c-dom.la (requires /usr/lib/libgcj.la) * broken /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/lib-org-xml-sax.la (requires /usr/lib/libgcj.la) [ 48% ] * broken /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgcjawt.la (requires /usr/lib/lib-gnu-java-awt-peer-gtk.la) * broken /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgij.la (requires /usr/lib/libgcj.la) * broken /usr/lib/gcc/i686-pc-linux-gnu/4.2.0/libgij.la (requires /usr/lib/libgcj.la) * broken /usr/lib/gcj-4.2.0/libjvm.la (requires /usr/lib/libgcj.la) [ 80% ] * broken /usr/lib/python2.5/site-packages/pyclamav.so (requires libclamav.so.2) [ 90% ] * broken /usr/lib/xine/plugins/1.1.8/xineplug_decode_dts.so (requires libdts.so.0) [ 100% ] * Generated new /root/.revdep-rebuild.3_rebuild * Assigning files to packages * !!! /usr/lib/R/library/RCurl/libs/RCurl.so not owned by any package is broken !!! * -n -e /usr/lib/R/library/RCurl/libs/RCurl.so -> (none) * !!! /usr/lib/R/library/Rgraphviz/libs/Rgraphviz.so not owned by any package is broken !!! * -n -e /usr/lib/R/library/Rgraphviz/libs/Rgraphviz.so -> (none) * /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/lib-org-w3c-dom.la -> sys-devel/gcc * /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/lib-org-xml-sax.la -> sys-devel/gcc * /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgcjawt.la -> sys-devel/gcc * /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgij.la -> sys-devel/gcc * /usr/lib/gcc/i686-pc-linux-gnu/4.2.0/libgij.la -> sys-devel/gcc * /usr/lib/gcj-4.2.0/libjvm.la -> sys-devel/gcc * /usr/lib/python2.5/site-packages/pyclamav.so -> dev-python/pyclamav * /usr/lib/xine/plugins/1.1.8/xineplug_decode_dts.so -> media-libs/xine-lib * Generated new /root/.revdep-rebuild.4_packages_raw and /root/.revdep-rebuild.4_package_owners [cut] # emerge --info Portage 2.1.3.12 (default-linux/x86/2007.0/desktop, gcc-4.2.0, glibc-2.6.1-r0, 2.6.22.6 i686) ================================================================= System uname: 2.6.22.6 i686 Mobile Intel(R) Pentium(R) 4 - M CPU 1.80GHz Timestamp of tree: Thu, 11 Oct 2007 13:00:09 +0000 app-shells/bash: 3.2_p17-r1 dev-java/java-config: 1.3.7, 2.1.1 dev-lang/python: 2.3.6-r2, 2.4.4-r5, 2.5.1-r2 dev-python/pycrypto: 2.0.1-r6 sys-apps/baselayout: 1.12.10-r5 sys-apps/sandbox: 1.2.18.1 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.24 virtual/os-headers: 2.6.22-r2 ACCEPT_KEYWORDS="x86 ~x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=pentium4 -mmmx -msse -msse2 -fomit-frame-pointer -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/config /usr/spool/PBS /var/bind /var/qmail/alias /var/qmail/control /var/vpopmail/domains /var/vpopmail/etc" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-O2 -march=pentium4 -mmmx -msse -msse2 -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks metadata-transfer sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LINGUAS="en cs cz" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="FFmpeg X Xaw3d a52 aac aalib acl acpi alsa amr amrnb amrwb apache2 asf ati avi berkdb bitmap-fonts bonobo caca cairo cddb cdio cdparanoia cdr cli cpudetection cracklib crypt cscope ctype cups curl dba dbus dga directfb divx divx5 divx5linux dri dts dv dvb dvd dvdr dvdread eds emacs emacs-w3 emboss emf encode ethereal evo f77 faad faad2 fam fame fbcon ffmpeg firefox flac flash fortran fvwm fvwm2 gb gcj gd gdbm ggi gif gphoto2 gpm gstreamer gtk gtk2 gtkhtml hal highvolume i8x0 icc iconv ieee1394 ifc imagemagick imlib imlib2 inifile innodb isdnlog ithreads jack java jpeg kdtree kerberos lcms leim libcaca libedit libwww live lzo mad matroska mcal mesa mhash midi mikmod ming mjpeg mmx mmx2 mmxext mng modplug motif mozilla mp2 mp3 mpeg mpi mudflap mule musepack mysql ncurses network nls nptl nptlonly ogg oggvorbis opengl openmp oss pam pcre pda pdf pdflib perl plotutils plugin png poppler ppds pppd pthread pthreads python qt qt3 qt3support qt4 qtx quicktime readline reflection rtc samba scanner scp server session slp spell spl sse sse2 ssl ssse3 stroke svg tcl tcltk tcpd tetex theora thread threads tiff tk truetype truetype-fonts type1-fonts unicode usb userlocales v4l v4l2 vcd vidix vorbis win32codecs winvidix wlan wmf x264 x86 xanim xml xml2 xorg xosd xprint xv xvid xvmc zeo zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en cs cz" USERLAND="GNU" VIDEO_CARDS="radeon" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, MAKEOPTS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY # # /usr/lib/gentoolkit/bin/revdep-rebuild Configuring search environment for revdep-rebuild Environment mismatch from previous run, deleting temporary files... Checking reverse dependencies... Packages containing binaries and libraries broken by a package update will be emerged. Collecting system binaries and libraries... done. (/root/.revdep-rebuild.1_files) Collecting complete LD_LIBRARY_PATH... done. (/root/.revdep-rebuild.2_ldpath) Checking dynamic linking consistency... broken /usr/lib/python2.5/site-packages/pyclamav.so (requires libclamav.so.2) broken /usr/lib/xine/plugins/1.1.8/xineplug_decode_dts.so (requires libdts.so.0) broken /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/lib-org-w3c-dom.la (requires /usr/lib/libgcj.la) broken /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/lib-org-xml-sax.la (requires /usr/lib/libgcj.la) broken /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgcjawt.la (requires /usr/lib/lib-gnu-java-awt-peer-gtk.la) broken /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgij.la (requires /usr/lib/libgcj.la) broken /usr/lib/gcc/i686-pc-linux-gnu/4.2.0/libgij.la (requires /usr/lib/libgcj.la) broken /usr/lib/gcj-4.2.0/libjvm.la (requires /usr/lib/libgcj.la) done. (/root/.revdep-rebuild.3_rebuild) Assigning files to ebuilds... done. [cut] I have edited the full paths in the *.la files to point to the correct gcc-version specific directories as mentioned in previous posts.
*** Bug 198520 has been marked as a duplicate of this bug. ***
*** Bug 198671 has been marked as a duplicate of this bug. ***
(In reply to comment #84) I have just enabled "gcj" flag and each time I run "revdep-rebuild", I have this error: ---cut--- Checking dynamic linking consistency... broken /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgij.la (requires /usr/lib/libgcj.la) done. (/root/.revdep-rebuild.3_rebuild) ---cut--- > > I have edited the full paths in the *.la files to point to the correct > gcc-version specific directories as mentioned in previous posts. > I think, this is only *true* workaround, to manually fix paths in *.la files, until it will be fixed
*** Bug 202836 has been marked as a duplicate of this bug. ***
more of the same. god I wish you people would add emerge --info and anything with long output as an attachment. you make these things hard to read. broken /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgij.la (requires /usr/lib/libgcj.la)
I see a comment about maybe it being revdep-rebuild. shouldn't just doing a manual emerge fix the problem? in my case emerge gcc. isn't that essentially what revdep-rebuild is doing after it finds the problem? if so I don't see that a new version of revdep-rebuild could be the problem.
See comment #29
Are we having a two year Birthday Party for this Bug tomorrow? I'd forgotten I was on the list, screw this crap. The last distro I installed was Ubuntu.
Happy birthday, dear Bug!
(In reply to comment #93) > Happy birthday, dear Bug! > Please everyone refrain from making such comments. They do not help to get the bug resolved any quicker, and merely make it harder to find useful information in the bug. If you wish to get this bug resolved, you could try to do some of the following: * Identify the remaining problems * If the problems have been identified, propose solutions * Try existing solutions on this bug and see if you run into any other problems Thanks
(In reply to comment #94) > If you wish to get this bug resolved, you could try to do some of the > following: > > * Identify the remaining problems > * If the problems have been identified, propose solutions > * Try existing solutions on this bug and see if you run into any other > problems Hmmm... Aren't there a few working solutions, at least working workarounds, mentioned here in this bug? Happy birthday, bug, from me, too!
There do seem to be working solutions. The problem is that none of them seem to be making it in to portage...
(In reply to comment #95) > Hmmm... Aren't there a few working solutions, at least working workarounds, > mentioned here in this bug? > > Happy birthday, bug, from me, too! Comment #29 describes the solution and as I say in #50 it worked fine for me. It worked in x86 and now in AMD64 (I upgraded my PC in the mean time), the same solution also works fine for me.
(In reply to comment #96) > There do seem to be working solutions. The problem is that none of them seem > to be making it in to portage... Because they are poor workarounds. The root cause needs to be identified and fixed instead.
In my naivete, it seems it ought to be pretty straightforward to track this down. Something writes those .la files, and it does it wrongly, repeatably. It's been ages since I poked around a compiler and I doubt any of that applies to gcc. But what the heck, I may as well find out how ignorant I am. So, if helping to track this down would be useful, how about some advice, such as what creates the .la files and what has been done to investigate this? Is it a gentoo only problem, or does it happen on other distros? Please don't point me to an archive of thousands of emails. This can't be that big an effort or it would have been solved by now. There is such a shortage of info on this bug that the only conclusion I come to is that there is a shortage of developers and/or testers, or that it only affects a few whiners, of which I am one.
(In reply to comment #99) > In my naivete, it seems it ought to be pretty straightforward to track this > down. Something writes those .la files, and it does it wrongly, repeatably... Start with 'info libtool' and check section 4.2 'Link mode'. Drink lots of coffee.
Created attachment 145756 [details] Patched toolchain.eclass Based on comment #16, I patched /usr/portage/eclass/toolchain.eclass. When building with the modified eclass, revdep-rebuild finds no errors. The patch is to add the following in the gcc_do_configure() function: # Bug 125728: get right .la files for gcj with gcc 4.x.y if [ ${PV/.*/} == "4" ]; then confgcc="${confgcc} --enable-version-specific-runtime-libs" fi It might make a little more sense to create a variable for passing in ebuild-specific configure options, and then add that option to the gcc-4 ebuilds. The net result would be the same, though. That should solve the problem for gcc-4, provided the change can get put into portage. While it would be nice to have a fix based on an understanding of the root cause, especially given the reports above that manual compiles do not exhibit this problem, at least this eliminates it in a way that doesn't require manual user action on each upgrade of gcc. Obviously, this isn't a workable solution without having it in portage, as overriding an eclass breaks things if the original is updated.
(In reply to comment #100) > (In reply to comment #99) > > In my naivete, it seems it ought to be pretty straightforward to track this > > down. Something writes those .la files, and it does it wrongly, repeatably... > > Start with 'info libtool' and check section 4.2 'Link mode'. Drink lots of > coffee. > I'm still naive :-) I see this: > If the OUTPUT-FILE ends in `.la', then a libtool library is created, which must be built only from library objects (`.lo' files). The `-rpath' option is required. In the current implementation, libtool libraries may not depend on other uninstalled libtool libraries (*note Inter-library dependencies::). If I redirect all "emerge gcc" output, will I see the command that creates the .la files? Does this command include all the libraries that end up in the .la file, or does it figure them out by analyzing deparate command line args?
> If I redirect all "emerge gcc" output, will I see the command that creates the > .la files? Does this command include all the libraries that end up in the .la > file, or does it figure them out by analyzing deparate command line args? Sounds like Preston knows more than both of us together, but try this: #ebuild /usr/portage/sys-devel/gcc/gcc-4.2.1.ebuild compile After this finishes there will be a 'build.log' in the temp subdirectory of /var/tmp/portage/sys-devel/gcc<etc> which will contain all the output you should need to find the errant libtool commands. I've been intending to do this for a year now, but ......
Created attachment 145776 [details] grep -C3 libgij.la on gcc-4.2.3 build log (In reply to comment #102) > If I redirect all "emerge gcc" output, will I see the command that creates the > .la files? Does this command include all the libraries that end up in the .la > file, or does it figure them out by analyzing deparate command line args? I have PORTAGE_LOGDIR=/var/log/portage in my make.conf, so I had the logs of my last gcc builds lying around. Grepping for libgij.la gives the attached result. "-o libgij.la" seems to be especially useful, as this indicates the creatioon of this .la file. As you can see, this occurs three times, once with --mode=link and twice with --mode=relink. I'm currently working on getting a libtool version in place that does "set -x" when the command line arbuments contain "-o libgij.la", but I'm not yet sure I modified the correct file (libtool.m4 from the gcc source dir) for this, and building gcc is taking ages, so I'm off for today.
I did "ebuild gcc-4.2.3.ebuild install", and then a "make install DESTDIR=..." from the build dir. The latter installs all paths to $DESTDIR/usr/lib, so at that point, the .la files and the paths still agree. Looking at toolchain.eclass, it seems that gcc_movelibs breaks these paths afterwards. To me, the --enable-version-specific-runtime-libs from comment #16 (TGL) still looks like the best solution we have so far. (In reply to comment #61 by SpanKY) > "--enable-version-specific-runtime-libs" is not an option as it breaks other > aspects of the toolchain and in general, does not fit into our methodology of > managing gcc paths Could you please elaborate? Why is this flag not an option, and manually moving files around preferable to having the build process put them in the desired location in the first place?(In reply to comment #98) > (In reply to comment #96 by Bo Ørsted Andresen) > Because they are poor workarounds. The root cause needs to be identified and > fixed instead. While I agree that manually rewriting the .la files seems like poor practice, so does manually moving the libraries in the eclass. I would consider the latter to be the root cause of the issue, at least for 4.2.x, and would assume that comment #16 presents an adequate fix. How about it?
I am still naive, and getting more so by the minute. My revdep-rebuild finds similar problems with many other packages; do they need the same fix? This also makes me wonder about something that several others have mentioned: is this a real bug in generating bad .la files, or is it a bug in revdep-rebuild reporting false errors? This is what I get now, after editing the gcc .la files: * /usr/lib64/gstreamer-0.8/libgstfaad.so -> media-plugins/gst-plugins-faad * /usr/lib64/gstreamer-0.8/libgstossaudio.so -> media-plugins/gst-plugins-oss * /usr/lib64/gstreamer-0.8/libgstvideo4linux2.so -> media-plugins/gst-plugins-v4l2 * /usr/lib64/gstreamer-0.8/libgstxvimagesink.so -> media-plugins/gst-plugins-xvideo * /usr/lib64/opensync-1.0/plugins/gcalendar.so -> app-pda/libopensync-plugin-google-calendar * /usr/lib64/python2.4/site-packages/gst/interfaces.la -> dev-python/gst-python * /usr/lib64/python2.4/site-packages/gst/interfaces.so -> dev-python/gst-python * /usr/lib64/python2.4/site-packages/gst/play.so -> dev-python/gst-python * /usr/lib64/ruby/site_ruby/1.8/x86_64-linux/conf2xml.so -> dev-util/libconf Should I edit these also? Or are these (and the gcc complaints) harmless and just a revdep-rebuild reporting bug?
I have a question regarding this. I used to get this error and I have not done any sort of manual fix and I don't get the error any more. revdep-rebuild reports no broken links and hasn't done so for a while. Here is my emerge --info root@smoker / # emerge --info Portage 2.1.4.4 (default-linux/x86/2006.1/desktop, gcc-4.1.2, glibc-2.6.1-r0, 2.6.23-gentoo-r8 i686) ================================================================= System uname: 2.6.23-gentoo-r8 i686 AMD Athlon(tm) XP 2500+ Timestamp of tree: Tue, 11 Mar 2008 03:00:01 +0000 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.4 [disabled] app-shells/bash: 3.2_p17-r1 dev-java/java-config: 1.3.7, 2.1.4 dev-lang/python: 2.4.4-r9 dev-python/pycrypto: 2.0.1-r6 dev-util/ccache: 2.4-r7 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.23-r3 ACCEPT_KEYWORDS="x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=athlon-xp -O2 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-march=athlon-xp -O2 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="buildsyspkg distlocks fixpackages metadata-transfer parallel-fetch sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LANG="en_US" LC_ALL="en_US.utf8" LINGUAS="en" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_EXTRA_OPTS="--timeout=600" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnow X acl acpi alsa amd arts artswrappersuid automount berkdb browserplugin bzip2 cairo cddb cdr chroot cli cracklib crypt cups curl dbus dri dvd dvdr dvdread eds emboss encode esd exif fam fdftk fortran gaim gdbm gif gimp gimpprint gkrellm gphoto2 gpm gstreamer gtk hal hbci iconv ipv6 isdnlog java javascript jbig jpeg jpeg2k justify kde ldap libwww logrotate mad midi mikmod mmx mp3 mpeg mudflap ncurses nptl nptlonly nsplugin offensive ofx ogg opengl openmp pam parport pcre pdf perl png ppds pppd python qt3 qt3support qt4 quicktime readline realmedia reflection sdl seamonkey session spell spl sqlite sse ssl syslog tcl tcpd tiff tk truetype udev unicode usb vorbis win32codecs wma wmf wmp x86 xml xorg xprint xv yahoo zlib" ALSA_CARDS="emu10k1" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CAMERAS="canon" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en" USERLAND="GNU" VIDEO_CARDS="nvidia" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTDIR_OVERLAY root@smoker / # Here is some more info: [I--] [ -] sys-devel/gcc-4.1.2 (4.1) [I--] [ ] app-portage/gentoolkit-0.2.3-r1 (0) Why did I stop getting this when others do? Is there something fixed on my machine but not others?
(In reply to comment #106) > I am still naive, and getting more so by the minute. My revdep-rebuild finds > similar problems with many other packages; [...] > * /usr/lib64/gstreamer-0.8/libgstfaad.so -> media-plugins/gst-plugins-faad [...] > Should I edit these also? Or are these (and the gcc complaints) harmless and > just a revdep-rebuild reporting bug? They are very different issues. What revdep-rebuild is telling you now is that some .so files are broken, probably because of a recent update of gstreamer. conf2xml.so is also broken. The issue of this bug is about gcc with gcj useflag, and about just one .la file that gets broken in this situation. (or at least revdep-rebuild reports it as broken) (In reply to comment #107) > I have a question regarding this. I used to get this error and I have not done > any sort of manual fix and I don't get the error any more. revdep-rebuild > reports no broken links and hasn't done so for a while. Here is my emerge > --info I don't see gcj useflag there.
> > (In reply to comment #107) > > I don't see gcj useflag there. > You are correct. Sorry for the noise. Thought maybe something was fixed on my end and could help in some way.
(In reply to comment #108) > (In reply to comment #106) > > I am still naive, and getting more so by the minute. My revdep-rebuild finds > > similar problems with many other packages; > [...] > > * /usr/lib64/gstreamer-0.8/libgstfaad.so -> media-plugins/gst-plugins-faad > [...] > > Should I edit these also? Or are these (and the gcc complaints) harmless and > > just a revdep-rebuild reporting bug? > > They are very different issues. What revdep-rebuild is telling you now is that > some .so files are broken, probably because of a recent update of gstreamer. > conf2xml.so is also broken. > > The issue of this bug is about gcc with gcj useflag, and about just one .la > file that gets broken in this situation. (or at least revdep-rebuild reports it > as broken) I must be dense, for I don't see this. I re-emerged dev-util/libconf, media-plugins/gst-plugins-oss, media-plugins/gst-plugins-v4l2, and media-plugins/gst-plugins-xvideo, all successfully, and revdep-rebuild still complains: * Checking dynamic linking consistency * broken /usr/lib64/gstreamer-0.8/libgstossaudio.la (requires /usr/lib64/libgstinterfaces-0.8.la) * broken /usr/lib64/gstreamer-0.8/libgstossaudio.so (requires libgstinterfaces-0.8.so.0) * broken /usr/lib64/gstreamer-0.8/libgstvideo4linux2.la (requires /usr/lib64/libgstinterfaces-0.8.la) * broken /usr/lib64/gstreamer-0.8/libgstvideo4linux2.so (requires libgstinterfaces-0.8.so.0) * broken /usr/lib64/gstreamer-0.8/libgstxvimagesink.la (requires /usr/lib64/libgstinterfaces-0.8.la) * broken /usr/lib64/gstreamer-0.8/libgstxvimagesink.so (requires libgstinterfaces-0.8.so.0) * broken /usr/lib64/ruby/site_ruby/1.8/x86_64-linux/conf2xml.so (requires libconf2xml.so) * Generated new /root/.revdep-rebuild.3_rebuild * Assigning files to packages * /usr/lib64/gstreamer-0.8/libgstossaudio.la -> media-plugins/gst-plugins-oss * /usr/lib64/gstreamer-0.8/libgstossaudio.so -> media-plugins/gst-plugins-oss * /usr/lib64/gstreamer-0.8/libgstvideo4linux2.la -> media-plugins/gst-plugins-v4l2 * /usr/lib64/gstreamer-0.8/libgstvideo4linux2.so -> media-plugins/gst-plugins-v4l2 * /usr/lib64/gstreamer-0.8/libgstxvimagesink.la -> media-plugins/gst-plugins-xvideo * /usr/lib64/gstreamer-0.8/libgstxvimagesink.so -> media-plugins/gst-plugins-xvideo * /usr/lib64/ruby/site_ruby/1.8/x86_64-linux/conf2xml.so -> dev-util/libconf I will attach both the make log and the revdep-rebuild log.
Created attachment 146031 [details] emerge log for comment 110
Created attachment 146032 [details] revdep-rebuild log for comment 110
(In reply to comment #110) > I will attach both the make log and the revdep-rebuild log. Please don't! You've been already told that this isn't the same bug. Please file another one.
(In reply to comment #113) > (In reply to comment #110) > > I will attach both the make log and the revdep-rebuild log. > > Please don't! You've been already told that this isn't the same bug. Please > file another one. > Well 'scooz me! I was under the impression that I was told this was not a bug at all, but just a result of updating gst-streamer. I added comment 110 and the attachments because this has all the same symptoms as the original two year old bug, near as I can see, that .la files are not correct. If that's your attitude, then I leave you to continue not fixing the two year old bug, and I see no point in filing a new bug which may as well end up getting marked as a duplicate, or also take two years to not get fixed all by itself.
1) this is not a portage bug 2) this is caused by a bad interaction betweeen gcc's build system and gcc's ebuild 3) it may be similar to your bug, but it is _not_ it 4) unless you have something _useful_ to add, please don't For the others, sorry for "feeding the troll".
using --libdir= would result in the same (libtool archives being right), however I have this problem that when gcc does invoke the linker (actually collect2) when compiled with --enable-runtime-specific-libs or --libdir= it will pass as one of the first arguments the gcc "version specific" lib path to the linker's search path. This in itself is not a problem, but when rpath instructions are added in the same way, it is. I'm not sure if this is the reason that vapier has for not using this, but at least it is a side effect that gives you undesired breakage if you update gcc within a slot.
How many people does it take for a bug like this to be absolutely resolved? This bug was reported way back in the gcc-3* series, and here I am, using gcc-4.2.3, and the bug still exists. Is this really something that difficult to fix? The crazy thing is, when I look in the directories that claim to have broken links, I don't see any. So what's the problem here? So are the paths broken in the files themselves? Shingoshi
#66 based on #29 fixed it for me. I suggest a sed script (or something like that) in portage, because it is the best solution found in two years. Then we keep waiting for a better one.
*** Bug 214507 has been marked as a duplicate of this bug. ***
I just came across this bug too. Isn't it technically a bug in gcc-config? After all, gcc-config makes /usr/bin/gcc point to whichever version of gcc is currently in use, shouldn't it also make /usr/lib/libgcj.la etc. all point to the current version? I can't really use the symlink solution, because I have three versions of GCC installed, so I'd have to keep changing the symlinks every time I run gcc-config to switch versions.
This is ridiculous. A trivial bug with simple known solutions surviving for more than two years, has gent0o become this bureacratic? Jeez this is FOSS just add a patch to the gcc or gcc-config ebuild and basta. Shall I make one? Lolz.
@#121 yes you should. actually aside from revdep-rebuild showing a needed rebuild what does this break? I haven't bothered using a work around and the one program that needed it to build seems to work (thorough testing hasn't been done yet)
If revdep-rebuild is to show packages _needing_ rebuild and not some random selection of packages, this is a quite serious bug. As portage does not yet automatically resolve handle reverse dependencies, the revdep-rebuild process is a vital part of system administration. "actually aside from revdep-rebuild showing a needed rebuild what does this break?" - if you're not running revdep-rebuild with -p, it not only shows an unnecessary rebuild, it actually performs it. And we're talking about several hours per installed gcc version.
*** Bug 216773 has been marked as a duplicate of this bug. ***
Hey, I have a very similar issue. It seems that gcc compiled with the gcj flag throws these broken libs. When I take the flag off, some packages don't compile, so I need it, but gcc works, even if revdep-rebuild sees issues. here are the libs: Checking dynamic linking consistency... broken /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgcjawt.la (requires /usr/lib/lib-gnu-java-awt-peer-gtk.la) broken /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgij.la (requires /usr/lib/libgcj.la) done.
Created attachment 149505 [details] emerge --info I upgraded to 0.2.4_rc3, (~amd64 masked), the bug is still present, this way will downgrade to unmasked version in one week, if no questions for me. Have a nice day!
> After all, gcc-config makes /usr/bin/gcc point to whichever version of > gcc is currently in use, shouldn't it also make /usr/lib/libgcj.la > etc. all point to the current version? The broken files (e.g. /usr/lib64/gcj-4.2.3/libjvm.la on my system) are version specific, and they each ought to point to the libgcj.la for the *matching* version, regardless of which is the currently used version. That being said, I'm a little hazy on what the information is actually used for, and though libjvm.la is located on a version specific path, the text of the file doesn't seem to refer to its version at all (except for a reference to its own location). So perhaps a link pointing to any version would be fine. It would satisfy revdep-rebuild, and I haven't heard of any other consequences from this bug. Presumably the current version would be best, since any other might get unmerged.
Most might have already seen it but I just want to reference the recent blog post by Diego "Flameeyes" Pettenò on the topic: http://blog.flameeyes.eu/articles/2008/04/14/what-about-those-la-files From the post's comments: > richard77 said about 7 hours later: > Is libtool the root cause of the gcc/revdep-rebuild infamous bug? > (gentoo bug >#125728) > > Flameeyes said about 7 hours later: > Yes that’s exactly what is causing that.
Seems to hit people running stable x86 by now (as e.g. me...)
(In reply to comment #129) > Seems to hit people running stable x86 by now (as e.g. me...) Not really. I'm using stable x86 and I've noticed this bug for long time, maybe one year or so.
(In reply to comment #130) > (In reply to comment #129) > > Seems to hit people running stable x86 by now (as e.g. me...) > > Not really. I'm using stable x86 and I've noticed this bug for long time, maybe > one year or so. > Same here, has come up a while ago
Oops, my fault. Added the useflag gcj recently. Sorry for the noise. Any news on a patch (that does not involve manual fiddling with base system files)? :)
Hi! I'm using the following code snipplet in my update script. Maybe it is of use for someone as a simple, automated work-around: if [ -L /usr/lib/libgcj.la ] ; then rm /usr/lib/libgcj.la ln -s /usr/lib/gcc/`gcc-config -l | grep * | awk '{print $2}' | sed 's/gnu-/gnu\//g'`/libgcj.la /usr/lib fi
I'd normally refrain from "me too" comments, but the long-standing nature of this issue is truly impressive :-O And, I have a tidbit to add: this issue appears to be expanding! I added the 'gcj' USE-flag, and gcc-4.1.2 was dutifully re-compiled (x86 stable, 2008.0 "desktop" profile - although it's an older system, I continually update everything... the Gentoo strength) . I now have the following *two* revdep-rebuild notifications: Checking dynamic linking consistency... broken /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgcjawt.la (requires /usr/lib/lib-gnu-java-awt-peer-gtk.la) broken /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgij.la (requires /usr/lib/libgcj.la) done. (/root/.revdep-rebuild.3_rebuild)
*** Bug 226163 has been marked as a duplicate of this bug. ***
*** Bug 228575 has been marked as a duplicate of this bug. ***
Still around on 4.3.1-r1 on amd64. Solved it by symlinking, but that's not really a solution. Seriously, fix this please :(
(In reply to comment #30) > (In reply to comment #29) > > (In reply to comment #15) > > > (In reply to comment #11) > > > > When I compiled and installed gcc-3.4.5 manually > > > What do you mean with 'manually'? > > > Also gcc-3.4.6 suffers the same problem. Fixed linking /usr/lib/libgcj.la to > > > the one of used gcc version. > > > Thanks. > > > > I found two solutions to this problem. One is to symlink /usr/lib/libgcj.la to > > /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/libgcj.la (in my case, obviously change > > i686-pc-linux-gnu to your target). The other is to edit the two .la files that > > revdep is complaining about and change the reference to /usr/lib/libgcj.la to > > /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/libgcj.la. The way I see it, all 3 files > > are installed with the gcc ebuild, and two of the .la files point to the wrong > > location for libgcj.la, so I think changing those files is better than making a > > symlink. > > > > The second of these two solutions worked for me. The .la files for > lib-org-w3c-dom and lib-org-xml-sax.la didn't get updated with the new location > for libgcj during the gcc 3.4 update. >
I get: broken /usr/lib/gcc/i686-pc-linux-gnu/4.3.1/libgij.la (requires /usr/lib/libgcj.la) broken /usr/lib/gcj-4.3.1-9/libjvm.la (requires /usr/lib/libgcj.la) emerging gcc again does not help, should I open a new bug?
Just create a symlink (this is a snipplet from my upgrade script): ln -s /usr/lib/gcc/`gcc-config -l | grep '*' | tail -n1 | awk '{print $2}' | sed 's/gnu-/gnu\//g'`/libgcj.la /usr/lib
(In reply to comment #140) > Just create a symlink (this is a snipplet from my upgrade script): Thanks! But shouldn't this be solved by the gcc ebuild?
The fix in comment #140 did not work for me. Also tried some other proposed solution in this bug months ago, which did not work either.
(In reply to comment #141) > (In reply to comment #140) > > Just create a symlink (this is a snipplet from my upgrade script): That worked for me also > But shouldn't this be solved by the gcc ebuild? Yes and no - as far as I understand the problem correctly: The symlinks should be updated by gcc-config, because it sets the default compiler. The problem is that gcc-config cannot do anything when gcc is rebuild due to a use flag change and new libs are added (like it is the case when setting gcj). From that point the gcc ebuild should set the symlinks. But what happens if you update a version of gcc in a slot which is not set as default compiler. Then the symlink(s) would point to the gcc-4.3.1 libs although gcc-4.1.2 is set as default compiler. Best regards, Chris
(In reply to comment #143) > use flag change and new libs are added (like it is the case when setting gcj). > From that point the gcc ebuild should set the symlinks. > But what happens if you update a version of gcc in a slot which is not set as > default compiler. Then the symlink(s) would point to the gcc-4.3.1 libs > although gcc-4.1.2 is set as default compiler. It can always set invalid symlink for the library if it does not exist.
(In reply to comment #144) > It can always set invalid symlink for the library if it does not exist. Yes, but when you have gcc-4.1.2 and gcc-4.3.1 installed, and gcc-4.1.2 is set as default by gcc-config, /usr/lib/libgcj.la should point to /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgcj.la. When you now update the 4.3 slot to 4.3.1-r1 - and leave 4.1.2 as default, the symlink should still point to /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgcj.la and not to /usr/lib/gcc/i686-pc-linux-gnu/4.3.1/libgcj.la. That's why the gcc ebuild cannot set the symlinks blindly. Or am I completely wrong?
(In reply to comment #145) > That's why the gcc ebuild cannot set the symlinks blindly. > Or am I completely wrong? gcc-config can...
(In reply to comment #146) > gcc-config can... Yes, I said that. My comment was a try to answer the question "But shouldn't this be solved by the gcc ebuild?" From comment #141. Still, how should gcc-config be used in the ebuild to fix the symlinks when new libs are added due to a use flag change? Should every gcc ebuild do something like (dummy code): (1) remember currently set gcc from "gcc-config -l" (2) set default gcc to all installed gccs to fix the symlinks (3) set it back to the remembered gcc from (1) ? Anyway, that should also work when only one slot is used - at least gcc-config says "switching to ..." when selecting the (only and already selected) gcc version.
Created attachment 163372 [details, diff] This would make gcc-config relink libgcj.la, when choosing gcc profile. use: $ sudo patch -p0 < gcc-config_libgcj_la.patch How about this, then? It makes gcc-config update /usr/lib/libgcj.la link at each gcc profile change... Worked for me so far. Now, do gcc ebuilds invoke gcc-config after (re)emerge? If so, the patch should be entirely enough, I guess - otherwise, there need to be another workaround added to all ebuilds...
Sorry, forgot to add sth. about the lib-gnu-java-awt-peer-gtk.la as well - didn't notice at first, that this came from the same bug. Just tell me, what you think about such patch - if it's ok, I'll post a "full version" ;)
*** Bug 219951 has been marked as a duplicate of this bug. ***
*** Bug 235924 has been marked as a duplicate of this bug. ***
Created attachment 163946 [details, diff] A workaround via patching gcc-config-1.4 > Sorry, forgot to add sth. about the lib-gnu-java-awt-peer-gtk.la as well - > didn't notice at first, that this came from the same bug. > > Just tell me, what you think about such patch - if it's ok, I'll post a "full > version" ;) No-one shouting, so I just drop my latest solution. At present, tested only against: gcc-config-1.4.0-r4 and, when patched, works with gcc-3.4.6-r2 and gcc-4.1.2 - but _should_ with any gcc-version; I don't see how it might not... (suggestions welcome) Just to remind: $ sudo patch -p0 < gcc-config_bug_125728.patch and then: $ gcc-config -l and, finally: $ sudo gcc-config <the_number_of_your_gcc_profile_from_the_list> Have fun ;)
You are testing twice for libgcj.la. I guess in the second if-statement you meant to test for lib-gnu-java-awt-peer-gtk.la. Also it would be enough to put one '[...]' there (not '[[...]]'), although both might work. Could some Gentoo developer comment on whether this patch could make it into Portage or not, please? We're having more than 150 comments here, but only a handful from someone @ gentoo.org.
Created attachment 164031 [details, diff] corrected version of the above Thanks to Comment #153 From Stephan Springer
Gentoolkit updated today and of course all the fixes that were in place went out the window with the rewrite of revdep-rebuild. The good news is I pasted the patch into gcc-config uploaded by Michal Janke and it works perfectly. Thank you Michal Janke, for doing something that could have been done 2 1/2 years ago if the prevailing attitudes (i.e. 'EGOS') would have permitted it.
(In reply to comment #155) > The good news is I pasted the patch into gcc-config uploaded by Michal Janke > and it works perfectly. So what should one do ---through portage-- to fix this problem? My tree is up-to-date and revdep-rebuild still says the same. Rebuilding gcc-config is the right way? Or your patch has not yet hit the portage tree?
(In reply to comment #156) > So what should one do ---through portage-- to fix this problem? My tree is > up-to-date and revdep-rebuild still says the same. > Rebuilding gcc-config is the right way? Or your patch has not yet hit the > portage tree? > Looking through the current ChangeLog, I don't see it being mentioned. So probably it either isn't good enough to be included, or just has to wait some time. I don't know - it is actually the first time I created some (seemingly) useful patch for gentoo and I've no idea, if/when it might be used by the devs/maintainers. But it's nice to see someone found it useful :)
I've just updated to gcc-4.2.4, and now revdep-rebuild (the new one) reports: * Checking dynamic linking consistency [ 14% ] * broken /usr/bin/pdftk (requires libgcj.so.7) [ 59% ] * broken /usr/lib/gcc/i686-pc-linux-gnu/4.2.4/libgij.la (requires /usr/lib/libgcj.la) * broken /usr/lib/gcj-4.2.4/libjvm.la (requires /usr/lib/libgcj.la) ... * Assigning files to packages * /usr/bin/pdftk -> app-text/pdftk * /usr/lib/gcc/i686-pc-linux-gnu/4.2.4/libgij.la -> sys-devel/gcc * /usr/lib/gcj-4.2.4/libjvm.la -> sys-devel/gcc If i look for broken links in /usr/lib, I get: $ find -L /usr/lib -maxdepth 1 -type l -ls 4620290 0 lrwxrwxrwx 1 root root 49 Sep 26 2007 /usr/lib/lib-gnu-java-awt-peer-gtk.la -> /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgcjawt.la 4620347 0 lrwxrwxrwx 1 root root 18 Sep 26 2007 /usr/lib/libORBit.so -> libORBit.so.0.5.17 4620808 0 lrwxrwxrwx 1 root root 46 Sep 26 2007 /usr/lib/libgcj.la -> /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgij.la 4620351 0 lrwxrwxrwx 1 root root 22 Sep 26 2007 /usr/lib/libORBitutil.so -> libORBitutil.so.0.5.17 4620907 0 lrwxrwxrwx 1 root root 20 Sep 26 2007 /usr/lib/libgnet-2.0.so -> libgnet-2.0.so.0.6.1 4620350 0 lrwxrwxrwx 1 root root 27 Sep 26 2007 /usr/lib/libORBitCosNaming.so -> libORBitCosNaming.so.0.5.17 4622456 0 lrwxrwxrwx 1 root root 19 Sep 26 2007 /usr/lib/libzvt-2.0.so -> libzvt-2.0.so.0.0.1 4620318 0 lrwxrwxrwx 1 root root 19 Sep 26 2007 /usr/lib/libIDL.so -> libIDL-0.6.so.0.4.4 4620776 0 lrwxrwxrwx 1 root root 22 Sep 26 2007 /usr/lib/libflash.so -> libflash-0.4.so.10.0.0 4620319 0 lrwxrwxrwx 1 root root 17 Sep 26 2007 /usr/lib/libIIOP.so -> libIIOP.so.0.5.17 The broken gcc libs have been pointing to 4.1.2, even though I've been running 4.2.2 for ages before updating to 4.2.4, and revdep-rebuild hasn't mentioned it. If I then use equery to find packages that may source these, I only get gcc, and that isn't even in the right place: $ equery belongs `find -L /usr/lib -maxdepth 1 -type l -print | sed 's/.*\///'` [ Searching for file(s) lib-gnu-java-awt-peer-gtk.la,libORBit.so,libgcj.la,libORBitutil.so,libgnet-2.0.so,libORBitCosNaming.so,libzvt-2.0.so,libIDL.so,libflash.so,libIIOP.so in *... ] sys-devel/gcc-4.2.4 (/usr/lib/gcc/i686-pc-linux-gnu/4.2.4/libgcj.la) Surely /usr/lib/libgcj.la should be 'owned' by gcc-config, as it creates it, and the patch given above included in it so that it keeps the link correct? (I shall remove the other broken links as they are obviously not required).
gcc-4.2.4 Also installs another broken link: sys-devel/gcc-4.2.4 (/usr/lib/gcc/i686-pc-linux-gnu/4.2.4/include/schily/scg -> ../scg) cdrtools is the only one that installs a correct link for scg: app-cdr/cdrtools-2.01.01_alpha51 (/usr/include/schily/scg -> ../scg) app-cdr/cdrtools-2.01.01_alpha51 (/usr/include/scg) This is after an upgrade from gcc-4.2.2, so gcc-config not explicitly run. Revdep-rebuild doesn't find this, and it is probably unimportant..
Created attachment 172810 [details] Script for finding broken links in /usr/lib This is the script I run after emerge -puNDv world now..
*** Bug 253930 has been marked as a duplicate of this bug. ***
should be fixed now http://sources.gentoo.org/eclass/toolchain.eclass?r1=1.383&r2=1.384
Thanks a lot =)
It's fixed on my x86 machine (thanks!), but on ~amd64 I still get this: * Checking dynamic linking consistency [ 45% ] * broken /usr/lib64/gcj-4.3.3-9/libjvm.la (requires /usr/lib/../lib64/libgcj.la) [ 100% ] * Generated new 3_broken.rr * Assigning files to packages * /usr/lib64/gcj-4.3.3-9/libjvm.la -> sys-devel/gcc * Generated new 4_raw.rr and 4_owners.rr * Cleaning list of packages to rebuild * Generated new 4_pkgs.rr * Assigning packages to ebuilds * Generated new 4_ebuilds.rr * Evaluating package order * Portage could not find any version of the following packages it could build: * sys-devel/gcc:x86_64-pc-linux-gnu-4.3.3 * (Perhaps they are masked, blocked, or removed from portage.) Maybe it's because /usr/lib/ is a symlink to /usr/lib64?
the code wasnt updating things in /usr/lib*/*/, so ive fixed that as well. thanks for testing. http://sources.gentoo.org/eclass/toolchain.eclass?r1=1.386&r2=1.387
*** Bug 258957 has been marked as a duplicate of this bug. ***
