bug#10197: compilation failure with no message caused by libtool

I ran into a weird case today - trying to compile libvirt with CFLAGS
including -Wsuggest-attribute=pure -fipa-pure-const produced a compile
failure, but no message.  It turns out that for the file in question,
libtool ended up compiling things twice, but gcc only warns when -fPIC
is not in effect (for some reason, the combination of fPIC and
-fipa-pure-const appears to not catch the warning, unless -O is also
present).

$ gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I../gnulib/lib
-I../gnulib/lib -I../include -I../src/util -I../include -DIN_LIBVIRT
-I/usr/include/libxml2 -Wsuggest-attribute=pure -fipa-pure-const -c
util/buf.c -fPIC -DPIC -o a.o

$ gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I../gnulib/lib
-I../gnulib/lib -I../include -I../src/util -I../include -DIN_LIBVIRT
-I/usr/include/libxml2 -Wsuggest-attribute=pure -fipa-pure-const -c
util/buf.c -o b.o
util/buf.c:86:1: warning: function might be candidate for attribute
‘pure’ [-Wsuggest-attribute=pure]
util/buf.c:227:1: warning: function might be candidate for attribute
‘pure’ [-Wsuggest-attribute=pure]
util/buf.c:242:1: warning: function might be candidate for attribute
‘pure’ [-Wsuggest-attribute=pure]

But because the warning only occurs during the second compilation, I end
up with no warning message:

$ make
make  all-am
make[1]: Entering directory `/home/remote/eblake/libvirt/src'

bug#10198: [GNU Libtool 2.4.2] testsuite: 71 87 91 110 112 failed

i use Linux Ubuntu 10.10 
and trying to install libtool 2.4.2 
this what i got

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

ERROR: 93 tests were run,
10 failed (5 expected failures).
33 tests were skipped.
## -------------------------- ##
## testsuite.log was created. ##
## -------------------------- ##

Please send `tests/testsuite.log' and all information you think might help:

   To: <bug-libtool <at> gnu.org>
   Subject: [GNU Libtool 2.4.2] testsuite: 71 87 91 110 112 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'.

make[1]: *** [installcheck-local] Error 1
make: *** [installcheck-recursive] Interrupt

bug#10197: compilation failure with no message caused by libtool

On 12/02/2011 12:41 PM, Eric Blake wrote:

>
> Any suggestions on how to make libtool display the compiler errors that
> occur only when -fPIC is missing?  Or am I stuck not using
> -fipa-pure-const without also passing -O?

Does -no-suppress do this?

Peter

bug#10202: [GNU Libtool 2.4.2.123-1186-dirty] testsuite: 65 72 73 74 75 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 112 113 114 117 failed

-

_______________________________________________
Bug-libtool mailing list
Bug-libtool <at> gnu.org
https://lists.gnu.org/mailman/listinfo/bug-libtool

bug#10236: Enhancement: support for the nagfor compiler in Libtool

Dear all,
this is a bug report, but a feature request. In order to have support for the 
nagfor Fortran compiler which is used in the quality assignment of our 
software project it would be great to have included the following two minor 
changes in the libtool setup w.r.t. to  the stable version 2.4.2:

in ltmain.sh (for linking on Darwin systems only)

--- ltmain.sh	2011-12-06 14:46:16.000000000 +0100
+++ libtool-2.4.2/libltdl/config/ltmain.sh	2011-10-17 12:19:35.000000000 
+0200
 <at>  <at>  -7406,15 +7406,6  <at>  <at> 
 	  minor_current=$func_arith_result
 	  xlcverstring="${wl}-compatibility_version ${wl}$minor_current ${wl}-
current_version ${wl}$minor_current.$revision"
 	  verstring="-compatibility_version $minor_current -current_version 
$minor_current.$revision"
-          # On Darwin other compilers
-          case $CC in
-              nagfor*)
-                  verstring="${wl}-compatibility_version ${wl}$minor_current 
${wl}-current_version ${wl}$minor_current.$revision"
-                  ;;
-              *)
-                  verstring="-compatibility_version $minor_current -
current_version $minor_current.$revision"
-                  ;;
-          esac
 	  ;;

bug#10231: libtool.m4 makes the wrong shell (dash) run libtool

This is an old bug by now, but the reports I've seen do not seem to
get at all of it.

libtool.m4:LT_INIT says LIBTOOL='$(SHELL) $(top_builddir)/libtool'.
Gnu Make exports SHELL=/bin/sh.  Maybe other Makes too, I do not know.

Thus even when a package is configured and built with the same $SHELL,
the libtool script can get run by another shell than it was built for.
This breaks when libtool is built as a bash script using '+=', but
$(SHELL) does not support '+='.  In my case: Ubuntu's /bin/sh = dash.

Either the LIBTOOL= line should lose $(SHELL) so the #!<shell> line in
the libtool script takes effect, or it should use e.g. $(LT_SHELL)
which would be set to the shell which libtool was built for, or
libtool should exec itself with its desired shell.  Users should not
have to set CONFIG_SHELL=/bin/sh.

This applies to at least libtoolize 2.4.2 and Ubuntu's patched 2.4.
I'm using aclocal 1.11.1, autoconf 2.68.

Here is a minimized example:

mkdir foo foo/m4
cd    foo
echo 'int main() {return 0;}'	> foo.c

cat <<'EOF'			> Makefile.in
top_builddir =  <at> top_builddir <at> 
foo.o:;  <at> LIBTOOL <at>  --mode=compile  <at> CC <at>  -c foo.c
EOF

bug#10231: libtool.m4 makes the wrong shell (dash) run libtool

On 12/06/2011 05:59 AM, Hallvard B Furuseth wrote:
> This is an old bug by now, but the reports I've seen do not seem to
> get at all of it.
>
> libtool.m4:LT_INIT says LIBTOOL='$(SHELL) $(top_builddir)/libtool'.
> Gnu Make exports SHELL=/bin/sh.  Maybe other Makes too, I do not know.
>
> Any advise as to what to do (other than staying with libtool 1.5)?
> For now I use the simplest fix, removing $(SHELL).  Or should
> Makefile.in be using something else than  <at> LIBTOOL <at> ?

Hi,

Thanks for the report.

Removing $(SHELL) from LIBTOOL makes sense to me, I don't know if it 
will cause problems on windows though?

If it's a problem, we can AC_SUBST(LT_SHELL) and use that (which will 
cause problems for people not using automake, like yourself).

Peter

bug#10231: libtool.m4 makes the wrong shell (dash) run libtool

Peter O'Gorman writes:
> Removing $(SHELL) from LIBTOOL makes sense to me, I don't know if it 
> will cause problems on windows though?

Don't know.  Since this is for a Unix-style Makefile, I expect it
depends on Cygnus et al to compile system() and exec() in the Make
program into library calls which handle '#!'.

> If it's a problem, we can AC_SUBST(LT_SHELL) and use that (which will 
> cause problems for people not using automake, like yourself).

Eh, right.  Sounds like the shell should be inserted in the LIBTOOL
definition itself then, without going via an LT_SHELL.

Which in turn would prevent people from running libtool with another
shell if the current shell breaks, if there is any reason to do that.

--

-- 
Hallvard

bug#10231: libtool.m4 makes the wrong shell (dash) run libtool

Peter O'Gorman wrote:
> 
> Removing $(SHELL) from LIBTOOL makes sense to me, I don't know if it
> will cause problems on windows though?
> 

I don't think it should matter.  Both Cygwin and MSYS have /bin/sh and
/usr/bin/sh.  Without a POSIX shell libtool is impossible anyway.

--

-- 
Earnie
-- https://sites.google.com/site/earnieboyd/

bug#10247: [GNU Libtool 2.4.2] testsuite: 119 passed unexpectedly

Hi Libtoolers,
 	Testing 2.4.2 on powerpc-darwin8, I got just one lone test 
failure (119: darwin gdb debug failure).  Otherwise, everything else looks 
good.

## ----------------------------- ##
## GNU Libtool 2.4.2 test suite. ##
## ----------------------------- ##

Shell option parser generator.

   1: short option splitting                          ok
   2: enhanced shell short option splitting           ok
   3: long option splitting                           ok
   4: XSI long option splitting                       ok
   5: option appending                               PASS: tests/quote.test
  ok
   6: enhanced shell option appending                 skipped 
(getopt-m4sh.at:172)

Libtoolize operation.

   7: libtoolize macro installation                   ok
   8: libtoolize macro directory mismatch error       ok
   9: libtoolize macro serial update                  ok
  10: libtoolize config files serial update          PASS: 
tests/suffix.test
  ok
  11: diagnose missing LT_CONFIG_LTDL_DIR             ok
  12: copy ltdl.m4 with shared macro directory        ok