Paul Eggert wrote on 2007-01-29:
> > The problem is that regex.h is defining "__restrict" to be "restrict"!
> > ...
> > And of course config.h is defining "restrict" to be "__restrict".
> >
> > #define restrict __restrict
> >
> > That combination is obviously not good.
>
> Thanks for reporting t
Paul Eggert <[EMAIL PROTECTED]> wrote:
> Jim Meyering <[EMAIL PROTECTED]> writes:
>
>> If you're serious about merging back to glibc, it'll help
>> (name space cleanliness) to add the "__" prefix: i.e., change
>> your Restrict to __Restrict.
>
> But the prefix _R suffices, no? As far as the standa
Jim Meyering <[EMAIL PROTECTED]> writes:
> If you're serious about merging back to glibc, it'll help
> (name space cleanliness) to add the "__" prefix: i.e., change
> your Restrict to __Restrict.
But the prefix _R suffices, no? As far as the standard C name space
rules are concerned, _R* is in t
Paul Eggert <[EMAIL PROTECTED]> wrote:
> Jim Meyering <[EMAIL PROTECTED]> writes:
>
>> Avoid a compile error from HP-UX's ia64 cc: s/__restrict\>/restrict/
>> * lib/regex.h: Use "restrict", not "__restrict", since only the
>> former works with 'config.h's "#define restrict ...".
>>
Jim Meyering <[EMAIL PROTECTED]> writes:
> Avoid a compile error from HP-UX's ia64 cc: s/__restrict\>/restrict/
> * lib/regex.h: Use "restrict", not "__restrict", since only the
> former works with 'config.h's "#define restrict ...".
> Problem reported by Bob Proulx.
>
Arg
[EMAIL PROTECTED] (Bob Proulx) writes:
> The problem is that regex.h is defining "__restrict" to be "restrict"!
> ...
> And of course config.h is defining "restrict" to be "__restrict".
>
> #define restrict __restrict
>
> That combination is obviously not good.
Thanks for reporting that. I ins
[EMAIL PROTECTED] (Bob Proulx) wrote:
> Bob Proulx wrote:
>> That seemed to mostly work. It is still failing under ia64 though. I
>> think the compiler there has no support for restrict. If I define
>> restrict to be nothing to disable it completely then the compilation
>> succeeds.
>> ...
>> So
Bob Proulx wrote:
> That seemed to mostly work. It is still failing under ia64 though. I
> think the compiler there has no support for restrict. If I define
> restrict to be nothing to disable it completely then the compilation
> succeeds.
> ...
> So apparently the configure test for a working r
Jim Meyering wrote:
> Actually restrict-detection is working just fine.
> The problem is that "config.h" isn't included.
That seemed to mostly work. It is still failing under ia64 though. I
think the compiler there has no support for restrict. If I define
restrict to be nothing to disable it co
Jim Meyering <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Bob Proulx) wrote:
>
>> Jim Meyering wrote:
>>> Check out the red columns here:
>>>
>>> http://proulx.com:9000/
>>>
>>> Maybe a system-provided mempcpy macro is causing trouble?
>>> ...
>>> cc -I. -Ae -O -c mempcpy.c
>>> c
[EMAIL PROTECTED] (Bob Proulx) wrote:
> Jim Meyering wrote:
>> Check out the red columns here:
>>
>> http://proulx.com:9000/
>>
>> Maybe a system-provided mempcpy macro is causing trouble?
>> ...
>> cc -I. -Ae -O -c mempcpy.c
>> cc: "string.h", line 39: error 1000: Unexpected symbo
Jim Meyering wrote:
> Check out the red columns here:
>
> http://proulx.com:9000/
>
> Maybe a system-provided mempcpy macro is causing trouble?
> ...
> cc -I. -Ae -O -c mempcpy.c
> cc: "string.h", line 39: error 1000: Unexpected symbol: "__dest".
> cc: "string.h", line 39: error 1
Check out the red columns here:
http://proulx.com:9000/
Maybe a system-provided mempcpy macro is causing trouble?
---
...
source='mempcpy.c' object='mempcpy.o' libtool=no \
DEPDIR=.deps depmode=hp /bin/sh ../build-aux/depcomp \
cc -I. -Ae -O -c mem
13 matches
Mail list logo
