Re: fixing "libtool -module" for C++

[Anthony Mallet <anthony.mallet%laas.fr@localhost>]

On Sunday 23 Mar 2025, at 20:21, Jörg Sonnenberger wrote:
> On 3/22/25 8:19 AM, Martin Husemann wrote:
> > I don't know anything about libtool, but not linking with -lgcc *might*
> > work on some modules on some platforms, but might fail on others
> > due to CPU differences.
>
> More specifically, there is something like millicode on some CPU which
> is never shared. I'm not 100% sure from memory right now if any of those
> are left with code in libgcc or if we provide a libc implementation at
> all times now, but that was a real concern in the past at least.

Ok, that's informative.
In the meantime, I also figured out that what gcc installs by default
as libgcc_s.so (e.g. from /usr/pkgsrc/lang/gcc12) is actually an ld
script that links with both libgcc_s and libgcc ... Our gcc specs from
base is much more clear in this respect.

So, according to this discussion, I ended up submitting a libtool
issue: https://savannah.gnu.org/support/?111210
It removes (on NetBSD) the command trying to figure out "hidden"
dependencies of the C++ linker and just uses a regular link command,
without -nostdlib. Let's see.

I also discovered that this part was updated a couple of weeks ago
(while it's probably been broken for years):
https://git.savannah.gnu.org/cgit/libtool.git/commit/?id=c7be1f229c
This works around the issue I was talking about, but I feel it's still
not the proper fix, as this simply removes -lgcc_s and -lgcc
altogether.

Cheers,
Anthony