Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#33003 closed defect (worksforme)

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

Reported by: roland@… Owned by: jeremyhu (Jeremy Huddleston Sequoia)
Priority: Normal Milestone:
Component: ports Version: 2.0.3
Keywords: Cc: exg (Emanuele Giaquinta), mamoll (Mark Moll)
Port: clang-2.9, clang-3.0, clang-3.1

Description

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

Change History (13)

comment:1 Changed 9 years ago by ryandesign (Ryan Schmidt)

Owner: changed from macports-tickets@… to jeremyhu@…

comment:2 Changed 9 years ago by 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.

comment:3 Changed 9 years ago by exg (Emanuele Giaquinta)

Cc: emanuele.giaquinta@… added

Cc Me!

comment:4 in reply to:  2 Changed 9 years ago by 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.).

comment:5 Changed 9 years ago 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.

comment:6 Changed 9 years ago by 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

comment:7 Changed 9 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Status: newassigned

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

comment:8 in reply to:  7 Changed 9 years ago by 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.

comment:9 Changed 9 years ago by jeremyhu (Jeremy Huddleston Sequoia)

And the output of these?

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

comment:10 in reply to:  9 Changed 9 years ago by 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

comment:11 Changed 9 years ago by mamoll (Mark Moll)

Cc: mmoll@… added

Cc Me!

comment:12 Changed 9 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Resolution: worksforme
Status: assignedclosed

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.

comment:13 in reply to:  12 Changed 9 years ago by 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!

Note: See TracTickets for help on using tickets.