Richard Biener <[email protected]> writes:
> On Fri, Apr 11, 2025 at 2:14 PM Rainer Orth <[email protected]>
> wrote:
>>
>> Andreas Schwab <[email protected]> writes:
>>
>> > On Apr 11 2025, Rainer Orth wrote:
>> >
>> >> All users of symbols.h fail to compile on Solaris:
>> >>
>> >> /vol/gcc/src/hg/master/local/gcc/cobol/symbols.h: At global scope:
>> >> /vol/gcc/src/hg/master/local/gcc/cobol/symbols.h:1365:13: error:
>> >> ‘NAME_MAX’ was not declared in this scope
>> >> 1365 | char name[NAME_MAX];
>> >> | ^~~~~~~~
>> >>
>> >> NAME_MAX being undefined is allowed by POSIX.1, actually: it's listed
>> >> for <limits.h> under "Pathname Variable Values":
>> >
>> > It doesn't look like this member is accociated with file names at all.
>>
>> You're right: seems to be all about COBOL function names. No idea what
>> value is appropriate/required here, though.
>
> It seems 'name' is never set!? Renaming it yields only
>
> ../../src/gcc/gcc/cobol/symbols.cc:496:59: error: ‘const struct
> cbl_function_t’ has no member named ‘name’; did you mean ‘namex’?
> 496 | return strcmp(k->elem.function.name, e->elem.function.name);
> | ^~~~
> | namex
> ../../src/gcc/gcc/cobol/symbols.cc: In function ‘size_t
> symbols_dump(size_t, bool)’:
> ../../src/gcc/gcc/cobol/symbols.cc:1088:50: error: ‘struct
> cbl_function_t’ has no member named ‘name’; did you mean ‘namex’?
> 1088 | "Function", e->elem.function.name);
> | ^~~~
> | namex
>
> the last is
>
> case SymFunction:
> s = xasprintf("%4zu %-15s %s", e->program,
> "Function", e->elem.function.name);
>
> Huh.
Unless this can be figured out quickly, I suspect the safest solution
for now would be to replace the (not filename-related) NAME_MAX by it's
Linux <limits.h> definition of 255. Something like this would be
required to unbreak Solaris/amd64 --enable-languages=all bootstrap.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
