FreeS/WAN allergic to egcs64 (SPARC)
All,
I've been trying to compile FreeS/WAN (1.3 and the 25 Apr 2000 snapshot)
on an UltraSPARC 5 (PCI based Sun) under Debian/Frozen (Potato). The
kernel build dies in a horrible cascade under the KLIPS (kernel level
ipsec patches) in /usr/src/linux/net/ipsec/libdes.. I've seen similar
failures on Debian/x86 when using egcs (apparently identical errors).
Here's the main error:
sparc64-linux-gcc -DLIBDES_LIT -DRAND -DTERMIO -O3 -fomit-frame-pointer -c -o cbc_enc.o cbc_enc.c
In file included from /usr/include/stdio.h:57,
from des.h:74,
from des_locl.h:76,
from cbc_enc.c:59:
/usr/include/libio.h:363: conflicting types for `__restrict'
/usr/include/libio.h:363: previous declaration of `__restrict'
/usr/include/libio.h:364: conflicting types for `__restrict'
/usr/include/libio.h:363: previous declaration of `__restrict'
/usr/include/libio.h:365: conflicting types for `__restrict'
/usr/include/libio.h:365: previous declaration of `__restrict'
In file included from des.h:74,
from des_locl.h:76,
from cbc_enc.c:59:
/usr/include/stdio.h:182: parse error before `__filename'
/usr/include/stdio.h:185: parse error before `__filename'
/usr/include/stdio.h:232: parse error before `__stream'
/usr/include/stdio.h:236: parse error before `__stream'
/usr/include/stdio.h:242: parse error before `__stream'
(It goes on from there, but y'all probably get the idea!)
I spent all night looking at the first error, trying to worm my way back
through the header files to figure out where this was coming from ---
and finally (doing a find . /usr/include -follow -type f | xargs grep __restrict)
I found the following tidbit (right at the top!):
/usr/include/sys/cdefs.h-#endif
/usr/include/sys/cdefs.h-
/usr/include/sys/cdefs.h:/* __restrict is known in EGCS 1.2 and above. */
/usr/include/sys/cdefs.h-#if !defined __GNUC__ || __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__
< 92)
/usr/include/sys/cdefs.h-
/usr/include/sys/cdefs.h:# define __restrict /* Ignore */
/usr/include/sys/cdefs.h-
/usr/include/sys/cdefs.h-#endif
-
... but in /usr/include/libio.h there are the following references to
__restrict:
extern int _IO_vfscanf __P ((_IO_FILE * __restrict, const char * __restrict,
_IO_va_list, int *__restrict));
extern int _IO_vfprintf __P ((_IO_FILE *__restrict, const char *__restrict,
_IO_va_list));
... this is NOT wrapped in any sorts of #ifdef's as far as I can see.
BTW: wrapping an #ifdef 0 around this pair of lines didn't help much.
(I didn't expect it to). It did get rid of the first couple of
errors in the cascade --- but stdio.h is riddled with other references
to __restrict. (This convinces me that I must be doing something VERY
wrong!). Notice these results:
$ find /usr/include/ -follow -type f | xargs grep -C __restrict | wc
1697 8725 94611
... I can't imagine that this egcs definition of __restrict is
correct in light of 1700 references to it in the standard libraries.
I must be horribly misunderstanding this!
Ooops! Reading back over this with my wife I see that __restrict is
ADDED in egcs! (I read that cdefs.h comment as "unknown" and missed
the bang sign in the #ifdef).
So I have a few questions:
Am I doing something egregiously stupid? Have I someone managed
to hork up my toolchain and mix incompatible sets of header files?
(If so, it would seem to be a big problem for Debian/Potato since
a couple of these systems where very recent slink installs followed
*immediately* by apt-get upgrades to frozen).
Is this really a problem with egcs?
What is this __restrict? It appears to be some sort of egcs extension,
some magic identifier that can take multiple types (FILE *, char *, etc).
Is this a bug in egcs? What the heck is __restrict!?!
Am I using the wrong toolchain? Is there a 64 bit gcc/SPARC? Is there
a way to compile a 32-bit kernel to drive an UltraSPARC?
I've been acting under the assumption that I must use egcs64 to compile
Linux kernels for an UltraSPARC system. My attempts to use the sparc32
environment and to use gcc272 as an alternative have given other errors.
(I also vaguely recall seeing some snippet that we need 64 bit kernels
on these systems). On x86 I've been able to get around this __restrict
problem by using gcc272. On all platforms that I've tried (x86, SPARC,
and PowerPC) I've been able to compile kernels without the KLIPS patches.
These problems only occur after the patch.
Should I use pipsecd (a user space IPSEC? ported from BSD?) I can
install it easily enough (just run apt-get install pipsecd)? However
I know nothing about the package. I don't know if it implements the
standards, if the code is robust or stable, if its interoperable with
(other?) IPSec implementations nor do I know anything about its
performance.
Is it likely that switching to Red Hat would allow me to get FreeS/WAN
to build? I'd prefer to stick with Debian --- but if Red Hat has a
toolchain that will build FreeS/WAN I think my preference for FreeS/WAN
will win. Are there any other distributions that run on UltraSPARC?
Does OpenBSD run on UltraSPARC? Is its support for IPSec robust,
interoperable, etc? Should I consider that?
(BTW: The requirement that this solution run on non-x86 hardware
is pretty firm; alternative non-x86 platforms *might* be considered
(not my decision) and alternatives to Linux might be considered before
an x86 solution was accepted. They are really serious about this).
Any other advice? I will have other questions later (after getting a
the core code to compile!). One of the big issues I'm facing is
policy management on these FreeS/WAN SGs. I need to configure the
security gateways with redundant DSL connections (there will be
our SGs at all points). I need to ensure that all traffic is required
to go through the IPSec tunnels --- NOTHING should go in the clear to
ANY outside route. Can I do this with simple routing commands?
Is FreeS/WAN still allergic to Kuznetsov's advanced/policy routing
options? What packet filtering rules could/should be employed to
further enforce this policy.
Sorry for the long message. Thanks for bearing with me and thanks in advance
(TIA) for any help y'all offer.
--
Jim Dennis jdennis@linuxcare.com
Reply to: