This is the mail archive of the crossgcc@sources.redhat.com 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: cross compiling x86-linux to alpha-linux


Tao Zhang <zhangtao@cc.gatech.edu>

> > http://kegel.com/crosstool
> > should make it a piece of cake.
> 
> I just want to say this crosstool works greatly!! I didn't use
> that before because I think I may have to configure a lot of things to
> make it cross compile a specific target.

 Just being curious...

 What is the "specific target", in the Linux/Alpha case, Dan's script
was aimed for?

 If I would target to Linux/Alpha, I would choose the Linux/Alpha
distribution (RedHat, SuSE,...) the target machine(s) are running
as my "specific target"... My thought is that these distributions
sold are now a little old, maybe in the RedHat/SuSE 7.x level with
glibc-2.2.x... So producing a cross-toolchain for Linux/Alpha using
the up-to-date gcc-3.3.1 and glibc-2.3.2 would be insane because
the produced executables wouldn't run on the old target systems. The
produced C++ apps would be the worst, if one doesn't think to produce
any GUI-apps, because one cannot take even the 'backwards-compatability'
as granted, using an older glibc in the cross-tools doesn't offer
any wider target sortiment...

 The 'libstdc++' will be produced to be in sync with the C library used
during the GCC-build, so if one builds a 'libstdc++.so.5' with gcc-3.2.3
and glibc-2.2.5 and then copies it to a system which has the up-to-date
glibc-2.3.2 installed as the runtime, it will be vain to expect any
'backwards compatability' with the installed '/lib/libc.so.6' when trying
the cross-produced C++ apps... The 'libstdc++.so.5' should have been
produced using the 'libc.so.6' on the target system.

 One insane case was presented here recently with 'arm-linux':  The
cross-platform had gcc-2.95 with glibc-2.2.5 but the target system had
a glibc-2.3.2 based runtime environment... Of course the 'libc.so.6' on
the target should be backwards-compatible with C apps produced with
glibc-2.2.5 but assuming the same about the C++ apps is insane... Then
I just didn't care to write how insane all that was, maybe the asker
himself understood the mistake...

 I have seen C apps produced with Sparc/Solaris2.7 target tools to
seemingly run on Sparc/Solaris2.6 too, but trusting on any 'forwards-
compatability' being true, for instance that apps produced on RedHat 8.0
will run on plain vanilla RedHat 7.3, is vain... Most probably they will
not run there. Some may think that if one produces an app on Win2k and
then tries to run it on WinNT 4.0 or Win98, of course it should run
there, if no Win2k-specific things were used on the apps... So why the
same kind of things don't work on Linuces?  Maybe the reason is that
people are expected to recompile everything for the "specific target",
so nobody cares so much about the 'binary compatability' issues, which
are so important on the Windoze-world --- only very few can rebuild the
apps for the "specific target" cases of Win95, Win98, WinME, WinNT 4.0,
Win2k, WinXP and Win2003, because there are no sources for the apps
available for the majority...

 Unless one has ones own Linux-distribution, built from scratch, as the
"specific target", one should take the binary-compatability issues very
seriously and try to produce the apps just for the target, not for
something else...

Cheers, Kai


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com


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