View previous topic :: View next topic |
Author |
Message |
elvanor Developer
Joined: 11 Oct 2004 Posts: 178 Location: France
|
Posted: Tue Sep 05, 2006 5:37 pm Post subject: sandbox emerge problem on amd64 (should fix the ebuild) |
|
|
Hello,
On AMD64 I was trying to update to gcc-4.1.1. Everything went smoothly (glibc 2.4 emerged ok) except sandbox that is refusing to emerge. I was doing a emerge -ea system and this was the only package out of 279 that refused to install. I have the following problem:
Quote: |
* Configuring sandbox for ABI=x86...
* econf: updating sandbox-1.2.17/config.guess with /usr/share/gnuconfig/config.guess
* econf: updating sandbox-1.2.17/config.sub with /usr/share/gnuconfig/config.sub
../sandbox-1.2.17//configure --prefix=/usr --host=i686-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --libdir=/usr/lib32 --enable-multilib --build=i686-pc-linux-gnu
checking for a BSD-compatible install... /bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for i686-pc-linux-gnu-gcc... i686-pc-linux-gnu-gcc
checking for C compiler default output file name... configure: error: C compiler cannot create executables
|
Here is attached the relevant files of the config.log:
Quote: |
configure:1533: checking for a BSD-compatible install
configure:1588: result: /bin/install -c
configure:1599: checking whether build environment is sane
configure:1642: result: yes
configure:1707: checking for gawk
configure:1723: found /bin/gawk
configure:1733: result: gawk
configure:1743: checking whether make sets $(MAKE)
configure:1763: result: yes
configure:1942: checking for i686-pc-linux-gnu-gcc
configure:1958: found /usr/bin/i686-pc-linux-gnu-gcc
configure:1968: result: i686-pc-linux-gnu-gcc
configure:2250: checking for C compiler version
configure:2253: i686-pc-linux-gnu-gcc --version </dev/null >&5
gcc-config error: i686-pc-linux-gnu-gcc wrapper: Unable to determine executable.
CTARGET=i686-pc-linux-gnu
exec=gcc
configure:2256: $? = 1
configure:2258: i686-pc-linux-gnu-gcc -v </dev/null >&5
gcc-config error: i686-pc-linux-gnu-gcc wrapper: Unable to determine executable.
CTARGET=i686-pc-linux-gnu
exec=gcc
configure:2261: $? = 1
configure:2263: i686-pc-linux-gnu-gcc -V </dev/null >&5
gcc-config error: i686-pc-linux-gnu-gcc wrapper: Unable to determine executable.
CTARGET=i686-pc-linux-gnu
exec=gcc
configure:2266: $? = 1
configure:2289: checking for C compiler default output file name
configure:2292: i686-pc-linux-gnu-gcc -O2 -pipe -march=k8 -fomit-frame-pointer conftest.c >&5
gcc-config error: i686-pc-linux-gnu-gcc wrapper: Unable to determine executable.
CTARGET=i686-pc-linux-gnu
exec=gcc
configure:2295: $? = 1
configure: failed program was:
|
As you see, the problem is that it is using i686-pc-linux-gnu-gcc and not x86_64-pc-linux-gnu-gcc as it probably should. I've checked things and it comes from the --host=i686-pc-linux-gnu passed to the configure program. Indeed if I remove this host thing sandbox compiles perfectly in its own directory (as reported the last user in https://forums.gentoo.org/viewtopic-t-485514.html).
Since I still wanted to use Portage to install sandbox, I've renamed the i686-pc-linux-gnu-gcc program found in /usr/bin. If you do so, the configure script simply uses "gcc" and then it finds the correct program (or profile).
I've done a equery belongs i686-pc-linux-gnu-gcc and it finds nothing, so this is strange... Maybe this is a file left over from the stage3 tarball or something? I don't know, but I'd like to know if it's safe to just simply remove all i686-pc-linux-gnu-* in /usr/bin ?
In case it's not, someone should fix the ebuild so that it doesn't not add the --host stuff.
Elvanor |
|
Back to top |
|
|
AlecTavi n00b
Joined: 21 Jul 2005 Posts: 18 Location: Washington, DC
|
Posted: Tue Sep 05, 2006 7:33 pm Post subject: |
|
|
I ran into this same issue with my upgrade from GCC 3.4.6 to 4.1.1. Removing the i686-specific files worked to fix the problem. I had them because I use my box to cross-compile in distcc. A simple crossdev -C i686-pc-linux-gnu solved the problem, but this should be fixed in the ebuild. Take a look at bug this bug: https://bugs.gentoo.org/show_bug.cgi?id=133209. Sandbox is doing something weird to determine it's target architecture. |
|
Back to top |
|
|
dusik Tux's lil' helper
Joined: 04 Jan 2005 Posts: 129 Location: Durham, NC, USA
|
Posted: Wed Sep 06, 2006 2:24 pm Post subject: |
|
|
I've got the same problem, and it's really confusing to me. I'm also running an amd64 system, and when I try to emerge sandbox it does mention:
Code: | * Configuring sandbox for ABI=x86... |
Looking in the sandbox ebuild, it actually looks like it's intentional (due to multilib):
Code: | if use amd64 && has_m32 && [[ ${CONF_MULTILIBDIR} == "lib32" ]]; then
export DEFAULT_ABI="amd64"
export MULTILIB_ABIS="x86 amd64"
export CFLAGS_amd64=${CFLAGS_amd64:-"-m64"}
export CFLAGS_x86=${CFLAGS_x86-"-m32 -L/emul/linux/x86/lib -L/emul/linux/x86/usr/lib"}
export CHOST_amd64="x86_64-pc-linux-gnu"
export CHOST_x86="i686-pc-linux-gnu"
export LIBDIR_amd64=${LIBDIR_amd64-${CONF_LIBDIR}}
export LIBDIR_x86=${LIBDIR_x86-${CONF_MULTILIBDIR}}
fi |
The old gcc had a multilib USE flag, I think, but it doesn't show up in --pretend 4.1.1:
Code: | $ emerge -pv gcc
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild R ] sys-devel/gcc-4.1.1 USE="fortran gtk multislot nls -bootstrap -build -doc -gcj -hardened -ip28 -ip32r10k -mudflap -nocxx -objc -objc++ -objc-gc -test -vanilla" 0 kB |
On the other hand, I get:
Code: | $ equery hasuse multilib
[ Searching for USE flag multilib in all categories among: ]
* installed packages
[I--] [ -] sys-libs/glibc-2.4-r3 (2.2)
[I--] [ -] sys-devel/gcc-3.4.6-r1 (x86_64-pc-linux-gnu-3.4.6)
[I--] [ ] sys-devel/gcc-3.4.5 (x86_64-pc-linux-gnu-3.4.5)
[I--] [ -] sys-devel/gcc-4.1.1 (x86_64-pc-linux-gnu-4.1.1)
|
So it must be implicit, which means I can't turn it off? I haven't been able to figure out the gcc ebuild itself yet. So, what is multilib good for anyway? I don't cross-compile for other systems. Does wine use it? (Wine compiles fine for me, though.)
And, most unfortunately, the actual error that stops the ebuild can be reproduced simply by:
Code: | $ i686-pc-linux-gnu-gcc
gcc-config error: i686-pc-linux-gnu-gcc wrapper: Could not determine which compiler to use. Invalid CTARGET or CTARGET has no selected profile. |
I can't figure this one out. The x86_64 compiler was at first giving me these too, but reemerging gcc-config fixed that for some reason. I noticed that i686- doesn't have symlinks like x86_64- does in /usr/bin:
Code: | $ ls -l /usr/bin/*gcc*
-rwxr-xr-x 1 root root 11416 2006-09-05 00:52 /usr/bin/gcc
-rwxr-xr-x 1 root root 11416 2006-09-05 00:52 /usr/bin/gcc32
lrwxrwxrwx 1 root root 62 2006-03-23 23:34 /usr/bin/gcc-3.4.5 -> /usr/x86_64-pc-linux-gnu/gcc-bin/3.4.5/x86_64-pc-linux-gnu-gcc
lrwxrwxrwx 1 root root 62 2006-06-28 15:51 /usr/bin/gcc-3.4.6 -> /usr/x86_64-pc-linux-gnu/gcc-bin/3.4.6/x86_64-pc-linux-gnu-gcc
lrwxrwxrwx 1 root root 62 2006-09-05 00:52 /usr/bin/gcc-4.1.1 -> /usr/x86_64-pc-linux-gnu/gcc-bin/4.1.1/x86_64-pc-linux-gnu-gcc
-rwxr-xr-x 1 root root 11416 2006-09-05 00:52 /usr/bin/gcc64
-rwxr-xr-x 1 root root 18888 2005-12-06 03:04 /usr/bin/gccbug
-rwxr-xr-x 1 root root 18567 2006-09-04 23:54 /usr/bin/gcc-config
-rwxr-xr-x 1 root root 2038 2006-07-03 13:08 /usr/bin/gccmakedep
-rwxr-xr-x 1 root root 18888 2005-12-06 03:04 /usr/bin/i686-pc-linux-gnu-gcc
-rwxr-xr-x 1 root root 18888 2005-12-06 03:04 /usr/bin/i686-pc-linux-gnu-gccbug
-rwxr-xr-x 1 root root 22636 2006-09-06 01:01 /usr/bin/winegcc
-rwxr-xr-x 1 root root 11416 2006-09-05 00:52 /usr/bin/x86_64-pc-linux-gnu-gcc
-rwxr-xr-x 1 root root 11416 2006-09-05 00:52 /usr/bin/x86_64-pc-linux-gnu-gcc32
lrwxrwxrwx 1 root root 62 2006-03-23 23:34 /usr/bin/x86_64-pc-linux-gnu-gcc-3.4.5 -> /usr/x86_64-pc-linux-gnu/gcc-bin/3.4.5/x86_64-pc-linux-gnu-gcc
lrwxrwxrwx 1 root root 62 2006-06-28 15:51 /usr/bin/x86_64-pc-linux-gnu-gcc-3.4.6 -> /usr/x86_64-pc-linux-gnu/gcc-bin/3.4.6/x86_64-pc-linux-gnu-gcc
lrwxrwxrwx 1 root root 62 2006-09-05 00:52 /usr/bin/x86_64-pc-linux-gnu-gcc-4.1.1 -> /usr/x86_64-pc-linux-gnu/gcc-bin/4.1.1/x86_64-pc-linux-gnu-gcc
-rwxr-xr-x 1 root root 11416 2006-09-05 00:52 /usr/bin/x86_64-pc-linux-gnu-gcc64
-rwxr-xr-x 1 root root 18888 2005-12-06 03:04 /usr/bin/x86_64-pc-linux-gnu-gccbug |
What gives? |
|
Back to top |
|
|
elvanor Developer
Joined: 11 Oct 2004 Posts: 178 Location: France
|
Posted: Wed Sep 06, 2006 4:49 pm Post subject: |
|
|
Remove the i686 gcc programs in /usr/bin, and it'll work. |
|
Back to top |
|
|
dusik Tux's lil' helper
Joined: 04 Jan 2005 Posts: 129 Location: Durham, NC, USA
|
Posted: Wed Sep 06, 2006 5:05 pm Post subject: |
|
|
elvanor wrote: | Remove the i686 gcc programs in /usr/bin, and it'll work. |
Ok, it worked. So are /usr/bin/i686-pc-linux-gnu-gcc* orphaned files from previous GCC versions? (I'm always worried about simply deleting a file in Gentoo)
Also, I'm still having the same problem with gfortran:
Code: | $ gfortran
gcc-config error: gfortran wrapper: Could not determine which compiler to use. Invalid CTARGET or CTARGET has no selected profile. |
So, sounds like it would be ok to remove that too? Should I remove /usr/bin/i686-*? |
|
Back to top |
|
|
elvanor Developer
Joined: 11 Oct 2004 Posts: 178 Location: France
|
Posted: Thu Sep 07, 2006 4:44 pm Post subject: |
|
|
I think that yes they are orphaned files from previous gcc versions. I moved them out of /usr/bin into a backup folder just in case, but I think they are really useless (I recompiled my whole world without problem without them).
You should also delete gfortran, yes, I had that problem too and it was blocking the emerge of fftw. Removing x86_64-pc-linux-gnu-gfrotran fixed the problem (I left only x86_64-pc-linux-gnu-gfrotran-4.1.1). |
|
Back to top |
|
|
Bigun Advocate
Joined: 21 Sep 2003 Posts: 2196
|
Posted: Fri Oct 20, 2006 6:17 pm Post subject: |
|
|
elvanor wrote: | Remove the i686 gcc programs in /usr/bin, and it'll work. |
Thank you thank you thank you thank you
*bookmarked* _________________ "It's ok, they might have guns but we have flowers." - Perpetual Victim |
|
Back to top |
|
|
moewe2 n00b
Joined: 12 Sep 2005 Posts: 3
|
Posted: Sun Nov 11, 2007 5:05 pm Post subject: Yeah! |
|
|
AlecTavi wrote: | I ran into this same issue with my upgrade from GCC 3.4.6 to 4.1.1. Removing the i686-specific files worked to fix the problem. I had them because I use my box to cross-compile in distcc. A simple crossdev -C i686-pc-linux-gnu solved the problem, but this should be fixed in the ebuild. Take a look at bug this bug: https://bugs.gentoo.org/show_bug.cgi?id=133209. Sandbox is doing something weird to determine it's target architecture. |
This did it - after a long day of searching a solution! |
|
Back to top |
|
|
ACDChook n00b
Joined: 05 Jan 2008 Posts: 2 Location: Geraldton, Western Australia
|
Posted: Sat Jan 05, 2008 10:51 am Post subject: |
|
|
Just an update on this bug. I've had this problem for ages, but have never been running a multilib system, and have not had any i686* files in /usr/bin to delete. I discovered today that my /etc/make.profile symlink was pointing to the /usr/portage/profiles/default-linux/amd64/2007.0/desktop profile instead of the /usr/portage/profiles/default-linux/amd64/2007.0/no-multilib profile. I corrected the symlink and sandbox compiles fine, and uses the x86_64* files instead of i686*. |
|
Back to top |
|
|
|