In my attempt to build Kyua on FreeBSD 9.1 powerpc64 with clang++, I have encountered a problem that smells like a compiler or toolchain issue. I don't know if this is a clang issue, or a clang issue only on powerpc64, but I don't have access to any other FreeBSD system to compare the results to. FWIW, building Kyua with GCC on this very same installation works just fine. I'm using Kyua sources from the upstream git repository, which can be found on http://code.google.com/p/kyua . My FreeBSD 9.1 installation is built from sources from yesterday (20130420). The error I've got from the build is as follows, which I've tweaked to use ld's -v flag for further details. This problem if fully reproducible now, so please, if you need any further details or intermediate files to debug this issue further, do not hesitate to ask! ===== make all-am clang++ -v -I/usr/local/include/lua51 -I/home/jmmv/os/local/include -I/usr/local/include/lua51 -I/home/jmmv/os/local/include -I/usr/local/include/lua51 -I/home/jmmv/os/local/include -I/usr/local/include -I/usr/local/include/lua51 -I/home/jmmv/os/local/include -I/usr/local/include/lua51 -I/home/jmmv/os/local/include -I/usr/local/include/lua51 -I/home/jmmv/os/local/include -I/usr/local/include -I/usr/local/include/lua51 -I/home/jmmv/os/local/include -I/usr/local/include/lua51 -I/home/jmmv/os/local/include -I/usr/local/include/lua51 -I/home/jmmv/os/local/include -I/usr/local/include -I/usr/local/include/lua51 -I/home/jmmv/os/local/include -I/usr/local/include/lua51 -I/home/jmmv/os/local/include -I/usr/local/include/lua51 -I/home/jmmv/os/local/include -I/usr/local/include -I/usr/local/include/lua51 -I/home/jmmv/os/local/include -I/usr/local/include/lua51 -I/home/jmmv/os/local/include -I/usr/local/include/lua51 -I/home/jmmv/os/local/include -I/usr/local/include -I/usr/local/i nclude/lua51 -I/home/jmmv/os/local/include -I/usr/local/include/lua51 -I/home/jmmv/os/local/include -I/usr/local/include/lua51 -I/home/jmmv/os/local/include -I/usr/local/include -I/usr/local/include/lua51 -I/home/jmmv/os/local/include -I/usr/local/include/lua51 -I/home/jmmv/os/local/include -I/usr/local/include/lua51 -I/home/jmmv/os/local/include -I/usr/local/include -O2 -D_FORTIFY_SOURCE=2 -Wall -Wcast-qual -Wextra -Wpointer-arith -Wredundant-decls -Wreturn-type -Wshadow -Wsign-compare -Wswitch -Wwrite-strings -Werror -Wabi -Wctor-dtor-privacy -Wno-deprecated -Wnon-virtual-dtor -Woverloaded-virtual -Wreorder -Wsign-promo -Wsynth -Wl,-R/home/jmmv/os/local/lib -o kyua kyua-main.o libcli.a libengine.a libstore.a libengine.a libutils.a -L/usr/local/lib/lua51 -llua -lm -L/home/jmmv/os/local/lib -llutok -L/usr/local/lib/lua51 -llua -lm -L/home/jmmv/os/local/lib -llutok -L/usr/local/lib/lua51 -llua -lm -L/home/jmmv/os/local/lib -llutok -L/usr/local/lib -lsqlite3 libutils.a - L/usr/local/lib/lua51 -llua -lm -L/home/jmmv/os/local/lib -l! lutok -L/usr/local/lib/lua51 -llua -lm -L/home/jmmv/os/local/lib -llutok -L/usr/local/lib/lua51 -llua -lm -L/home/jmmv/os/local/lib -llutok -L/usr/local/lib -lsqlite3 libstore.a libengine.a libutils.a -L/usr/local/lib/lua51 -llua -lm -L/home/jmmv/os/local/lib -llutok -L/usr/local/lib/lua51 -llua -lm -L/home/jmmv/os/local/lib -llutok -L/usr/local/lib/lua51 -llua -lm -L/home/jmmv/os/local/lib -llutok -L/usr/local/lib -lsqlite3 libutils.a -L/usr/local/lib/lua51 -llua -lm -L/home/jmmv/os/local/lib -llutok -L/usr/local/lib/lua51 -llua -lm -L/home/jmmv/os/local/lib -llutok -L/usr/local/lib/lua51 -llua -lm -L/home/jmmv/os/local/lib -llutok -L/usr/local/lib -lsqlite3 libengine.a libstore.a libengine.a libutils.a -L/usr/local/lib/lua51 -llua -lm -L/home/jmmv/os/local/lib -llutok -L/usr/local/lib/lua51 -llua -lm -L/home/jmmv/os/local/lib -llutok -L/usr/local/lib/lua51 -llua -lm -L/home/jmmv/os/local/lib -llutok -L/usr/local/lib -lsqlite3 libutils.a -L/usr/local/lib/lua51 -llua -lm -L/home/jmmv/os/local/lib -llutok -L/usr/local/lib/lua51 -llua -lm -L/home/jmmv/os/local/lib -llutok -L/usr/local/lib/lua51 -llua -lm -L/home/jmmv/os/local/lib -llutok -L/usr/local/lib -lsqlite3 libutils.a -L/usr/local/lib/lua51 -llua -lm -L/home/jmmv/os/local/lib -llutok -L/usr/local/lib/lua51 -llua -lm -L/home/jmmv/os/local/lib -llutok -L/usr/local/lib/lua51 -llua -lm -L/home/jmmv/os/local/lib -llutok -L/usr/local/lib -lsqlite3 FreeBSD clang version 3.2 (tags/RELEASE_32/final 170710) 20121221 Target: powerpc64-unknown-freebsd9.1 Thread model: posix "/usr/bin/ld" --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 --enable-new-dtags -o kyua /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/local/lib/lua51 -L/home/jmmv/os/local/lib -L/usr/local/lib/lua51 -L/home/jmmv/os/local/lib -L/usr/local/lib/lua51 -L/home/jmmv/os/local/lib -L/usr/local/lib -L/usr/local/lib/lua51 -L/home/jmmv/os/local/lib -L/usr/local/lib/lua51 -L/home/jmmv/os/local/lib -L/usr/local/lib/lua51 -L/home/jmmv/os/local/lib -L/usr/local/lib -L/usr/local/lib/lua51 -L/home/jmmv/os/local/lib -L/usr/local/lib/lua51 -L/home/jmmv/os/local/lib -L/usr/local/lib/lua51 -L/home/jmmv/os/local/lib -L/usr/local/lib -L/usr/local/lib/lua51 -L/home/jmmv/os/local/lib -L/usr/local/lib/lua51 -L/home/jmmv/os/local/lib -L/usr/local/lib/lua51 -L/home/jmmv/os/local/lib -L/usr/local/lib -L/usr/local/lib/lua51 -L/home/jmmv/os/local/lib -L/usr/local/lib/lua51 -L/home/jmmv/os/local/lib -L/usr/local/lib/lua51 -L/home/jmmv/os/local/lib -L/usr/local/lib -L/usr/local/lib/lua51 - L/home/jmmv/os/local/lib -L/usr/local/lib/lua51 -L/home/jmmv/os/local/lib -L/usr/local/lib/lua51 -L/home/jmmv/os/local/lib -L/usr/local/lib -L/usr/local/lib/lua51 -L/home/jmmv/os/local/lib -L/usr/local/lib/lua51 -L/home/jmmv/os/local/lib -L/usr/local/lib/lua51 -L/home/jmmv/os/local/lib -L/usr/local/lib -L/usr/lib -R/home/jmmv/os/local/lib kyua-main.o libcli.a libengine.a libstore.a libengine.a libutils.a -llua -lm -llutok -llua -lm -llutok -llua -lm -llutok -lsqlite3 libutils.a -llua -lm -llutok -llua -lm -llutok -llua -lm -llutok -lsqlite3 libstore.a libengine.a libutils.a -llua -lm -llutok -llua -lm -llutok -llua -lm -llutok -lsqlite3 libutils.a -llua -lm -llutok -llua -lm -llutok -llua -lm -llutok -lsqlite3 libengine.a libstore.a libengine.a libutils.a -llua -lm -llutok -llua -lm -llutok -llua -lm -llutok -lsqlite3 libutils.a -llua -lm -llutok -llua -lm -llutok -llua -lm -llutok -lsqlite3 libutils.a -llua -lm -llutok -llua -lm -llutok -llua -lm -llutok -lsqlite3 -lstdc++ -lm -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-! needed -lgcc_s --no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o /usr/bin/ld: kyua: section `.got' can't be allocated in segment 3 /usr/bin/ld: final link failed: Bad value clang++: error: linker command failed with exit code 1 (use -v to see invocation) *** [kyua] Error code 1 Stop in /home/jmmv/os/kyua/src. *** [all] Error code 1 Stop in /home/jmmv/os/kyua/src. ===== How-To-Repeat: Supposedly: 1) Fetch Kyua git sources from upstream. 2) Set CC=clang CXX=clang++ CPP=clang-cpp . 3) Configure and attempt to build the package. You'll get the error above at the very end of the process, during linking.
Does this still happen with latest? There are hoops to jump through to build head's clang, as it doesn't build with base gcc (need to buildworld with CC=clang CXX=clang, or gcc48, etc). I've successfully built many binaries on FreeBSD, and I believe most, if not all, of head can be built with clang now (except csu, which still needs gcc to build).
It's been 2 years since the last request for update. I've built many binaries on FreeBSD head with clang since then, but have not tried to reproduce the test conditions.
[This is not an objection to closing 178038. It is more of a status note since while kyua builds it does not work.] I've built kyua via system clang 3.8 and later for powerpc family members. The builds completed. But even as of clang 4.0 the code generation is bad and kyua fails to run. This is for both TARGET_ARCH=powerpc64 and TARGET_ARCH=powerpc. All of the below applies to clang 4.0 (so far). kyua makes extensive use of C++ exception handling, among other things. One problem for both TARGET_ARCH's is that handling thrown C++ exceptions is messed up. Even: #include <exception> int main(void) { try { throw std::exception(); } catch (std::exception& e) {} return 0; } fails. This makes kyua currently useless. TARGET_ARCH=powerpc also has problems with use and restore of R31 when floating point code is involved (restored for returning but later used for floating point code expecting R31 to not have been restored yet). (There may be more issues for one or both TARGET_ARCH's but the above is sufficient to classify clang as broken for kyua.)
Sorry, I don't have my powerpc64 machine any longer, so I cannot try to see if this is fixed.