[MacPorts] #40889: libsndfile won't build when sed is GNU sed (was: libsndfile won't build under Mavericks)

[MacPorts]

#40889: libsndfile won't build when sed is GNU sed
-----------------------------+--------------------
  Reporter:  steve.linton@…  |      Owner:  hans@…
      Type:  defect          |     Status:  new
  Priority:  Normal          |  Milestone:
 Component:  ports           |    Version:  2.2.0
Resolution:                  |   Keywords:
      Port:  libsndfile      |
-----------------------------+--------------------
Changes (by ryandesign@…):

 * keywords:  mavericks =>


Comment:

 Replying to [comment:2 steve.linton@…]:
 > Could this be something to do with the ports that are present as
 universal and non-universal versions, like gettext?

 No, inactive ports have no effect.

 Comparing your configure output with mine, I see mine says:

 {{{
 :info:configure checking for a sed that does not truncate output...
 /opt/local/bin/gsed
 }}}

 whereas yours says:

 {{{
 :info:configure checking for a sed that does not truncate output...
 /opt/local/bin/sed
 }}}

 I believe this is significant. Where did /opt/local/bin/sed come from? I'm
 not aware of any port that provides this file. Use `port provides
 /opt/local/bin/sed` to find out if a port provided it. If not, did you
 perhaps create it as a symlink to `gsed`? You can use `ls -l
 /opt/local/bin/sed` to see if this is so. If it is, then I believe that
 explains the problem; I am able to reproduce the problem if I create such
 a symlink.

 On OS X, `sed` is supposed to be BSD sed, but by creating a symlink to
 `gsed` you've changed `sed` into GNU sed.

 Further on, my configure output contains:

 {{{
 :info:configure checking for version of /usr/bin/clang... 4.2.1
 :info:configure checking if /usr/bin/clang accepts -Wextra... yes
 :info:configure checking if /usr/bin/clang++ accepts -Wextra... yes
 }}}

 but yours contains:

 {{{
 :info:configure checking for version of /usr/bin/clang... 4.2.1
 :info:configure configure: WARNING:
 ****************************************************************
 :info:configure configure: WARNING: ** GCC version 4.2 warns about the
 inline keyword for no good **
 :info:configure configure: WARNING: ** reason but the maintainers do not
 see it as a bug.         **
 :info:configure configure: WARNING: ** See
 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33995      **
 :info:configure configure: WARNING: ** Using -fgnu-inline to avoid this
 stupidity.                **
 :info:configure configure: WARNING:
 ****************************************************************
 :info:configure checking if /usr/bin/clang accepts -fgnu89-inline... yes
 :info:configure checking if /usr/bin/clang accepts -Wextra... yes
 :info:configure checking if /usr/bin/clang++ accepts -Wextra... yes
 }}}

 It seems your build has decided it needs to use `-fgnu-inline`, and I
 believe this is why your build ultimately failed.

 Looking into why this difference exists, I believe I've found multiple
 errors in the libsndfile configure script:

  * Its method of detecting GCC is flawed; it incorrectly identifies clang
 as GCC
  * Its method of detecting the GCC version number is flawed; it doesn't
 work correctly when using BSD sed

 Happily, on normal OS X systems where `sed` is BSD sed, two wrongs make a
 right, and the configure script continues on its way. But on your system,
 where I'm presuming `sed` is GNU sed, the GCC version checking code works
 correctly, and therefore adds a flag which would presumably be correct for
 GCC 4.2.x but which is not correct for clang.

 The solution, assuming I'm right that /opt/local/bin/sed doesn't belong
 there, is to remove it, clean libsndfile, and try again.

 We could also patch the configure script to remove the incorrect check
 since on normal OS X systems it has evidently never taken effect.

 If you added the /opt/local/bin/sed symlink because you would like to be
 able to type "sed" in the terminal and have it be GNU sed, then the
 intended way for you to achieve that is to add /opt/local/libexec/gnubin
 to your PATH environment variable. Another option would be to define a
 shell alias in your shell startup file. Both of these methods would not
 have the deleterious impact that creating an /opt/local/bin/sed symlink
 has.

-- 
Ticket URL: <https://trac.macports.org/ticket/40889#comment:3>
MacPorts <http://www.macports.org/>
Ports system for OS X