Re: [FAILURE] XEmacs 21.0-beta38 on MkLinux
- First Post
- Replies
- Stats
-
Go to
- ----- 2024 -----
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2010 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2009 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2008 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2007 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2006 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2005 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2004 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2003 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2002 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2001 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2000 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 1999 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 1998 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
>>>> Martin Buchholz writes:
The unilateral change to __exception must be a mistake in glibc.
It will likely be fixed in any released version of glibc. Someone who
understands floating point error handling should look at this and
likely expunge it. My guess is that a signal handler for SIGFPE is
all a modern system needs to have. FLOAT_CATCH_SIGILL should be nuked
too.
He's using glibc961212 - that's an ancient;-) snapshot before glibc
2.0 was released.
Current glibc 2.0.x and glibc 2.1 have both:
#ifdef __USE_SVID
/* In SVID error handling, `matherr' is called with this description
of the exceptional condition.
We have a problem when using C++ since `exception' is reserved in
C++. */
#ifdef __cplusplus
struct __exception
#else
struct exception
#endif
Therefore if you compile with c++ you still have problems :-(.
Andreas
--
Andreas Jaeger aj(a)arthur.rhein-neckar.de jaeger(a)informatik.uni-kl.de
for pgp-key finger ajaeger(a)alma.student.uni-kl.de
Martin Buchholz
Thursday, 7 May
Thu, 7 May
9:31 a.m.
New subject: [FAILURE] XEmacs 21.0-beta38 on MkLinux
>>>> "AJ" == Andreas Jaeger
<aj(a)arthur.rhein-neckar.de> writes:
>>>> Martin Buchholz writes:
> The unilateral change to __exception must be a mistake in glibc.
> It will likely be fixed in any released version of glibc. Someone who
> understands floating point error handling should look at this and
> likely expunge it. My guess is that a signal handler for SIGFPE is
> all a modern system needs to have. FLOAT_CATCH_SIGILL should be nuked
> too.
AJ> He's using glibc961212 - that's an ancient;-) snapshot before glibc
AJ> 2.0 was released.
AJ> Current glibc 2.0.x and glibc 2.1 have both:
AJ> #ifdef __USE_SVID
AJ> /* In SVID error handling, `matherr' is called with this description
AJ> of the exceptional condition.
AJ> We have a problem when using C++ since `exception' is reserved in
AJ> C++. */
AJ> #ifdef __cplusplus
AJ> struct __exception
AJ> #else
AJ> struct exception
AJ> #endif
AJ> Therefore if you compile with c++ you still have problems :-(.
Right. For the time being the whole matherr definition is wrapped in
#ifdef __cplusplus
This works fine for me, and also adds fuel to my suspicions that
matherr is basically ignorable.
Try
(/ 5 0)
=> Arithmetic error
Martin
9697
days inactive
9697
days old
1 comments
2 participants
tags (0)
participants (2)
-
Andreas Jaeger -
Martin Buchholz