After bumping to lasted version of the slot which is identical to the normal tree version, gcc cannot compile anymore with the error in topic. Could it be that the keywording is wrong and we should stick to the specific prefix version? Or problem with the eclass import?
the eclass is vital in this, so I suspect this bug is invalid
Also an rebuild of 4.52 also gives a broken compiler. Where could the problem be?
(In reply to comment #1) > the eclass is vital in this, so I suspect this bug is invalid I didn't do anything to the eclass. Simple emerge --sync.
slot 4.4 can be compiled to a working state, slot 4.5 not.
After some testing, it seems to be the 4.5 slot
Doing the same procedures with other slots let the thing create a working compiler.
can you tell me what you mean exactly with "after bumping to lasted version of the slot ..."? did you do something, or did I/we do something? The ChangeLog doesn't reveal much changes for a while
I didn't update for more then a month or two now. what I did emerge --sync emerge -e1 system Most probably I was with the last gcc:4.5 real prefix version at that time. As soon as gcc was rebuilt nothing compiled anymore. Luckily I had still slot 4.1 installed so I can try. Building 4.4 and 4.5 succeeds with 4.1 and 4.4, but 4.5 doesn't work with the missing lib error. But it is installed in the correct path.
(In reply to comment #8) > Building 4.4 and 4.5 succeeds with 4.1 and 4.4, but 4.5 doesn't work with > the missing lib error. But it is installed in the correct path. Of course, gcc-config and the sourcing of the profile was done properly.
how about 4.6.3? I'm leaning towards skipping figuring out why, if 4.6.3 works fine
(In reply to comment #10) > how about 4.6.3? I'm leaning towards skipping figuring out why, if 4.6.3 > works fine Its the same. But there seems to be something else being broken. The problem is that parts of gcc get installed in lib others into lib64.
So I am coming closer the config log says those two things: | | # If user did not specify libdir, guess the correct target: | # Use lib64 for 64 bit targets, keep the default for the rest. | if test "$libdir" = '${exec_prefix}/lib' ; then | | # Running with linux32: | # (Changes detected platform, but not the toolchain target.) | case "`/bin/uname -i`" in | x86_64 | ppc64 | s390x ) | ;; | * ) | ac_config_site_32bit_target=YES | ;; | esac | | if test "x$ac_config_site_32bit_target" = xNONE; then | libdir='${exec_prefix}/lib64' | fi | fi On gentoo uname -i says "GenuineIntel" on suse it says "x86_64". Probably we should always pass libdir to work around the detection.
(In reply to comment #12) > On gentoo uname -i says "GenuineIntel" on suse it says "x86_64". Is this your VM still?
(In reply to comment #13) > (In reply to comment #12) > > > On gentoo uname -i says "GenuineIntel" on suse it says "x86_64". > > Is this your VM still? Right, but a clean one. New installation before creating the prefix.
This bug report is still pointless then, your VM is not matching physical hardware... % cat /etc/SuSE-release SUSE Linux Enterprise Server 11 (x86_64) VERSION = 11 PATCHLEVEL = 2 % uname -i GenuineIntel
But shouldn't I be able to use prefix in VMs? I checked a couple and it seems that only on gentoo VMs everything is fine. Other OS like Suse or Centos return the arch instead of the platform with -i.
(In reply to comment #16) > But shouldn't I be able to use prefix in VMs? Sure, but I consider your VM solution to be not emulating physical hardware properly. You should fix that *or* get upstream to make accommodations for you. In other words, "we" cannot make special hacks for every virtual solution if the virtual solution doesn't emulate the physical hardware properly. Anyway, that is just my opinion. In any case, please attach some patches that you would like to see implemented for review.
I'd wonder if this is related to this patch being applied to coreutils in gentoo: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/src/patchsets/coreutils/8.17/003_all_coreutils-gentoo-uname.patch?view=markup
(In reply to comment #18) > I'd wonder if this is related to this patch being applied to coreutils in > gentoo: > http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/src/patchsets/coreutils/ > 8.17/003_all_coreutils-gentoo-uname.patch?view=markup Doh, thanks Michael. Justin, you can safely ignore my comments on this thread. On my physical SuSE host, I was using the gentoo coreutils, not native. Sorry about that. % cat /etc/SuSE-release SUSE Linux Enterprise Server 11 (x86_64) VERSION = 11 PATCHLEVEL = 2 % /bin/uname -i x86_64
Okay, I think then the real deep problem is that autotools are using uname -i to get platform information which is bad. Can we do something against this? Gentoo wide?
1) is this a problem on Gentoo Linux in a VM (if yes, make it a gcc-herd bug) 2) if not, does it fix it if we epatch_exclude that 003_* patch from coreutils for Prefix I hope 1) because that would make more sense to me
(In reply to comment #21) > 1) is this a problem on Gentoo Linux in a VM (if yes, make it a gcc-herd bug) gentoo Linux VMs report correctly e.g "GenuineIntel"
A few things in question I can see here about what is correct: * Output of "uname -i" is different in Gentoo (Linux+Prefix), we do this: http://lists.gnu.org/archive/html/bug-coreutils/2005-09/msg00063.html * The idea behind $ac_config_site_32bit_target in gcc (comment#12) * Intention for using "uname -i" rather than "uname -p" (in comment#12) * Correct value of $ac_config_site_32bit_target for Prefix (no multilib)
Err: (In reply to comment #23) > A few things in question I can see here about what is correct: > * Output of "uname -i" is different in Gentoo (Linux+Prefix), we do this: > http://lists.gnu.org/archive/html/bug-coreutils/2005-09/msg00063.html This is even true for "uname -p". > * The idea behind $ac_config_site_32bit_target in gcc (comment#12) > * Intention for using "uname -i" rather than "uname -p" (in comment#12) It is "uname -m" being consistent across distros: $ uname -m; linux32 uname -m x86_64 i686 > * Correct value of $ac_config_site_32bit_target for Prefix (no multilib)
*** Bug 427210 has been marked as a duplicate of this bug. ***
We do not use gcc-4.5 any more in Prefix: Still a problem with current gcc (>=5.3)?
