Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 125728 - gcc installs .la files containing broken paths
Summary: gcc installs .la files containing broken paths
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: x86 Linux
: Highest normal with 8 votes (vote)
Assignee: Gentoo Toolchain Maintainers
URL:
Whiteboard:
Keywords:
: 126200 126440 126701 127535 128093 134920 136463 138390 139345 139513 139881 140317 141467 142069 142762 146183 147962 148535 156461 156792 157907 166645 170718 171497 176504 179239 179259 179311 185962 194524 198520 198671 202836 214507 216773 219951 226163 228575 235924 253930 258957 (view as bug list)
Depends on:
Blocks:
 
Reported: 2006-03-10 09:45 UTC by Rumen Yotov
Modified: 2009-02-14 17:43 UTC (History)
133 users (show)

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


Attachments
contents-la-files.txt (contents-la-files.txt,6.26 KB, text/plain)
2006-03-10 21:33 UTC, Rumen Yotov
Details
Patched toolchain.eclass (toolchain.eclass,77.18 KB, text/plain)
2008-03-10 18:15 UTC, Preston Crow
Details
grep -C3 libgij.la on gcc-4.2.3 build log (libgij.la.log,20.50 KB, text/plain)
2008-03-10 23:28 UTC, Martin von Gagern
Details
emerge log for comment 110 (em.log,146.49 KB, text/plain)
2008-03-13 15:41 UTC, Felix Finch
Details
revdep-rebuild log for comment 110 (rev,3.29 KB, text/plain)
2008-03-13 15:42 UTC, Felix Finch
Details
emerge --info (emergeinfo.txt,3.48 KB, text/plain)
2008-04-12 19:43 UTC, Imre Péntek
Details
This would make gcc-config relink libgcj.la, when choosing gcc profile. (gcc-config_libgcj_la.patch,358 bytes, patch)
2008-08-20 09:47 UTC, Michal Janke
Details | Diff
A workaround via patching gcc-config-1.4 (gcc-config_bug_125728.patch,493 bytes, patch)
2008-08-27 23:12 UTC, Michal Janke
Details | Diff
corrected version of the above (gcc-config_bug_125728.patch,508 bytes, patch)
2008-08-28 21:58 UTC, Michal Janke
Details | Diff
Script for finding broken links in /usr/lib (findbrokenlibs.sh,665 bytes, text/plain)
2008-11-22 09:12 UTC, Peter Fox
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Rumen Yotov 2006-03-10 09:45:06 UTC
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"
Comment 1 Paul Varner (RETIRED) gentoo-dev 2006-03-10 12:46:56 UTC
Please run revdep-rebuild --ignore --pretend --verbose and attach the output along with the .la files that it considers to be broken.
Comment 2 Rumen Yotov 2006-03-10 21:31:38 UTC
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
Comment 3 Rumen Yotov 2006-03-10 21:33:42 UTC
Created attachment 81892 [details]
contents-la-files.txt
Comment 4 Paul Varner (RETIRED) gentoo-dev 2006-03-13 11:29:30 UTC
(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?
Comment 5 Rumen Yotov 2006-03-13 12:41:39 UTC
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
Comment 6 Paul Varner (RETIRED) gentoo-dev 2006-03-13 12:58:00 UTC
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.
Comment 7 Rumen Yotov 2006-03-13 21:51:00 UTC
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
Comment 8 Paul Varner (RETIRED) gentoo-dev 2006-03-14 09:10:16 UTC
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.
Comment 9 SpanKY gentoo-dev 2006-03-14 16:02:34 UTC
*** Bug 126200 has been marked as a duplicate of this bug. ***
Comment 10 Jakub Moc (RETIRED) gentoo-dev 2006-03-16 11:28:43 UTC
*** Bug 126440 has been marked as a duplicate of this bug. ***
Comment 11 Paul Varner (RETIRED) gentoo-dev 2006-03-17 12:40:44 UTC
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.
Comment 12 Jakub Moc (RETIRED) gentoo-dev 2006-03-18 11:18:56 UTC
*** Bug 126701 has been marked as a duplicate of this bug. ***
Comment 13 Erik Zeek 2006-03-20 12:29:05 UTC
(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)
Comment 14 Jakub Moc (RETIRED) gentoo-dev 2006-03-25 10:18:50 UTC
*** Bug 127535 has been marked as a duplicate of this bug. ***
Comment 15 Emiliano Vavassori 2006-03-27 03:02:50 UTC
(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.
Comment 16 TGL 2006-03-27 05:50:14 UTC
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.
Comment 17 TGL 2006-03-27 14:00:13 UTC
(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).
Comment 18 Rumen Yotov 2006-03-27 21:34:05 UTC
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
Comment 19 Jakub Moc (RETIRED) gentoo-dev 2006-03-30 02:46:20 UTC
*** Bug 128093 has been marked as a duplicate of this bug. ***
Comment 20 Rumen Yotov 2006-05-10 03:36:58 UTC
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
Comment 21 Jakub Moc (RETIRED) gentoo-dev 2006-05-30 08:04:54 UTC
*** Bug 134920 has been marked as a duplicate of this bug. ***
Comment 22 Jakub Moc (RETIRED) gentoo-dev 2006-06-11 12:28:17 UTC
*** Bug 136463 has been marked as a duplicate of this bug. ***
Comment 23 John Altstadt 2006-06-11 18:28:38 UTC
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.
Comment 24 Kristian Poul Herkild 2006-06-12 05:55:30 UTC
(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.
Comment 25 TGL 2006-06-12 12:15:53 UTC
@ 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.
Comment 26 Steve Kutnar 2006-06-15 16:03:11 UTC
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.
Comment 27 Paolo Pedroni 2006-06-20 06:54:20 UTC
gcc-3.4.6-r1 on amd64 has the same problem.
Comment 28 Gergan Penkov 2006-06-21 10:16:45 UTC
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.
Comment 29 Marc Morrisette 2006-06-21 13:32:38 UTC
(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.
Comment 30 DrChandra the Gentoo Person 2006-06-23 10:07:20 UTC
(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.
Comment 31 Jakub Moc (RETIRED) gentoo-dev 2006-06-28 13:15:20 UTC
*** Bug 138390 has been marked as a duplicate of this bug. ***
Comment 32 Jakub Moc (RETIRED) gentoo-dev 2006-07-05 10:47:37 UTC
*** Bug 139345 has been marked as a duplicate of this bug. ***
Comment 33 Paul Varner (RETIRED) gentoo-dev 2006-07-06 20:20:50 UTC
*** Bug 139513 has been marked as a duplicate of this bug. ***
Comment 34 Jakub Moc (RETIRED) gentoo-dev 2006-07-10 07:24:10 UTC
*** Bug 139881 has been marked as a duplicate of this bug. ***
Comment 35 Jakub Moc (RETIRED) gentoo-dev 2006-07-14 02:11:49 UTC
*** Bug 140317 has been marked as a duplicate of this bug. ***
Comment 36 Jakub Moc (RETIRED) gentoo-dev 2006-07-23 01:45:00 UTC
*** Bug 141467 has been marked as a duplicate of this bug. ***
Comment 37 Jakub Moc (RETIRED) gentoo-dev 2006-07-29 03:05:56 UTC
*** Bug 142069 has been marked as a duplicate of this bug. ***
Comment 38 Jakub Moc (RETIRED) gentoo-dev 2006-08-04 02:38:56 UTC
*** Bug 142762 has been marked as a duplicate of this bug. ***
Comment 39 Rumen Yotov 2006-08-31 22:23:36 UTC
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
Comment 40 Jakub Moc (RETIRED) gentoo-dev 2006-09-03 14:05:03 UTC
*** Bug 146183 has been marked as a duplicate of this bug. ***
Comment 41 Jakub Moc (RETIRED) gentoo-dev 2006-09-17 10:29:09 UTC
*** Bug 147962 has been marked as a duplicate of this bug. ***
Comment 42 Jakub Moc (RETIRED) gentoo-dev 2006-09-21 09:28:23 UTC
*** Bug 148535 has been marked as a duplicate of this bug. ***
Comment 43 Andreas Thalhammer 2006-11-15 07:12:41 UTC
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...
Comment 44 Daniel Herzog 2006-11-18 04:19:58 UTC
Please fix this, several working solutions seem to be known.
Comment 45 Renato Caldas 2006-11-21 16:49:33 UTC
Did someone submit a bug report upstream?
Comment 46 Jakub Moc (RETIRED) gentoo-dev 2006-11-27 15:48:51 UTC
*** Bug 156461 has been marked as a duplicate of this bug. ***
Comment 47 Jakub Moc (RETIRED) gentoo-dev 2006-12-01 05:22:46 UTC
*** Bug 156792 has been marked as a duplicate of this bug. ***
Comment 48 Heiko Baums 2006-12-01 12:33:42 UTC
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?
Comment 49 ivo welch 2006-12-02 19:34:13 UTC
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?
Comment 50 Vasilis Lourdas 2006-12-04 06:18:32 UTC
(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.
Comment 51 Jakub Moc (RETIRED) gentoo-dev 2006-12-12 04:30:05 UTC
*** Bug 157907 has been marked as a duplicate of this bug. ***
Comment 52 Pacho Ramos gentoo-dev 2007-01-26 08:38:48 UTC
When will this bug be fixed?

Thanks
Comment 53 Erik Quaeghebeur 2007-02-05 23:04:52 UTC
Joining CC list.
Comment 54 Jakub Moc (RETIRED) gentoo-dev 2007-02-13 11:39:06 UTC
*** Bug 166645 has been marked as a duplicate of this bug. ***
Comment 55 Peter Lewis 2007-02-15 18:31:56 UTC
Hi, just hoping that this gets fixed soon too.

Thanks.
Comment 56 Preston Crow 2007-03-12 12:53:27 UTC
Happy Birthday bug 125728!
Comment 57 Alex Tarkovsky 2007-03-12 13:53:11 UTC
(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.
Comment 58 Jakub Moc (RETIRED) gentoo-dev 2007-03-13 14:25:42 UTC
*** Bug 170718 has been marked as a duplicate of this bug. ***
Comment 59 Alex Tarkovsky 2007-03-13 17:44:06 UTC
This bug has the longest CC: list I've ever seen.
Comment 60 Jakub Moc (RETIRED) gentoo-dev 2007-03-19 23:13:19 UTC
*** Bug 171497 has been marked as a duplicate of this bug. ***
Comment 61 SpanKY gentoo-dev 2007-03-31 00:44:33 UTC
"--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
Comment 62 Harald van Dijk (RETIRED) gentoo-dev 2007-04-29 20:59:11 UTC
*** Bug 176504 has been marked as a duplicate of this bug. ***
Comment 63 David D. Huff Jr. 2007-05-13 07:45:43 UTC
amd64 is also having the same problem with gcc-4.1.1-r3
Comment 64 Constantin Baranov 2007-05-20 12:52:37 UTC
Problem still exists in gcc-4.1.2 at least on x86 and amd64.
Comment 65 Vasilis Lourdas 2007-05-20 15:05:50 UTC
(In reply to comment #64)
> Problem still exists in gcc-4.1.2 at least on x86 and amd64.

Yeap, I confirm (x86).
Comment 66 William Sherwin 2007-05-20 15:35:37 UTC
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?
Comment 67 Jakub Moc (RETIRED) gentoo-dev 2007-05-20 16:18:32 UTC
*** Bug 179239 has been marked as a duplicate of this bug. ***
Comment 68 Pacho Ramos gentoo-dev 2007-05-20 17:00:07 UTC
(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 ?
Comment 69 Emiliano Vavassori 2007-05-20 17:11:15 UTC
(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.

Comment 70 Jakub Moc (RETIRED) gentoo-dev 2007-05-20 19:56:30 UTC
*** Bug 179259 has been marked as a duplicate of this bug. ***
Comment 71 Philip Belemezov 2007-05-20 22:24:59 UTC
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?).
Comment 72 daniel mohr 2007-05-21 10:22:47 UTC
> 
> 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.
Comment 73 Jakub Moc (RETIRED) gentoo-dev 2007-05-21 10:43:42 UTC
*** Bug 179311 has been marked as a duplicate of this bug. ***
Comment 74 Jakub Moc (RETIRED) gentoo-dev 2007-07-20 09:17:23 UTC
*** Bug 185962 has been marked as a duplicate of this bug. ***
Comment 75 Preston Crow 2007-07-31 13:59:46 UTC
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?
Comment 76 Constantin Baranov 2007-07-31 16:00:34 UTC
(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.
Comment 77 Alex Tarkovsky 2007-07-31 16:39:54 UTC
(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.
Comment 78 William Sherwin 2007-07-31 16:58:44 UTC
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...)
Comment 79 Paul Varner (RETIRED) gentoo-dev 2007-07-31 18:02:18 UTC
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
Comment 80 Paul Varner (RETIRED) gentoo-dev 2007-07-31 18:11:18 UTC
Sorry for the noise, the path to the older revdep-rebuild is /usr/lib/gentoolkit/bin/revdep-rebuild
Comment 81 ivo welch 2007-09-24 00:19:43 UTC
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
Comment 82 Andrei Slavoiu 2007-10-02 19:26:29 UTC
(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?
Comment 83 Jakub Moc (RETIRED) gentoo-dev 2007-10-02 21:04:15 UTC
*** Bug 194524 has been marked as a duplicate of this bug. ***
Comment 84 Martin Mokrejš 2007-10-11 23:54:36 UTC
# 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.
Comment 85 SpanKY gentoo-dev 2007-11-09 04:56:58 UTC
*** Bug 198520 has been marked as a duplicate of this bug. ***
Comment 86 Jakub Moc (RETIRED) gentoo-dev 2007-11-10 13:08:07 UTC
*** Bug 198671 has been marked as a duplicate of this bug. ***
Comment 87 Tomas Thiemel 2007-11-15 01:11:28 UTC
(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
Comment 88 Jakub Moc (RETIRED) gentoo-dev 2007-12-20 07:53:45 UTC
*** Bug 202836 has been marked as a duplicate of this bug. ***
Comment 89 Caleb Cushing 2008-03-09 19:38:45 UTC
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)
Comment 90 Caleb Cushing 2008-03-09 19:44:28 UTC
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.
Comment 91 Bo Ørsted Andresen (RETIRED) gentoo-dev 2008-03-09 20:10:53 UTC
See comment #29
Comment 92 David D. Huff Jr. 2008-03-09 23:41:50 UTC
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. 
Comment 93 Carlos Eduardo Santos 2008-03-10 15:38:17 UTC
Happy birthday, dear Bug!
Comment 94 Mark Loeser (RETIRED) gentoo-dev 2008-03-10 15:56:11 UTC
(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
Comment 95 Heiko Baums 2008-03-10 16:04:56 UTC
(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!
Comment 96 Nicholas Doyle 2008-03-10 16:08:08 UTC
There do seem to be working solutions. The problem is that none of them seem to be making it in to portage...
Comment 97 Vasilis Lourdas 2008-03-10 16:09:53 UTC
(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.
Comment 98 Bo Ørsted Andresen (RETIRED) gentoo-dev 2008-03-10 16:14:20 UTC
(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.
Comment 99 Felix Finch 2008-03-10 16:37:03 UTC
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.
Comment 100 walt 2008-03-10 17:32:39 UTC
(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.
Comment 101 Preston Crow 2008-03-10 18:15:35 UTC
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.
Comment 102 Felix Finch 2008-03-10 21:58:01 UTC
(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?
Comment 103 walt 2008-03-10 22:46:56 UTC
> 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 ......
Comment 104 Martin von Gagern 2008-03-10 23:28:44 UTC
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.
Comment 105 Martin von Gagern 2008-03-11 10:02:50 UTC
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?
Comment 106 Felix Finch 2008-03-11 23:57:52 UTC
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?
Comment 107 Dale 2008-03-12 02:10:56 UTC
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?
Comment 108 Denilson Sá 2008-03-12 11:13:30 UTC
(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.
Comment 109 Dale 2008-03-12 11:27:03 UTC
> 
> (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.  
Comment 110 Felix Finch 2008-03-13 15:36:42 UTC
(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.
Comment 111 Felix Finch 2008-03-13 15:41:16 UTC
Created attachment 146031 [details]
emerge log for comment 110
Comment 112 Felix Finch 2008-03-13 15:42:08 UTC
Created attachment 146032 [details]
revdep-rebuild log for comment 110
Comment 113 Renato Caldas 2008-03-13 15:42:38 UTC
(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.

Comment 114 Felix Finch 2008-03-13 15:47:16 UTC
(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.
Comment 115 Renato Caldas 2008-03-13 15:54:20 UTC
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".
Comment 116 Fabian Groffen gentoo-dev 2008-03-14 17:28:47 UTC
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.
Comment 117 Xavian-Anderson Macpherson 2008-03-15 04:10:09 UTC
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
Comment 118 Carlos Eduardo Santos 2008-03-18 02:34:33 UTC
#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.
Comment 119 Jakub Moc (RETIRED) gentoo-dev 2008-03-24 12:28:20 UTC
*** Bug 214507 has been marked as a duplicate of this bug. ***
Comment 120 Adam Nielsen 2008-03-31 06:27:36 UTC
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.
Comment 121 Marcel Partap 2008-04-05 18:10:02 UTC
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.
Comment 122 Caleb Cushing 2008-04-05 18:35:17 UTC
@#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)
Comment 123 Jens Mueller 2008-04-05 19:08:54 UTC
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.
Comment 124 Carsten Lohrke (RETIRED) gentoo-dev 2008-04-07 21:22:43 UTC
*** Bug 216773 has been marked as a duplicate of this bug. ***
Comment 125 Nils Schlupp 2008-04-08 04:01:45 UTC
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.
Comment 126 Imre Péntek 2008-04-12 19:43:27 UTC
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!
Comment 127 Ralph Hartley 2008-04-14 16:28:19 UTC
> 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.
Comment 128 Ingo Bormuth 2008-04-15 01:30:39 UTC
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.
Comment 129 Andreas K. Hüttel gentoo-dev 2008-05-05 10:56:24 UTC
Seems to hit people running stable x86 by now (as e.g. me...)
Comment 130 Denilson Sá 2008-05-05 11:29:13 UTC
(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.
Comment 131 Nils Schlupp 2008-05-05 13:02:14 UTC
(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
Comment 132 Andreas K. Hüttel gentoo-dev 2008-05-05 13:39:31 UTC
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)? :)
Comment 133 Olaf Leidinger 2008-06-10 06:44:51 UTC
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
Comment 134 Gordon Pritchard 2008-06-10 18:33:43 UTC
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)

Comment 135 Carsten Lohrke (RETIRED) gentoo-dev 2008-06-13 11:02:07 UTC
*** Bug 226163 has been marked as a duplicate of this bug. ***
Comment 136 Carsten Lohrke (RETIRED) gentoo-dev 2008-06-20 16:07:39 UTC
*** Bug 228575 has been marked as a duplicate of this bug. ***
Comment 137 R Bar-On 2008-07-25 02:17:54 UTC
Still around on 4.3.1-r1 on amd64.  Solved it by symlinking, but that's not really a solution.  Seriously, fix this please :(
Comment 138 Martin Ereth 2008-07-26 15:37:38 UTC
(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.
> 

Comment 139 Alon Bar-Lev 2008-08-05 16:39:18 UTC
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?
Comment 140 Olaf Leidinger 2008-08-05 17:34:58 UTC
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
Comment 141 Alon Bar-Lev 2008-08-06 04:41:34 UTC
(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?
Comment 142 Christian Schlotter 2008-08-06 20:49:10 UTC
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.
Comment 143 Christian Schwinn 2008-08-14 09:27:10 UTC
(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
Comment 144 Alon Bar-Lev 2008-08-14 10:37:07 UTC
(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.
Comment 145 Christian Schwinn 2008-08-14 10:50:47 UTC
(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?
Comment 146 Alon Bar-Lev 2008-08-14 10:53:39 UTC
(In reply to comment #145)
> That's why the gcc ebuild cannot set the symlinks blindly.
> Or am I completely wrong?

gcc-config can...
Comment 147 Christian Schwinn 2008-08-14 11:23:35 UTC
(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.
Comment 148 Michal Janke 2008-08-20 09:47:09 UTC
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...
Comment 149 Michal Janke 2008-08-20 10:20:10 UTC
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" ;)
Comment 150 Carsten Lohrke (RETIRED) gentoo-dev 2008-08-27 16:34:14 UTC
*** Bug 219951 has been marked as a duplicate of this bug. ***
Comment 151 Carsten Lohrke (RETIRED) gentoo-dev 2008-08-27 16:34:34 UTC
*** Bug 235924 has been marked as a duplicate of this bug. ***
Comment 152 Michal Janke 2008-08-27 23:12:18 UTC
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 ;)
Comment 153 Stephan Springer 2008-08-28 12:01:17 UTC
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.
Comment 154 Michal Janke 2008-08-28 21:58:57 UTC
Created attachment 164031 [details, diff]
corrected version of the above

Thanks to Comment #153 From Stephan Springer
Comment 155 David D. Huff Jr. 2008-10-03 05:42:55 UTC
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.
Comment 156 Pablo Montepagano 2008-10-21 18:50:08 UTC
(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?
Comment 157 Michal Janke 2008-11-03 02:31:15 UTC
(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 :)
Comment 158 Peter Fox 2008-11-20 20:13:38 UTC
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).
Comment 159 Peter Fox 2008-11-22 09:10:59 UTC
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..
Comment 160 Peter Fox 2008-11-22 09:12:25 UTC
Created attachment 172810 [details]
Script for finding broken links in /usr/lib

This is the script I run after emerge -puNDv world now..
Comment 161 Patrick Lauer gentoo-dev 2009-01-07 18:37:17 UTC
*** Bug 253930 has been marked as a duplicate of this bug. ***
Comment 162 SpanKY gentoo-dev 2009-01-28 05:22:20 UTC
should be fixed now

http://sources.gentoo.org/eclass/toolchain.eclass?r1=1.383&r2=1.384
Comment 163 Pacho Ramos gentoo-dev 2009-01-28 07:41:17 UTC
Thanks a lot =)
Comment 164 walt 2009-01-28 22:29:47 UTC
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?
Comment 165 SpanKY gentoo-dev 2009-01-28 23:41:19 UTC
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
Comment 166 SpanKY gentoo-dev 2009-02-14 17:43:27 UTC
*** Bug 258957 has been marked as a duplicate of this bug. ***