helpGNU Libtool - Support: sr #108201, libtool problems with...

 
 

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

Submitted by:  Richard PALO <risto3>
Submitted on:  Mon 10 Dec 2012 01:58:02 PM UTC  
 
Category: NonePriority: 5 - Normal
Severity: 4 - ImportantStatus: None
Privacy: PublicAssigned to: None
Open/Closed: OpenOperating System: Solaris

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Sun 24 Feb 2013 05:48:44 PM UTC, comment #31:

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.

Richard PALO <risto3>
Sun 23 Dec 2012 10:34:36 AM UTC, comment #30:

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)

Richard PALO <risto3>
Thu 20 Dec 2012 03:04:35 PM UTC, comment #29:

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

Bob Friesenhahn <bfriesen>
Project Administrator
Thu 20 Dec 2012 05:37:40 AM UTC, comment #28:

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

Gary V. Vaughan <gary>
Project Administrator
Thu 20 Dec 2012 04:48:06 AM UTC, comment #27:

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

Richard PALO <risto3>
Wed 19 Dec 2012 10:28:26 AM UTC, comment #26:

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

Peter Rosin <pekberg>
Project Member
Wed 19 Dec 2012 06:21:47 AM UTC, comment #25:

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)

Richard PALO <risto3>
Tue 18 Dec 2012 10:58:43 PM UTC, comment #24:

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

Peter Rosin <pekberg>
Project Member
Tue 18 Dec 2012 07:03:47 AM UTC, comment #23:

Since my original patch was in the vicinity, I suppressed $LDFLAGS as suggested, and it did get over the unsupported option problem.

Decided to try the OBJDUMP flavor of SONAME test since libtool stores it in config (stolen from destdir.at).

Attached is git diff that seems to work alright
I test with
gmake CC=g++ check-local TESTSUITEFLAGS="-d -x -k export"

I think now the pieces are at least in place thanks to Mr Rosin.

cheers

(file #27116)

Richard PALO <risto3>
Mon 17 Dec 2012 12:15:39 AM UTC, comment #22:

I had a look in the code and it is only for Solaris that
old_archive_cmds and archive_cmds are rigged to include
$LDFLAGS. This is clearly a buggy thing to do and it explains
why -no-undefined is passed down to gcc for you.

However, I have little Solaris expertise and will therefore
leave the resolution of the issue to someone more capable.

All in all, it's the Solaris part/port of libtool that is
buggy, and -no-undefined should stay in LDFLAGS in all those
test cases.

Cheers,
Peter

Peter Rosin <pekberg>
Project Member
Sun 16 Dec 2012 04:18:55 PM UTC, comment #21:

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

(file #27107)

Richard PALO <risto3>
Sun 16 Dec 2012 03:18:11 PM UTC, comment #20:

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

Bob Friesenhahn <bfriesen>
Project Administrator
Sun 16 Dec 2012 10:57:00 AM UTC, comment #19:

Well, I can certainly understand your reluctance to spend much more time on this, as I never really intended myself to do more than suggest a patch that fixes a libtool bug on solaris with gcc and solaris ld.

Adding the test functionality is more or less a moral responsability when suggesting the bugfix. Unfortunately, being an indirect libtool user and not a developer, I cannot do more than demonstrate the additional problem.

The testsuite problems in master (see comment #1) enticed me to focus on the version I'm testing in pkgsrc, namely in test v2.4.2 and in stable 2.2.6b).

BTW, perhaps it is buried in the comments below, but at least on the solaris platform, "-no-undefined" is by default, because if I change LDFLAGS to "-Wl,-z -Wl,defs" or "-Wl,--no-undefined" I get a warning that the option specified is a duplicate.

I do feel that the patch is warranted on 2.4.2 (perhaps generating patch release v2.4.2a or v2.4.3) and also in the master, so I will submit another patch, as Bob indicated, for the master and consider the 2.4.2 patch as a backport.

As the elements are provided to include the missing test functionality in export.at, I will leave that to the release team given the massive reoganisation of the sources, the tests will certainly need some generally updating. The case here is a good example...

I noticed in the document README-release that prior to releasing that

make distcheck CC=g++

should be executed.

I believe that

make check-local CC=g++

should also be executed and when it works, that is with a recent gcc (4.7.x), then the libtool and the testsuite are ready for release on a Linux/unix platform.

Cheers

Richard PALO <risto3>
Sun 16 Dec 2012 10:05:10 AM UTC, comment #18:

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.

Peter Rosin <pekberg>
Project Member
Sun 16 Dec 2012 07:50:59 AM UTC, comment #17:

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

Richard PALO <risto3>
Sun 16 Dec 2012 12:05:28 AM UTC, comment #16:

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)

Peter Rosin <pekberg>
Project Member
Sat 15 Dec 2012 11:18:58 AM UTC, comment #15:

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

Richard PALO <risto3>
Thu 13 Dec 2012 12:04:59 PM UTC, comment #14:

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

Peter Rosin <pekberg>
Project Member
Thu 13 Dec 2012 11:05:51 AM UTC, comment #13:

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.

Richard PALO <risto3>
Thu 13 Dec 2012 10:55:00 AM UTC, comment #12:

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.

Richard PALO <risto3>
Thu 13 Dec 2012 06:50:35 AM UTC, comment #11:

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.GA441@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

Richard PALO <risto3>
Wed 12 Dec 2012 07:20:43 PM UTC, comment #10:

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

Peter Rosin <pekberg>
Project Member
Wed 12 Dec 2012 03:58:31 PM UTC, comment #9:

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. ##

Richard PALO <risto3>
Wed 12 Dec 2012 03:13:44 PM UTC, comment #8:

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)

Richard PALO <risto3>
Wed 12 Dec 2012 02:38:32 PM UTC, comment #7:

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.

Bob Friesenhahn <bfriesen>
Project Administrator
Wed 12 Dec 2012 02:17:12 PM UTC, comment #6:

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

Richard PALO <risto3>
Wed 12 Dec 2012 01:52:40 PM UTC, comment #5:

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 was run,
1 failed unexpectedly.
## -------------------------- ##
## testsuite.log was created. ##
## -------------------------- ##

Please send per-test log files and all information you think might help:

To: <bug-libtool@gnu.org>
Subject: [GNU Libtool 2.4.2] testsuite: 45 failed

You may investigate any problem if you feel able to do so, in which
case the test suite provides a good starting point. Its output may
be found below `tests/testsuite.dir'.

gmake: *** [check-local] Error 1

I'll append the testsuite.log to show the absence of SONAME.

I guess I don't know enough about libtools testsuite system to get this invoked with the CXX tests...

(file #27081)

Richard PALO <risto3>
Tue 11 Dec 2012 04:54:49 PM UTC, comment #4:

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.

Richard PALO <risto3>
Tue 11 Dec 2012 03:58:21 PM UTC, comment #3:

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 <gord@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.000000000 +0000
+++ /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.

Richard PALO <risto3>
Tue 11 Dec 2012 02:57:29 PM UTC, comment #2:

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'.

Bob Friesenhahn <bfriesen>
Project Administrator
Tue 11 Dec 2012 11:58:04 AM UTC, comment #1:

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 ) \&&;/' < "$nlist"I >> "$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'

Richard PALO <risto3>
Mon 10 Dec 2012 01:58:02 PM UTC, original submission:

(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 -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 -Wl,-h -Wl,librarian.so.0 -o .libs/librarian.so.0.0.0
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" )

the corresponding -Wl,-h -Wl,$soname is now generated.

In looking at libtool.m4 from the 2.4.2 sources, the following lines appear suspect (in comparing with the GCC part a bit earlier in the code), follow the $GXX with_gnu_ld=no branch:

# GNU C++ compiler with Solaris linker
if test "$GXX" = yes && test "$with_gnu_ld" = no; then
_LT_TAGVAR(no_undefined_flag, $1)=' ${wl}-z ${wl}defs'
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 ${wl}-h $wl$soname -o $lib'
_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 -nostdlib ${wl}-M $wl$lib.exp -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags~$RM $lib.exp'

# Commands to make compiler produce verbose output that lists
# what "hidden" libraries, object files and flags are used when
# linking a shared library.
output_verbose_link_cmd='$CC -shared $CFLAGS -v conftest.$objext 2>&1 | $GREP -v "^Configured with:" | $GREP "\-L"'
else
# g++ 2.7 appears to require `-G' NOT `-shared' on this
# platform.
_LT_TAGVAR(archive_cmds, $1)='$CC -G -nostdlib $LDFLAGS $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-h $wl$soname -o $lib'
_LT_TAGVAR(archive_expsym_cmds, $1)='echo "{ global:" > $lib.exp~cat $export_symbols | $SED -e "s/\(.\)/\1;/" >> $lib.exp~echo "local: ; };" >> $lib.exp~
$CC -G -nostdlib ${wl}-M $wl$lib.exp -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags~$RM $lib.exp'

# Commands to make compiler produce verbose output that lists
# what "hidden" libraries, object files and flags are used when
# linking a shared library.
output_verbose_link_cmd='$CC -G $CFLAGS -v conftest.$objext 2>&1 | $GREP -v "^Configured with:" | $GREP "\-L"'
fi

Richard PALO <risto3>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

Attached Files
file #27141:  export.at.git-diff added by risto3 (1kB - application/octet-stream - git diff tests/export.at using testing for ELF and using OBJDUMP)
file #27123:  libtool.m4.git-diff added by risto3 (2kB - application/octet-stream - git diff --staged with $LDFLAGS suppressed in $archive_cmds)
file #27116:  export.at.git-diff added by risto3 (961B - application/octet-stream - git diff tests/export.at using OBJDUMP instead of ELFDUMP)
file #27107:  libtool.m4.git-diff-master added by risto3 (2kB - application/octet-stream - $ git diff --staged done in master)
file #27101:  testsuite.log added by pekberg (17kB - application/octet-stream - ...configure CC=g++; make CC=g++ check-local TESTSUITEFLAGS="-d -k export"...)
file #27082:  libtool.m4.git-diff added by risto3 (2kB - application/octet-stream - git diff --staged libtool.m4)
file #27081:  testsuite.log added by risto3 (7kB - text/x-log - export.at failure testsuite.log)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by gary (Posted a comment)
  • -unavailable- added by pekberg (Posted a comment)
  • -unavailable- added by bfriesen (Posted a comment)
  • -unavailable- added by risto3 (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 8 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun 23 Dec 2012 10:34:36 AM UTCristo3Attached File-=>Added export.at.git-diff, #27141
    Wed 19 Dec 2012 06:21:47 AM UTCristo3Attached File-=>Added libtool.m4.git-diff, #27123
    Tue 18 Dec 2012 07:03:47 AM UTCristo3Attached File-=>Added export.at.git-diff, #27116
    Sun 16 Dec 2012 04:18:55 PM UTCristo3Attached File-=>Added libtool.m4.git-diff-master, #27107
    Sun 16 Dec 2012 03:33:06 PM UTCbfriesenOperating System*BSD=>Solaris
    Sun 16 Dec 2012 12:05:28 AM UTCpekbergAttached File-=>Added testsuite.log, #27101
    Wed 12 Dec 2012 03:13:44 PM UTCristo3Attached File-=>Added libtool.m4.git-diff, #27082
    Wed 12 Dec 2012 01:52:40 PM UTCristo3Attached File-=>Added testsuite.log, #27081

    Back to the top


    Powered by Savane 3.1-cleanup