Subject: RE: [RFC PATCH 3/6] contrib/cgit-rs: introduce Rust wrapper for libgit.a

From: <[email-masked]>
Date: Thu, 8 Aug 2024 16:14:19 -0400

On Thursday, August 8, 2024 3:58 PM, Junio C Hamano wrote:
><[email-masked]> writes:
>
>> I got to:
>>
>> ld -r contrib/cgit-rs/public_symbol_export.o libgit.a
>> reftable/libreftable.a xdiff/lib.a -o
>> contrib/cgit-rs/partial_symbol_export.o
>> /usr/bin/c89: illegal option -- r
>>
>> The -r option is not supported on NonStop. I think we had discussed this.
>
>Does it happen to call the feature under different name?  'r' stands for
relocatable
>output, but some linkers may call the feature as incremental linking and
use '-i'.

Well... depends on some factors. ld should not be run directly. Other links
are done
via the CC setting in config.mak.uname. That would invoke c99 for us for the
linker
as with the rest of git C, and that would make thinks somewhat easier as the
linker
is either xld or eld depending on the hardware.

The -Wr option to c99 creates a load file in this situation, which might or
might not
work. I need to look at it after built. I don't think it is what we want.
What I think
we need is -Wxld=unres_symbols ignore which builds an object that can be
linked to other objects even with undefined link symbols - although maybe
not.
I need to be able to select a different option on ia64, but that may not
matter
much. I still worry that we are depending on non-portable linker semantics
that
may not give the result we ultimately want.

Would not the build option be best selected in config.mak.uname?

Maybe GITRS_LINKER= or GITRS_CFLAGS=, etc.