clang++ 2.9, 3.0 and 3.1 fail to link properly

[roland@…]

The clang++ C++ front ends from ports clang-2.9, clang-3.0 and clang-3.1 fail to link code properly:

% cat a.cc
#include <iostream>

int
main ()
{
  std::cout << "Hello World!" << std::endl;
}
% clang++-mp-2.9 a.cc
ld: unknown option: -demangle
clang: error: linker command failed with exit code 1 (use -v to see invocation)
% clang++-mp-3.0 a.cc
ld: unknown option: -demangle
clang: error: linker command failed with exit code 1 (use -v to see invocation)
% clang++-mp-3.1 a.cc
ld: unknown option: -demangle
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Using directly the clang++ binary from the /opt/local/libexec/llvm-x.y/bin/ directory produces the same error:

% /opt/local/libexec/llvm-2.9/bin/clang++ a.cc
ld: unknown option: -demangle
clang: error: linker command failed with exit code 1 (use -v to see invocation)
% /opt/local/libexec/llvm-3.0/bin/clang++ a.cc
ld: unknown option: -demangle
clang: error: linker command failed with exit code 1 (use -v to see invocation)
% /opt/local/libexec/llvm-3.1/bin/clang++ a.cc
ld: unknown option: -demangle
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Here is the output of clang++-mp-2.9 with the -v option:

% clang++-mp-2.9 -v a.cc
clang version 2.9 (tags/RELEASE_29/final)
Target: x86_64-apple-darwin10
Thread model: posix
 "/opt/local/libexec/llvm-2.9/bin/clang" -cc1 -triple x86_64-apple-darwin10.0.0 -emit-obj -mrelax-all -disable-free -main-file-name a.cc -pic-level 1 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 127.2 -v -resource-dir /opt/local/libexec/llvm-2.9/bin/../lib/clang/2.9 -ferror-limit 19 -fmessage-length 80 -stack-protector 1 -fblocks -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o /var/folders/TT/TTWwnJg92RaMtk+BYog6aU+++TI/-Tmp-/cc-CZUJ1t.o -x c++ a.cc
clang -cc1 version 2.9 based upon llvm 2.9 hosted on x86_64-apple-darwin10
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/4.2.1
 /usr/include/c++/4.2.1/i686-apple-darwin10/x86_64
 /usr/include/c++/4.2.1/backward
 /usr/include/c++/4.0.0
 /usr/include/c++/4.0.0/i686-apple-darwin8
 /usr/include/c++/4.0.0/backward
 /usr/local/include
 /opt/local/libexec/llvm-2.9/bin/../lib/clang/2.9/include
 /usr/include
 /System/Library/Frameworks (framework directory)
 /Library/Frameworks (framework directory)
End of search list.
 "/usr/libexec/gcc/i686-apple-darwin10/4.2.1/ld" -demangle -dynamic -arch x86_64 -macosx_version_min 10.6.0 -o a.out -lcrt1.10.6.o /var/folders/TT/TTWwnJg92RaMtk+BYog6aU+++TI/-Tmp-/cc-CZUJ1t.o /usr/lib/libstdc++.6.dylib -lSystem
ld: unknown option: -demangle
clang: error: linker command failed with exit code 1 (use -v to see invocation)

(clang++-mp-3.0 and clang++-mp-3.1 show similar error messages.)

[exg (Emanuele Giaquinta)]

Does /opt/local/bin come after /usr/bin in your PATH? clang is using "/usr/libexec/gcc/i686-apple-darwin10/4.2.1/ld" as linker, which does not work. I get the same error with "PATH=/usr/bin:/opt/local/bin clang++-mp-3.0 -v a.cc", although clang uses "/usr/bin/ld" in my case.

[exg (Emanuele Giaquinta)]

Cc Me!

[roland@…]

Replying to emanuele.giaquinta@…:

Does /opt/local/bin come after /usr/bin in your PATH? clang is using "/usr/libexec/gcc/i686-apple-darwin10/4.2.1/ld" as linker, which does not work. I get the same error with "PATH=/usr/bin:/opt/local/bin clang++-mp-3.0 -v a.cc", although clang uses "/usr/bin/ld" in my case.

My PATH is as follows:

/Users/roland/bin:/Users/roland/local/bin:/opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin

So /opt/local/bin comes before /usr/bin (the first two directories of the PATH contain nothing related to clang nor ld.).

[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.

[jeremyhu (Jeremy Huddleston Sequoia)]

What are your OS and XCode versions? I don't have /usr/libexec/gcc/i686-apple-darwin11/4.2.1 on my Lion machines (XCode 4.2.x), and I don't have it on my one SL machine (XCode 3.2.x)

So my guess is that it's old crud sitting around. Can you tell me what these report:

/usr/libexec/gcc/i686-apple-darwin11/4.2.1/ld -v
/usr/bin/ld -v

[jeremyhu (Jeremy Huddleston Sequoia)]

Ah, I see you're on SL, so please just tell me what XCode version you have.

[roland@…]

Replying to jeremyhu@…:

Ah, I see you're on SL, so please just tell me what XCode version you have.

My version of Xcode is 3.2.3.

[jeremyhu (Jeremy Huddleston Sequoia)]

And the output of these?

/usr/libexec/gcc/i686-apple-darwin11/4.2.1/ld -v
/usr/bin/ld -v

[roland@…]

Replying to jeremyhu@?:

And the output of these?

/usr/libexec/gcc/i686-apple-darwin11/4.2.1/ld -v
/usr/bin/ld -v

Here they are:

% /usr/libexec/gcc/i686-apple-darwin11/4.2.1/ld -v
zsh: no such file or directory: /usr/libexec/gcc/i686-apple-darwin11/4.2.1/ld
% /usr/libexec/gcc/i686-apple-darwin10/4.2.1/ld -v
@(#)PROGRAM:ld  PROJECT:ld64-97.14
llvm version 2.7svn,  Apple Build #2326-10
% /usr/bin/ld -v
@(#)PROGRAM:ld  PROJECT:ld64-97.14
llvm version 2.7svn,  Apple Build #2326-10

[mamoll (Mark Moll)]

Cc Me!

[jeremyhu (Jeremy Huddleston Sequoia)]

On my Snow Leopard machine with XCode 3.2.6,

My ld is:

ld64-97.17
llvm version 2.9svn, from Apple Clang 1.7 (build 77)

And with clang-3.1 (r150641), it is not passing -demangle. With clang-3.0, it *is* passing -demangle, but the linker is ok with it.

It looks like this was probably an issue with 2.9, 3.0, and earlier 3.1 and fixed with recent revisions on trunk. If you really want to use 2.9 or 3.0, I suggest you update your XCode to 3.2.6 or later.

[roland@…]

Replying to jeremyhu@…:

On my Snow Leopard machine with XCode 3.2.6,

My ld is:

ld64-97.17
llvm version 2.9svn, from Apple Clang 1.7 (build 77)

And with clang-3.1 (r150641), it is not passing -demangle. With clang-3.0, it *is* passing -demangle, but the linker is ok with it.

It looks like this was probably an issue with 2.9, 3.0, and earlier 3.1 and fixed with recent revisions on trunk. If you really want to use 2.9 or 3.0, I suggest you update your XCode to 3.2.6 or later.

I updated Xcode to version 3.2.6 and everything works fine now (clang++-mp-2.9, clang++-mp-3.0 and clang++-mp-3.1). Thanks!