This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


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: Building gcc for solaris on sparc64 from linux on x86


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


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