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
