| View previous topic :: View next topic |
| Author |
Message |
hansfn
n00b
Joined: 21 Nov 2017
Posts: 27
|
 Posted: Tue May 28, 2019 2:08 pm Post subject: crossdev - two toolchains for same target |
 |
|
I have used crossdev for RaspberryPi earlier and had no problems. Now, I'm in a situation that I need to build two toolchains (different versions of Glibc) for the same target. (Which target doesn't really matter). Is there anyway I can name the targets so that it works without hacking? In my understanding, the two toolchains will overwrite each other if the target is the same. I have read all the crossdev pages in the wiki and many forums posts, but I might of course have missed something obvious.
Another minor question: How do I get metadata about an existing cross-compiler? "<target>-emerge --info" didn't reveal much. I can of course look into "/var/db/pkg/cross-<target>" ... |
|
| Back to top |
|
 |
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54587
Location: 56N 3W
|
| Posted: Tue May 28, 2019 6:15 pm Post subject: |
|
|
hansfn,
For my arm64 cross tool chain on my amd64 host.
| Code: | aarch64-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=aarch64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/aarch64-unknown-linux-gnu/9.1.0/lto-wrapper
Target: aarch64-unknown-linux-gnu
Configured with: /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-9.1.0/work/gcc-9.1.0/configure --host=x86_64-pc-linux-gnu --target=aarch64-unknown-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/aarch64-unknown-linux-gnu/gcc-bin/9.1.0 --includedir=/usr/lib/gcc/aarch64-unknown-linux-gnu/9.1.0/include --datadir=/usr/share/gcc-data/aarch64-unknown-linux-gnu/9.1.0 --mandir=/usr/share/gcc-data/aarch64-unknown-linux-gnu/9.1.0/man --infodir=/usr/share/gcc-data/aarch64-unknown-linux-gnu/9.1.0/info --with-gxx-include-dir=/usr/lib/gcc/aarch64-unknown-linux-gnu/9.1.0/include/g++-v9 --with-python-dir=/share/gcc-data/aarch64-unknown-linux-gnu/9.1.0/python --enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 9.1.0 p1.0' --disable-esp --enable-libstdcxx-time --with-build-config=bootstrap-lto --enable-poison-system-directories --with-sysroot=/usr/aarch64-unknown-linux-gnu --disable-bootstrap --enable-__cxa_atexit --enable-clocale=gnu --disable-multilib --disable-altivec --disable-fixed-point --enable-libgomp --disable-libmudflap --disable-libssp --disable-systemtap --enable-vtable-verify --enable-lto --with-isl --disable-isl-version-check --enable-default-pie --enable-default-ssp
Thread model: posix
gcc version 9.1.0 (Gentoo 9.1.0 p1.0) |
I can only think of ugly ways to keep the cross toolchains apart, like put one in a chroot or a KVM
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
hansfn
n00b
Joined: 21 Nov 2017
Posts: 27
|
| Posted: Wed May 29, 2019 9:38 am Post subject: |
|
|
OK, I was really hoping to avoid ugly ways ... I maybe though I could abuse the vendor part by using "unknown" and <somethingelse>
Regarding "target-gcc -v": I don't see that it reports the Glibc version? |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22720
|
| Posted: Thu May 30, 2019 2:05 am Post subject: |
|
|
| Correct, gcc does not report the glibc version and generally has no special dependency on it. Your glibc version issue is probably because of an oddity that programs built with a new glibc refuse to run with an older glibc, even if they aren't actually using any features from the new glibc. |
|
| Back to top |
|
|
|
Portage & Programming
