Re: linux-ipsec: Re: FreeS/WAN allergic to egcs64 (SPARC)
Date: Tue, 02 May 2000 18:04:48 -0700
From: Jim Dennis <jimd@starshine.org>
I'd tried building the .../ipsec/libdes with gcc and with
gcc272 before building the rest of the kernel. I haven't
yet figured out how to hack KLIPS libdes to use HOSTCC
instead of egcs-sparc-64 and I have no confidence that
this would work.
If ipsec wants to use libdes in the kernel, it must be compiled
with sparc64-linux-egcs, not the 32-bit userland compiler. I've
not seen any information indicating one or the other. If both
user applications and the kernel need libdes, then it will need
to be compiled twice, once with each compiler for each purpose.
I don't suppose its possible to compile a 32-bit kernel and
run it on an UltraSPARC. Is it? (I've tried a couple of
ways --- and it doesn't seem to work).
No. It's a fully 64-bit kernel and all of the sparc64 kernel code
expects to be compiled with 64-bit compilation tools.
I'm willing to switch to Red Hat (SPARC) if the tool chain
included with that can cope with this.
No tool chain can cope with hopelessly non-portable code which wants
to use user application header files in the kernel.
Do they believe in a PC centric world out there? Seems like
an odd bias to me; particularly considering the background
of their principle sponsor.
Not necessarily a PC centric one, but one in which most people just
are lazy and do not consider portability issues from the start, and
people who do end up needing to use their code in a cross-build
environment (for example) eat the pains of cleaning up the mess
usually.
Is there any chance that I might get this working if I
were to get the latest egcs out of CVS (and/or upgrade to
a new glibc?). Would any of you like access to this box?
(I can to a scratch new install if you like. This was a
Debian Potato using Ben Collins 60Mb ISO image and an
apt-get update && apt-get upgrade. I'll see if I can
dig up a Red Hat if that would help.
The compiler _does not matter_! IPSEC needs to be cleaned up so that
it is more portable and can handle different compilation environments
for the kernel vs. userland and not expect them to be identical.
Later,
David S. Miller
davem@redhat.com
Reply to: