| 1 |
On Wed, 2008-10-29 at 21:07 +0100, Stefan Hoelldampf wrote: |
| 2 |
> Hi, |
| 3 |
> |
| 4 |
> right now I'm having some trouble boostrapping Gentoo Prefix on RHEL4 |
| 5 |
> using amd64. |
| 6 |
|
| 7 |
I do not have an amd64 with RHEL4 where I could run Prefix, so I need to |
| 8 |
guess... |
| 9 |
|
| 10 |
> 1. Using sys-devel/gcc-4.2.4 the bootstrap process is working but e.g. |
| 11 |
> app-text/poppler-0.10.0 can not be emerged. I traced it down to a |
| 12 |
> $EPREFIX/usr/lib{,64} problem. r29645 removed the usr/lib64->lib |
| 13 |
> "multilib" symlink creation in scripts/bootstrap-prefix.sh. Therefore |
| 14 |
> libtool of poppler can not find $EPREFIX/usr/lib64 and eventually uses |
| 15 |
> /usr/lib64 |
| 16 |
|
| 17 |
Does poppler have some nonstandard libtool eventually? |
| 18 |
Or which compiler is used to ask for system libraries? |
| 19 |
|
| 20 |
> The following diff shows a formatted output of the library |
| 21 |
> paths of "gcc -print-search-dirs". The compiler takes $EPREFIX/usr/lib64 |
| 22 |
> only into account which does not exist without the symlink. Therefore |
| 23 |
> the old system library is used during linking. |
| 24 |
> |
| 25 |
> > --- normal.log |
| 26 |
> > +++ with-symlink.log |
| 27 |
<snip> |
| 28 |
|
| 29 |
Seems your gcc-wrapper uses the host compiler, not the prefix one... |
| 30 |
|
| 31 |
> 2. Bootstrapping having gcc-4.3.2 unmasked fails when |
| 32 |
> sys-devel/gcc-4.3.2 is emerged for the first time. Although CPPFLAGS and |
| 33 |
> LDFLAGS are correctly set, the required and of course already emerged |
| 34 |
> libraries gmp and mpfr are not found. |
| 35 |
> binutils-config seems to be the root of this problem. Using |
| 36 |
> $EPREFIX/usr/x86_64-pc-linux-gnu/bin/ld (is this the binutils-config |
| 37 |
> wrapper?) the paths given by $LDFLAGS are not passed in the original |
| 38 |
> order to the "real" |
| 39 |
> $EPREFIX/usr/x86_64-pc-linux-gnu/binutils-bin/2.18.50.0.9/ld. |
| 40 |
> Eventually the gcc conftest.c for gmp/mpfr fails because the outdated |
| 41 |
> system libs /usr/lib64/lib{gmp,mpfr}.so are used for linking instead of |
| 42 |
> the ones from $EPREFIX/usr/lib. The following diff shows how the paths |
| 43 |
> are reordered when using the binutils-config wrapper instead of directly |
| 44 |
> calling the actual ld binary (output generated using some strace magic). |
| 45 |
> Is there a reason why the "-L$EPREFIX/..." parameters are moved to the |
| 46 |
> end of the list when using the ld wrapper? |
| 47 |
> |
| 48 |
> > --- real-ld.log |
| 49 |
> > +++ wrapper-ld.log |
| 50 |
<snip> |
| 51 |
> > +"/usr/lib/gcc/x86_64-redhat-linux"..., |
| 52 |
> > +"-rpath"..., |
| 53 |
> > +"$EPREFIX/usr/x86_64-pc-linux-"..., |
| 54 |
|
| 55 |
Seems your host compiler uses prefix ld-wrapper, or some similar mixups. |
| 56 |
|
| 57 |
HTH, |
| 58 |
/haubi/ |
| 59 |
-- |
| 60 |
Michael Haubenwallner |
| 61 |
Gentoo on a different level |
Archives