Total confusion over toolchain/xdev behavior [redux]

[Andrew Turner]

On Tue, 16 Sep 2014 09:06:33 -0700
Sean Bruno <sbruno at 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