https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119217
--- Comment #21 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot
Uni-Bielefeld.DE> ---
> --- Comment #20 from James K. Lowden <jklowden at gcc dot gnu.org> ---
> NAME_MAX has been removed entirely as of
> ca44643f75c437fb1fb4b17e59b72bc836d12cc6.
This commit isn't in the gcc repo yet.
>> * GLOB_BRACE and GLOB_TILDE are not in POSIX.1 and missing on Solaris:
>
> What is the rule? When cobol is enabled, both c and c++ are built, too. I
> was
> told a bootstrap build is the standard, and that libgcobol should link to the
> just-built libstdc++. Is that not true of libc, too? Or does that rule apply
There's no libc inside the gcc tree, unlike libstdc++, and I know of no
libc implementation portable to the wide variety of hosts and targets
supported by gcc.
> only to the target, whereas the compiler runs on the host and uses the host
> system libraries?
Neither: libc will always be the host resp. target libc.
GCC is supposed to work on the primary and secondary platforms listed in
the release criteria:
https://gcc.gnu.org/gcc-15/criteria.html
> The patch (which was applied) to #define GLOB_BRACE 0 indeed compiles, and
> will
> never work. Braces are supplied in the pattern as static text; if not
> expanded
> by the library, glob(3) will not execute the intended search.
>
> If we are constrained to work with every libc and not only glibc, then my
> answer to would be to add xglob to libiberty. At least then the work would be
> useful outside the GCC COBOL front end.
I'd already mentioned (Comment #10) that gnulib provides an
implementation of glob(3) that includes GLOB_BRACE and GLOB_TILDE. If
it's feasible to integrate that is another question (the gnulib
framework is considerable, though gdb currently uses it).
