Re: Problems due to platform binutils

On 4/4/26 11:19, Paul Floyd wrote:
> Hi
> 
> Bah, clicked send before I'd finished.
> 
> I'm looking at some Valgrind testcase failures when I run the testsuite
> on the GCC build server farm FreeBSD machines. I haven't yet asked how
> the servers were installed. uname says
> 
> 16.0-CURRENT FreeBSD 16.0-CURRENT main-n284729-ccc235fe0229 GENERIC arm64
> 
> and
> 
> 
> 16.0-CURRENT FreeBSD 16.0-CURRENT main-n284742-7b6be0014a4e GENERIC amd64
> 
> They both have GNU binutils and platform binutils installed
> 
> pkg info | grep binutils
> aarch64-binutils-2.44,1        GNU binary tools
> binutils-2.44,1                GNU binary tools
> elfutils-0.187_3               Library for manipulating ELF files and
> partial implementation of binutils
> 
> (amd64-binutils-2.44 on the amd64 machine).
> 
> clang seems to want to use this ld.bfd ( /usr/local/bin/aarch64-unknown-
> freebsd16.0-ld) rather than /usr/bin/ld (which is ld.lld).

That is a long-term known property that breaks various things when
/usr/local/bin/PLATFORM-unknown-freebsd??.0-ld is present to find. It
does not fit nicely in a FreeBSD context in my view: there is no
notification of a port-package installation of such overriding system
command behavior that takes an extra command line argument to avoid.

I have been involved in example message list exchanges referencing the
issue spanning 2016-Nov .. 2024-Dec . It is only about 101 messages in
my Email archive (not all mine).

> 
> I did see one issue because of this which I've now fixed. The
> alternative is to use something like LDFLAGS=-fuse-ld=/usr/bin/ld.

In the past, I've used: -fuse-ld=lld
It avoided having to be explicit about the path but also avoided the
specific PLATFORM-unknown-freebsd??.0-ld use.

> 
> The other thing that I'm seeing is quite a few failures that look like
> they are because the servers were installed from source .
> 
> For instance
> 
> --- annotate_barrier.stderr.exp2025-11-22 18:33:32.333659000 +0000
> +++ annotate_barrier.stderr.out2026-04-04 16:46:36.872126000 +0000
> @@ -25,7 +25,7 @@
> Conflicting store by thread 2 at 0x........ size 4
>    at 0x........: threadfunc (annotate_barrier.c:?)
>    by 0x........: vgDrd_thread_wrapper (drd_pthread_intercepts.c:?)
> -   by 0x........: start_thread
> +   by 0x........: ??? (worktrees/main/lib/libthr/thread/thr_create.c:299)
> Address 0x........ is at offset 0 from 0x......... Allocation context:
>    at 0x........: malloc (vg_replace_malloc.c:...)
>    by 0x........: barriers_and_races (annotate_barrier.c:?)
> 
> That one is a but odd, I wonder why I'm getting file and line but not
> function name.
> 
> We already have a lot of filtering to make the results as platform
> independent as possible. Other than extending that filtering to cover
> all these extra cases does anyone else have any experience with this
> kind of issue on FreeBSD?
> 
> There are also massif and helgrind failures that I don't yet understand.
> 
> A+
> 
> Paul
> 
> 
> 


-- 
===
Mark Millard
marklmi at yahoo.com