Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Cross-compiling problem on SGI O2
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Gentoo on Alternative Architectures
View previous topic :: View next topic  
Author Message
iMike
Apprentice
Apprentice


Joined: 01 Apr 2005
Posts: 208
Location: Stockholm, Sweden

PostPosted: Thu Dec 27, 2007 10:18 am    Post subject: Cross-compiling problem on SGI O2 Reply with quote

I have successfully installed gentoo on an SGI O2 awhile back, but apparently have forgotten a trick or two. I was following the manual, so installed sys-devel/kgcc64-4.1.2, made sure cross-compile was turned OFF in the kernel configure, but then got the following when trying to build the most recent mips-sources (linux-2.6.20.18-20070902):
Code:
livecd linux # make vmlinux.32 CROSS_COMPILE=mips64-unknown-linux-gnu-
  CHK     include/linux/version.h
  CHK     include/linux/utsrelease.h
  CHK     include/linux/compile.h
dnsdomainname: Unknown host
  LD      init/mounts.o
mips64-unknown-linux-gnu-ld: cannot open linker script file ldscripts/elf64btsmip.xr: No such file or directory
make[1]: *** [init/mounts.o] Error 1
make: *** [init] Error 2

So should one NOT specify CROSS_COMPILE then?

In the chrooted environment, I have:
Code:
livecd linux # gcc-config -l
 [1] mips-unknown-linux-gnu-4.1.1 *
 [2] mips64-unknown-linux-gnu-4.1.2 *


Thanks for any advice.
/iMike
Back to top
View user's profile Send private message
Redhatter
Retired Dev
Retired Dev


Joined: 20 Sep 2003
Posts: 548
Location: Brisbane, QLD, Australia

PostPosted: Tue Jan 01, 2008 10:38 am    Post subject: Reply with quote

This is apparently caused by a broken version of binutils-config. Update that, then use it to re-select your cross-binutils and try again.
_________________
Stuart Longland (a.k.a Redhatter, VK4MSL)
I haven't lost my mind - it's backed up on a tape somewhere...

Gentoo/MIPS Cobalt developer, Mozilla herd member.
Back to top
View user's profile Send private message
iMike
Apprentice
Apprentice


Joined: 01 Apr 2005
Posts: 208
Location: Stockholm, Sweden

PostPosted: Wed Jan 02, 2008 2:44 pm    Post subject: Reply with quote

I think you are right about the broken binutils-config, and now my entire install seems to be borked. This was a fresh install that worked after following the steps of the manual up to and including the point of booting into the kernel (arcload) and then starting an update of the entire system. I was doing this on a couple of O2s and I know that one died during an overall update (emerge -vauDN world) after updating openssl. On that machine I get floating point exception when trying to do env-update. This traces to a python dload of an ssl .so file, which I suspect was incorrectly compiled in the wrong ENDIAN. Perhaps an ENDIAN problem also got the machine where I tried to install the 2.6.20 kernel (as detailed earlier).

I had picked the profile
Code:
default-linux/mips/2007.0/generic-be/o32/nptl
and my make.conf looked like:
Code:
CFLAGS="-mabi=32 -mips4 -pipe -O2"
CXXFLAGS="${CFLAGS}"
Did I blow it by not specifying
Code:
march=r5000
? Is there any recourse besides reinstalling from stage3-mips4-2007.0 and portage snapshot files?

Best regards,
/iMike
Back to top
View user's profile Send private message
Redhatter
Retired Dev
Retired Dev


Joined: 20 Sep 2003
Posts: 548
Location: Brisbane, QLD, Australia

PostPosted: Wed Jan 02, 2008 9:57 pm    Post subject: Reply with quote

I doubt endianness is the problem here. While yes, passing -LE to gcc will possibly yield a little endian binary, by default, a mips-unknown-linux-gnu compiler is big endian.

You can confirm this by running file /usr/lib/libssl.so.*, you'll see it's a "MSB" executable (Most Significant Byte first, aka big endian).

Floating-point exceptions are caused by broken compilers/assemblers and such. I'm not sure what's happened in your case, but you may be able to recover it by manually unpacking a tbz2 of openssl (tar -C / -xjvf foo.tbz2) from a known working BE MIPS system. Such binaries can be produced using quickpkg.
_________________
Stuart Longland (a.k.a Redhatter, VK4MSL)
I haven't lost my mind - it's backed up on a tape somewhere...

Gentoo/MIPS Cobalt developer, Mozilla herd member.
Back to top
View user's profile Send private message
iMike
Apprentice
Apprentice


Joined: 01 Apr 2005
Posts: 208
Location: Stockholm, Sweden

PostPosted: Thu Jan 03, 2008 4:14 pm    Post subject: Reply with quote

OK, thank you for the tip. I will try it.

Just to make it crystal clear for me.... when I emerge mips-sources-2.6.20.18, I get the message below. The question I have about that is the following: is the ugly hack referred to kgcc64, which implies we should be using plain old gcc for compiling the kernel (instead of kgcc), as on other platforms, or is it really just about the version of kgcc64, and thus implies that we should only use >= kgcc64-4.1.1 when compiling more recent kernels? Clarification would be helpful.

Although I have thus far just compiled the kernel on the O2, it would of course be much nicer to use a nearby and faster gentoo x86 or ppc32 for the job. Thus a different, but related question, would be: do I have to install kgcc64 on the x86 or ppc32 to cross-compile the kernel? If you only have time to answer one of these two questions, then this one is definitely secondary, as to work through the strange problem I had earlier I would just as soon keep all compiling on the O2 at least for starters.

Code:

* !!! BIG FAT WARNING
* !!! To Build 64bit kernels for SGI O2 (IP32) or SGI Indy/Indigo2 R4x00 (IP22)
* !!! systems, you _need_ to be using a >=gcc-4.1.1 compiler, have CONFIG_BUILD_ELF64
* !!! disabled in your kernel config, and building with the vmlinux.32 make target.
* !!! In prior times, an ugly hack was used to build an ELF64 binary that resembled
* !!! an ELF32 binary in order to make the ARCS PROMs on these systems boot the
* !!! kernel. This hack is no longer in use nor supported in 2.6.17 and beyond.  In
* !!! order to achieve the same effect, a new flag available in >=gcc-4.x is used,
* !!! and as such, makes >=gcc-4.1.1 the preferred compiler for 2.6.17 and beyond.
* !!! Remember, build your IP22 and IP32 kernels with the following command:
* !!! following make command: make vmlinux.32
* !!! Once done, copy the vmlinux.32 file and boot that.  [...]
Back to top
View user's profile Send private message
Redhatter
Retired Dev
Retired Dev


Joined: 20 Sep 2003
Posts: 548
Location: Brisbane, QLD, Australia

PostPosted: Fri Jan 04, 2008 11:28 pm    Post subject: Reply with quote

Okay, that message actually refers to kgcc64, the plain old gcc is 32-bit, and won't compile a 64-bit kernel correctly.

As for kgcc64 on other architectures. If you merge it on x86, AFAIK it generates a x86_64-pc-linux-gnu compiler, or on ppc32, it'd generate a ppc64 compiler. Not much use.

If you want a cross-compiler on your x86 box, look into a package called crossdev. crossdev -t mips64-unknown-linux-gnu -s1 should yield a toolchain similar to that produced by kgcc64 on the O2.
_________________
Stuart Longland (a.k.a Redhatter, VK4MSL)
I haven't lost my mind - it's backed up on a tape somewhere...

Gentoo/MIPS Cobalt developer, Mozilla herd member.
Back to top
View user's profile Send private message
ddc
Guru
Guru


Joined: 29 Aug 2006
Posts: 527

PostPosted: Sun Jan 06, 2008 1:12 pm    Post subject: Reply with quote

(I hope the soonest I can) I will be given by an O2 R5K as gift, so i will have to load gentoo to an O2, too
Back to top
View user's profile Send private message
armanox
n00b
n00b


Joined: 03 Jan 2008
Posts: 32
Location: Baltimore, MD

PostPosted: Sun Jan 06, 2008 11:14 pm    Post subject: Reply with quote

I've got the same problem listed above on an SGI Octane. Now that I know how to fix the issue, it should be smooth sailing for it.
Back to top
View user's profile Send private message
iMike
Apprentice
Apprentice


Joined: 01 Apr 2005
Posts: 208
Location: Stockholm, Sweden

PostPosted: Mon Jan 07, 2008 3:49 pm    Post subject: Reply with quote

It's gonna be interesting to see where this problem sneaks in. I was doing as standard (i.e., by-the-manual) an install as possible. Thanks to emerge's logging I know what got updated and when things started going south.

Taking redhatter's advice, I braved it and got my system back to running. Without his advice, I'm sure I would have just started over, since having a broken toolchain seems like too bad a starting point for me without some expert advice. Specifically that I did was test a few commands and see what clearly wasn't working. I then did a quickpkg of these on a correctly working O2:
Code:

dewey ~ # ls -1 /usr/portage/packages/All/
binutils-2.17.tbz2
binutils-config-1.9-r4.tbz2
gcc-4.1.1-r3.tbz2
kgcc64-4.1.1.tbz2
openssl-0.9.8d.tbz2
util-linux-2.12r-r7.tbz2

and scp'ed them over to the broken machine running the livecd. I unpacked them to /mnt/gentoo and chrooted in. Next I reset the compilers with gcc-config and the binary utilitities with binutils-config, rebuilt libtool, and proceeded to re-try and build the 2.6.22.6-mipsgit-20070902 kernel. I am now running that kernel and things seems OK.

My next step will be to try updating the out-of-date packages on the system. I will proceed more carefully this time, seeing if I can tell where the toolchain-breaking problem sneaks in. Of course it's possible it's a hardware or even (yikes!) a user problem :D

Thanks for the help, redhatter. I will leave this thread UNSOLVED for now, pending a little more investigation.
/iMike
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gentoo on Alternative Architectures All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum