Trying to build crosscompiler for Sparc Solaris 8 ->SparcSolaris 10 (& others)...
Aaron Gaudio
agaudio@eng.mc.xerox.com
Wed Apr 6 18:54:00 GMT 2005
On Wed, 2005-04-06 at 16:46 +0100, Dave Korn wrote:
> ----Original Message----
> >From: Aaron Gaudio
> >Sent: 06 April 2005 14:25
>
> 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.
Sorry, I wasn't saving off that output, so I tried to simulate it :)
In the future, I'll redirect output or use script...
> 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.
In my case, however, the make macro "AS_FOR_TARGET" does indeed find
"i586-sun-solaris2.10-as", but the make macro "AS" is simply "as". I
believe this is correct: AS should be able to assemble code for the host
platform, not the target platform, and AS_FOR_TARGET should assemble
code for the target platform, right?
> Well, it *absolutely* should have found and used that one. Assuming you
> really did configure gcc for that target, of course.....
Definitely, I used the same target name and prefix for both binutils and
for gcc...
>
> 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!
This problem is actually not in the makefile itself, but in
gcc-3.4.3/gcc/config/i386/t-sol2. I suspect only people trying to cross-
compile gcc-3.4.3 for x86 Solaris would hit this (those compiling native
might hit it, but it would probably go unnoticed since $AS and
$AS_FOR_TARGET would both handle the correct assembler code).
That being said, I'm perfectly willing to accept that it is a problem on
my side, but I cannot see what that problem might be... If the .s being
assembled (gcrt1.s, based on gcc-3.4.3/gcc/config/i386/sol2-gc1.asm) is
x86 assembly, and if it is correct to be assembling that file, then
$AS_FOR_TARGET is only the assembler which could assemble it, because
$AS is the host (Sparc) assembler.
>
> 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.
From what I can tell, makefile is including the aforementioned t-sol2
file, which is not autoconfed, but just part of the gcc source
installation... I am definitely configuring gcc with the same --prefix
and --target as binutils.
> Did you try reconfiguring in the same
> object directory you had previously used for the sparc-sun-solaris2.8
> target?
No, my build script blows away both the object and the src directories,
then untars a fresh src directory and creates a new object dir. I tried
to write a quick-and-dirty version of how rpm builds from pristine
source....
>
> 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
> report!
I'll try it again with full output, both from configure, make and from
my buildscripts themselves, so you can see fully what's happening....
>
> BTW, there's a list called the crossgcc mailing list
> (http://sources.redhat.com/ml/crossgcc/), 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.
Thanks.. that list was not referenced from
http://gcc.gnu.org/lists.html, which is where I was looking. I've
subscribed to that list as well as gcc-help, and I'll take
gcc@gcc.gnu.org off the CC and replace it with crossgcc (to try
balancing getting knowledgeable folks to help against cross-posting to
unnecessary lists).
As always, thanks for your input, Dave!
--
Aaron Gaudio agaudio @ eng.mc.xerox.com 585-422-6876
madcap @ irc://rockhopper.eng.mc.xerox.com
OpenPGP fingerprint: 74B3 1018 08EB 1B3F E7C7 B944 11B1 E0C3 949C 8906
"Every man is a mob, a chain gang of idiots."
- Jonathan Nolan, /Memento Mori/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://sourceware.org/pipermail/crossgcc/attachments/20050406/5a36608c/attachment.sig>
More information about the crossgcc
mailing list