[Bug libfortran/60324] Handle arbitrarily long path names

["jb at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60324

--- Comment #7 from Janne Blomqvist <jb at gcc dot gnu.org> ---
(In reply to Rich Townsend from comment #6)
> This change introduces a dependency on strndup -- which, alas, is absent
> from libSystem in OS X 10.6 (Snow Leopard), although later releases of OS X
> include it. This isn't a problem per se, as it appears that an internal
> strndup will be built if a system one can't be found.

Indeed. This is similar to how libgfortran handles a lot of functionality
beyond basic C89 + POSIX.

> Howver, today, I've run into the problem that when I build gcc/gfortran
> (trunk) on 10.9, I can't then use the compiler on 10.6 due to the reference
> in libgfortran (and perhaps elsewhere) to the (missing) system strndup. Any
> suggestions for workarounds? Can I hack libgfortran/configure.ac to force
> the internal strndup to be used?

I think hacking configure.ac is how people doing cross-compilers etc. typically
do it, so it should work, yes. configure.ac does already have such a hard-coded
list for newlib targets, take a look at that, it ought to be relatively
straightforward to create a similar list for OSX.

Another alternative would be for you to compile gfortran on your 10.6 system,
the result should be usable on a 10.9 system as well.

The strnlen/strndup implementations provided by the target system might be
faster compared to the simple fallback implementations in libgfortran, but for
the usage in libgfortran it's unlikely to be an issue.