[Clfs-support] gcc-4.8.0 clfs

[Martin Ward]

On 27/05/13 13:48, bvl wrote:
> On Sunday 26 May 2013 15:33:35 Martin Ward wrote:
>> That sounds like where the problem lies, a misconfiguration of eglibc
>> some where along the line?
> I have redone the build this time leaving out ppl.  Here are my findings:-
>
> ---CLooG-0.18.0 at 5.13 in the clfs book  ( prefix=/cross-tools compiles and

i use stand along isl with the following switches/flags

isl-0.11.2 LDFLAGS="-Wl,-rpath,/cross-tools/lib" ./configure 
--prefix=/cross-tools --with-gmp-prefix=/cross-tools

then cloog built as follows

cloog-0.18.0, LDFLAGS="-Wl,-rpath,/cross-tools/lib"      ./configure 
--prefix=/cross-tools --with-isl=system --with-gmp=system 
--with-gmp-prefix=/cross-tools --with-isl-prefix=/cross-tools
> installs )
> ---CLooG-0.18.0 at 6.7  in the clfs book  ( prefix=/tools  needs these
> switches
> LDFLAGS="-L/cross-tools/lib" LIBS="-lcloog-isl" )
i use a stand-alone isl again

isl-0.11.2 ok CC="${CC} ${BUILD64}" ./configure --prefix=/tools 
--build=${CLFS_HOST} --host=${CLFS_TARGET} --with-gmp-prefix=/tools
cloog-0.18.0 ok CC="${CC} ${BUILD64}" ./configure --prefix=/tools      
--build=${CLFS_HOST} --host=${CLFS_TARGET} --enable-shared 
--with-isl=system --with-gmp=system --with-gmp-prefix=/tools 
--with-isl-prefix=/tools

>
> #-----------snippet on typical make log file
> CC     libcloog_isl_la-constraints.lo
>    CC     libcloog_isl_la-backend.lo
> cd isl; make  libisl.la
> make[2]: Entering directory `/mnt/clfs/cloog-0.18.0/isl'
> make[2]: `libisl.la' is up to date.
> make[2]: Leaving directory `/mnt/clfs/cloog-0.18.0/isl'
>    CCLD   libcloog-isl.la
>    CC     cloog.o
>    CCLD   cloog
> make[1]: Leaving directory `/mnt/clfs/cloog-0.18.0'
> Making all in doc
> #--------------------------------
>
> #---------- eglibc built like so (from a dedicated build tree )
> cd eglibc-2_17SVNrv23140/libc
>
> if [ ! -r /usr/include/rpc/types.h ]; then
>    su -c 'mkdir -p /usr/include/rpc'
>    su -c 'cp -v sunrpc/rpc/*.h /usr/include/rpc'
> fi
not needed any-more  can use --enable-obsolete-rpc but i don't use that 
switch until chap 10.7
>
> cp -v Makeconfig{,.orig}
> sed -e 's/-lgcc_eh//g' Makeconfig.orig > Makeconfig
not needed eglibc from 2.17+ doesn't link against libgcc
>
> rm -fR  ../../eglibc-build
> mkdir -v ../../eglibc-build
> cd ../../eglibc-build
>
>
>
> cat > config.cache << "EOF"
> libc_cv_forced_unwind=yes
> libc_cv_c_cleanup=yes
> libc_cv_gnu89_inline=yes
> libc_cv_ssp=no
> EOF
>
>
> BUILD_CC="gcc" CC="${CLFS_TARGET}-gcc ${BUILD64}" \
> AR="${CLFS_TARGET}-ar" RANLIB="${CLFS_TARGET}-ranlib" \
> ../eglibc-2_17SVNrv23140/libc/configure \
> --prefix=/tools \
> --host=${CLFS_TARGET} \
> --build=${CLFS_HOST} \
> --disable-profile \
> --with-tls \
> --enable-kernel=2.6.25 \
> --with-headers=/tools/include    \
> --with-__thread \
> --with-binutils=/cross-tools/bin \
> --with-headers=/tools/include \
> --cache-file=config.cache
>
> #-------------
>
> builds and installs without errors.
>
> BUT a test before I mount   filesystem and try to chroot shows the old problem
> still remains. For instance:-
>
> readelf -e /tools/bin/env | grep interpreting
>
> returns
> Requesting program interpreter /tools/tools/lib/ld-linux-x86-64.so.2
> (In otherwords the problem has not been fixed and I should even bother trying
> to chroot )
>
> nb  I am using:-
> a)  eglibc the full svn tree but the libc branch
> b)  linux headers  from latest linux-3.10-rc2
>
> The host has clfs from 2010 (gcc-4.4.2, eglibc-2.10 kernel-3.0x)  But I have a
> build with eglibc-2.14, gcc-4.6,kernel-3.6x on the same machine.  Just as a
> test  I booted that one and mounted   the clfs partition and did the readelf
> test and the same thing resulted.
>
> It appears that   there is a problem with eglibc I either need some patches or
> a version (of eglibc-2.17)  that works. Perhaps if you post a copy of the
> eglibc-2.17 you used somwehere on the clfs site I could download it and have a
> go as eglibc-2.17rv23140 from eglibc.org may be problematic
never needed any patches at all, i used r22751 from svn, but your 
version should be ok
>
it does seem there is a problem with your symlinks somewhere along the line
regards

martin