[MacPorts] #33003: clang++ 2.9, 3.0 and 3.1 fail to link properly

[MacPorts]

#33003: clang++ 2.9, 3.0 and 3.1 fail to link properly
----------------------------------+-----------------------------------------
 Reporter:  roland@…              |       Owner:  jeremyhu@…                     
     Type:  defect                |      Status:  new                            
 Priority:  Normal                |   Milestone:                                 
Component:  ports                 |     Version:  2.0.3                          
 Keywords:                        |        Port:  clang-2.9, clang-3.0, clang-3.1
----------------------------------+-----------------------------------------

Comment(by roland@…):

 I have looked a bit at clang's source code, and the definition of the
 method `Driver::GetProgramPath()` suggests that clang looks for programs
 (such as `ld`) first in own search path, then in the `PATH` environment
 variable (see the code at http://llvm.org/viewvc/llvm-
 project/cfe/trunk/lib/Driver/Driver.cpp?view=markup).

 On my system, the search path includes `/usr/libexec/gcc/i686-apple-
 darwin10/4.2.1/`, which seems to hides the `ld` installed in
 `/opt/local/bin` by the `ld64` package (which, unlike
 `/usr/libexec/gcc/i686-apple-darwin10/4.2.1/ld`, supports the `-demangle`
 option).  clang displays the following results when invoked with the
 `-print-search-dirs` option:

 {{{
 % clang++-mp-2.9 -print-search-dirs
 programs:
 =/opt/local/libexec/llvm-2.9/bin:/opt/local/libexec/llvm-2.9/bin:/opt/local/libexec/llvm-2.9/bin/../libexec/gcc/i686
 -apple-darwin10/4.2.1:/usr/libexec/gcc/i686-apple-darwin10/4.2.1
 libraries: =
 }}}
 {{{
 % clang++-mp-3.0 -print-search-dirs
 programs:
 =/opt/local/libexec/llvm-3.0/bin:/opt/local/libexec/llvm-3.0/bin:/opt/local/libexec/llvm-3.0/bin
 /../llvm-gcc-4.2/libexec/gcc/i686-apple-darwin10/4.2.1:/usr/llvm-
 gcc-4.2/libexec/gcc/i686-apple-
 darwin10/4.2.1:/opt/local/libexec/llvm-3.0/bin/../llvm-
 gcc-4.2/libexec/gcc/i686-apple-darwin8/4.2.1:/usr/llvm-
 gcc-4.2/libexec/gcc/i686-apple-
 darwin8/4.2.1:/opt/local/libexec/llvm-3.0/bin/../llvm-
 gcc-4.2/libexec/gcc/i686-apple-darwin9/4.2.1:/usr/llvm-
 gcc-4.2/libexec/gcc/i686-apple-
 darwin9/4.2.1:/opt/local/libexec/llvm-3.0/bin/../llvm-
 gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1:/usr/llvm-
 gcc-4.2/libexec/gcc/i686-apple-
 darwin11/4.2.1:/opt/local/libexec/llvm-3.0/bin/../llvm-
 gcc-4.2/libexec/gcc/i686-apple-darwin12/4.2.1:/usr/llvm-
 gcc-4.2/libexec/gcc/i686-apple-darwin12/4.2.1
 libraries: =/opt/local/libexec/llvm-3.0/bin/../lib/clang/3.0
 }}}
 {{{
 % clang++-mp-3.1 -print-search-dirs
 programs:
 =/opt/local/libexec/llvm-3.1/bin:/opt/local/libexec/llvm-3.1/bin:/opt/local/libexec/llvm-3.1/bin
 /../llvm-gcc-4.2/libexec/gcc/i686-apple-darwin10/4.2.1:/usr/llvm-
 gcc-4.2/libexec/gcc/i686-apple-
 darwin10/4.2.1:/opt/local/libexec/llvm-3.1/bin/../llvm-
 gcc-4.2/libexec/gcc/i686-apple-darwin8/4.2.1:/usr/llvm-
 gcc-4.2/libexec/gcc/i686-apple-
 darwin8/4.2.1:/opt/local/libexec/llvm-3.1/bin/../llvm-
 gcc-4.2/libexec/gcc/i686-apple-darwin9/4.2.1:/usr/llvm-
 gcc-4.2/libexec/gcc/i686-apple-
 darwin9/4.2.1:/opt/local/libexec/llvm-3.1/bin/../llvm-
 gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1:/usr/llvm-
 gcc-4.2/libexec/gcc/i686-apple-
 darwin11/4.2.1:/opt/local/libexec/llvm-3.1/bin/../llvm-
 gcc-4.2/libexec/gcc/i686-apple-darwin12/4.2.1:/usr/llvm-
 gcc-4.2/libexec/gcc/i686-apple-darwin12/4.2.1
 libraries: =/opt/local/libexec/llvm-3.1/bin/../lib/clang/3.1
 }}}

 The `darwin::Link::AddLinkArgs()` method (see http://llvm.org/viewvc/llvm-
 project/cfe/trunk/lib/Driver/Tools.cpp?view=markup) uses a heuristic to
 guess whether the `-demangle` option should be passed to the linker, but
 it does not work in the current case.  However, it honors the option
 `-Xlinker --no-demangle`, if it is passed to clang.  So far, this is the
 best workaround I have found.  The following commands all run fine:

 {{{
 clang++-mp-2.9 -Xlinker --no-demangle a.cc
 }}}
 {{{
 clang++-mp-3.0 -Xlinker --no-demangle a.cc
 }}}
 {{{
 clang++-mp-3.1 -Xlinker --no-demangle a.cc
 }}}

 I also tested the upstream release of clang 3.0 (together with llvm-3.0),
 and the behavior of `clang++` w.r.t. the linker is exactly the same. As
 this issue does not seem to be MacPorts-specific, it should probably be
 reported upstream to the maintainers of clang.

-- 
Ticket URL: <https://trac.macports.org/ticket/33003#comment:5>
MacPorts <http://www.macports.org/>
Ports system for Mac OS