I had to revert /usr/local/aarch64-freebsd from 2.28 for its bin/ld to work for -r315870 buildworld (adm64 -> arm64 cross build)

[Mark Millard]

On 2017-Mar-26, at 5:07 AM, Li-Wen Hsu <lwhsu at freebsd.org> wrote:

On Fri, Mar 24, 2017 at 11:31 AM, Mark Millard <markmi at dsl-only.net> wrote:
> Building /usr/obj/pine64_clang/arm64.aarch64/usr/src/lib/libc/libc.so.7.full
> --- libc.so.7.full ---
> building shared library libc.so.7
> /usr/local/aarch64-freebsd/bin/ld: getutxent.pico(.debug_info+0x3b): R_AARCH64_ABS64 used with TLS symbol udb
> /usr/local/aarch64-freebsd/bin/ld: getutxent.pico(.debug_info+0x58): R_AARCH64_ABS64 used with TLS symbol uf
> /usr/local/aarch64-freebsd/bin/ld: utxdb.pico(.debug_info+0x5a): R_AARCH64_ABS64 used with TLS symbol futx_to_utx.ut
> /usr/local/aarch64-freebsd/bin/ld: jemalloc_tsd.pico(.debug_info+0x3c): R_AARCH64_ABS64 used with TLS symbol __je_tsd_tls
> /usr/local/aarch64-freebsd/bin/ld: jemalloc_tsd.pico(.debug_info+0x146e): R_AARCH64_ABS64 used with TLS symbol __je_tsd_initialized
> /usr/local/aarch64-freebsd/bin/ld: cxa_thread_atexit_impl.pico(.debug_info+0x3b): R_AARCH64_ABS64 used with TLS symbol dtors
> /usr/local/aarch64-freebsd/bin/ld: xlocale.pico(.debug_info+0x403): R_AARCH64_ABS64 used with TLS symbol __thread_locale
> /usr/local/aarch64-freebsd/bin/ld: setrunelocale.pico(.debug_info+0x3c): R_AARCH64_ABS64 used with TLS symbol _ThreadRuneLocale
> cc: error: linker command failed with exit code 1 (use -v to see invocation)
> 
> I also see this on our CI server: https://ci.freebsd.org/job/FreeBSD-head-aarch64-build/ , this job began failing since aarch64-binutils upgraded to 2.28 on pkg.freebsd.org.
> 
> Should we revert this change for now?  Or the fix is being prepared?

I have no clue about any effort to fix the problem.

I noticed this after first doing a self-hosted amd64 update.
Once I noticed the amd64 -> arm64 problem (the next thing
that I tried), I also reverted for targeting armv6/v7 and
for targeting powerpc64 and powerpc without testing 2.28 for
them. I had to in order to complete targeting arm64 because
of the slave-port status that had me revert devel/binutils
itself as well.

So I do not even know if TARGET_ARCH=aarch64 is the only
problem area.

I've no say in if something like this is reverted but I'd
guess that unless the time frame for a fix is known to be
rather short it would be reverted until there is an
expected-fix available.

===
Mark Millard
markmi at dsl-only.net