In regard to: Re: hardcode_into_libs and Tru64 UNIX, Tim Mooney said (at...:
In regard to: Re: hardcode_into_libs and Tru64 UNIX, Peter O'Gorman said...:
Tim Mooney wrote:
Anyone know if the reversion to hardcode_into_libs=no was an intentional change, and if so what the reasoning was?
I have no idea, and a quick ChangeLog grep was not enlightening. If you feel like posting a patch with ChangeLog entry to -patches I'll apply it.
I would be willing to do that, but libtool 1.5.6 with hardcode_into_libs=no passes all 101 test on Tru64 UNIX 5.1b. libtool 1.5.6 with hardcode_into_libs=yes fails 2 of 97 tests, and skips 4 others. I haven't had a chance to look at what that's happening. The tests are:
FAIL: demo-make.test SKIP: demo-exec.test SKIP: demo-inst.test
FAIL: pdemo-make.test SKIP: pdemo-exec.test SKIP: pdemo-inst.test
I did some more testing of this over the weekend. It's not my patch
that's causing this, it's that after the patch demo/Makefile.in and
pdemo/Makefile.in need to be rebuilt, and automake (I've tried 1.8.2 and 1.8.5) is exiting with an error:
cd /local/src/RPM/BUILD/libtool-1.5.6/tests/../demo && /bin/ksh /local/src/RPM/BUILD/libtool-1.5.6/missing --run automake-1.8 --foreign Makefile.am: object `hello.$(OBJEXT)' created both with libtool and without
Makefile.am: object `foo.$(OBJEXT)' created both with libtool and without
gmake[3]: *** [/local/src/RPM/BUILD/libtool-1.5.6/tests/../demo/Makefile.in] Err
or 1
gmake[3]: Leaving directory `/local/src/RPM/BUILD/libtool-1.5.6/demo'
and
cd /local/src/RPM/BUILD/libtool-1.5.6/tests/../pdemo && /bin/ksh /local/src/RPM/BUILD/libtool-1.5.6/missing --run automake-1.8 --foreign Makefile.am: object `longer_file_name_hello.$(OBJEXT)' created both with libtool and without
Makefile.am: object `longer_file_name_foo.$(OBJEXT)' created both with libtool and without
gmake[3]: *** [/local/src/RPM/BUILD/libtool-1.5.6/tests/../pdemo/Makefile.in] Er
ror 1
gmake[3]: Leaving directory `/local/src/RPM/BUILD/libtool-1.5.6/pdemo'
Interestinly, if I do
make check;
make check;The first set fails 2 and skips 4, the second check passes all 101 tests, which means that Makefile.in is being updated, even though automake is exiting with an error.
BTW, after looking closer at the test suite, I have a couple questions:
- Are there plans to modify the test suite to use the 1.5.x tagging mechanism that Albert introduced, so that the test cases only use the parts of libtool they need (i.e. don't do a bunch of C++ and Fortran checks for a testsuite that only uses C)
- Is it necessary to have identical copies of `acinclude.m4' in each of the demo directories and the top level libtool directory? Must those directories be completely self-contained, or could they just reference/include the top level acinclude.m4?
I'll send along my original hardcode_into_libs patch for Tru64, but I think someone else is going to need to figure out how to pacify automake in the test suite.
Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164
_______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
