[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: porting to NeXTstep
From: |
Daniel Richard G. |
Subject: |
Re: porting to NeXTstep |
Date: |
Mon, 17 Oct 2011 13:54:07 -0400 |
I've been playing around with this further, and have some new findings,
and a revised patch.
* Turns out the problem with -lposix yielding "Floating point exception"
is that you're not supposed to link to that library directly; instead,
you specify "cc -posix". Akin to -lpthread vs. -pthread.
With this, a *lot* more things are working now. In fact, the only
breakage still in gllib is strcoll(), due to this platform's odd
three-
argument form of it. (Could you point me to where this sort of quirk
should be worked around?)
* I've added a definition of EILSEQ to lib/errno.in.h; does that
look right?
The libiconv folks may need to be pinged about this change, as I
noticed that they check for EILSEQ too, and if it's missing, #define
it to ENOENT.
* Changed all uses of __STRICT_ANSI__ to "defined __STRICT_ANSI__". This
is how both NeXT and current glibc headers use the symbol; IMO, this
is really how it should be done.
A bit of clarification: There is actually no difference in how this
ancient version of GCC handles cpp symbols versus newer ones. An
undefined cpp symbol is silently replaced with 0 (thus none of the
missing HAVE_* symbols broke).
An empty cpp symbol, however, will be substituted as-is, which can
lead to cpp expression breakage. This is as true today as in 1992.
__STRICT_ANSI__ is usually #defined by GCC, and when it does so, it's
nice enough to set a value of 1. You run into trouble, however, if
some header somewhere defines this symbol (or some other symbol) to an
empty value. That's what was happening here. (And this is hardly
limited to NeXT; look in the current X11/Xarch.h header.)
(Ideally, all of these cpp symbols should be tested with #ifdef / #if
defined(). Not only does that make expressions robust to this kind of
breakage, it quashes warnings from -Wundef, and it avoids the
somewhat awkward nature of the undef-versus-1 duality. It makes more
sense to say your coffee cup is either empty or full, rather than
empty or hot!)
* Tacked on "&& !defined __NeXT__" in lib/stdio.in.h. Easier than adding
a separate test for asm-label functionality, anyway.
* New and improved absolute-header matching code.
* Make use of setrlimit() if available to escape from the infinite
frexp() trap.
* Check the program return code when comparing strerror() and perror().
* I missed that the 50-day sleep is necessary to check for a Cygwin bug.
So I tweaked the test so that this long sleep is only used on Cygwin
(where, presumably, alarm() has always worked correctly), and all
other systems use 15 seconds.
* Many of the tests still fail to build, not because the functions for
them are not available, but because said declarations for these
functions either disappear with -posix->_POSIX_SOURCE->__STRICT_ANSI__
(which we can't do anything about), or don't exist in any standard
headers at all.
Math functions tend to fall in the former category, and various
syscalls in the latter. (Seriously; you look at the man pages for e.g.
fsync() or readlink(), and the synopsis has no #includes.)
Providing the declarations should get all of these going again. Is
there any precedent for doing this in gnulib?
Patch against current git master is attached.
--Daniel
--
Daniel Richard G. || address@hidden
My ASCII-art .sig got a bad case of Times New Roman.
gnulib-fixes-2.patch
Description: Text Data
- Re: gl_ABSOLUTE_HEADER_ONE and older seds, (continued)
- Re: gl_ABSOLUTE_HEADER_ONE and older seds, Bruno Haible, 2011/10/13
- Re: gl_ABSOLUTE_HEADER_ONE and older seds, Daniel Richard G., 2011/10/14
- Re: porting to NeXTstep, Bruno Haible, 2011/10/14
- Re: porting to NeXTstep, Daniel Richard G., 2011/10/15
- Re: perror.m4 test, Bruno Haible, 2011/10/15
- Re: perror.m4 test, Eric Blake, 2011/10/15
- Re: perror.m4 test, Bruno Haible, 2011/10/22
- Preserving non-alphanumeric characters in git commits [was Re: porting to NeXTstep], Gary V. Vaughan, 2011/10/15
- Re: porting to NeXTstep,
Daniel Richard G. <=
- Re: porting to NeXTstep, Bruno Haible, 2011/10/19
- Re: porting to NeXTstep, Bruno Haible, 2011/10/22
- Re: porting to NeXTstep, Daniel Richard G., 2011/10/23
- Re: porting to NeXTstep, Daniel Richard G., 2011/10/23