Hello,
I would say that we aren't against taking in variables on the configure
command line for setting executables to use in the build, as that's a
well established standard way of doing just that with Autoconf. The
built in Autoconf macros for CC and similar executables pick up such
variables, so at least in principle I'm not against the idea of being
able to do so for the linker. I may have opinions, and I'm sure Magnus
would have too, on the particulars of how this is implemented.
Unfortunately, I can't comment on this particular implementation
proposal until it's submitted in a PR with the OCA signed.
/Erik
On 1/22/25 3:19 AM, Julian Waters wrote:
Hi!
I believe it's not a hard requirement that special variables can't be
used, just that it's strongly discouraged in favour of configure
options. I'm not sure if we support linker combinations other than the
one the compiler comes with, the extent of my knowledge is that I
think Oracle uses gold for gcc, but regardless you'd have to ask
Magnus for that. But the issue is still that different linkers might
need to be treated differently by the build system, and it might not
yet be prepared to use linkers like mold instead of lld
best regards,
Julian
On Wed, Jan 22, 2025 at 5:54 PM Bingwu Zhang <x...@envs.net> wrote:
Hi!
The patch I mentioned in last message will first try to resolve
the full,
absolute path of lld, and use --ld-path to pass the path to Clang.
It should
have the same effect as passing -fuse-ld=lld. If it failed to do
so, it will
fallback to use -fuse-ld=lld to let Clang pick up the proper linker.
btw it seems that CC and CXX is picked by the build system [1].
Why don't we
just pick up the variable?
I will later change it to use a configure option. How about
--with-linker-path?
Thanks! :)
[1] https://github.com/magicus/jdk/blob/
a62a870150cf199f16277b478af2f5d937255b3c/make/autoconf/toolchain.m4#L430
--
Bingwu Zhang
xtex @ Wed, 22 Jan 2025 09:45:35 +0000
