libunwind @5.0.1: unrecognized command line option '-stdlib=libstdc++' with clang-3.4

[sideeffect42 (Dennis Camera)]

Compilation of libunwind 5.0.1 fails on Mac OS X 10.5.8 PowerPC when using Clang.

Compiling with macports-gcc-7 works.

/opt/local/bin/clang++-mp-3.4 -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -D_LIBUNWIND_IS_NATIVE_ONLY -U__STRICT_ANSI__  -I../include -I/opt/local/include -DUSE_MACPORTS_LIBUNWIND -DNDEBUG -arch ppc -fvisibility-inlines-hidden -fvisibility-inlines-hidden -fno-rtti -fstrict-aliasing -fno-exceptions -fPIC -funwind-tables -Os -stdlib=libstdc++ -stdlib=libstdc++ -c -o Unwind_AppleExtras.o Unwind_AppleExtras.cpp
/opt/local/bin/clang++-mp-3.4 -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -D_LIBUNWIND_IS_NATIVE_ONLY -U__STRICT_ANSI__  -I../include -I/opt/local/include -DUSE_MACPORTS_LIBUNWIND -DNDEBUG -arch ppc -fvisibility-inlines-hidden -fvisibility-inlines-hidden -fno-rtti -fstrict-aliasing -fno-exceptions -fPIC -funwind-tables -Os -stdlib=libstdc++ -stdlib=libstdc++ -c -o libunwind.o libunwind.cpp
g++: error: unrecognized command line option '-stdlib=libstdc++'; did you mean '-static-libstdc++'?
g++: error: unrecognized command line option '-stdlib=libstdc++'; did you mean '-static-libstdc++'?
clang: error: assembler (via gcc) command failed with exit code 1 (use -v to see invocation)
make: *** [Unwind_AppleExtras.o] Error 1
make: *** Waiting for unfinished jobs....
g++: error: unrecognized command line option '-stdlib=libstdc++'; did you mean '-static-libstdc++'?
g++: error: unrecognized command line option '-stdlib=libstdc++'; did you mean '-static-libstdc++'?
clang: error: assembler (via gcc) command failed with exit code 1 (use -v to see invocation)
make: *** [libunwind.o] Error 1

[sideeffect42 (Dennis Camera)]

failed build using clang-3.4

[kencu (Ken)]

another manifestation of the faulty MacPorts compiler selection logic for PPC.

If the system gcc versions are blacklisted, PPC needs to go to gcc6+ rather than clang*

[ryandesign (Ryan Carsten Schmidt)]

Weird that the error message talks about g++ not understanding -stdlib=libstdc++, when the log clearly shows that g++ isn't being used; clang++-mp-3.4 is, and clang++-mp-3.4 does understand -stdlib=libstdc++.

But sure, as we know, clang doesn't work on ppc, so we should adjust base to pick a better compiler on ppc.

[kencu (Ken)]

I think that comes from the -no-integrated-assember thing.

[sideeffect42 (Dennis Camera)]

I do agree that clang is a bad choice on PowerPC. So many ports that just don't compile properly with clang.

Does anyone know more about how clang works internally? I just set up this little test to figure out what's going on and it looks like clang is just a wrapper for GCC:

hello.cxx:

#include <cstdio>

int main() {
	printf("Hello World\n");
}

$ clang++-mp-3.4 -v -stdlib=libstdc++ hello.cxx
clang version 3.4.2 (tags/RELEASE_34/dot2-final)
Target: powerpc-apple-darwin9.8.0
Thread model: posix
Selected GCC installation:
 "/opt/local/libexec/llvm-3.4/bin/clang" -cc1 -triple powerpc-apple-darwin9.8.0 -S -disable-free -disable-llvm-verifier -main-file-name hello.cxx -mrelocation-model static -mdisable-fp-elim -fmath-errno -target-linker-version 127.2 -v -resource-dir /opt/local/libexec/llvm-3.4/bin/../lib/clang/3.4.2 -stdlib=libstdc++ -fdeprecated-macro -fno-dwarf2-cfi-asm -fno-dwarf-directory-asm -fno-autolink -fdebug-compilation-dir /tmp -ferror-limit 19 -fmessage-length 115 -mstackrealign -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -vectorize-slp -o /var/folders/+n/+nOIyIexGQyIeCv9kUV2mU+++TI/-Tmp-/hello-b09da6.s -x c++ hello.cxx
clang -cc1 version 3.4.2 based upon LLVM 3.4.2 default target powerpc-apple-darwin9.8.0
ignoring nonexistent directory "/usr/include/c++/4.2.1"
ignoring nonexistent directory "/usr/include/c++/4.2.1/powerpc-apple-darwin10/"
ignoring nonexistent directory "/usr/include/c++/4.2.1/backward"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/4.0.0
 /usr/include/c++/4.0.0/powerpc-apple-darwin8
 /usr/include/c++/4.0.0/backward
 /usr/local/include
 /opt/local/libexec/llvm-3.4/bin/../lib/clang/3.4.2/include
 /usr/include
 /System/Library/Frameworks (framework directory)
 /Library/Frameworks (framework directory)
End of search list.
 "/opt/local/bin/g++" -v -stdlib=libstdc++ -c -arch ppc -m32 -o /var/folders/+n/+nOIyIexGQyIeCv9kUV2mU+++TI/-Tmp-/hello-6a3a66.o -x assembler /var/folders/+n/+nOIyIexGQyIeCv9kUV2mU+++TI/-Tmp-/hello-b09da6.s
Using built-in specs.
COLLECT_GCC=/opt/local/bin/g++
g++: error: unrecognized command line option '-stdlib=libstdc++'; did you mean '-static-libstdc++'?
Target: ppc-apple-darwin9
Configured with: /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_gcc7/gcc7/work/gcc-7.2.0/configure --prefix=/opt/local --build=ppc-apple-darwin9 --enable-languages=c,c++,objc,obj-c++,lto,fortran --libdir=/opt/local/lib/gcc7 --includedir=/opt/local/include/gcc7 --infodir=/opt/local/share/info --mandir=/opt/local/share/man --datarootdir=/opt/local/share/gcc-7 --with-local-prefix=/opt/local --with-system-zlib --disable-nls --program-suffix=-mp-7 --with-gxx-include-dir=/opt/local/include/gcc7/c++/ --with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local --with-isl=/opt/local --enable-stage1-checking --disable-multilib --enable-lto --enable-libstdcxx-time --with-build-config=bootstrap-debug --with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld --with-ar=/opt/local/bin/ar --with-bugurl=https://trac.macports.org/newticket --disable-tls --with-pkgversion='MacPorts gcc7 7.2.0_0'
Thread model: posix
gcc version 7.2.0 (MacPorts gcc7 7.2.0_0)
clang: error: assembler (via gcc) command failed with exit code 1 (use -v to see invocation)

[kencu (Ken)]

clang on PPC is set up to process the incoming code to LLVM-IR, pass that on to LLVM to make assembly language out of it, and then pass the assembly source to gcc's assembler to make it into code.

Many errors ensue in the process on PPC, at least until clang-3.8, which works actually quite well on PPC (some work required, let me know if you're interested, some skills needed, not yet for the squeamish, not ready for prime-time, your mileage may vary, no promises, etc, etc). See <​https://github.com/kencu/LeopardPorts/tree/master/lang/llvm-3.8> if you're brave.

FYI, almost nobody is working on this any more, although it's actually quite close to being usable (passes about 99% of the LLVM/Clang test suite, except for c++ exceptions, which are still broken).

Also, check out the no-integrated-assembler flag.

[jeremyhu (Jeremy Huddleston Sequoia)]

So many ports that just don't compile properly with clang.

Which ones? pretty much all ports build just fine with clang. I spent quite a bit of time ~3-5 years ago making sure all of our ports were building fine with clang. There are a few buggy ports that I haven't had resources to fix that clang properly errs out on rather than violating language specifications and producing an executable with undefined behavior. There are also a couple very fringe cases where GCC extensions are used by projects that clang doesn't support, but that's again a project issue and a very rare one.

clang has been the defacto compiler on darwin for almost a decade now, on FreeBSD for I believe 5+ years.

@ryandesign: clang++-mp-3.4 understands -stdlib=libstdc++. clang-3.4 execs g++ for -arch ppc and lipos the result back into the output file. g++ doesn't understand -stdlib=libstdc++, so that's why the message is about g++.

[sideeffect42 (Dennis Camera)]

@jeremyhu I don't have an exhaustive list of ports that fail to build with clang, but I opened some tickets in the last few days for the ones I've stumbled across. Given my personal experience and what other people have reported here, I'd assume that there are more ports that fail to build than ones that work (i.e. the famous "C compiler does work: no" configure error).

I don't want to start a GCC vs. LLVM war. In the past GCC has done a tremendous job for me and was zero-hassle.
If there are reasons for using clang I can live with that, but at least on 10.5.8 PPC (this is the only combination I have) clang doesn't work as has been noted by multiple people.

And as you have said yourself, clang++-mp-3.4 is only a wrapper around g++, so what's the advantage of defaulting to a compiler that's just a wrapper around another compiler, and of which only an ancient version even runs on PowerPC? A compiler that does not violate language specifications and does not create executables with undefined behaviour does not help me if it does not compile.

Since this issue is moving into a compiler-selection debate, what's the way to go forward here? Should I open a new ticket for MacPorts itself?

[kencu (Ken)]

@sideeffect42: see the recent mailing list discussion about this topic <​https://lists.macports.org/pipermail/macports-dev/2017-December/036928.html>.

[jeremyhu (Jeremy Huddleston Sequoia)]

If you get 'C compiler does work: no' from configure, that means that you've misconfigured your compiler setting somehow. That has nothing to do with individual ports. Every port will fail with that issue until you resolve your configuration problem.

Usually a quick look in config.log will immediately reveal what the problem is.

Yes, as I noted, clang does not officially support darwin-ppc. I think there are literally two people (myself included) who have worked on trying to bring clang support to Lion and earlier (including to ppc) over the past 5 years, and neither of us has really put in any effort since around llvm-3.8. Ken has done a great job of trying to revive that effort, but there is a lot of entropy to fight, and bootstrapping the build process is even harder than ever. I don't see a way of doing the bootstrap without using a second system to cross compile (or using prebuilt binaries).

If I was going to live on darwin-ppc right now, I'd definitely be using FSF gcc. If it was a hobby system (as I suspect it is for just about anyone still using it), I'd resurrect the ppc work.

clang++-mp-3.4 is not "only a wrapper around g++". It's quite a stable and usable compiler that supports a wide array of platforms. However, the ancient platform that you are running on is simply not one of them, so it calls out to g++ for darwin-ppc. In 3.4, that is only for ppc. In very earlier versions of clang that did not support C++, that was also done for C++ on Intel.

MacPorts does not actually support the use of GCC as a primary toolchain, and we don't support ppc any more. If you really want to use darwin-ppc (which was EOLd over a decade ago), you're going to hit many road bumps and will need to submit patches to address the failures you run into. You will also need to manage your compiler settings manually. Most MacPorts developers do not even have systems with which to reproduce the issues you are reporting or to test the relevant changes.

---

I believe you will need to build libunwind for intel-only in order to build libcxx universal in order to build clang-3.7 in order to build cmake in order to build clang-5.0 ... but Ken can point you to more specific steps.

[kencu (Ken)]

I just posted up to the developer mailing list a possibly workable modification to the compiler selection on PPC. Feel free to try it out .

[kencu (Ken)]

actually building llvm/clang-3.8 on PPC is pretty easy now. The portfile I referenced above does everything for you, building it with gcc6. It builds right through on 10.5 PPC (and mostly also on 10.4 PPC) with no bootstrapping issues.

There is just one step involving clang_rt where the cmake script has an error, and I just do that part manually. Haven't found the enthusiasm to rewrite it.

I backported the macports-libstdc++ fixes into 3.8, so you get c++11 by linking against gcc7's libstdc++, just like on MacPorts now.

$ port -v installed | grep clang
  clang-3.4 @3.4.2_12+analyzer (active) platform='darwin 9' archs='ppc' date='2017-06-27T16:59:50-0700'
  clang-3.8 @3.8.1_9+analyzer+libstdcxx (active) platform='darwin 9' archs='ppc' date='2017-12-02T15:20:15-0800'
  clang_select @2_0 (active) platform='darwin 9' archs='noarch' date='2017-06-25T17:14:40-0700'

$ port -v installed | grep llvm
  ld64-127 @127.2_14+llvm33 (active) platform='darwin 9' archs='ppc' date='2017-06-25T17:24:10-0700'
  llvm-3.3 @3.3_10 (active) platform='darwin 9' archs='ppc' date='2017-06-25T17:23:00-0700'
  llvm-3.4 @3.4.2_12 (active) platform='darwin 9' archs='ppc' date='2017-06-27T16:53:05-0700'
  llvm-3.8 @3.8.1_3 (active) platform='darwin 9' archs='ppc' date='2017-12-01T22:16:08-0800'
  llvm-4.0 @4.0.1_2 (active) platform='darwin 9' archs='ppc' date='2017-12-02T20:08:46-0800'
  llvm_select @2_0 (active) platform='darwin 9' archs='noarch' date='2017-06-25T17:21:35-0700'

$ clang -v
clang version 3.8.1 (tags/RELEASE_381/final)
Target: powerpc-apple-darwin9.8.0
Thread model: posix
InstalledDir: /opt/local/libexec/llvm-3.8/bin

If I would just get around to fixing that clang_rt cmake script, I'd post it up to MacPorts for general use.

c++ exceptions are still broken -- but I think the error is in the personalily file in that clang_rt, so at least I (probably) know where the error is...