Date: Sat, 20 Sep 2014 10:55:47 +0100 From: Andrew Turner <andrew@fubar.geek.nz> To: Sean Bruno <sbruno@ignoranthack.me> Cc: freebsd-arch <freebsd-arch@freebsd.org> Subject: Re: Total confusion over toolchain/xdev behavior [redux] Message-ID: <20140920105547.673a54de@bender.lan> In-Reply-To: <1410883593.10088.9.camel@bruno> References: <1404688077.1059.115.camel@bruno> <1410883593.10088.9.camel@bruno>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 16 Sep 2014 09:06:33 -0700 Sean Bruno <sbruno@ignoranthack.me> wrote: ... > I've run into, what appears to be, a tool chain setup problem that I > don't quite grok. I suspect, we are not setting up the amd64-clang > toolchain inserted into the jail correctly. I.e. we are using an > external toolchain here, that is amd64 binaries configured to output > armv6 (all clang). > > I have identified a list of several ports (probably 40 or 50) that > seem to have the same failure case when "linking". Some are hidden by > "configure" while most fail the same way. In general it looks like > this: > > rm -f bltwish25 > /nxb-bin/usr/bin/cc -Wall -fPIC -O -pipe > -I/usr/local/include/tcl8.6/generic > -I/usr/local/include/tk8.6/generic -I/usr/local/include/tk8.6/unix > -DUSE_INTERP_RESULT -DUSE_INTERP_ERRORLINE -I.. -I./.. -I./../.. > -I/usr/local/include -I/usr/local/include/tk8.6 > -I/usr/local/include/tcl8.6 -o bltwish25 \ ./../bltUnixMain.c > libBLT25.so -L/usr/local/lib -ltk86 -ltcl86 -LNONE -lX11 > -L/usr/local/lib -ljpeg -lm /nxb-bin/usr/bin/ld: bltwish25: hidden > symbol `__aeabi_memcpy' in /usr/lib/libgcc.a(aeabi_memcpy.o) is > referenced by DSO /nxb-bin/usr/bin/ld: final link failed: > Nonrepresentable section on output cc: error: linker command failed > with exit code 1 (use -v to see invocation) gmake[3]: *** [bltwish25] > Error 1 > > full build log: > http://chips.ysv.freebsd.org/data/11armv632-default/2014-09-04_01h04m05s/logs/errors/blt-2.5.3_2.log The problem is the port is attempting to link the shared objects using ld directly however it's not linking these against libgcc which provides the needed symbol. The simple fix is to change the port to use the compiler to link the .so files. I've submitted a patch for the port to do this at [1]. With this patch I can build the port with no error. I don't know what the other ports are so am unable to look into if these have the same problem. A simple check is to see if they use cc or ld to perform the linking. Clang and gcc should both do the right thing and link against libgcc as needed. Andrew [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193791
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140920105547.673a54de>