[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Patch for coreutils 4.5.7 on Mac OS X
From: |
Petter Reinholdtsen |
Subject: |
Re: Patch for coreutils 4.5.7 on Mac OS X |
Date: |
Thu, 20 Feb 2003 21:29:13 +0100 |
User-agent: |
Mutt/1.2.5i |
[Paul Eggert]
> The <sys/types.h> part of that change seems reasonable, but the
> other change (enclosed below) looks like a maintenance nightmare.
> We don't want to have that kind of #ifdef in the code, since we'd
> then have to add another #ifdef for every kind of processor on such
> operating systems.
I partly agree. Hardcoding the processor type is a the start of
maintainence nightmare, but making the includes match the protection
should not be.
Why does the code read '#if HAVE_SYSCTL_H then #include
<sys/param.h>'? This do not make sense. The header file included is
<sys/param.h>, so the test should use HAVE_SYS_PARAM_H.
> How does MacOS solve this problem? Does it have a different system
> call that returns the processor name?
After tracing /usr/bin/uname and running 'strings' on the binary, I
suspect MacOS hardcoded the return value. The binary contains <10
strings, and one of them is 'powerpc'.
> If not, perhaps a better workaround would be something like this:
>
> char const *default_processor = 0;
> #ifdef PROCESSOR
> default_processor = PROCESSOR;
> #endif
>
> and then use "else element = default_processor;" in the mainline code.
> You can then compile with -DPROCESSOR="\"`uname -p`\"'. This sort of
> thing could be Autoconf'ed, though it is a bit circular....
This sounds like a good idea to me. :)
configure chould call '/usr/bin/uname -p' and use that as the default
value. That is in effect what I am doing. :-)