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.
