Building gcc for solaris on sparc64 from linux on x86

[Kai Ruottu]

David Cournapeau wrote:
> Kai Ruottu wrote:
>> Generally a crosscompiler produces "identical" stuff with the native 
>> compiler... BESIDES when runs that
>> '*gcc -dumpspecs' to produce the 'specs' !   This is one of the 
>> mistakes people usually do, they trust the
>> cross-compiler produced 'specs' to work on the native system too!
>>
>> So I would check this "stupid mistake" :-) first  !
>>
> I understand that compiling with a cross compiler to M2 and a native 
> compiler on M2 will produce the same programs more or less; 
> unfortunately, I want to compile python for M2, which configuration 
> needs to run on M2. That's the justification for building a native 
> compiler for M2.
 Yes, there is usually some reason to do something...  I reallly didn't 
mean to suggest using only the crosscompiler
but to tell that what the crosscompiler produces, isn't in every case 
identical. The 'specs' cannot be produced by the
new 'alien' compiler, so the crosscompiler produces it.

 Also other build results may differ, sometimes in the cross-produced 
'libgcc.a' the '__eprintf()' or something was
an empty function...  Then "fixing the target headers", including 
modifying the GCC's own 'limits.h' to have that
'#include <syslimits.h>' in its beginning, wasn't done quite ok...

 These things don't hurt only native GCCs made somewhere else, but also 
crosscompilers made elsewhere, for
instance when producing Windoze-hosted GCCs on Linux with 
Linux-X-Windoze crosstools.  (If one has Linux
available for builds, why use Windoze as a build platform at all?).  But 
when in these cases the crosscompiler on
the $build platform is the first,  its $target stuff can be copied "as 
is"  onto the $host platform,  not caring much
what the $host-X-$target GCC build produced as the new target headers 
and libraries....

 So the "Canadian Cross" build really hasn't worked "perfectly", so 
using steps like :

1.  configure

2.  make

3.  make install   (onto some $sysroot'ed place on the $build system in 
the final scheme  below the $sysroot)

really shouldn't work, or nobody shouldn't think that these steps will 
work...

 The crosscompiler-made 'specs' is so only one thing which can be wrong, 
or at least it is wrong...

> Now, I am not sure to understand the dumpspecs stuff, and how it 
> matters. Where (eg which step) is it used, and for what purpose ?
>
> Here is the specs for the "native" gcc I built (with host and target 
> for solaris):
>
> *cross_compile:
> 0
>
> *version:
> 4.0.3
>
> So if 0 is really false, it looks like the specs say it is not a cross 
> compiler, right ?
 Yes, in a crosscompiler-made 'specs' this is "1", so you must have 
produced this with the native
GCC on the native host...

 I remember the "1" here causing the native '/lib', '/usr/lib' and 
'/usr/include' being dropped from
the built-in search paths, seen with the commands :

   gcc -print-search-dirs

for the 'programs' and 'libraries', and :

   cpp -v

for the 'headers'....  So if these commands didn't show the native 
'/lib' and '/usr/lib' for the libs
and '/usr/include' for the headers, the wrong "1" in the 'specs' was the 
reason...

This issue with 'specs' was discussed some times on this crossgcc list 
earlier, and should now
be remembered by those who have cared to read the messages here...

As should have becomen clear, also things like the GCC's own 'limits.h' 
should be checked,
the beginning in it should be :

-------------- clip ---------------------
/* This administrivia gets added to the beginning of limits.h
   if the system has its own version of limits.h.  */

/* We use _GCC_LIMITS_H_ because we want this not to match
   any macros that the system's limits.h uses for its own purposes.  */
#ifndef _GCC_LIMITS_H_  /* Terminated in limity.h.  */
#define _GCC_LIMITS_H_

#ifndef _LIBC_LIMITS_H_
/* Use "..." so that we find syslimits.h only in this same directory.  */
#include "syslimits.h"
#endif
#ifndef _LIMITS_H___
#define _LIMITS_H___

/* Number of bits in a `char'.  */
#undef CHAR_BIT
#define CHAR_BIT __CHAR_BIT__
-------------- clip ---------------------

if being handled ok....  And the whole :

 $prefix/lib/gcc/sparc-sun-solaris2.9/4.0.3/include

should be identical with the equivalent in the crosscompiler, nothing 
missing or
being different in the native compiler...  The general rule is that all 
the $target
stuff in a crosscompiler should be totally identical with the $target 
stuff in  the
native compiler (if it's version is just the same, if not, then the 
GCC-version
specific $target stuff is different of course).   But my thought is that 
quite many
on this list haven't yet understood this very simple rule but think that 
every part
in the crosscompiler should be different from the native compiler, including
the $target libraries :-(

Cheers, Kai



--
For unsubscribe information see http://sourceware.org/lists.html#faq