Summary: | x86_64-linux-uclibc target fails when the host is multilib based | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Jimmy.Jazz |
Component: | [OLD] Development | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | andrew.frink, contact, nbowler |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | gcc log file |
Description
Jimmy.Jazz
2008-10-29 15:57:57 UTC
Created attachment 170230 [details]
gcc log file
The result: # PORTDIR_OVERLAY=/usr/portage/local/crossdev crossdev --k 2.6.27-r2 --g 4.3.2 --b 2.19.50.0.1 --l 0.9.30_rc3 --target x86_64-pc-linux-uclibc -vp * Restoring user setting 'UCLIBC_CPU' to 'K7' * Restoring user setting 'USE' to 'ipv6 savedconfig -iconv -uclibc-compat ' * Restoring user setting 'CFLAGS' to '-Os -pipe' ------------------------------------------------------------------------------------------------------------ * Host Portage ARCH: amd64 * Target Portage ARCH: amd64 * Target System: x86_64-pc-linux-uclibc * Stage: 4 (C/C++ compiler) * binutils: binutils-2.19.50.0.1 * gcc: gcc-4.3.2 * headers: linux-headers-2.6.27-r2 * libc: uclibc-0.9.30_rc3 * PORTDIR_OVERLAY: /usr/portage/local/crossdev * PORT_LOGDIR: /var/log/ebuild * PKGDIR: /usr/portage/packages/cross/x86_64-pc-linux-uclibc * PORTAGE_TMPDIR: /var/tmp/cross/x86_64-pc-linux-uclibc _ - ~ - _ - ~ - _ - ~ - _ - ~ - _ - ~ - _ - ~ - _ - ~ - _ - ~ - _ - ~ - rm: ne peut enlever `/usr/portage/local/crossdev/cross-x86_64-pc-linux-uclibc/uclibc': est un dossier ln: création d'un lien symbolique `/usr/portage/local/crossdev/cross-x86_64-pc-linux-uclibc/uclibc/uclibc': Le fichier existe * Forcing the latest versions of {binutils,gcc}-config/gnuconfig ... [ ok ] * Log: /var/log/ebuild/cross-x86_64-pc-linux-uclibc-binutils.log * Emerging cross-binutils ... These are the packages that would be merged, in order: Total: 0 packages, Size of downloads: 0 kB [ ok ] * Log: /var/log/ebuild/cross-x86_64-pc-linux-uclibc-linux-headers-quick.log * Emerging cross-linux-headers-quick ... These are the packages that would be merged, in order: Total: 0 packages, Size of downloads: 0 kB [ ok ] * Log: /var/log/ebuild/cross-x86_64-pc-linux-uclibc-uclibc-headers.log * Emerging cross-uclibc-headers ... These are the packages that would be merged, in order: Total: 0 packages, Size of downloads: 0 kB [ ok ] * Log: /var/log/ebuild/cross-x86_64-pc-linux-uclibc-gcc-stage1.log * Emerging cross-gcc-stage1 ... These are the packages that would be merged, in order: Total: 0 packages, Size of downloads: 0 kB [ ok ] * Log: /var/log/ebuild/cross-x86_64-pc-linux-uclibc-linux-headers.log * Emerging cross-linux-headers ... These are the packages that would be merged, in order: Total: 0 packages, Size of downloads: 0 kB [ ok ] * Log: /var/log/ebuild/cross-x86_64-pc-linux-uclibc-uclibc.log * Emerging cross-uclibc ... These are the packages that would be merged, in order: Total: 0 packages, Size of downloads: 0 kB [ ok ] * Log: /var/log/ebuild/cross-x86_64-pc-linux-uclibc-gcc-stage2.log * Emerging cross-gcc-stage2 ... These are the packages that would be merged, in order: [ebuild R ] cross-x86_64-pc-linux-uclibc/gcc-4.3.2 USE="(multilib) nls (-altivec) -bootstrap -build -doc (-fixed-point) -fortran -gcj -gtk -hardened -ip28 -ip32r10k -libffi -mudflap -multislot (-n32) (-n64) -nocxx* -objc -objc++ -objc-gc -openmp -test -vanilla" 0 kB [1] Total: 1 package (1 reinstall), Size of downloads: 0 kB Portage tree and overlays: [0] /usr/portage [1] /usr/portage/local/crossdev [ ok ] x86_64 uclibc really has never been tested (In reply to comment #3) > x86_64 uclibc really has never been tested > It works well and the binaries are small. I'm pleased with x86_64 uclibc because I use it to generate small static executables for my initramfs filesystem. I could use i386 and even get smaller one but I prefer to have a full 64 bits system. crossdev was working well with uclibc 0.9.29, 2.18 binutils and 2.6.25 headers. I was even able to compile with 0.9.30_rc1 until I had the bad idea to crossdev -C everything. The binaries becomes even smaller. Now I'm getting the -lc message everytime I compile. I didn't find something useful on the net about it but few people have the same issue. I never emerged uclibc in a glibc environment directly with emerge -a uclibc. Does it harm /etc/ld.so.conf ? Is it possible ? Could you please confirm ? (In reply to comment #3) > x86_64 uclibc really has never been tested > I don't understand why gcc package built a 32bits version when uclibc libraries are 64bits only. The issue could have something to do with the multilib flag. Also, I recompiled the old toolchain/headers/uclibc packages that have been successful in the past but this time they failed. I don't have more success with i386-pc-linux-uclibc either :( I tried all sort of combinations and none of them is working. Also I don't understand the meaning of the comment, "# @multilib_dir@ is not really necessary, but sometimes it has # more uses than just a directory name." Does it say multilib_dirs are not necessary. Also, why not tell crossdev to compile with -m64 or --disable-multilib flags and ignore such multilib directories when the target is 64bits. Has someone tried to cross compile for sparc64 platform ? Has it worked ? Many things have changed in portage scripts as in toolchain eclasses since my last successful x86_64 cross-compilation. I was not able to alter them to make crossdev work again (it really has). When compiling i686-pc-linux-uclibc it is even worse. I have got the following message, cc1: error: CPU you selected does not support x86-64 instruction set cc1: error: CPU you selected does not support x86-64 instruction set CC ldso/ldso/ldso.oS ldso/ldso/ldso.c:1: error: CPU you selected does not support x86-64 instruction set AS ldso/ldso/i386/resolve.oS It looks like there is a real breakdown in the code. Please could someone confirm both issues. So I won't feel too much lonely :) i meant x86_64-uclibc has never been tested with the ebuilds. the uclibc port itself has of course been tested (i'm the one who ported it in the first place after all). (In reply to comment #7) > i meant x86_64-uclibc has never been tested with the ebuilds. the uclibc port > itself has of course been tested (i'm the one who ported it in the first place > after all). > I know very well that you are an active member of gentoo community and a lead developer on that project. Also, I'm glad to see you are still involved in :). I tried to find out what has turned wrong but the toolchain class has been too deeply altered since and it has become difficult to trace the issue. gcc 4.3.2 doesn't help either. The fact that I was able to upgrade the crossdev's toolchain and even build the last 1.12 busybox and uclibc 0.9.30 successfully (I could see that mdev block device generation as been corrected since :) is hard to understand.It was a really bad idea to run crossdev -C and refresh the x86_64-uclibc toolchain again. So... I'm stuck with that nasty stage 4 failure. I would be glad if you could give me any hints. Thanks *** Bug 312327 has been marked as a duplicate of this bug. *** *** Bug 322757 has been marked as a duplicate of this bug. *** Since the bug i filed got marked as a dupe of this bug, with the message "clear USE=multilib in your local package.use for now", i'll add this here. * cross-x86_64-gentoo-linux-uclibc/gcc-4.4.4-r1 still fails with the same error message. * The profile "default/linux/amd64/10.0/desktop" forces the multilib flag for me, and all other non "no-multilib" profiles do as well. I'm running a ~amd64 system. * As a "work around" you can add "cross-x86_64-gentoo-linux-uclibc/gcc -multilib" to "/etc/portage/profile/package.use.force" and "/etc/portage/package.use". GCC with uclibc compiled and installed and builds binaries just fine after the addition of -multilib in the files mentioned above. *** Bug 343423 has been marked as a duplicate of this bug. *** the latest crossdev controls multilib, so this should be fixed implicitly |