[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

FreeS/WAN allergic to egcs64 (SPARC)


 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:/* __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:# define __restrict    /* Ignore */

 ... but in /usr/include/libio.h there are the following references to

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,

  ... 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

     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: