Ok, thank you anyways for the help!
Now, if I want to build a toolchain from ubuntu on my pc for raspbian on my raspberry, I need to set sysroot for arm-linux?
----------------------------------------
> Date: Wed, 18 Mar 2015 14:04:51 +0200
> From: kai.ruottu@xxxxxxxxxxx
> To: niccolo.ferrari@xxxxxxxxxx
> Subject: Re: Trying to build gcc cross compiler from linux to freebsd
>
> 18.3.2015, 4:15, Niccolò Ferrari kirjoitti:
>> Ok, sorry I sent you so many emails, but finally I compiled and installed with no errors the tool-chain!
>
> No worry, I sleeped while those came so I didn't even read them :)
>
>> The second problem was related to symlinks in sysroot path: they referenced to a absolute path obviously not valid on my system.
>
> I seemingly forgot this "only native" attitude in some systems. Some
> Linuces also have symlinks to the absolute
> '/lib' and '/lib64' or something in their installed glibcs. Building and
> installing a glibc from its sources however
> creates symlinks to the relative '../../lib*' and at least the Red Hat
> derivatives like Fedora and CentOS have used
> this default scheme. But the Debian and Ubuntu and probably also SuSE
> have used those absolute addresses. So
> they must be fixed in a crosscompiler. Only the startups (crt*.o) and
> basic libc/libm files will be automatically handled
> with the '--with-sysroot=' logic in GCC...
>
>> I solved the problem with a simple bash script:
>>
>> #!/bin/bash
>> for fff in `find . -type l ! -exec test -e {} \; -print`; do
>> echo "found link $fff"
>> if [ ! -e "$fff" ]; then
>> echo "found broken link $fff"
>> link=$(readlink "$fff")
>> echo "link $link"
>> rm "$fff"
>> echo "rm $fff"
>> ln -sf "$SYSROOT_PATH"/"$link" "$fff"
>> echo "link done"
>> fi
>> done
>> exit 0
>>
>> I don't know if there are more elegant way to do this, but now, with this script it worked!
>> I tried also to compile a test.c and a test.cpp and run in freebsd.
>
> I used 'grep' to find the symlinks to the absolute '/lib' and then
> edited a script to fix the symlinks :
>
> ln -f -s ../../lib/libalias.so.7 libalias.so
> ln -f -s ../../lib/libavl.so.2 libavl.so
> ln -f -s ../../lib/libbegemot.so.4 libbegemot.so
> ln -f -s ../../lib/libbsdxml.so.4 libbsdxml.so
> ln -f -s ../../lib/libcam.so.6 libcam.so
> ln -f -s ../../lib/libcrypto.so.7 libcrypto.so
> ln -f -s ../../lib/libcrypt.so.5 libcrypt.so
> ln -f -s ../../lib/libctf.so.2 libctf.so
> ln -f -s ../../lib/libcxxrt.so.1 libcxxrt.so
> ln -f -s ../../lib/libdevstat.so.7 libdevstat.so
> ln -f -s ../../lib/libdtrace.so.2 libdtrace.so
> ln -f -s ../../lib/libedit.so.7 libedit.so
> ln -f -s ../../lib/libgcc_s.so.1 libgcc_s.so
> ln -f -s ../../lib/libgeom.so.5 libgeom.so
> ln -f -s ../../lib/libipsec.so.4 libipsec.so
> ln -f -s ../../lib/libipx.so.5 libipx.so
> ln -f -s ../../lib/libjail.so.1 libjail.so
> ln -f -s ../../lib/libkiconv.so.4 libkiconv.so
> ln -f -s ../../lib/libkvm.so.6 libkvm.so
> ln -f -s ../../lib/libmd.so.6 libmd.so
> ln -f -s ../../lib/libm.so.5 libm.so
> ln -f -s ../../lib/libncurses.so.8 libncurses.so
> ln -f -s ../../lib/libncursesw.so.8 libncursesw.so
> ln -f -s ../../lib/libnvpair.so.2 libnvpair.so
> ln -f -s ../../lib/libpcap.so.8 libpcap.so
> ln -f -s ../../lib/libreadline.so.8 libreadline.so
> ln -f -s ../../lib/libsbuf.so.6 libsbuf.so
> ln -f -s ../../lib/libssp.so.0 libssp.so
> ln -f -s ../../lib/libthr.so.3 libthr.so
> ln -f -s ../../lib/libufs.so.6 libufs.so
> ln -f -s ../../lib/libulog.so.0 libulog.so
> ln -f -s ../../lib/libumem.so.2 libumem.so
> ln -f -s ../../lib/libutil.so.9 libutil.so
> ln -f -s ../../lib/libuutil.so.2 libuutil.so
> ln -f -s ../../lib/libzfs_core.so.2 libzfs_core.so
> ln -f -s ../../lib/libzfs.so.2 libzfs.so
> ln -f -s ../../lib/libzpool.so.2 libzpool.so
> ln -f -s ../../lib/libz.so.6 libz.so
>
> I compared this with the earlier one for FreeBSD 7.2 for x86_64 and
> seemingly all the shared library names
> (in '/lib) were changed so editing the earlier script wouldn't have made
> the task much quicker (maybe 5-10
> minutes used to create this). Maybe your script to automatically edit
> those wrong symlinks could be better...
>
> My old 32-bit AthlonXP 2.8 GHz PC with CentOS 5.11 Linux is just now
> compiling the libstdc++-v3 part in
> gcc-4.9.2, no problems this far....
>
> I unpacked only the 'base.txz' and 'lib32.txz' packages and seemingly in
> them is quite a lot unnecessary
> stuff. The '/usr/bin/cc' didn't seem to be GCC at all, I tried to see
> which extra configure options the
> "native GCC for FreeBSD 10.1 / x86_64" had used but when there wasn't
> that, I just used the basic
> options and trusted the system's defaults to be OK....
>
> BTW. The build here went trough without any problems. Here my configure
> options can be seen :
>
> [root@localhost ~]# x86_64-freebsd10.1-gcc-4.9 -v
> Using built-in specs.
> COLLECT_GCC=x86_64-freebsd10.1-gcc-4.9
> COLLECT_LTO_WRAPPER=/opt/cross/lib/gcc/x86_64-freebsd10.1/4.9.2/lto-wrapper
> Target: x86_64-freebsd10.1
> Configured with: ../configure --build=i686-linux-gnu
> --host=i686-linux-gnu --target=x86_64-freebsd10.1 --prefix=/opt/cross
> --libdir=/opt/cross/lib --libexecdir=/opt/cross/lib
> --with-sysroot=/opt/host-FreeBSD10.1_x86_64 --enable-languages=c,c++
> --enable-shared --enable-threads=posix --disable-nls
> --enable-version-specific-runtime-libs
> --with-gxx-include-dir=/opt/cross/include/c++/4.9.2
> --program-prefix=x86_64-freebsd10.1- --program-suffix=-4.9
> Thread model: posix
> gcc version 4.9.2 (GCC by Kai Ruottu)
>
