#47813: texlive-bin @2014_9 won't build on PPC Tiger (Mac OS X 10.4.11) because of re-write of C definition ------------------------------+---------------------- Reporter: Peter_Dyballa@… | Owner: dports@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Resolution: | Keywords: haspatch Port: texlive-bin | ------------------------------+---------------------- Changes (by ryandesign@…): * keywords: => haspatch Comment: Replying to [comment:6 ryandesign@…]:
Replying to [comment:2 ryandesign@…]:
on some systems, strings.h is not self-contained, and it is necessary to `#include <sys/types.h>` first. Can you try making that change, wherever strings.h is `#include`d?
I'm trying this now, but of course it will take a long time to build.
This didn't make any difference, but I think the attached patch does. Replying to [ticket:47813 Peter_Dyballa@…]:
{{{ /usr/include/strings.h:75: error: expected declaration specifiers or '...' before '(' token /usr/include/strings.h:75: error: expected declaration specifiers or '...' before '(' token /usr/include/strings.h:76: error: expected declaration specifiers or '...' before '(' token /usr/include/strings.h:76: error: expected declaration specifiers or '...' before '(' token }}}
My understanding of the problem is that [http://stackoverflow.com/questions/4291149/difference-between-string-h -and-strings-h strings.h is a collection of obsolete nonstandard functions].
/usr/include/strings.h has:
{{{ 75 char *index(const char *, int); 76 char *rindex(const char *, int); }}}
These are two of the obsolete functions. The modern name of `index` is `strchr` and the modern name of `rindex` is `strrchr`.
which then gets pre-compiled as:
{{{ char *(strchr((const char *),(int))); char *(strrchr((const char *),(int))); }}}
Note that here, `index` has changed to `strchr` and `rindex` has changed to `strrchr`. Note also the added parentheses. It seems something has `#define`d the old names to the new names, leading to the strings.h system header becoming unusable. (The `#define` makes sense if you want to use the function but don't have a declaration for it, but makes no sense when applied to a function declaration.) I believe the code responsible for doing this is in Xos.h. MacPorts' version of that file (in xorg-xproto) contains in part: {{{ # include <string.h> # if defined(__SCO__) || defined(__UNIXWARE__) || defined(__sun) || defined(__CYGWIN__) || defined(_AIX) # include <strings.h> # else # ifndef index # define index(s,c) (strchr((s),(c))) # endif # ifndef rindex # define rindex(s,c) (strrchr((s),(c))) # endif # endif }}} That looks like what we're seeing. There's an older version of Xos.h on Tiger installed by its optional X11 package, but due to the order of the include paths I think the MacPorts version is the one that's being used. I guess this means `__SCO__`, `__UNIXWARE__`, `__sun`, `__CYGWIN__` and `_AIX` are all not defined (which makes sense since OS X is not any of those operating systems), and therefore it doesn't think we have strings.h (although we do—why doesn't it know that OS X has strings.h?). And the subsequent `ifndef` guards for `index` and `rindex` wouldn't match because `index` and `rindex` are never ''defined'' (using `#define`); rather, they're ''declared'' (as normal functions). I would call it a misfeature that an X header tries to influence what string functions are available. That should be up to the string headers, not the X headers. The simplest solution for us here is to `#include <string.h>` instead of strings.h because the file in question (psgs.c) doesn't actually use any of the obsolete nonstandard functions anymore; it used to, but the ChangeLog in that directory says it was fixed in 2013, but I guess they forgot to update the `#include` statement. Before committing, let me try the patch on another Tiger system just to be sure (my build succeeded but it wasn't a clean build), and let me also verify that it still builds ok on a modern system like Yosemite. You're welcome to try the patch on your Tiger system too. -- Ticket URL: <https://trac.macports.org/ticket/47813#comment:7> MacPorts <https://www.macports.org/> Ports system for OS X