This is the mail archive of the gcc-help@gcc.gnu.org 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)...


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/

Attachment: signature.asc
Description: This is a digitally signed message part


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