randux@xxxxxxxxx wrote:
Thanks. I understood from your post that sysroot is used to point to the
Solaris files but I couldn't figure out how the end compiler is
supposed to know its path when it is finally built, because the sysroot
path won't exist on the target machine. I guess this is specified later
when building the target compiler somehow.
When producing the "native" GCC, one will not use the '--with-sysroot='
at all...
I couldn't find on the gcc web pages which target to specify for x64 Solaris.
I'm not sure that gcc has explicit support for x86_64 Solaris systems.
That might be very easy to add, I don't know. For 32-bit Intel
Solaris systems use something like i686-sun-solaris2.
The $target name must be 'i686-*solaris2.1[0-9]', for instance
'i686-sun-solaris2.10' in order to get the bi-arch support enabled.
For Solarises before the version 10 there is no 64-bit support :(
Furthermore it must be told that the 'i686' is a "fake" CPU, the
"real" CPU will be given via '--with-cpu=<cpu>', the choices 'generic',
'nocona', 'x86_64', 'k8', 'opteron', 'athlon64' and 'athlon-fx' seem
to be available for the '<cpu>'.
And using the '--with-gnu-as --with-gnu-ld' may be (still) obligatory,
even in a crosscompiler the native Sun 'as' and 'ld' may be the
defaults. With the final native GCC these options then shouldn't be used
if one wants the Sun ones there on the native host...
For me the point will be enabling a full 64 bit compiler and taking
advantage of this expensive box I have sitting here. When you say this
may be easy to add for Solaris, does it mean something special has to be
done to gcc itself to support it?
Nothing special... On March I built GCCs from 4.0 to 4.3 for this target
with configure options :
--target=i686-solaris2.10 --with-cpu=x86_64 --with-gnu-as --with-gnu-ld
Only the crosscompilers, but it wouldn't be hard or time-consuming to
make those "equivalent" native GCCs with them...
