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

[Martin Husemann <martin%duskware.de@localhost>]

On Sat, Mar 22, 2025 at 12:27:30AM +0100, Anthony Mallet wrote:
> So I was wondering if not linking a dlopen-able module with nothing
> would be the correct approach
> ... or if maybe it would be better to hardcode the libraries, like in:
>   output_verbose_link_cmd='func_echo_all -lstdc++ -lm -gcc_s -lc'
> ... or if the above 'sed' should be updated to just remove "-lgcc",
> even though I don't feel that this would be the right approach.

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.

If you look at the symbols it provides there are things like (random
example from a powerpc machine):

00000000 T __fixunsdfdi

which are required on some CPUs but are handled inline on others (if the
CPU provides a simple instruction to do the operation or gcc has a pattern
to expand it inline).

We try to also provide most of those symbols from libc and in this 
case we actually do:

         U __fixunsdfdi
00000000 T __fixunsdfdi

but I wouldn't bet on every architecture required microcode symbol being
available w/o libgcc.a (maybe we should guarnatee that and have tests
to check that at build time).


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

Martin