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

[Peter Rosin]

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

Regarding the -no-undefined issue, I believe it is correct to
set -no-undefined in LDFLAGS in export.at. This is the case
since libtool is used to link in that test, and nothing else.

Or is LDFLAGS special in some way on Solaris, so that it gets
picked up automatically by the compiler driver? That would be
highly surprising since normal Makefile usage of LDFLAGS during
linking would then cause duplicate options to be passed...

If -no-undefined does not work properly on Solaris, that seems
like a platform specific problem that should not be used as an
excuse to clobber export.at for platforms that handles the
option correctly.

As for the patch to add SONAME, I am not qualified to say if
it is good or bad, but it looks sane enough to me. The only
issue I have with that part was that the test for it requires
elfdump to exist (and work) and that the shared library happens
to be named .libs/liba.so, which is not generally true. It also
assumes that there is a shared library at all, which is also
wrong. Not all platforms have something called SONAME. Etc. All
I tried to do was to point out these problems with the patch;
there needs to be a path past the new check in case any of the
above is not as it is on Solaris.

No single "maintainer" possesses knowledge on all platforms
libtool support. The knowledge is spread out and I'm just
speaking from my corner. Punting the issues to some
"export.at maintainer" is not going to work, because there is
none. "We" maintain it.

So, this new check needs to be special cased for Solaris, and
possibly any number or other unnamed systems where it is
appropriate. It should not be a burden to systems and/or
configurations where it simply is an invalid check. You (or
someone) need to find some criteria for when the new check is
sure to be valid, and skip past it otherwise.

SONAME is ELF-specific. Not everything is ELF.

Cheers,
Peter


    _______________________________________________________

Reply to this item at:

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

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