bug#15258: Fortran tests in configure script seem questionable

[Stefano Lattarini]

tags 15258 + moreinfo
severity 15258 minro
thanks

Hi Dennis, sorry for the delay.

On 09/03/2013 04:36 PM, Dennis Clarke wrote:
>  
> I am going to try to build automake-13.4 on Solaris with the Oracle Solaris 
> 12.3
> dev tools and within configure I see that Fortran tests fail : 
> 
> 
> node002$ ./configure 
> checking whether /usr/local/bin/gmake supports nested variables... yes
> checking build system type... sparc-sun-solaris2.10
> checking host system type... sparc-sun-solaris2.10
> checking for a BSD-compatible install... lib/install-sh -c
> checking whether build environment is sane... yes
> checking for a thread-safe mkdir -p... lib/install-sh -c -d
> checking for gawk... gawk
> checking whether /usr/local/bin/gmake sets $(MAKE)... yes
> checking whether ln -s works... yes
> checking for perl... /usr/local/bin/perl
> checking whether /usr/local/bin/perl supports ithreads... no
> checking for tex... tex
> checking for yacc... yacc
> checking for lex... lex
> checking whether autoconf is installed... yes
> checking whether autoconf works... yes
> checking whether autoconf is recent enough... yes
> checking whether ln works... yes
> checking for grep that handles long lines and -e... /usr/xpg4/bin/grep
> checking for egrep... /usr/xpg4/bin/grep -E
> checking for fgrep... /usr/xpg4/bin/grep -F
> configure: will now look for a sturdy POSIX shell, for our testsuite
> checking for sh... /usr/xpg4/bin/sh
> checking for sh5... no
> checking for dash... no
> checking for ash... no
> checking for bash... /usr/local/bin/bash
> checking for zsh... /usr/bin/zsh
> checking for ksh... /usr/bin/ksh
> checking for pdksh... no
> checking whether /usr/local/bin/bash supports $(cmd)... yes
> checking whether /usr/local/bin/bash supports $((expr))... yes
> checking whether /usr/local/bin/bash supports ${#var}... yes
> checking whether /usr/local/bin/bash supports ${var#glob} and ${var%glob}... 
> yes
> checking whether /usr/local/bin/bash preserves exit traps with "set -e"... yes
> checking whether /usr/local/bin/bash can define exit traps in a shell 
> function... yes
> checking whether /usr/local/bin/bash corrupts stderr with "set -x"... no
> checking whether /usr/local/bin/bash can return early from "dot-sourced" 
> files... yes
> checking whether /usr/local/bin/bash supports alias named like shell 
> builtins... yes
> checking whether /usr/local/bin/bash supports "test -e"... yes
> configure: shell /usr/local/bin/bash is good enough, stop looking
> configure: will use /usr/local/bin/bash as the testsuite shell
> configure: will now look for generic compilers
> checking whether the C compiler works... yes
> checking for C compiler default output file name... a.out
> checking for suffix of executables... 
> checking whether we are cross compiling... no
> checking for suffix of object files... o
> checking whether we are using the GNU C compiler... no
> checking whether /opt/solarisstudio12.3/bin/cc accepts -g... yes
> checking for /opt/solarisstudio12.3/bin/cc option to accept ISO C89... none 
> needed
> checking whether the C++ compiler works... yes
> checking for C++ compiler default output file name... a.out
> checking for suffix of executables... 
> checking whether we are cross compiling... no
> checking for suffix of object files... o
> checking whether we are using the GNU C++ compiler... no
> checking whether /opt/solarisstudio12.3/bin/CC accepts -g... yes
> checking for xlf95... no
> checking for f95... f95
> checking whether the Fortran compiler works... no
> configure: WARNING: Fortran compiler cannot create executables
> configure: tests requiring the Fortran compiler will be skipped
> checking for xlf... no
> checking for f77... f77
> checking whether the Fortran 77 compiler works... no
> configure: WARNING: Fortran 77 compiler cannot create executables
> configure: tests requiring the Fortran 77 compiler will be skipped
> configure: will now look for GNU compilers
> checking for gcc... no
> checking for g++... no
> checking for gpp... no
> checking for gfortran... no
> checking for g77... no
> checking for gfortran... no
> checking for gcj... no
> checking that generated files are newer than configure... done
> configure: creating ./config.status
> config.status: creating Makefile
> config.status: creating t/wrap/aclocal-1.13
> config.status: creating t/wrap/automake-1.13
> node002$ 
> 
> This is highly suspect given that I have a full Fortran 77, 90 and 95
> compiler in the Oracle software : 
>
> [SNIP]
>
To actually try to understand where the problem might be, I'd need the
content of the generated config.log file.  Could you please send it over?

> So perhaps the configure script is looking for GNU Fortran only? 
>
No, on the contrary, the script is tweaked to prefer non-GNU compilers
where available, to enhance testsuite coverage.

> The Fortran compilers provided, as well as everything else, are installed 
> in the bizarre location /opt/solarisstudio12.3/bin. For many many years
> the "defacto" 

bug#15256: GNU Automake 1.14 : FAIL 6 on Solaris 10 Sparc v9

[Stefano Lattarini]

severity 15256 minor
tags 15256 + moreinfo
stop

On 09/03/2013 03:47 PM, Dennis Clarke wrote:
>  As per test report : 
> 
> 
> Testsuite summary for GNU Automake 1.14
> 
> # TOTAL: 2874
> # PASS: 2726
> # SKIP: 101
> # XFAIL: 41
> # FAIL: 6
> # XPASS: 0
> # ERROR: 0
> 
> See ./test-suite.log
> Please report to bug-automake@gnu.org
> 
> gmake[2]: *** [test-suite.log] Error 1
> gmake[2]: Leaving directory 
> `/usr/local/build/automake-1.14_SunOS5.10_sparcv9.001'
> gmake[1]: *** [check-TESTS] Error 2
> gmake[1]: Leaving directory 
> `/usr/local/build/automake-1.14_SunOS5.10_sparcv9.001'
> gmake: *** [check-am] Error 2
> 
> I attach the test-suite.log file.
> 
> The testsuite log shows these are the culprits : 
> 
> $ grep "^FAIL\:\ " ./test-suite.log
> FAIL: t/instmany
> FAIL: t/instmany-mans
> FAIL: t/instmany-python
>
About this failures: you should try the patch I posted at:

and let me know if that fixes the failure of 't/instmany'.

> FAIL: t/yacc-cxx
> FAIL: t/yacc-d-cxx
> FAIL: t/yacc-mix-c-cxx
> 
Re these: I'm not sure if and when I'm going to look into them, sorry.
It might help if you took a stab yourelf at figuring out what is going
wrong.

Regards,
  Stefano

bug#14728: filenames starting with a dash confuse automake

[Stefano Lattarini]

tags 14728 wontfix
close 14728
stop

Stefano Lattarini wrote:
>
> Yes, but it might complicate or slow down the code, and I think it's
> not really worth spending time on it.  I won't refuse a patch in this
> direction though, *if* it doesn't complicate or slow-down the code.
> Otherwise, I will close this bug as "wontfix" sometime in the nearish
> future.

Since no new activity has been seen on this report in the last six
months, I'm closing it as promised.

Regards,
  Stefano

bug#7892: test failures induced by stale NFS files on Solaris

[Stefano Lattarini]

tags 7892 wontfix
close 7892
stop

Reference:


According to the details in the report, this issue was probably due
to a bug on Solaris NFS support.  Also, this bug hasn't seen any
activity in the past three years, and it's extremely unlikely it
will see any in the foreseeable future.  I'm thus closing it to
reduce the clutter in our bug tracker.

If anyone can reproduce this issue *and* has ideas for a fix can
feel free to reopen it.

Regard,
  Stefano

bug#7451: Better name for $(AM_V_at)?

[Stefano Lattarini]

tags 7451 wontfix
close 7451
stop

Reference:


I no longer think it's worth spending any more time on this issue, at
least not with the lack of manpower automake is suffering from at the
moment.  Closing to reduce the clutter in our bug tracker.

bug#15720: 1 failure in testsuite of GNU Automake 1.14

[Stefano Lattarini]

severity 15720 minor
close 15720
stop

Reference:

See also:


I'm closing this bug, since the spuriously failing test case
(tap-realtime.sh) has been removed from the Automake testsuite
already, as too brittle.

Thanks,
  Stefano

bug#12620: Parallel tests vs fast tests (and beyond)

[Stefano Lattarini]

severity 12620 wishlist
stop

Reference:


Marking this as a "wishlist" rather than a bug, since the current
implementation of parallel tests is working correctly and is mostly
"good enough", and your proposal is thus geared towards improving an
already decent situation rather than fixing errors or misbehaviors
(this doesn't mean I'm denying or belittling the merits of your
proposal, of course).

Just one nit:

Reuben Thomas wrote:
>
> The implication of the 1.12 release notes is that serial-tests
> will be dropped at some point post-1.13.
>
I've been convinced that any idea I had in such a direction was
misguided; the old serial harness is now marked merely as
"discouraged", but there no plans to deprecate pr remove it in
the foreseeable future.

Thanks,
  Stefano

bug#15521: two minor testsuite failures in Automake 1.14

[Stefano Lattarini]

tags 15521 + wontfix
close 15521
stop

Reference:


No reply after two months from our feedback request, so I'm
closing this bug to reduce the cluttering of our bug tracker.

Regards,
  Stefano

bug#13314: GNU Automake 1.12.6 Testsuite FAIL: 2 on Solaris 10

[Stefano Lattarini]

tags 13314 + wontfix
close 13314
thanks

Reference:


As part of an effort to reduce clutter in our bug tracker, I'm closing
this bug as "obsolete", since we have results of testsuite runs for
later automake releases (13.x and 14.x) on Solaris 10 already;
e.g., see ).

Regards,
  Stefano

bug#11377: configure.am - fails to remove configure before attempting replacement

[Stefano Lattarini]

tags 11377 + wontfix
close 11377
stop

Reference:


No more activity on this wishlist and controversial bug for
an year and a half.  I'm thus closing it to reduce the clutter
in our bug tracker.

Regards,
  Stefano

bug#14014: GNU Automake 1.13.1 testsuite FAIL: 1 on 3.2.0-4-powerpc64

[Stefano Lattarini]

severity 14014 minor
close 14014
stop

Reference:


I'm closing this bug, since the spuriously failing test case
(tap-realtime.sh) has been removed from the Automake testsuite
already, as too brittle.

Thanks,
  Stefano

bug#8599: upc (Unified Parallel C) support in automake

[Stefano Lattarini]

tags 8599 notabug
close 8599
stop

Reference:


It seems that all the issues relevant to this report where
either solved or offered viable and "blessed" workarounds,
but I still forgot to close the bug.  Doing it now to remove
some old clutter from our bug tracker.

Regards,
  Stefano

bug#15949: Apparently out-of-date warning

[Stefano Lattarini]

tags 15949 + notabug
close 15949
thanks

On 11/21/2013 11:05 PM, Reuben Thomas wrote:
> I am using automake 1.13.3. I noticed in the manual the following sentence
> in the section on building static libraries, which I do for my project with
> libgnu.a:
> 
> You should call 'AC_PROG_RANLIB' from your 'configure.ac' to define
> 'RANLIB' (Automake will complain otherwise).
> 
> I call AM_PROG_AR, and as far as I can see from the placement in my
> generated configure, that seems to be sufficient to define RANLIB;
> AC_PROG_RANLIB doesn't seem to be needed. At least, I get no errors, and
> the library is built.
>
But AM_PROG_AR truly does not define $RANLIB itself.  Perhaps you are
using libtool and calling AC_PROG_LIBTOOL or LT_INIT?  This would
exaplain your situation, since those macros call AC_REQUIRE on
AC_PROG_RANLIB (or define $RANLIB in a way similar to how AC_PROG_RANLIB
does it, I don't remember the exact details now).

> Can this sentence therefore be removed from the manual? I checked, and it
> is still present in current git.
> 
Give the above, I'd rather leave the sentence there :-)
Closing this bug.

Regards,
  Stefano

bug#9088: [PATCH] Make clear the JAVA primary will no longer be developed, not even for bug fixes.

[Stefano Lattarini]

tags 8540 + wontfix
tags 8662 + wontfix
close 8540
close 8662
stop

References:



The existing java support in Automake is (with the JAVA primary) is
botched and hardly usable, so I'd rather declare it frozen and spend
no more time on it.  The right direction for a better Java support
in automake is likely to implement the proposed new JARS primary:


The attached patch enhances the manual to make it clear that the
JAVA primary support is to be considered frozen, and will not even
receive bug fixes.

Unfortunately, I will have no time to attempt that implementation
myself in the foreseeable future, but I sill hope someone else will
find the time and motivation to give it a shot.

Anyway, I'm closing the bugs referring to the old JAVA primary as
"Will not fix", to try to reduce the clutter in the Automake bug
tracker.

Thanks,
  Stefano
>From 50a08a2bc300d600603cdb5b5756baf71b9b431a Mon Sep 17 00:00:00 2001
Message-Id: <50a08a2bc300d600603cdb5b5756baf71b9b431a.1388069253.git.stefano.lattar...@gmail.com>
From: Stefano Lattarini 
Date: Thu, 26 Dec 2013 15:46:13 +0100
Subject: [PATCH] docs: make clear the JAVA primary is frozen

* doc/automake.texi: Here.  The JAVA primary is broken in several ways,
and will no longer be developed, not even for bug fixes.

See also automake bugs #9088, #8662 and #8540.

Signed-off-by: Stefano Lattarini 
---
 doc/automake.texi | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/doc/automake.texi b/doc/automake.texi
index 91b4a0a..6d90182 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -7598,7 +7598,9 @@ native machine code; @pxref{Java Support with gcj}).  Note however that
 Future Automake releases will strive to provide a better and cleaner
 interface, which however @emph{won't be backward-compatible}; the present
 interface will probably be removed altogether some time after the
-introduction of the new interface (if that ever materializes).
+introduction of the new interface (if that ever materializes).  In any
+case, the current @code{JAVA} primary features are frozen and will no
+longer be developed, not even to take bug fixes.
 
 Any @file{.java} files listed in a @code{_JAVA} variable will be
 compiled with @code{JAVAC} at build time.  By default, @file{.java}
-- 
1.8.5.rc0.335.g7794a68

bug#11155: when cross-compiling with LT_INIT([win32-dll]) wrappers are installed instead of real programs

[Stefano Lattarini]

tags 11155 notabug
close 11155
stop

Reference:


This actually looks like a libtool bug rather than an Automake one.
I suggest you bring up the issue on libtool's list.  If it turns
out this actually is an Automake-specific issue, feel free to
reopen this bug.

Thanks (and sorry for the shameful delay in replying),
  Stefano

bug#13317: automake fails make check

[Stefano Lattarini]

tags 13317 + wontfix moreinfo
close 13317
stop

Reference:


Hi Ronald, sorry for the ridiculous delay.  I'm going through
some old logs, and stumbled on this old report of yours.

It seems to me that most of the failures you reported seem due
to some misconfiguration of your environment, e.g.:

  ar cru liblib.a x.o
  /usr/bin/ranlib: invalid option -- q

  cc  -g -O2   -o LDADD LDADD.o lib/liblib.a
  ld: warning: ignoring file lib/liblib.a, file was built for \
archive which is not the architecture being linked (x86_64)
  Undefined symbols for architecture x86_64:
"_lib", referenced from:
_main in LDADD.o
  ld: symbol(s) not found for architecture x86_64
  collect2: ld returned 1 exit status

In addition, automake have seen several non trivial changes in the
areas relevant to your report since you sent it here.  I'm thus
going to close this report to avoid keeping the bug tracker too
cluttered.

If you want to retry running the testsuite of the new Automake
release of just few days ago (1.14.1), feel free to open a new
bug to report any failure you incur into.

Thanks,
  Stefano

bug#14410: (was: GNU Automake 1.13.2 released)

[Stefano Lattarini]

retitle 14410  Suggested Texinfo suffixes inconsistent with suggestions of 
Texinfo manual
severity 14410 minor
tags 14410 wontfix
close 14410
stop

Reference:


> Hello Stefano.
>
Hi Antonio, sorry for the awful delay in replying.

> Thanks for the detailed announcement. One learns things reading it. :-)
>
> Stefano Lattarini wrote:
>>
>>   - Use of Texinfo input files with '.txi' or '.texinfo' extensions
>> is discouraged, and its use will raise warnings in the 'obsolete'
>> category.  You are advised to simply use the '.texi' extension
>> instead.
>
> After reading this, I have noticed an inconsistency between the automake
> and texinfo manuals about what extension is preferred:
>
> [1]http://www.gnu.org/software/automake/manual/html_node/Texinfo.html
> "Any Texinfo source file must end in the .texi, .txi, or .texinfo
> extension. We recommend .texi for new manuals."
>
> [2]http://www.gnu.org/software/texinfo/manual/texinfo/html_node/Minimum.html
> "By convention, the name of a Texinfo file ends with (in order of
> preference) one of the extensions .texinfo, .texi, .txi, or .tex. The
> longer extensions are preferred since they describe more clearly to a
> human reader the nature of the file. The shorter extensions are for
> operating systems that cannot handle long file names."
>
> Is there a reason to recommend a different extension that what texinfo
> itself recommends?
>
Yes, two related reasons:

  - Almost all existing GNU packages use the '.texi' extension for the
sources of their Texinfo manuals.

  - To simplify the implementation, in Automake-NG I had decided to only
support one suffix for Texinfo sources; since most existing
packages use the '.texi' suffix already, that is the one I settled
for, removing support for '.txi' and '.texinfo'.  For backward
compatibility reasons I didn't remove support for these two suffixes
in mainline Automake, but still, I marked them as discouraged, in
order to make an hypothetical transition to Automake-NG easier.

Regards,
  Stefano