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

Anthony Mallet <[email protected]> Sat, 22 Mar 2025 13:18:31 +0100
Newsgroups gmane.os.netbsd.devel.toolchain
Organization LAAS/CNRS - Toulouse - France
Message-ID <[email protected]>
On Saturday 22 Mar 2025, at 08:19, 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.

I naively thought that those symbols would also be in -lgcc_s, which I
was considering as the 'shared equivalent of -lgcc'. Isn't it the case?

For instance, using your fixunsdfdi example (x86_64):
$ nm /usr/lib/libgcc_s.so  | grep fixunsdfdi
000000000000b8c4 T __fixunsdfdi


> The typical reaction on the whole topic would probably be: why not
> use the c++ compiler frontend to do the linking? It knows best :-)

That was also my first thought ... I don't understand why libtool by
default wants to link with "-nostdlib" and then figure out whatever
library is required. But I guess that's the whole philosphy of the
project and submitting a patch that goes against this might be harder.


Unrelated question : do we still have non-ELF platforms?
Can this test still trigger nowadays?
  if echo __ELF__ | $CC -E - | $GREP __ELF__ >/dev/null; then