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

[Ileana Dumitrescu]

Update of sr#108201 (group libtool):

 Open/Closed:Open => Closed 

___

Follow-up Comment #32:

Did some digging and gcc appears to have solved the issue themselves[1].

>From GCC commit 6ee5892

"lto-plugin: Use GNU ld or Solaris ld version script in preference to
-export-symbols-regex [PR102426]

As reported, libtool -export-symbols-regex doesn't work on Solaris
when using GNU ld instead of Sun ld, libtool just always assumes Sun ld.
As I'm unsure what is the maintainance status of libtool right now,
this patch solves it on the lto-plugin side instead, tests at configure time
similar way how libssp and other target libraries test for symbol versioning
(except omitting the symbol version because we just want one GLOBAL symbol
and rest of them LOCAL), and will use the current way of"

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102426


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Richard PALO]

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

apparently Joyent believe that this isn't closed, if there is somebody that
has tested this too could determine whether or not to close the issue as
fixed, thanks in advance.

___

Reply to this item at:

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

___
  Message posté via/par Savannah
  http://savannah.gnu.org/


___
https://lists.gnu.org/mailman/listinfo/libtool

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

[Richard PALO]

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

The following patch to export.at seems to work on solaris

now testing for ELF in the shared object and using shrext_cmds to generate the
.so extension.


(file #27141)
___

Additional Item Attachment:

File name: export.at.git-diff Size:1 KB


___

Reply to this item at:

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

___
  Message posté via/par Savannah
  http://savannah.gnu.org/


___
https://lists.gnu.org/mailman/listinfo/libtool

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

[Bob Friesenhahn]

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

There are currently many unapplied patches. Several of them are useful for
Solaris.

___

Reply to this item at:

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

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


___
https://lists.gnu.org/mailman/listinfo/libtool

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

[Peter Rosin]

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

I have pushed the code changes to m4/Libtool.m4 (as two separate
commits), but left the testsuite alone. Thank you for your work
on this!

I also added you to THANKS, I hope that was ok?

A libtool release is not on my table though.

Cheers,
Peter


___

Reply to this item at:

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

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


___
https://lists.gnu.org/mailman/listinfo/libtool

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

[Richard PALO]

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

This is fine with me.

When *is* the next release planned then? 

In the meanwhile I will try to finish a pkgsrc patch to the already released
bits (which seems to complain with auto* tools)...

cheers



___

Reply to this item at:

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

___
  Message posté via/par Savannah
  http://savannah.gnu.org/


___
https://lists.gnu.org/mailman/listinfo/libtool

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

[Gary V. Vaughan]

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

On Thu 20 Dec 2012 04:48:06 GMT in comment #27 Richard PALO risto3 wrote:
 When is the next release planned then? 

Soon.

I had hoped to find time to do all the necessary testing before the end of the
year, but with wedding and honeymoon to plan, attend and pay for my time was
even more limited than I had feared.  Once Christmas is out of the way, I will
begin to co-ordinate the next release... probably dropping a month or two
after that (depending how many unapplied patches I am pointed to, and how much
work is required to pass the test-suite everywhere).

HTH,
Gary

___

Reply to this item at:

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

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


___
https://lists.gnu.org/mailman/listinfo/libtool

[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/


___
https://lists.gnu.org/mailman/listinfo/libtool

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

[Richard PALO]

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

These are good arguments, I offer as well some observations and/or arguments
before I sign off...

1. I thought about that last night, that *was* the advantage of elfdump, but
not all ELF systems have elfdump and objdump is used instead! Perhaps the
libtool system could put the mechanisms in place to indicate via the --config
command that the target platform is ELF in order to better instrument the
test case.

2. I initially wanted to use soname_spec, but there were too many fields
missing and I couldn't seem to get it right.  Now I see that
'shrext_cmds=.so' is in config so perhaps that could be used to generate the
file extension.
something like  '$objdir/liba$shrext_cmds'

3. I believe absence of a shared file being generated (on an ELF platform)
would be already a sign of a test failure!

4. The objdump chosen by libtools configure should be for the target... I
didn't check, but that *is* already the responsability of the build
environment.


Regarding zapping of $LDFLAGS, I compared this case (GXX) with the GCC case,
and indeed GXX seemed again in error, justifying your remarks.  Here is an
extract from GCC for comparison:

solaris*)
  _LT_TAGVAR(no_undefined_flag, $1)=' -z defs'
  if test yes = $GCC; then
wlarc='$wl'
_LT_TAGVAR(archive_cmds, $1)='$CC -shared $pic_flag $wl-z ${wl}text
$wl-h $wl$soname -o $lib $libobjs $deplibs $compiler_flags'
_LT_TAGVAR(archive_expsym_cmds, $1)='echo { global:  $lib.exp~cat
$export_symbols | $SED -e s/(.*)/1;/  $lib.exp~echo local: *; }; 
$lib.exp~
  $CC -shared $pic_flag $wl-z ${wl}text $wl-M $wl$lib.exp $wl-h
$wl$soname -o $lib $libobjs $deplibs $compiler_flags~$RM $lib.exp'
  else

I don't believe Green Hills C++ code path is touched here, the patch I
submitted touches only Gnu CXX with solaris ld.

To summarize, I believe the libtool.m4 code patch should move ahead, but I
agree that the libtool testsuite could be (globally) improved to deal with
shared libraries on the different plastforms. 

By the way, given pkgsrc is preparing for 2012Q4, it is urgent to release a
patched kit. 

I've attached the combined diff upon libtool.m4

cheers

(file #27123)
___

Additional Item Attachment:

File name: libtool.m4.git-diffSize:2 KB


___

Reply to this item at:

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

___
  Message posté via/par Savannah
  http://savannah.gnu.org/


___
https://lists.gnu.org/mailman/listinfo/libtool

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

[Peter Rosin]

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

I believe gcc 4.5.3 is the latest stable for Cygwin. I do not
trust myself to be able to build a new gcc and verify that it
actually works for Cygwin without investing far more time than I
think is warranted. I imagine that there is some good reason for
Cygwin gcc to remain 4.5.3... And, the gcc version is not likely
to affect if libtool passes -un-undefined on to the toolchain
or if libtool handles the flag correctly.

The libtool I used was git master as of 2012-11-02 (34fe402efa1)
plus a couple of local changes which do not affect things in
any relevant way. Besides, any change will have to be against
master anyway, so you might as well test that first, instead
of asking me to go digging in the history.

However, my prediction is that master and 2.4.2 will behave the
same for you in this regard.

So, all in all, I don't think it is productive for me to test
with different versions.

___

Reply to this item at:

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

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


___
https://lists.gnu.org/mailman/listinfo/libtool

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

[Bob Friesenhahn]

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

FYI, Peter Rosin is able to commit fixes to libtool.  That is one reason why
he focuses on the master version.

Barring some severe nightmarish security defect, there will be no follow-on
release based on the v2.4.2 sources.  The next release will be from master so
we need to focus on making it work.  Libtool maintainers always work with
latest code from git.

There was a (substantially long) time where active libtool maintainers were no
longer able to bootstrap the project from git.  Luckily that issue was
resolved so we are able to work with the master version again and usefully
apply well-tested patches.

Bob

___

Reply to this item at:

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

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


___
https://lists.gnu.org/mailman/listinfo/libtool

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

[Bob Friesenhahn]

Update of sr #108201 (project libtool):

Operating System:*BSD = Solaris


___

Reply to this item at:

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

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


___
https://lists.gnu.org/mailman/listinfo/libtool

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

[Richard PALO]

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

Here is the git diff for master (apparently the same except for the file
path).

(file #27107)
___

Additional Item Attachment:

File name: libtool.m4.git-diff-master Size:1 KB


___

Reply to this item at:

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

___
  Message posté via/par Savannah
  http://savannah.gnu.org/


___
https://lists.gnu.org/mailman/listinfo/libtool

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

[Richard PALO]

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

could you please post your testsuite.log for the following command:

gmake CC=g++ check-local

it is possible that this is yet another bug (either in libtool or in gcc...)

When I only run test 45 with

gmake CC=g++ check-local TESTSUITEFLAGS=45 -d

The test fails with the following extract from
tests/testsuite.dir/045/testsuite.log :
==
eval '/home/richard/src/libtool/libtool --mode=link g++ -g -O2  -no-undefined
-o liba.la a.lo 
   -rpath
/home/richard/src/libtool/tests/testsuite.dir/045/inst/lib' 
./export.at:171: eval '$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o liba.la
a.lo 
   -rpath $libdir' $exportsyms
stderr:
g++: error: unrecognized command line option '-no-undefined'
stdout:
libtool: link: g++ -shared  -fPIC -DPIC -nostdlib  -no-undefined
/usr/lib/amd64/crti.o /usr/lib/amd64/values-Xa.o /opt/pkg/gcc47/lib
/gcc/x86_64-sun-solaris2.11/4.7.2/crtbegin.o  .libs/a.o  
-L/opt/pkg/gcc47/lib/gcc/x86_64-sun-solaris2.11/4.7.2 -L/opt/pkg/gcc47/lib
/gcc/x86_64-sun-solaris2.11/4.7.2/../../../../x86_64-sun-solaris2.11/lib/amd64
-L/opt/pkg/gcc47/lib/gcc/x86_64-sun-solaris2.11/4.7.2
/../../../amd64 -L/lib/amd64 -L/usr/lib/amd64
-L/opt/pkg/gcc47/lib/gcc/x86_64-sun-solaris2.11/4.7.2/../../../../x86_64-sun-solaris2.
11/lib -L/opt/pkg/gcc47/lib/gcc/x86_64-sun-solaris2.11/4.7.2/../../.. -lstdc++
-lm -lc -lgcc_s /opt/pkg/gcc47/lib/gcc/x86_64-sun-sol
aris2.11/4.7.2/crtend.o /usr/lib/amd64/crtn.o  -O2   -Wl,-h -Wl,liba.so.0 -o
.libs/liba.so.0.0.0
./export.at:171: exit code was 1, expected 0






___

Reply to this item at:

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

___
  Message posté via/par Savannah
  http://savannah.gnu.org/


___
https://lists.gnu.org/mailman/listinfo/libtool

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

[Peter Rosin]

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

I had an old git checkout from some time back (with some totally
unrelated work in it) and I used that to run the export test.
I'm not wasting hours on a full testsuite runs for this.
I tested once configuring with CC=g++ and once with CC=gcc. Both
times I then did

make CC=g++ check-local TESTSUITEFLAGS=-d -k export

and both times the test passed on Cygwin for me.

I'm attaching testsuite.log from one of the runs.


(file #27101)
___

Additional Item Attachment:

File name: testsuite.log  Size:16 KB


___

Reply to this item at:

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

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


___
https://lists.gnu.org/mailman/listinfo/libtool

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

[Richard PALO]

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

I gather that your gcc is rather ancient (4.5.3 from april 2011) but I cannot
determine which version of libtool you are using.

Would it be possible to upgrade gcc to the latest 4.7.2 and

git checkout v2.4.2 

in order to update your repository as well.  I'm dubious testing a version
that is not the last stable.

I agree that the export test (45) is sufficient as it adds '-no-undefined' to
LDFLAGS.  Thanks for the 'k export' hint.
That is, in effect, what I do.

Thank you in advance

___

Reply to this item at:

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

___
  Message posté via/par Savannah
  http://savannah.gnu.org/


___
https://lists.gnu.org/mailman/listinfo/libtool

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

[Richard PALO]

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

perhaps to refine the test a bit more, would it be possible to check that the
value of SONAME is the value expected.

With elfdump, the SONAME could be extracted for example by:

elfdump -d $soname | grep SONAME | awk '{printf $4}'

Apparently when in absence of elfdump, linux has objdump:

objdump -p $soname | grep SONAME | awk '{printf $2}'

It has been over a decade since I touched a compiler on W32, so I wouldn't
even attempt to determine the equivalent.

Again, the maintainer probably [has|should have] this knowledge.

___

Reply to this item at:

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

___
  Message posté via/par Savannah
  http://savannah.gnu.org/


___
https://lists.gnu.org/mailman/listinfo/libtool

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

[Richard PALO]

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

if the solaris developer/gnu-binutils or pkgsrc/devel/binutils is installed,
then objdump is on the system.

Just noticed that libtool's configure found objdump:
richard@devzone:~/src/libtool$ grep objdump config*
config.log:configure:5686: checking for objdump
config.log:configure:5702: found /opt/pkg/gnu/bin/objdump
config.log:configure:5713: result: objdump
config.log:ac_cv_prog_ac_ct_OBJDUMP=objdump
config.log:OBJDUMP='objdump'
config.status:OBJDUMP='objdump'
config.status:S[OBJDUMP]=objdump
configure:  # Extract the first word of ${ac_tool_prefix}objdump, so it can
be a program name with args.
configure:set dummy ${ac_tool_prefix}objdump; ac_word=$2
configure:ac_cv_prog_OBJDUMP=${ac_tool_prefix}objdump
configure:  # Extract the first word of objdump, so it can be a program name
with args.
configure:set dummy objdump; ac_word=$2
configure:ac_cv_prog_ac_ct_OBJDUMP=objdump
configure:test -z $OBJDUMP  OBJDUMP=objdump
configure:  # func_win32_libid shell function, so use a weaker test based on
'objdump',
configure:  # use the weaker test based on 'objdump'. See mingw*.
configure:  # Extract the first word of ${ac_tool_prefix}objdump, so it can
be a program name with args.
configure:set dummy ${ac_tool_prefix}objdump; ac_word=$2
configure:ac_cv_prog_OBJDUMP=${ac_tool_prefix}objdump
configure:  # Extract the first word of objdump, so it can be a program name
with args.
configure:set dummy objdump; ac_word=$2
configure:ac_cv_prog_ac_ct_OBJDUMP=objdump
configure:test -z $OBJDUMP  OBJDUMP=objdump

I don't believe binutils is explicitly a libtool prerequisite, though, in
order to use only $OBJDUMP in this case.


___

Reply to this item at:

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

___
  Message posté via/par Savannah
  http://savannah.gnu.org/


___
https://lists.gnu.org/mailman/listinfo/libtool

[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/


___
https://lists.gnu.org/mailman/listinfo/libtool

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

[Richard PALO]

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

Here is my feable and first attempt to detect the problem using the
testsuite.

First, the test export.at seems to work by default, but it is only a gcc
(simple 'C') test:

richard@devzone:~/src/libtool$ gmake check-local TESTSUITEFLAGS=45 -d
cd ./tests  
autom4te --language=autotest `echo tests/testsuite.at tests/getopt-m4sh.at
tests/libtoolize.at tests/help.at tests/duplicate_members.at
tests/duplicate_conv.at tests/duplicate_deps.at tests/flags.at
tests/inherited_flags.at tests/convenience.at tests/link-order.at
tests/link-order2.at tests/fail.at tests/shlibpath.at
tests/runpath-in-lalib.at tests/static.at tests/export.at tests/search-path.at
tests/indirect_deps.at tests/archive-in-archive.at tests/exeext.at
tests/execute-mode.at tests/bindir.at tests/cwrapper.at
tests/deplib-in-subdir.at tests/infer-tag.at tests/localization.at
tests/nocase.at tests/install.at tests/versioning.at tests/destdir.at
tests/old-m4-iface.at tests/am-subdir.at tests/lt_dlexit.at
tests/lt_dladvise.at tests/lt_dlopen.at tests/lt_dlopen_a.at
tests/lt_dlopenext.at tests/ltdl-libdir.at tests/ltdl-api.at
tests/dlloader-api.at tests/loadlibrary.at tests/lalib-syntax.at
tests/resident.at tests/slist.at tests/need_lib_prefix.at tests/standalone.at
tests/subproject.at tests/nonrecursive.at tests/recursive.at tests/template.at
tests/ctor.at tests/exceptions.at tests/early-libtool.at tests/with-pic.at
tests/no-executables.at tests/deplibs-ident.at tests/configure-iface.at
tests/stresstest.at tests/cmdline_wrap.at tests/pic_flag.at tests/darwin.at
tests/dumpbin-symbols.at tests/deplibs-mingw.at tests/sysroot.at | sed
's,tests/,,g'` -o testsuite.tmp  
mv -f testsuite.tmp testsuite
abs_srcdir=`CDPATH=${ZSH_VERSION+.}:  cd .  pwd`; cd tests; 
CONFIG_SHELL=/bin/sh /bin/sh $abs_srcdir/tests/testsuite 
  MAKE=gmake CC=gcc CFLAGS=-g -O2 CPP=gcc -E CPPFLAGS=
LD=/usr/bin/ld -64 LDFLAGS= LIBS= LN_S=ln -s NM=/opt/pkg/gnu/bin/nm
-B RANLIB=ranlib AR=ar M4SH=autom4te --language=m4sh
SED=/opt/pkg/bin/gsed STRIP=strip lt_INSTALL=/opt/pkg/bin/ginstall -c
MANIFEST_TOOL=: OBJEXT=o EXEEXT= SHELL=/bin/sh CONFIG_SHELL=/bin/sh
CXX=g++ CXXFLAGS=-g -O2 CXXCPP=g++ -E F77=gfortran FFLAGS=-g -O2
FC=gfortran FCFLAGS=-g -O2 GCJ= GCJFLAGS=-g -O2
lt_cv_to_host_file_cmd=func_convert_file_noop
lt_cv_to_tool_file_cmd=func_convert_file_noop
_lt_pkgdatadir=/home/richard/src/libtool
LIBTOOLIZE=/home/richard/src/libtool/libtoolize
LIBTOOL=/home/richard/src/libtool/libtool
tst_aclocaldir=/home/richard/src/libtool/libltdl/m4 45 -d
## - ##
## GNU Libtool 2.4.2 test suite. ##
## - ##
 45: Export test ok

## - ##
## Test results. ##
## - ##

1 test was successful.

I updated this test as follows (unsure about this test on other than an
elf-based platform):

richard@devzone:~/src/libtool$ git diff tests/export.at 
diff --git a/tests/export.at b/tests/export.at
index 39adfbc..1f59fa5 100644
--- a/tests/export.at
+++ b/tests/export.at
@@ -35,7 +35,7 @@ AT_CHECK([eval `$LIBTOOL --config | sed -n
'/^archive_expsym_cmds=/,/^$/p'`
 can_hide=:
 test -s can-hide  can_hide=false
 
-LDFLAGS=$LDFLAGS -no-undefined
+#LDFLAGS=$LDFLAGS -no-undefined
 libdir=`pwd`/inst/lib
 mkdir inst inst/lib
 
@@ -170,6 +170,7 @@ do
   # case 1: shared library built from object.
   LT_AT_CHECK([eval '$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o liba.la
a.lo 
   -rpath $libdir' $exportsyms], [], [ignore], [ignore])
+  AT_CHECK([elfdump -d .libs/liba.so | grep SONAME],[], [ignore],
[ignore])
   AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o main$EXEEXT
main.$OBJEXT liba.la],
   [], [ignore], [ignore])
   LT_AT_EXEC_CHECK([./main])

I can manually run this for C++ as follows:
richard@devzone:~/src/libtool$ gmake CC=g++ check-local TESTSUITEFLAGS=45
-d
abs_srcdir=`CDPATH=${ZSH_VERSION+.}:  cd .  pwd`; cd tests; 
CONFIG_SHELL=/bin/sh /bin/sh $abs_srcdir/tests/testsuite 
  MAKE=gmake CC=g++ CFLAGS=-g -O2 CPP=gcc -E CPPFLAGS=
LD=/usr/bin/ld -64 LDFLAGS= LIBS= LN_S=ln -s NM=/opt/pkg/gnu/bin/nm
-B RANLIB=ranlib AR=ar M4SH=autom4te --language=m4sh
SED=/opt/pkg/bin/gsed STRIP=strip lt_INSTALL=/opt/pkg/bin/ginstall -c
MANIFEST_TOOL=: OBJEXT=o EXEEXT= SHELL=/bin/sh CONFIG_SHELL=/bin/sh
CXX=g++ CXXFLAGS=-g -O2 CXXCPP=g++ -E F77=gfortran FFLAGS=-g -O2
FC=gfortran FCFLAGS=-g -O2 GCJ= GCJFLAGS=-g -O2
lt_cv_to_host_file_cmd=func_convert_file_noop
lt_cv_to_tool_file_cmd=func_convert_file_noop
_lt_pkgdatadir=/home/richard/src/libtool
LIBTOOLIZE=/home/richard/src/libtool/libtoolize
LIBTOOL=/home/richard/src/libtool/libtool
tst_aclocaldir=/home/richard/src/libtool/libltdl/m4 45 -d


## - ##
## GNU Libtool 2.4.2 test suite. ##
## - ##
 45: Export test FAILED (export.at:173)

## - ##
## Test results. ##
## - ##

ERROR: 1 test 

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

[Richard PALO]

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

And here is the diff for the proposed patch.
After cleanup and rebuilding (seemed like a zillion autoreconfs)
running the export tests as indicated (both for standard and CC=g++) are
successful.

richard@devzone:~/src/libtool$ git diff --staged
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 44e0ecf..397756f 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -6742,7 +6742,7 @@ if test $_lt_caught_CXX_error != yes; then
  if $CC --version | $GREP -v '^2.7'  /dev/null; then
_LT_TAGVAR(archive_cmds, $1)='$CC -shared $pic_flag -nostdlib
$LDFLAGS $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags
${w
_LT_TAGVAR(archive_expsym_cmds, $1)='echo { global: 
$lib.exp~cat $export_symbols | $SED -e s/(.*)/1;/  $lib.exp~echo local:
*; };
- $CC -shared $pic_flag -nostdlib ${wl}-M $wl$lib.exp -o $lib
$predep_objects $libobjs $deplibs $postdep_objects $compiler_flags~$RM
$lib.exp
+ $CC -shared $pic_flag -nostdlib ${wl}-M $wl$lib.exp ${wl}-h
$wl$soname -o $lib $predep_objects $libobjs $deplibs $postdep_objects
$compiler
 
# Commands to make compiler produce verbose output that lists
# what hidden libraries, object files and flags are used
when
@@ -6753,7 +6753,7 @@ if test $_lt_caught_CXX_error != yes; then
# platform.
_LT_TAGVAR(archive_cmds, $1)='$CC -G -nostdlib $LDFLAGS
$predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-h
$wl$soname
_LT_TAGVAR(archive_expsym_cmds, $1)='echo { global: 
$lib.exp~cat $export_symbols | $SED -e s/(.*)/1;/  $lib.exp~echo local:
*; };
- $CC -G -nostdlib ${wl}-M $wl$lib.exp -o $lib $predep_objects
$libobjs $deplibs $postdep_objects $compiler_flags~$RM $lib.exp'
+ $CC -G -nostdlib ${wl}-M $wl$lib.exp ${wl}-h $wl$soname -o
$lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags~$RM
$lib
 
# Commands to make compiler produce verbose output that lists
# what hidden libraries, object files and flags are used
when


___

Reply to this item at:

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

___
  Message posté via/par Savannah
  http://savannah.gnu.org/


___
https://lists.gnu.org/mailman/listinfo/libtool

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

[Bob Friesenhahn]

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

Can you please re-post your patch as a file attachment?  It seems that posting
as a comment trashes the patch.

Do any of the existing libtool test cases test the functionality you are
fixing?

Also, libtool.m4 is at m4/libtool.m4 in current git rather than the path your
patch used.  I assume that your patch is against an older version before the
source tree was re-organized.

On my OpenIndiana oi_151a5 system with current git and using a self-compiled
GCC 4.7.1 toolchain, I see this in the test result summary:

ERROR: 156 tests were run,
7 failed (5 expected failures).
12 tests were skipped.

The two failures are due to my Java compiler not working right.

___

Reply to this item at:

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

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


___
https://lists.gnu.org/mailman/listinfo/libtool

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

[Richard PALO]

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

Bob, please see comment  #5

As I indicated, local test n° 45 export.at is the existing test.

I added the following line :
AT_CHECK([elfdump -d .libs/liba.so | grep SONAME],[], [ignore], [ignore]) 

to ensure that the SONAME was being added, elfdump being available on ELF
platforms... as I mentioned, I can't answer for other platforms.

The LDFLAGS statement commented out is a misnomer, I believe, as the link
editor is not being invoked directly but indirectly via libtool and on via
$CC.  When I modified it to -Wl,--no-undefined I got a duplicate ld option
warning so I simply commented it out.
Perhaps this as well could be cleaned up to use lt_no_undefined_flag or
something like that.

Please find the git diff attached.

(file #27082)
___

Additional Item Attachment:

File name: libtool.m4.git-diffSize:1 KB


___

Reply to this item at:

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

___
  Message posté via/par Savannah
  http://savannah.gnu.org/


___
https://lists.gnu.org/mailman/listinfo/libtool

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

[Richard PALO]

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

BTW Bob, perhaps you didn't catch that I did a 

$git checkout  v2.4.2

since it appears much has changed since the last stable.

This is why, I believe, the tests indicate
 ## GNU Libtool 2.4.2 test suite. ## 



___

Reply to this item at:

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

___
  Message posté via/par Savannah
  http://savannah.gnu.org/


___
https://lists.gnu.org/mailman/listinfo/libtool

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

[Peter Rosin]

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

Dropping -no-undefined from LDFLAGS in export.at kills the test
on Windows and it's unacceptable to assume that elfdump
exists. Passing -no-undefined to libtool is NOT a misnomer and
-no-undefined is in fact a perfectly valid libtool option, not a
compiler driver or linker option. On most systems libtool simply
removes -no-undefined, I believe.

I know it was stated that it was a feeble and first attempt,
but I wanted to spell out that the current form of the patch is
problematic before anyone started thinking that it was ok to
push the changes as is.

Cheers,
Peter


___

Reply to this item at:

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

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


___
https://lists.gnu.org/mailman/listinfo/libtool

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

[Bob Friesenhahn]

On Wed, 12 Dec 2012, Peter Rosin wrote:


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

Dropping -no-undefined from LDFLAGS in export.at kills the test
on Windows and it's unacceptable to assume that elfdump
exists. Passing -no-undefined to libtool is NOT a misnomer and
-no-undefined is in fact a perfectly valid libtool option, not a
compiler driver or linker option. On most systems libtool simply
removes -no-undefined, I believe.


Agreed.  Responsible packages will pass -no-undefined and have taken 
care that it works.  Libtool needs to work reliably with it.


Even systems which do not require -no-undefined may still have a 
linker which can be told to enforce that there are no remaining 
undefined symbols.  If libtool passes on this request to the linker, 
then libtool needs to take care to also pass any implicit dependencies 
so that linking can succeed.


I am still trying to understand the exact issues that Richard PALO 
trying to resolve. It feels like there are several separate issues 
here.   I have seen mention of embedding the SONAME in the library (as 
Linux libraries almost always do) and some issue with 
-export-symbols-regex not working properly with a wildcard 
specification.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

___
https://lists.gnu.org/mailman/listinfo/libtool

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

[Richard PALO]

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

I guess I can add the following:

1. regarding -no-undefined, when I changed this to avoid the syntax error on
solaris (which should be, for example, -Wl,--no-undefined), the linker
complained that it was a duplicate option implying, I believe, that it is by
default.

If it is a libtool directive, then it should not be in LDFLAGS which are
linker directives, it should be added independently as an additional argument
in the appropriate libtool calls.

Export.at is not the only test that uses this.

To see all that fail:

'$ gmake CC=g++ check-local'

2. as for the issues object of my libtool bug report, there is
only one... libtool omits '-Wl,-h -Wl,$soname' on solaris platforms when
CC=g++ and the link editor is solaris ld (/usr/bin/ld). 

This omits to tell the linker to add the SONAME to resulting object.

Therefore the patch submitted for libltdl/m4/libtool.m4

The test case for this is to add to 'export.at' a crucial subtest that, at
least on solaris and I presume on all ELF platforms, check that SONAME is
correctly added to the shared library/object.
(reference:news://news.gmane.org:119/20121209215323.ga...@joyent.com )

I submit that the maintainer of the test 'export.at' ensure that the test
works on all platforms.

By the way, I added only to '# case 1: shared library built from object'

Perhaps '# case 2: shared library built from convenience archive.' should also
be tested.

I leave this as well to the export.at maintainer.

Cheers 

___

Reply to this item at:

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

___
  Message posté via/par Savannah
  http://savannah.gnu.org/


___
https://lists.gnu.org/mailman/listinfo/libtool

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

[Richard PALO]

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

trying to bootstrap git base to provide a test case and patch proposal, but I
notice some problems already in doing after ./bootstrap  ./configure
 
gmake check syntax-check distcheck


## - ##
## Test results. ##
## - ##

151 tests behaved as expected.
17 tests were skipped.
gmake[3]: Leaving directory `/home/richard/src/libtool'
gmake[2]: Leaving directory `/home/richard/src/libtool'
gmake[1]: Leaving directory `/home/richard/src/libtool'
GFDL_version
0.12 GFDL_version
...
libtool_m4_cc_basename
sed: -e expression #1, char 86: unterminated address regex
0.03 libtool_m4_cc_basename
...
prohibit_set_dummy_without_shift
sed: -e expression #1, char 136: unterminated address regex
0.08 prohibit_set_dummy_without_shift
...
prohibit_strcmp
build-aux/ltmain.in:2824:   $SED 's/.*/  if (!strcmp
(symbol-name, )) symbol-address = (void *) ;/'  $nlistI 
$output_objdir/$my_dlsyms
maint.mk: replace strcmp calls above with STREQ/STRNEQ
gmake: *** [sc_prohibit_strcmp] Error 1

does libtool not like pkgsrc version of sed?

richard@devzone:~/src/libtool$ which sed
/opt/pkg/gnu/bin/sed
richard@devzone:~/src/libtool$ grep 'SED=' config.log
ac_cv_path_SED=/opt/pkg/bin/gsed
SED='/opt/pkg/bin/gsed'



___

Reply to this item at:

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

___
  Message posté via/par Savannah
  http://savannah.gnu.org/


___
https://lists.gnu.org/mailman/listinfo/libtool

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

[Bob Friesenhahn]

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

I notice that the error message mentions the program name 'sed' rather than
'gsed'.  Perhaps two different sed programs are being used?  It seems likely
that the 'sed' which failed is Solaris 'sed' rather than GNU 'sed'.

___

Reply to this item at:

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

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


___
https://lists.gnu.org/mailman/listinfo/libtool

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

[Richard PALO]

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

Hello Bob,

I wonder too, which is why I indicated at the end of my last comment:
 does libtool not like pkgsrc version of sed?
 
 richard@devzone:~/src/libtool$ which sed
 /opt/pkg/gnu/bin/sed
 richard@devzone:~/src/libtool$ grep 'SED=' config.log
 ac_cv_path_SED=/opt/pkg/bin/gsed
 SED='/opt/pkg/bin/gsed'


Anyway, my PATH is:
richard@devzone:~/src/libtool$ echo $PATH
/opt/pkg/sbin:/opt/pkg/bin:/opt/pkg/gnu/bin:/opt/pkg/gcc47/bin:/usr/bin:/usr/sbin:/sbin

so it has to use RPN to get to Solaris 'sed'... 

shouldn't all scripts be using more or less the same 'sed' anyway?  


I'm a bit surprised after taking a look at 'egrep sed|SED *.mk'

After looking a bit at config.log and config.status, I'm uneasy about respect
for my PATH. 

Is there a way to get this to work on OI_151a7?  

For what it is worth, I'm able to continue with pkgsrc after manually patching
/opt/pkg/bin/libtool:

richard@devzone:~$ libtool --version
ltmain.sh (GNU libtool) 2.2.6b
Written by Gordon Matzigkeit g...@gnu.ai.mit.edu, 1996

Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
richard@devzone:~$ pkgdiff /opt/pkg/bin/libtool
$NetBSD$

--- /opt/pkg/bin/libtool.orig   2012-12-11 12:43:45.0 +
+++ /opt/pkg/bin/libtool
@@ -8967,7 +8967,7 @@ old_archive_from_expsyms_cmds=
 # Commands used to build a shared archive.
 archive_cmds=$CC -shared -nostdlib $LDFLAGS $predep_objects $libobjs
$deplibs $postdep_objects $compiler_flags ${wl}-h $wl$soname -o $lib
 archive_expsym_cmds=echo \{ global:\  $lib.exp~cat $export_symbols | $SED
-e \s/\\(.*\\)/\\1;/\  $lib.exp~echo \local: *; };\  $lib.exp~
- $CC -shared -nostdlib ${wl}-M $wl$lib.exp -o $lib
$predep_objects $libobjs $deplibs $postdep_objects $compiler_flags~$RM
$lib.exp
+ $CC -shared -nostdlib ${wl}-M $wl$lib.exp ${wl}-h $wl$soname
-o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags~$RM
$lib.exp
 
 # Commands used to build a loadable module if different from building
 # a shared archive.


It's a very short term remedy but hopefully we can rapidly get libtool, and
then pkgsrc updated.

___

Reply to this item at:

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

___
  Message posté via/par Savannah
  http://savannah.gnu.org/


___
https://lists.gnu.org/mailman/listinfo/libtool

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

[Richard PALO]

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

I was working off of master. With git blame I noticed that the strcmp problem
was introduced recently, so I'm trying over after git checkout v2.4.2, which
is the latest tarball version I've tested with pkgsrc.

HEAD is now at fdb4c54... Release 2.4.2

hopefully it'll go a bit cleaner.

___

Reply to this item at:

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

___
  Message posté via/par Savannah
  http://savannah.gnu.org/


___
https://lists.gnu.org/mailman/listinfo/libtool

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

[Dennis Clarke]

- Original Message -
From: Bob Friesenhahn invalid.nore...@gnu.org
Date: Tuesday, December 11, 2012 9:57 am
Subject: [sr #108201] libtool problems with -export-symbols-regex on solaris 
with gcc-4.7.x
To: Richard PALO richard.p...@baou.fr, Bob Friesenhahn 
bfrie...@simple.dallas.tx.us, libtool@gnu.org


 Follow-up Comment #2, sr #108201 (project libtool):
 
 I notice that the error message mentions the program name 'sed' rather 
 than
 'gsed'.  Perhaps two different sed programs are being used?  It seems 
 likely
 that the 'sed' which failed is Solaris 'sed' rather than GNU 'sed'.
 

Is there a valid reason why a POSIX compliant ( POSIX.2, POSIX.2a, SUS, SUSv2, 
XPG4  ) sed can not be used ? 

That would be the sed in /usr/xpg4/bin on Solaris 10 and if GNU extensions are 
required, which are not covered in the standard, the the questions is .. why?

Dennis 

ps: I know this is slightly out of scope but a continual source of problems in 
the POSIX world

___
https://lists.gnu.org/mailman/listinfo/libtool

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

[Bob Friesenhahn]

On Tue, 11 Dec 2012, Dennis Clarke wrote:


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

I notice that the error message mentions the program name 'sed' rather
than
'gsed'.  Perhaps two different sed programs are being used?  It seems
likely
that the 'sed' which failed is Solaris 'sed' rather than GNU 'sed'.



Is there a valid reason why a POSIX compliant ( POSIX.2, POSIX.2a, SUS, SUSv2, 
XPG4  ) sed can not be used ?


This is (i.e. should be) intended to work.  However, what we seem to 
be seeing is that the sed intentionally selected for use ('gsed') was 
not always consistently used.  In a few cases bare 'sed' was used from 
Richard's PATH (which does not include /usr/xpg4/bin) and this 'sed' 
failed.


It seems that Richard started down one path (-export-symbols-regex did 
not work as expected) but now he is on a new path (sed failure).


There are several Solaris-related patches which were posted to the 
libtool list which have not yet been applied.  The libtool project is 
considerably behind at evaluating and applying patches.  I don't think 
that any of the patches are for -export-symbols-regex or sed though.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

___
https://lists.gnu.org/mailman/listinfo/libtool

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

[Richard PALO]

URL:
  http://savannah.gnu.org/support/?108201

 Summary: libtool problems with -export-symbols-regex on
solaris with gcc-4.7.x
 Project: GNU Libtool
Submitted by: risto3
Submitted on: lun. 10 déc. 2012 13:58:02 GMT
Category: None
Priority: 5 - Normal
Severity: 4 - Important
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
Operating System: *BSD

___

Details:

(I put *BSD because SunOS not available)

In trying to build rarian-0.8.1, it appears that the shared library
(librarian.so) is not built correctly.

I have I isolated the problem to the following statement in Makefile.am

librarian_la_LDFLAGS = -export-symbols-regex ^rrn_.*

Here is the resulting libtool output for this command:
/bin/sh ../libtool --tag=CXX   --mode=link g++  -g -O2 -export-symbols-regex
^rrn_.*  -o librarian.la -rpath /usr/local/lib librarian_la-rarian-main.lo
librarian_la-rarian-reg-utils.lo librarian_la-rarian-language.lo
librarian_la-rarian-utils.lo librarian_la-rarian-info.lo
librarian_la-rarian-man.lo rarian-omf.lo tinyxml.lo tinyxmlparser.lo
tinystr.lo tinyxmlerror.lo

libtool: link: rm -fr  .libs/librarian.a .libs/librarian.exp
.libs/librarian.la .libs/librarian.lai .libs/librarian.so .libs/librarian.so.0
.libs/librarian.so.0.0.0
libtool: link: /opt/pkg/gnu/bin/nm -B  .libs/librarian_la-rarian-main.o
.libs/librarian_la-rarian-reg-utils.o .libs/librarian_la-rarian-language.o
.libs/librarian_la-rarian-utils.o .libs/librarian_la-rarian-info.o
.libs/librarian_la-rarian-man.o .libs/rarian-omf.o .libs/tinyxml.o
.libs/tinyxmlparser.o .libs/tinystr.o .libs/tinyxmlerror.o   | sed -n -e
's/^.*[  ]\([ABCDGIRSTW][ABCDGIRSTW]*\)[ ][  
]*\([_A-Za-z][_A-Za-z0-9]*\)$/\1
\2 \2/p' | sed '/ __gnu_lto/d' | /opt/pkg/bin/gsed 's/.* //' | sort | uniq 
.libs/librarian.exp
libtool: link: /opt/pkg/bin/ggrep -E -e ^rrn_.* .libs/librarian.exp 
.libs/librarian.expT
libtool: link: mv -f .libs/librarian.expT .libs/librarian.exp
libtool: link: echo { global:  .libs/librarian.so.0.0.0.exp
libtool: link: cat .libs/librarian.exp | /opt/pkg/bin/gsed -e s/\(.*\)/\1;/
 .libs/librarian.so.0.0.0.exp
libtool: link: echo local: *; };  .libs/librarian.so.0.0.0.exp
libtool: link:  g++ -shared  -fPIC -DPIC -nostdlib -Wl,-M
-Wl,.libs/librarian.so.0.0.0.exp -o .libs/librarian.so.0.0.0
/usr/lib/amd64/crti.o /usr/lib/amd64/values-Xa.o
/opt/pkg/gcc47/lib/gcc/x86_64-sun-solaris2.11/4.7.2/crtbegin.o 
.libs/librarian_la-rarian-main.o .libs/librarian_la-rarian-reg-utils.o
.libs/librarian_la-rarian-language.o .libs/librarian_la-rarian-utils.o
.libs/librarian_la-rarian-info.o .libs/librarian_la-rarian-man.o
.libs/rarian-omf.o .libs/tinyxml.o .libs/tinyxmlparser.o .libs/tinystr.o
.libs/tinyxmlerror.o   -L/opt/pkg/gcc47/lib/gcc/x86_64-sun-solaris2.11/4.7.2
-L/opt/pkg/gcc47/lib/gcc/x86_64-sun-solaris2.11/4.7.2/../../../../x86_64-sun-solaris2.11/lib/amd64
-L/opt/pkg/gcc47/lib/gcc/x86_64-sun-solaris2.11/4.7.2/../../../amd64
-L/lib/amd64 -L/usr/lib/amd64
-L/opt/pkg/gcc47/lib/gcc/x86_64-sun-solaris2.11/4.7.2/../../../../x86_64-sun-solaris2.11/lib
-L/opt/pkg/gcc47/lib/gcc/x86_64-sun-solaris2.11/4.7.2/../../.. -lstdc++ -lm
-lc -lgcc_s /opt/pkg/gcc47/lib/gcc/x86_64-sun-solaris2.11/4.7.2/crtend.o
/usr/lib/amd64/crtn.o  -O2  
libtool: link: rm -f .libs/librarian.so.0.0.0.exp
libtool: link: (cd .libs  rm -f librarian.so.0  ln -s
librarian.so.0.0.0 librarian.so.0)
libtool: link: (cd .libs  rm -f librarian.so  ln -s
librarian.so.0.0.0 librarian.so)
libtool: link: ar cru .libs/librarian.a  librarian_la-rarian-main.o
librarian_la-rarian-reg-utils.o librarian_la-rarian-language.o
librarian_la-rarian-utils.o librarian_la-rarian-info.o
librarian_la-rarian-man.o rarian-omf.o tinyxml.o tinyxmlparser.o tinystr.o
tinyxmlerror.o
libtool: link: ranlib .libs/librarian.a
libtool: link: ( cd .libs  rm -f librarian.la  ln -s ../librarian.la
librarian.la )

If I suppress the -export-symbols-regex ^rrn_.*, the following is output:
libtool: link: rm -fr  .libs/librarian.a .libs/librarian.exp
.libs/librarian.la .libs/librarian.lai .libs/librarian.so .libs/librarian.so.0
.libs/librarian.so.0.0.0
libtool: link: g++ -shared  -fPIC -DPIC -nostdlib  /usr/lib/amd64/crti.o
/usr/lib/amd64/values-Xa.o
/opt/pkg/gcc47/lib/gcc/x86_64-sun-solaris2.11/4.7.2/crtbegin.o 
.libs/librarian_la-rarian-main.o .libs/librarian_la-rarian-reg-utils.o
.libs/librarian_la-rarian-language.o .libs/librarian_la-rarian-utils.o
.libs/librarian_la-rarian-info.o .libs/librarian_la-rarian-man.o
.libs/rarian-omf.o .libs/tinyxml.o .libs/tinyxmlparser.o .libs/tinystr.o
.libs/tinyxmlerror.o   -L/opt/pkg/gcc47/lib/gcc/x86_64-sun-solaris2.11/4.7.2
-L/opt/pkg/gcc47/lib/gcc/x86_64-sun-solaris2.11/4.7.2/../../../../x86_64-sun-solaris2.11/lib/amd64