clang-3.4 @3.4 fails building on 10.5.8 PPC because cctools is too old

[udbraumann]

As I am still on search for a working clang version running on PPC (clang-3.3 builds, but unfortunately is not usable), I have tried to build clang-3.4. While llvm-3.4 builds fine, clang-3.4 stops after hours while making runtime libraries during the compiler-rt/.makeall phase when building armv6m/libcompiler_rt.a in the clang_darwin_embedded/soft_static/armv6m branch. Unfortunately, there is no easily interpretable message in the log (at least for me). I have not specified a certain compiler, it automatically selects Xcode GCC 4.2. Log file will be attached.

[jeremyhu (Jeremy Huddleston Sequoia)]

Work with upstream on ppc issues in llvm. We're not supporting it.

[udbraumann]

Replying to jeremyhu@…:

Work with upstream on ppc issues in llvm. We're not supporting it.

You probably have misunderstood, I do not report a functionality issue (which indeed could be interesting for people working upstream), I address a building issue inside macports:

:info:build /opt/local/bin/ar cru 2> /dev/null /Volumes/Data/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_llvm-3.4/clang-3.4/work/llvm-3.4/tools/clang/runtime/compiler-rt/clang_darwin_embedded/soft_static/armv6m/libcompiler_rt.a /Volumes/Data/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_llvm-3.4/clang-3.4/work/llvm-3.4/tools/clang/runtime/compiler-rt/clang_darwin_embedded/soft_static/armv6m/SubDir.lib/int_util.o
:info:build make[4]: *** [/Volumes/Data/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_llvm-3.4/clang-3.4/work/llvm-3.4/tools/clang/runtime/compiler-rt/clang_darwin_embedded/soft_static/armv6m/libcompiler_rt.a] 
Error 1

If, however, the strategic decision is to drop ppc support for clang at all, then please exclude ppc support on the portfile level issuing a message e.g. "unsupported platform".

Concerning the error above, under ​https://lists.macosforge.org/pipermail/macports-users/2014-January/034330.html I found a similar error report for clang-3.4 which however has occurred on a 10.6.8 platform, obvious not on a PPC. So I really would appreciate if you could check what has been done to get rid of this problem for SL platforms.

[jeremyhu (Jeremy Huddleston Sequoia)]

Oh, sorry for misunderstanding. Reopening.

Note that I don't want to exclude ppc platforms because it should be perfectly fine to *install* llvm and clang on darwin/ppc, but it doesn't generate darwin/ppc code very well. I think it's much better than it was in the 3.0 days, but I haven't had a darwin/ppc system for a few years.

[jeremyhu (Jeremy Huddleston Sequoia)]

Can you give this a try?

Index: Portfile
===================================================================
--- Portfile	(revision 119368)
+++ Portfile	(working copy)
@@ -183,11 +183,14 @@
         }
     }
 
-    if {${os.major} < 9} {
+    if {${os.major} < 11} {
         # Tiger's DevTools make has issues with the nested ifs in compiler-rt
+        # Leopard and SL also have issues (#43484)
         depends_run-append      port:gmake
         build.cmd               ${prefix}/bin/gmake
+    }
 
+    if {${os.major} < 9} {
         post-configure {
             reinplace "/^RPATH/s/=.*/=/" ${worksrcpath}/Makefile.config
         }

[udbraumann]

Thanks, but apparently I obtain the same error in the compiler-rt part using gmake:

:info:build /opt/local/bin/ar cru 2> /dev/null /Volumes/Data/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_llvm-3.4/clang-3.4/work/llvm-3.4/tools/clang/runtime/compiler-rt/clang_darwin_embedded/soft_static/armv6m/libcompiler_rt.a /Volumes/Data/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_llvm-3.4/clang-3.4/work/llvm-3.4/tools/clang/runtime/compiler-rt/clang_darwin_embedded/soft_static/armv6m/SubDir.lib/int_util.o
:info:build Makefile:267: recipe for target '/Volumes/Data/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_llvm-3.4/clang-3.4/work/llvm-3.4/tools/clang/runtime/compiler-rt/clang_darwin_embedded/soft_static/armv6m/libcompiler_rt.a' failed
:info:build gmake[4]: *** [/Volumes/Data/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_llvm-3.4/clang-3.4/work/llvm-3.4/tools/clang/runtime/compiler-rt/clang_darwin_embedded/soft_static/armv6m/libcompiler_rt.a] Error 1

Do you possibly have further ideas?

[jeremyhu (Jeremy Huddleston Sequoia)]

No ideas, sorry.

[jeremyhu (Jeremy Huddleston Sequoia)]

I suggest you remove that '2> /dev/null' from the Makefile (manually) then try again. That will cause the error to actually be printed.

[udbraumann]

Was not sure which Makefile is the right one, so I just did a manual call of the failing command without suppressing output:

$ sudo /opt/local/bin/ar cru /Volumes/Data/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_llvm-3.4/clang-3.4/work/llvm-3.4/tools/clang/runtime/compiler-rt/clang_darwin_embedded/soft_static/armv6m/libcompiler_rt.a /Volumes/Data/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_llvm-3.4/clang-3.4/work/llvm-3.4/tools/clang/runtime/compiler-rt/clang_darwin_embedded/soft_static/armv6m/SubDir.lib/int_util.o 
/opt/local/bin/ranlib: object: /Volumes/Data/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_llvm-3.4/clang-3.4/work/llvm-3.4/tools/clang/runtime/compiler-rt/clang_darwin_embedded/soft_static/armv6m/libcompiler_rt.a(int_util.o) malformed object (unknown load command 1)
/opt/local/bin/ar: internal ranlib command failed

So what is basically says with respect to in_util.o when trying to build up libcompiler_rt.a: ranlib complains about a "malformed object (unknown load command 1)". What does this mean? What can I do?

[jeremyhu (Jeremy Huddleston Sequoia)]

That doesn't make sense... /opt/local/bin/ranlib is your MacPorts' provided cctools. It should be up to date...

Oh wait, this is on Leopard, so you have an older cctools in order to support ppc, so it doesn't know about newer load commands...

ugg...

[jeremyhu (Jeremy Huddleston Sequoia)]

Could you attach your int_util.o file?

[udbraumann]

Replying to jeremyhu@…:

Could you attach your int_util.o file?

Have added the int_util.o which has let /opt/local/bin/ranlib fail during my last building attempts. Curious what you are going to try.

[jeremyhu (Jeremy Huddleston Sequoia)]

Load command 1
      cmd LC_DATA_IN_CODE
  cmdsize 16
  dataoff 468
 datasize 8

[udbraumann]

Replying to jeremyhu@…: Is this list a description of the mysterious "unknown load command 1" which seemingly cannot be handled in Leopard's cctools @806_3? What consequences can be drawn from these parameters?

[jeremyhu (Jeremy Huddleston Sequoia)]

The issue is that your version of cctools does not support LC_DATA_IN_CODE.

Options:

1. Update llvm to not emit it.
2. Update cctools to support it.

I won't have time to look at either until mid-May or June at the earliest.

[khepler]

Cc Me!

[khepler]

For what it's worth (which remains to be seen; I haven't tested it at all), cctools @855_1+llvm34 builds on Leopard/PPC with the snowleopard-strnlen.patch. I'll wait until someone asks for the Portfile, because I'm skeptical that this actually works.

[khepler]

I am admittedly in over my head, however it seems clang-3.4 tries to use the GCC ld:

[Vertigo:~/Projects/C++/UniqueString] kris% time clang++-mp-3.4 -O2 -v -o unique.clang34 main.cpp
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 -main-file-name main.cpp -mrelocation-model static -mdisable-fp-elim -fmath-errno -target-linker-version 97.17 -v -resource-dir /opt/local/libexec/llvm-3.4/bin/../lib/clang/3.4.2 -O2 -fdeprecated-macro -fno-dwarf2-cfi-asm -fno-dwarf-directory-asm -fno-autolink -fdebug-compilation-dir /Users/kris/Projects/C++/UniqueString -ferror-limit 19 -fmessage-length 192 -mstackrealign -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops -vectorize-slp -o /var/tmp/main-b2dc29.s -x c++ main.cpp
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"
ignoring nonexistent directory "/usr/include/c++/4.0.0/powerpc-apple-darwin10/"
ignoring nonexistent directory "/usr/local/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/4.0.0
 /usr/include/c++/4.0.0/backward
 /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++" -O2 -v -c -arch ppc -m32 -o /var/tmp/main-abd300.o -x assembler /var/tmp/main-b2dc29.s
Using built-in specs.
Target: powerpc-apple-darwin9
Configured with: /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_apple-gcc42/apple-gcc42/work/objroot/src/configure --disable-checking --enable-werror --prefix=/opt/local --mandir=/opt/local/share/man --enable-languages=c,c++,objc,obj-c++ --libexecdir=/opt/local/libexec/apple-gcc42 --libdir=/opt/local/lib/apple-gcc42 --includedir=/opt/local/include/apple-gcc42 --program-suffix=-apple-4.2 --with-system-zlib --disable-nls --with-slibdir=/usr/lib --build=powerpc-apple-darwin9 --with-gxx-include-dir=/usr/include/c++/4.0.0 --host=powerpc-apple-darwin9 --target=powerpc-apple-darwin9
Thread model: posix
gcc version 4.2.4 (Apple Inc. build 5666) (dot 3) (MacPorts apple-gcc42 5666.3_14+gpl3)
 /opt/local/libexec/apple-gcc42/gcc/powerpc-apple-darwin9/4.2.4/as -arch ppc -o /var/tmp/main-abd300.o /var/tmp/main-b2dc29.s
 "/opt/local/bin/g++" -O2 -v -arch ppc -m32 -o unique.clang34 /var/tmp/main-abd300.o
Using built-in specs.
Target: powerpc-apple-darwin9
Configured with: /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_apple-gcc42/apple-gcc42/work/objroot/src/configure --disable-checking --enable-werror --prefix=/opt/local --mandir=/opt/local/share/man --enable-languages=c,c++,objc,obj-c++ --libexecdir=/opt/local/libexec/apple-gcc42 --libdir=/opt/local/lib/apple-gcc42 --includedir=/opt/local/include/apple-gcc42 --program-suffix=-apple-4.2 --with-system-zlib --disable-nls --with-slibdir=/usr/lib --build=powerpc-apple-darwin9 --with-gxx-include-dir=/usr/include/c++/4.0.0 --host=powerpc-apple-darwin9 --target=powerpc-apple-darwin9
Thread model: posix
gcc version 4.2.4 (Apple Inc. build 5666) (dot 3) (MacPorts apple-gcc42 5666.3_14+gpl3)
 /opt/local/libexec/apple-gcc42/gcc/powerpc-apple-darwin9/4.2.4/collect2 -dynamic -arch ppc -macosx_version_min 10.5.8 -weak_reference_mismatches non-weak -o unique.clang34 -lcrt1.10.5.o -L/opt/local/lib/apple-gcc42/gcc/powerpc-apple-darwin9/4.2.4 -L/opt/local/lib/apple-gcc42/gcc/powerpc-apple-darwin9/4.2.4/../../.. /var/tmp/main-abd300.o -lstdc++ -lgcc_s.10.5 -lgcc -lSystemStubs -lSystem
ld: absolute address to symbol std::basic_string<char, std::char_traits<char>, std::allocator<char> >::_Rep::_S_empty_rep_storagein a different linkage unit not supported in _main from /var/tmp/main-abd300.o
collect2: ld returned 1 exit status
clang: error: linker (via gcc) command failed with exit code 1 (use -v to see invocation)
2.716u 0.288s 0:03.54 84.4%     0+0k 0+56io 0pf+0w

The "UniqueString" project is a trivial academic exercise. I'm only using it to avoid re-writing HelloWorld.cpp for the 800th time.

After much web searching I have the impression Clang falls-back to linking with GCC when it doesn't have a "toolchain" defined for the current platform.

Dunno what else I can do at this point.

[jeremyhu (Jeremy Huddleston Sequoia)]

This isn't something that we'll be putting effort into. There are some developers at llvm.org working to improve Leopard/ppc and Tiger/ppc, and if that ever stabilizes, we'll certainly support it in a newer llvm port.

[dgonyier (Dwaine Gonyier)]

Cc Me!

[devernay (Frédéric Devernay)]

Cc Me!

[Schamschula (Marius Schamschula)]

Cc Me!

[ken-cunningham-webuse]

For closure, clang now builds without issue on 10.5.8 PPC

port -v installed | grep clang
  clang-3.3 @3.3_11+analyzer+python27 (active) platform='darwin 9' archs='ppc'
  clang-3.4 @3.4.2_12+analyzer (active) platform='darwin 9' archs='ppc'
  clang_select @2_0 (active) platform='darwin 9' archs='noarch'

how it actually works is another story ...