Bugzilla Bug 81974

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