This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Trying to build crosscompiler for Sparc Solaris 8 ->SparcSolaris 10 (& others)...

----Original Message----
>From: Aaron Gaudio
>Sent: 06 April 2005 14:25

> Thanks for your attention, Dave. I checked the script I'm using to build
> and I actually am using an absolute path to gcc's configure, despite
> what I wrote in my original mailnote.

  Oh well, so much for that one.  This is why you should cut and paste the
real output from builds that go wrong when you're making a bug report,
rather than faking it: you gave me false information about your problem.
This is not very constructive.

> As for the prefix... you're right, I should be adding $prefix/bin to my
> path. I was adding $prefix in my script, but lo, I had already added
> $prefix/bin to my path in my shell. I'll fix my script, but that won't
> have any impact on the problems I'm facing. You see, the 'as' being
> called was in fact the one in $prefix/bin, but the problem is that
> $prefix is a holding place for binaries with multiple targets.

  Yes indeed, but that isn't a problem.  When you're doing a cross-compile,
the make process is in fact looking out for ${target}-as.  If you've
configured gcc for "i586-sun-solaris2.10", and there is a
"i586-sun-solaris2.10-as" in your $PATH, the make process should find it.
It's only after completely failing to find ${target}-as that the make
process will fall back as a last resort to just trying to use the first 'as'
it can find.

> $prefix/bin/as is a Sparc Solaris 8 binary with a Sparc Solaris 8 target
> (eg --version "This assembler was configured for a target of `sparc-sun-
> solaris2.8'."). However, $prefix/bin/i586-sun-solaris2.10-as is a Sparc
> Solaris 8 binary with an i586 Solaris 10 target (--version "This
> assembler was configured for a target of `i586-sun-solaris2.10'.").

  Well, it *absolutely* should have found and used that one.  Assuming you
really did configure gcc for that target, of course.....

> It seems like either Makefile should be using $AS_FOR_TARGET (which
> would expand to 'i586-sun-solaris2.10-as'), instead of $AS (which is
> just 'as') OR the .s file being assembled should be using Sparc assembly
> instructions instead of x86. I assumed the former was the case, and that
> let me get further in the build, so that's what I've stuck with for
> now...

  No, no, no, you are definitely wrong.  Leave the makefile alone: it works
fine for every other kind of cross-compile, there's nothing wrong with it,
gcc 3.4.3 has been out for a while now and people would have noticed if it
was so badly broken!

  There is an unbreakable rule when making cross toolchains: you must use
the EXACT same arguments for --prefix and for --target when you configure
gcc as you used when you configured binutils.  You appear to have broken
that rule.  If the makefile is using $AS instead of $AS_FOR_TARGET, then you
have gotten a bad configure somehow, and autoconf has made you a makefile
suitable for a host-native compiler.  Did you try reconfiguring in the same
object directory you had previously used for the sparc-sun-solaris2.8

  I think you should blow away your object directory, create a new one,
freshly configure and try again.  If it still doesn't work, show me the REAL
configure commands you've been using.  Don't post forged output in a bug

  BTW, there's a list called the crossgcc mailing list
(, which is more suitable to this
sort of problem than the main gcc or gcc-help lists, but since we're here
now, we may as well try and sort this one out here; I'm just letting you
know for future reference.

Can't think of a witty .sigline today....

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]