On Fri, Feb 21, 2003 at 11:00:03AM -0700, Marc Aurele La France wrote:
>On Fri, 21 Feb 2003, David Dawes wrote:
>
>> On Fri, Feb 21, 2003 at 01:19:08PM +0000, Dr Andrew C Aitchison wrote:
>> >The setjmp/longjmp fix in
>> >    xc/programs/Xserver/hw/xfree86/loader/xf86sym.c
>> >and xc/programs/Xserver/hw/xfree86/xf86cfg/loadmod.c
>> >doesn't compile in
>> >    RedHat 6.2      egcs-2.91.66
>
>> >It works fine with
>> >    Red Hat 7.3     gcc 2.96
>> >and
>> >    Red Hat 8.0     gcc (GCC) 3.2 20020903 (Red Hat Linux 8.0 3.2-7)
>
>> It looks like RH 6.2 and earlier (i.e. glibc before 2.2) uses a macro for
>> setjmp():
>
>> extern int __sigsetjmp __P ((jmp_buf __env, int __savemask));
>
>> #ifndef __FAVOR_BSD
>> /* Set ENV to the current position and return 0, not saving the signal mask.
>>    This is just like `sigsetjmp (ENV, 0)'.
>>    The ISO C standard says `setjmp' is a macro.  */
>> # define setjmp(env)    __sigsetjmp ((env), 0)
>> #else
>> /* We are in 4.3 BSD-compatibility mode in which `setjmp'
>>    saves the signal mask like `sigsetjmp (ENV, 1)'.  */
>> # define setjmp(env)    __sigsetjmp ((env), 1)
>> #endif /* Favor BSD.  */
>
>> Harbison & Steele also refers to "the macro setjump" and "the function
>> longjmp".
>
>> This certainly complicates things.
>
>> A couple of possibilities:
>
>>   1. Include <setjmp.h> directly into modules that need it, ensure that the
>>      necessary (platform-specific) entry points are exported, and accept that
>>      modules that use it are not OS-neutral.
>
>>   2. Provide aliases for the actual functions uses on the platforms we support,
>>      and come up with a macro for xf86setjmp() that calls the correct one in
>>      the correct way, probably by first querying a function in the core
>>      server for which way to use.
>
>Just another data point:  libGLU compilation on such systems fails also.

libGLU builds OK on the RH 6.2 system I've been looking into this with.
It does do some things with setjmp (using inlined functions).

We don't build libGLU for libc5-based systems, but I don't have access to
one (RH 4.2, is one I think -- anyone have a CD image for RH 4.2?  I don't
see one on RH's ftp site.).

David
-- 
David Dawes
Release Engineer/Architect                      The XFree86 Project
www.XFree86.org/~dawes
_______________________________________________
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Reply via email to