Date: Fri, 10 Feb 2017 15:01:42 +0000 From: "Meyer, Wolfgang" <wolfgang.meyer@hob.de> To: "'freebsd-arm@FreeBSD.org'" <freebsd-arm@FreeBSD.org>, "'freebsd-toolchain@FreeBSD.org'" <freebsd-toolchain@FreeBSD.org> Subject: How to get a crosscompile toolchain for aarch64 for use in poudriere[?] Message-ID: <EC88118611AE564AB0B10C6A4569004D015C063770@HOBEX11.hob.de>
next in thread | raw e-mail | index | archive | help
Hello, I am gaining experience in building packages for aarch64 on an amd64 host u= sing poudriere and it works (most of the time) quite well but it is really = slow. In order to accelerate the build I wanted to crosscompile within poudriere = using the instructions provided in http://phaq.phunsites.net/2015/10/11/freebsd-on-armv6-cross-compile-perform= ance-optimization-for-poudriere/comment-page-1/ and getting it to work with aarch64. The first problems arose when trying to build the xdev target: > make XDEV=3Darm64 XDEV_ARCH=3Daarch64 xdev The build fails and after doing some not very educated hacks to workaround = the problems I get to the point where I do not have a clue on how to fix th= is. The error message looks like: =3D=3D=3D> lib/libc++ (obj,all,install) c++ -isystem //usr/aarch64-freebsd/usr/include -L//usr/aarch64-freebsd/usr/= lib --sysroot=3D//usr/aarch64-freebsd/ -B//usr/aarch64-freebsd/usr/libexec= -B//usr/aarch64-freebsd/usr/bin -B//usr/aarch64-freebsd/usr/lib -O2 -pip= e -isystem /usr/FBSD_src/src_head/contrib/libc++/include -isystem /usr/FBSD= _src/src_head/contrib/libcxxrt -nostdinc++ -nostdlib -DLIBCXXRT -MD -MF.dep= end.algorithm.o -MTalgorithm.o -fstack-protector-strong -Qunused-arguments = -std=3Dc++11 -Wno-c++11-extensions -c /usr/FBSD_src/src_head/contrib/libc= ++/src/algorithm.cpp -o algorithm.o In file included from /usr/FBSD_src/src_head/contrib/libc++/src/algorithm.c= pp:11: In file included from /usr/FBSD_src/src_head/contrib/libc++/include/random:= 1638: /usr/FBSD_src/src_head/contrib/libc++/include/cmath:313:12: error: no membe= r named 'signbit' in namespace 'std' using std::signbit; ~~~~~^ ... + some more errors of the same kind. Hence I tried another way to get a crosscompile toolchain for use in poudri= ere. When crosscompiling on the host we use at the moment the stuff generat= ed by the kernel-toolchain target of the src tree (+ the sysroot and + the = aarch64-binutils from the ports as the kernel-toolchain does not build a cr= osscompile lld for aarch64). So I looked whether I would be able to import = this setup in a poudriere jail. Therefore I made the kernel-toolchain build= with the MAKEOBJDIRPREFIX set to the /usr/obj dir within the jail as shown= in the above mentioned link. The contents of the $MAKEOBJDIRPREFIX/usr/src= /tmp/ directory were copied to the /usr/aarch64-freebsd dir in the jail to = have a seperated toolchain directory. In the first try I did not add a cross-linker hoping the native lld in the = jail would be able to do the work. Well it won't. After learning how to ent= er the poudriere jail and looking at the verbose output from the compilatio= n I concluded that the compiler seemed to work but the linker failed. Next = step was installing the aarch64-binutils from ports in the jail (in my /usr= /aarch-freebsd cross-toolchain directory). Still no success as the linker c= omplained about some ELF interpreter /libexec/ld-elf.so.1 not found error. Which I ascribed to the fact that the executables from the aarch64-b= inutls port are dynamically linked. Adding a LDFLAGS+=3D -all-static line to the binutils ports Makefile I was able to create a statically linke= d linker and installed it in my poudriere jail. Still no success though, as= again similar errors occured like for the usage of the native linker (comp= laining about missing crt1.o files and missing lgcc_somethings). To make the long story short, after comparing the verbose output of my comp= iling in the jails with that of a direct crosscompile I found out that it w= as able to correctly link some object files when providing absolute paths t= o the crt*.o files and correct library search path for the libgcc_something= libraries. Which of course doesn't help when the linker is implicitly call= ed by the compiler. Further research showed that I could crosscompile/link = when providing the --sysroot=3D/ flag to overwrite the sysroot configuratio= n from the build of the crosscompiler. Amending the lines CFLAGS+=3D--sysroot=3D/ CPPFLAGS+=3D--sysroot=3D/ (Don't know if needed) CXXFLAGS+=3D--sysroot=3D/ LDFLAGS+=3D--sysroot=3D/ to my poudriere make.conf file I finally was able to produce a working cros= s-compiled package for aarch64 in poudriere. And the gains are quite signif= icant (around 21 minutes for building pkg package with qemu-user emulation = vs 5 minutes using cross-compilation, native amd64 build in poudriere finis= hes in less than a minute). Still the creation of the cross-compiling toolchain seems to be quite cumbe= rsome. Hence advice on getting such a toolchain in a cleaner way (ideally p= robably a working build for the xdev target) are greatly appreciated. ________________________________ Follow HOB: - HOB: http://www.hob.de/redirect/hob.html - Xing: http://www.hob.de/redirect/xing.html - LinkedIn: http://www.hob.de/redirect/linkedin.html - HOBLink Mobile: http://www.hob.de/redirect/hoblinkmobile.html - Facebook: http://www.hob.de/redirect/facebook.html - Twitter: http://www.hob.de/redirect/twitter.html - YouTube: http://www.hob.de/redirect/youtube.html - E-Mail: http://www.hob.de/redirect/mail.html HOB GmbH & Co. KG Schwadermuehlstr. 3 D-90556 Cadolzburg Geschaeftsfuehrung: Klaus Brandstaetter, Zoran Adamovic AG Fuerth, HRA 5180 Steuer-Nr. 218/163/00107 USt-ID-Nr. DE 132747002 Komplementaerin HOB electronic Beteiligungs GmbH AG Fuerth, HRB 3416
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?EC88118611AE564AB0B10C6A4569004D015C063770>