[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

[Peter Rosin]

Follow-up Comment #24, sr #108201 (project libtool):

Hi again!

I have no quarel with the original change to augment
archive_expsym_cmds with ${wl}-h $wl$soname. That looks
like a no-brainer as it just matches archive_cmds. That
can go in at any time, as far as I'm concerned.

The testsuite change still needs work, even with the
change to use objdump. Enumerated list of problems:

1. objdump exists on non-ELF systems also, and is not
required to output a line with "SONAME" in it.
2. The check assumes that the generated library is named
liba.so.
3. The check assumes that a shared library is generated at
all.
4. Even if objdump (or elfdump) is present in $PATH, it
may not be valid to run it on the output from the toolchain
in use. Think cross-compiles. E.g. Cygwin provides elfedit,
but I don't think it has anything to do with the output of
Cygwin gcc/ld, it is provided for working with ELF binaries
generated elsewhere. I wouldn't be all that surprised if
binutils grows elfdump in the future, and that elfdump is
eventually included in Cygwin (or if a clash exists somewhere
else already) with obvious problems.

Regarding the zapping of $LDFLAGS, it is obviously wrong
to have it in there, e.g. it breaks the libtool -no-undefined
option. At the same time I'm weary of zapping it as I can
easily imagine that people have setups that might break if it
is removed. At the same time $LDFLAGS isn't included in
archive_expsym_cmds so it can't be all wrong to zap it from
archive_cmds as well. But your patch might indicate that
archive_expsym_cmds isn't used all that much and receives
little testing?

Again, I'm not qualified to resolve these issues, but my
*guess* is that $LDFLAGS could be removed from archive_cmds
with little or no ill effect. However, removing it from
old_archive_cmds (for the Green Hills C++ Compiler) will
probably cause trouble and I'm unsure of what should be added
to old_archive_cmds instead to make it work properly.

The testsuite change still needs work (as enumerated above),
and holding the real change hostage to the testsuite work
might just be enough the get the remaining kinks hammered
out. >;-)      But then again, maybe we should simply punt
and not test the SONAME at all, given that it seems non-
trivial to know when the check should actually run? Anybody
else with an opinion?

A ChangeLog entry is missing BTW...

Cheers,
Peter


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?108201>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/