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