Current configure script assumes that ld on Linux has a default list of
library search paths, like GNU ld.bfd. This caused problems when testing
`mold --run cproc', since mold[1] has no default search paths. While this is
easily fixed by passing -L/usr/lib, ld errors are not known for being
user-friendly or easily diagnosed. To support greater variety of `ld's on
Linux, should -L /usr/lib be added to linkflags?

Pros: ability to swap out any part of the toolchain is in the spirit of the
project, since cproc itself is likely to be dropped in to replace gcc/clang

Cons: personally I have no experience on any Linux where /{usr/,}lib{,64}
didn't all point to the same location; is there any occasion where the
configure script would have to guess a distinction between them?

[1]: https://github.com/rui314/mold

On Sat, Feb 8, 2025, at 21:12, lhr@disroot.org wrote:
> Current configure script assumes that ld on Linux has a default list of
> library search paths, like GNU ld.bfd. This caused problems when testing
> `mold --run cproc', since mold[1] has no default search paths. While this is
> easily fixed by passing -L/usr/lib, ld errors are not known for being
> user-friendly or easily diagnosed. To support greater variety of `ld's on
> Linux, should -L /usr/lib be added to linkflags?

I am not sure I understand the problem you are facing. Can it be
solved by building qbe with `make LDFLAGS="-L /usr/lib"`? If so
I'd be reluctant to change the Makefile as it's been working for
most for a while now.