Trying a current 'emerge -uDavt world' it tries to emerge sys-apps/file-4.12. This fails with the following message: if test -f ./$frag; then \ f=./$frag; \ else \ f=$frag; \ fi; \ cat $f; \ done >> magic ../src/file -C -m magic WARNING: type lestring16 >0 Description: %15.15s invalid lt-file: could not find any magic files! make[2]: *** [magic.mgc] Error 255 make[2]: Leaving directory `/var/tmp/portage/file-4.12/work/file-4.12/magic' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/file-4.12/work/file-4.12' make: *** [all] Error 2 I'm setting this major as it blocks updating world. Reproducible: Always Steps to Reproduce: 1. emerge file 1a: emerge -uDavt world 3. Actual Results: see listing of details Expected Results: Compiled and installed file-4.12 Portage 2.0.51-r15 (default-linux/x86/2004.3, gcc-3.3.5, glibc-2.3.4.20040808-r1, 2.6.10-gentoo-r4 i686) ================================================================= System uname: 2.6.10-gentoo-r4 i686 Intel(R) Xeon(TM) CPU 3.06GHz Gentoo Base System version 1.4.16 Python: dev-lang/python-2.1.3-r1,dev-lang/python-2.2.3-r5,dev-lang/python-2.3.4-r1 [2.3.4 (#1, Feb 10 2005, 19:57:22)] ccache version 2.3 [enabled] dev-lang/python: 2.1.3-r1, 2.2.3-r5, 2.3.4-r1 sys-devel/autoconf: 2.59-r6, 2.13 sys-devel/automake: 1.5, 1.6.3, 1.9.4, 1.8.5-r3, 1.4_p6, 1.7.9-r1 sys-devel/binutils: 2.15.92.0.2-r1 sys-devel/libtool: 1.5.10-r4 virtual/os-headers: 2.4.21-r1 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O2 -march=pentium4 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/web2c /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=pentium4 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig buildpkg ccache distlocks sandbox sfperms" GENTOO_MIRRORS="ftp:///ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ http://ftp.du.se/pub/os/gentoo http://ftp.ntua.gr/pub/linux/gentoo/" MAKEOPTS="-j5" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X acl apache2 apm arts avi bash-completion berkdb bitmap-fonts bonobo crypt cups curl encode esd f77 fam flac font-server foomaticdb fortran gdbm gif gnome gpm gstreamer gtk gtk2 imagemagick imlib ipv6 java jpeg junit kde ldap libg++ libwww mad mikmod motif mozilla moznoirc mpeg mysql ncurses nls oggvorbis opengl oss pam pdflib perl png postgres python qt quicktime readline samba sasl sdl slang snmp spell ssl svga tcltk tcpd tetex tiff truetype truetype-fonts type1-fonts xml xml2 xmms xv zlib linguas_de linguas_en" Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS, PORTDIR_OVERLAY
can you try with MAKEOPTS=-j1 ?
Yup. Tried that, didn't help. :(
can you try this then please: `MAKEOPTS="-j1 -d" emerge file >& log` and post the log here as an attachment
Created attachment 51205 [details] Output of proposed emerge command
I stumbled upon this blocking bug while installing a fresh new stage 1 Gentoo system using a RedHat 9 rescue CD because the latest Gentoo LiveCD had some other blocking bugs at the SCSI and Megaraid levels. I've taken the time to analyze the bug and I came up with several conclusions. The short answer is that you have to unset LD_LIBRARY_PATH before using emerge. The long answer and the explanation that might induce some modifications to lower and more global levels of the Gentoo system is not that much more complicated. With regards to this particular issue, the make process uses the newly compiled file command to compile the magic file. At this stage though, the file command is actually a stub created by libtool that invokes a differently linked binary executable called lt-file. This scheme is supposed to make absolutely sure that the file command uses the newly compiled shared library libmagic.so.1 as opposed to using some version of the same library from the root system. Things start to go wrong when the system already has a version of this shared library installed and the LD_LIBRARY_PATH variable points to it. Due to the way libtool links the stub binary _and_ creates the stub calling script, the command ends up using the root shared library. Unsetting the variable fixes the lookup and under most circumstances, it doesn't affect any other components of the system. What happens is that libtool disregards the new elf binary DT_RUNPATH tag when setting DT_RPATH for hardcoding the path to the library. It neither uses --disable-new-dtags when linking the stub, nor does it prepare a local variant of the LD_LIBRARY_PATH variable since shlibpath_overrides_runpath is set to no for the linux profile. Both tags get set, RUNPATH invalidates RPATH and the LD variable is used instead. Now since unsetting the LD variable is not a definitive solution and while there are tons of places where this issue can be addressed for the package in question alone, the problem is global and can resurface at just about any level. Since I'm not yet a Gentoo specialist, I can only propose that this thing be addressed either at the global libtool level or at the ebuild level for tweaking the LD variable. Than again the LD variable may be of use to testers and developers while the behavior of libtool can be unambiguously defined so it'd probably be best to fix libtool rather than modify the user's environment. Looking at the libtool patches that portage can currently apply, I see fixes for path lookups at build time in case the linker is not given specific references to libraries but I don't see anything related to this particular issue. Could the libtool eclass be the place to fix this thing ? Daniel
*** Bug 83449 has been marked as a duplicate of this bug. ***
i broke out the magic subdir from the others ... this should crop up again ... the bundled libtool version is 1.4.2, so perhaps the next release will have updated libtool and allow this to not be an issue in the future ...
