Disable test cleanup trap with OSF1/Tru64 sh.
The git master Automake testsuite still didn't work with Tru64 /bin/sh,
due to the shell messing up exit status values when both 'set -e' and an
EXIT trap were used. One way out would be to use the shell that
configure chooses: CONFIG_SHELL gets set to /bin/ksh, which doesn't have
this bug. However, since I'm so used to also run tests by just ./TEST
and that will choose /bin/sh anyway, I'm going to punt and just not
install a cleanup trap in this case. The warning should tell the user
to make clean so those 300some MB worth of testsuite leftovers get
cleaned here, too.
Applied to master. This makes the testsuite on a Tru64 5.1 go from two
XPASSes (i.e., all test results nonsensible), to a successful run, yay!
Cheers,
Ralf
Disable test cleanup trap with OSF1/Tru64 sh.
* configure.ac: Test whether /bin/sh has working 'set -e'
in conjunction with an exit trap. Set $am_cv_sh_errexit_works
accordingly, substitute sh_errexit_works, and warn about
leftover test directories with broken shells like Tru64 /bin/sh.
* tests/defs.in: Do not install any traps with broken shells.
diff --git a/configure.ac b/configure.ac
index 4229d68..e3c8535 100644
--- a/configure.ac
+++ b/configure.ac
@@ -171,6 +171,23 @@ AC_SUBST([MODIFICATION_DELAY])
AC_PROG_EGREP
AC_PROG_FGREP
+AC_CACHE_CHECK([whether /bin/sh has working 'set -e' with exit trap],
+[am_cv_sh_errexit_works],
+[if /bin/sh -ec trap 'exit \$?' 0; (exit 77); exit 77; test $? = 77
+then
+ am_cv_sh_errexit_works=yes
+else
+ am_cv_sh_errexit_works=no
+fi
+])
+if test $am_cv_sh_errexit_works = no; then
+ AC_MSG_WARN([`${MAKE-make} check' will leave leftover directories
tests/*.dir])
+ AC_MSG_WARN([you can clean them up manually using `${MAKE-make} clean' or])
+ AC_MSG_WARN([`cd tests ${MAKE-make} clean-local-check'])
+ dnl restore font-lock: `
+fi
+AC_SUBST([sh_errexit_works], [$am_cv_sh_errexit_works])
+
AC_CONFIG_FILES([
Makefile
doc/Makefile
diff --git a/tests/defs.in b/tests/defs.in
index d44ac9f..47e1c3a 100644
--- a/tests/defs.in
+++ b/tests/defs.in
@@ -251,21 +251,24 @@ chmod -R u+rwx $testSubDir /dev/null 21
rm -rf $testSubDir /dev/null 21
mkdir $testSubDir
-trap 'exit_status=$?
- cd $curdir
- case $exit_status,$keep_testdirs in
- 0,)
-chmod -R a+rwx $testSubDir /dev/null 21
-rm -rf $testSubDir ;;
- esac
- test $signal != 0
-echo $as_me: caught signal $signal
- echo $as_me: exit $exit_status
- exit $exit_status
-' 0
-for signal in 1 2 13 15; do
- trap 'signal='$signal'; { Exit 1; }' $signal
-done
+sh_errexit_wor...@sh_errexit_works@
+if test $sh_errexit_works = yes; then
+ trap 'exit_status=$?
+cd $curdir
+case $exit_status,$keep_testdirs in
+0,)
+ chmod -R a+rwx $testSubDir /dev/null 21
+ rm -rf $testSubDir ;;
+esac
+test $signal != 0
+ echo $as_me: caught signal $signal
+echo $as_me: exit $exit_status
+exit $exit_status
+ ' 0
+ for signal in 1 2 13 15; do
+trap 'signal='$signal'; { Exit 1; }' $signal
+ done
+fi
signal=0
# Copy in some files we need.
Setting shared lib version not functioning
The following is the beginning of my Makefile.am script: include_HEADERS = project.h lib_LTLIBRARIES = libproject.la noinst_HEADERS = proj_list.h libproject_la_LDFLAGS = -version-info 2:0:1 which worked fine when with previous loading of a library with 2:0:0 versioning code. But now, when I go through the autoreconf, configure, compile and install I get: libproject.a libproject.la libproject.so libproject.so.1 libproject.so.1.1.0 in /usr/local/lib and, of course, my previous application linkages will not work. Looking at the Makefile, all the set up looks fine with the 2:0:1 stuff inserted. I am at my wits end and any help greatly appreciated. Thanks in advance. -- The whole religious complexion of the modern world is due to the absence from Jerusalem of a lunatic asylum. -- Havelock Ellis (1859-1939) British psychologist
Re: Setting shared lib version not functioning
On Sunday 2009-05-03 17:41, Gerald I. Evenden wrote: libproject_la_LDFLAGS = -version-info 2:0:1 which worked fine when with previous loading of a library with 2:0:0 versioning code. But now, when I go through the autoreconf, configure, compile and install I get: libproject.so.1.1.0 Which is absolutely correct. Either you wanted 2:1:0, or 3:0:1 (just a guess though, I can't read minds). Have a look at `info libtool`, section Versioning::.
Re: Setting shared lib version not functioning
Hi Gerald, On 5/3/2009 9:51 AM, Jan Engelhardt wrote: On Sunday 2009-05-03 17:41, Gerald I. Evenden wrote: libproject_la_LDFLAGS = -version-info 2:0:1 which worked fine when with previous loading of a library with 2:0:0 versioning code. But now, when I go through the autoreconf, configure, compile and install I get: libproject.so.1.1.0 Which is absolutely correct. Either you wanted 2:1:0, or 3:0:1 (just a guess though, I can't read minds). Have a look at `info libtool`, section Versioning::. Hmmm. Jan is correct in his analysis of your versioning strategy. current : revision : age You really have no reason to increment only the age value of a library version. What you're implying by this new version of 2.0.1 is that this particular instance of your library is identical in every way to the previous version of 2.0.0, except that this one is now backward compatible with a prior version (1.x.y). If you made changes to the library, but did not in any way modify the interface, then you probably want to use version 2.1.0. If you modified the interface in a manner that's 100% backward compatible with the previous version, then you probably want 3.0.1. If you modified the interface in a manner that is NOT backward compatible (i.e., you removed an API function), then you probably want 3.0.0. It appears that Libtool is smart enough to detect ridiculous cases, but it should probably throw an error of some sort, rather than simply generate code with a different version number. Adding the libtool list. Regards, John
Re: Setting shared lib version not functioning
On Sunday 2009-05-03 18:58, John Calcote wrote: It appears that Libtool is smart enough to detect ridiculous cases, but it should probably throw an error of some sort, rather than simply generate code with a different version number. Since libtool is just a linker as far as is considered here, it has no knowledge of whether you added, remove, or abi/api-changed something. Of course 3:0:5 is ridiculous. You cannot have a version 3 library that supports the last 5 AXI versions. (If it were, then it would be possible to have a minus-1, minus-2 library version, but that is not plausible and hence contradicts 3:0:5.
Re: Setting shared lib version not functioning
On Sunday 03 May 2009 1:02:54 pm Jan Engelhardt wrote: On Sunday 2009-05-03 18:58, John Calcote wrote: It appears that Libtool is smart enough to detect ridiculous cases, but it should probably throw an error of some sort, rather than simply generate code with a different version number. Since libtool is just a linker as far as is considered here, it has no knowledge of whether you added, remove, or abi/api-changed something. Of course 3:0:5 is ridiculous. You cannot have a version 3 library that supports the last 5 AXI versions. (If it were, then it ^-- ??? would be possible to have a minus-1, minus-2 library version, but that is not plausible and hence contradicts 3:0:5. I want to thank you all for the assistance, however I still find the libtool manual not very illuminating. In particular, I used section 7.3 in make my release number and, in particular, item 5 related to adding an interface since last release as causing an addition to age. The big problem here is the three number do not seem independent, which compounds the problem. Perhaps item 3 was what should have changes but item 5 clause was also true. What I did to the library was add several procedures but the original functions were not changed nor affected. To me that affected item 5 or age. I was afraid that changing revision would negate previous linkages and necessitate redoing application linkage---which was unnecessary as none of the code they used was altered (as least as far as entry) You all seem to be indicating that age is superfluous. -- The whole religious complexion of the modern world is due to the absence from Jerusalem of a lunatic asylum. -- Havelock Ellis (1859-1939) British psychologist
Re: Setting shared lib version not functioning
On Sunday 2009-05-03 20:40, Gerald I. Evenden wrote: What I did to the library was add several procedures That in itself would cause a bump in the 'current' number to 3. but the original functions were not changed nor affected. So 'age' becomes 1, since you are still supporting (3-1) = 2. You all seem to be indicating that age is superfluous. Not at all.
Re: Effects of some references to other libraries in a shared library
On Sunday 2009-05-03 23:32, Gerald I. Evenden wrote: In a shared library there are about 8 routines out over 100 that refer to libgsl and libpthread. A frequent situation may arise where an application program has no need for using the 8 procedures infected with other library needs. At the current time, when I try to link such a program I get a failure unless I add all the references to the additional libraries---even though they are not employed by the program in any manner. Then something is wrong in your setup, because I do not need to list all indirect libraries. The only exception is when dealing with non-libtooled static libraries that have poor subobject management. Am I missing a trick? If the above answer does not answer it, try providing a test case and we'll take it apart :)
Re: Setting shared lib version not functioning
Gerald, On 5/3/2009 12:40 PM, Gerald I. Evenden wrote: I want to thank you all for the assistance, however I still find the libtool manual not very illuminating. In particular, I used section 7.3 in make my release number and, in particular, item 5 related to adding an interface since last release as causing an addition to age. The big problem here is the three number do not seem independent, which compounds the problem. Perhaps item 3 was what should have changes but item 5 clause was also true. The numbers aren't independent at all. Don't try to make the library interface version components into a software revision number. The scheme is the way it is because the OS library loader uses the values in these fields to determine if a particular library will support a particular interface request. When a program attempts to load a library versioned 1.0.0, but the OS loader can only find 2.0.1, then the loader will go ahead and load 2.0.1 because the '1' in the age field indicates that this library supports 1.x interfaces as well as 2.x. Jan answers the rest of your question in his response. Regards, John
