public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "jb at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug libfortran/60324] Handle arbitrarily long path names Date: Tue, 15 Jul 2014 06:09:00 -0000 [thread overview] Message-ID: <bug-60324-4-hTUdstk9mu@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-60324-4@http.gcc.gnu.org/bugzilla/> 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.
next prev parent reply other threads:[~2014-07-15 6:09 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <bug-60324-4@http.gcc.gnu.org/bugzilla/> 2014-04-30 22:30 ` jb at gcc dot gnu.org 2014-05-22 3:52 ` jb at gcc dot gnu.org 2014-05-22 21:18 ` jb at gcc dot gnu.org 2014-06-08 16:44 ` fxcoudert at gcc dot gnu.org 2014-06-10 10:21 ` jb at gcc dot gnu.org 2014-07-14 22:03 ` townsend at astro dot wisc.edu 2014-07-15 6:09 ` jb at gcc dot gnu.org [this message] 2014-11-13 12:05 ` jb at gcc dot gnu.org 2014-11-13 12:07 ` jb at gcc dot gnu.org 2014-11-16 1:58 ` jb at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-60324-4-hTUdstk9mu@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).