Re: Any known way to build devel/llvm* ( such as devel/llvm19 ) with --threads=1 for its linker activity during the build?

On Aug 6, 2024, at 11:27, Mark Millard <[email protected]> wrote:

> On Aug 6, 2024, at 01:56, [email protected] wrote:
> 
> . . .
>> Mark, I think that root case of your problems is that you're trying to link with libraries (shared or local) with debug information (unstriped).
> 
> Seems likely that more needs to be stripped (or never generated)
> than before. I'll probably manage to regenerate the armv7 context
> and test that at some point. It is definitely true that I've
> historically kept more of such information around than FreeBSD
> does on its own for optimized code: with symbols or debug
> information. But it seems that such no longer fits in the armv7
> context for what I've historically done.

Confirmed. Use of -gline-tables-only instead of -g allowed
lang/rust to build and allowed devel/llvm19 to reach the error
that you had reported, getting well past the earlier failure
point.

But clang*'s -gline-tables-only looks to enable a subset of
gcc*'s -g1 and the two do not have a common command line
notation. This lead to lang/gcc14 failing to build (unlike
before) for how I did this experiment:

checking for suffix of object files... configure: error: in `/wrkdirs/usr/ports/lang/gcc14/work/.build/armv7-portbld-freebsd15.0/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details
gmake[1]: *** [Makefile:13527: configure-target-libgcc] Error 1
gmake[1]: *** Waiting for unfinished jobs....


>> This causes a huge memory consumption. I don't remember if it just wastes address space (because  mmapping a large library but never accessing the debugging information) or if it accessing the debugging information (so the link needs physical memory for it as well).



===
Mark Millard
marklmi at yahoo.com