bug-gnulib
[Top][All Lists]
Advanced

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

Attachment: gnulib-fixes-2.patch
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]