fixing "libtool -module" for C++

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

Hi,

I recently noticed that autoconf generated "libtool" scripts fail to
build so-called "modules" when using the C++ linker, and I wanted to
investigate that. That might not be the most appropriate list to post
this to, and if you've got a better idea, please redirect me :)

So, I'm willing to fix this kind of commands:
$ ...some/build/dir/libtool --tag=CXX --mode=link g++ -module -o foo.so foo.cc
that is meant to build a shared object that can be dlopen'ed (libtool
"module" in libtool's jargon).
This currently fails with:
*** Warning: linker path does not have real file for library -lgcc.
[...]
*** Last file checked: /usr/lib/libgcc.a

In short, libtool refuses to link a shared library foo.so with a
static libgcc.a. Oh, well.

This libtool failure is essentially due to libtool.m4 doing:
$ g++ -v -shared foo.o
to figure out which libraries are to be linked to a C++ shared library.
This turns out to be: -lstdc++ -lm -lgcc_s -lgcc -lc

I see in our gcc specs (from
/usr/src/external/gpl3/gcc/dist/gcc/config/netbsd-elf.h) that both
-lgcc_s and -lgcc are expected to be there for the !static case, so I
assume the above list of libraries is fine.

The libtool magic command is defined in
/usr/pkg/share/aclocal/libtool.m4, line 7127 in our current pkgsrc
libtool package (2.4.7r1). Here is the excerpt:

7126: # Workaround some broken pre-1.5 toolchains
7127: output_verbose_link_cmd='$CC -shared $CFLAGS -v conftest.$objext 2>&1 | $GREP conftest.$objext | $SED -e "s:-lgcc -lc -lgcc::"'

This line (and the comment) were added to (the upstream) libtool like
more than 20 years ago, apparently when we were still at netbsd-1.5 :)

What strikes me is the nowadays useless "sed" that does not sed
anything (check it, the list of libraries has changed), but
whose intent is apparently to remove -lgcc.

Indeed, if I replace the above excerpt with the libtool equivalent of
'void', that is:
  output_verbose_link_cmd='func_echo_all'
then libtool happily links the "module" without complaining, although
it does not link any system library (e.g. not even -lstdc++), which
may be an issue?

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.

If anyone has some more insights ... that would help me filing an
upstream libtool bug and try to sort this out.

Sorry for the lengthy mail, it's not easy at all to summarize this in a
readable way :)

Cheers,
Anthony