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

Re: FreeS/WAN allergic to egcs64 (SPARC)

> On Wed, Apr 26, 2000 at 01:19:24PM -0700, Jim Dennis wrote:

>>  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).
> Just edit /usr/include/sys/cdefs.h to something like:
> #if !__GNUC_PREREQ (2,92) || (defined(__sparc__) && defined(__arch64__) && !__GNUC_PREREQ (2,95))
> # define __restrict     /* Ignore */
> #endif

  Tried that.  It gives an error like:

make[3]: Entering directory `/usr/local/src/linux/drivers/char'
gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -o conmakehash conmakehash.c
In file included from /usr/include/features.h:250,
                 from /usr/include/stdio.h:27,
                 from conmakehash.c:17:
/usr/include/sys/cdefs.h:161: parse error

  So something isn't quite right here.
> The issue is that the egcs64 compiler is based on a snapshot of pre-egcs
> 1.2 which does not have yet the __restrict keyword, but is catched by the
> On the other side, what files are you compiling with the egcs64 compiler
> that they include glibc headers?
> egcs64 should be used only to compile kernel modules, for the rest you
> should use normal gcc (and make sure the system can deal with converting its
> syscalls/ioctls etc. between 32bit userland and 64bit kernel).

 I don't know why the freeswan is including stdio.h --- that's what the 
 FreeS/WAN KLIPS is doing.  I'm just trying to compile it.  I thought it
 was strange, too.

 It looks like conmakehash.c is also including stdio.h --- though it wasn't
 tripping over the __restrict problem like this.  

> 64bit userland will be ready in a not too distant future (but not using the
> egcs64 compiler, but using patched gcc 2.96, glibc 2.1.90 and stuff like
> that).
> 	Jakub

 That doesn't sound like it's going to help me here.  I really need a 
 first cut of this this weekend.

Jim Dennis                                             jdennis@linuxcare.com
Linuxcare: Linux Corporate Support Team:            http://www.linuxcare.com

Reply to: