Re: How to get autoconf to respect CC="gcc -std=c89"?

[Bob Friesenhahn]

On Wed, 11 Oct 2023, Evgeny Grin wrote:


This wouldn't work for the original problem: detection of C++-style comments 
by force enabling C89-only to check that sources still could be compiled with 
C89 compiler.


Yes, it seems that efforts have gone off the rails and are trying to 
address some other problem.


The problem is that Autoconf is defeating the recipient's freedom to 
select the compilation settings used.


The person who is compiling the software should be able to specify the 
parameters to use used.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: How to get autoconf to respect CC="gcc -std=c89"?

[Bob Friesenhahn]

On Fri, 6 Oct 2023, Zack Weinberg wrote:


This is currently not possible, but you are not the only person who has
asked for it to be made possible, and it's on our near-future list.
However, none of the core Autoconf developers currently have time to work
on it.  Might you be willing to put some time into it?  I think something
like this in configure.ac

AC_C_STANDARD_VERSION([c89])
AC_PROG_CC


I have also wanted (and tried to) test code for c89 and c99 compliance 
(to test for an element of portabilty) , but was similarly foiled.


The suggested approach does not allow the user to optionally compile 
the code for a particular C version without editing configure.ac.  The 
developer may prefer to use the Autoconf default.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: AC_SYS_LARGEFILE

[Bob Friesenhahn]

On Mon, 11 Sep 2023, Sébastien Hinderer wrote:


Dear all,

I am writing with a quesiton about the AC_SYS_LARGEFILE macro.

It would be great to be able to use it but according to its
documentation, the macro adds its flags to the CC output variable, which
is not convenient in my context because we have dedicated variables not
only for C flags but also for C preprocessor flags. Thus, what I'd
ideally need is a version of the macro where I can somehow specify what to
do with both large-file related CFLAGS and CPPFLAGS.


The pre-processor and linker options produced are not like normal 
pre-processor and linker options so they are treated differently.  If 
they are not submitted via CC / LD, then the final result might not 
work properly.


It seems that the original LFS specification has gone off line except 
for perhaps archive.org.  I found it at 
https://web.archive.org/web/20010703085350/http://ewe3.sas.com/standards/large.file/


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: INSTALL nits

[Bob Friesenhahn]

On Thu, 17 Aug 2023, Gavin Smith wrote:


Is there any consistency in naming across different packages, i.e.
is "bootstrap" the most widely used name?


No, there is no consistency across different packages.  If this was 
part of the GNU coding standards then perhaps actual GNU projects 
might be convinced to use a standard name.  But most consumers of 
Autoconf are not GNU projects.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: INSTALL nits

[Bob Friesenhahn]

On Mon, 14 Aug 2023, Gavin Smith wrote:

It seems that people are more likely to be have broken or unusual setups
when reading an INSTALL file than when reading other text files, making
UTF-8 more of a potential problem.


* A "bootstrap" command is recommended as the first step:

The following shell commands:

  test -f configure || ./bootstrap
  ./configure
  make
  make install

 should configure, build, and install this package.

However, a "bootstrap" command does not exist in all packages (and isn't
specified by the GNU coding standards(*)), making this INSTALL file less
useful to include in other packages.

 (*) 
https://www.gnu.org/prep/standards/html_node/Managing-Releases.html#Managing-Releases).

The text also says, several paragraphs later, that the "bootstrap" command
can download data from a network, which is not respecting the user's privacy
and the other downsides of network access (expense, reliability).


You make good points about unecessary use of UTF-8 and particularly 
the "bootstrap" command.


In a normal GNU package, there should be no need for a bootstrap 
command since the provided tarball should already be completely 
prepared.


If the software is accessed if a source repository (e.g. git), then it 
is much more likely that some "bootstrap" magic is required. 
Unfortunately, the "bootstrap" magic is highly project-specific.  It 
might just execute already installed Autotools, or it might do 
something like check out sub-repositories from other projects.


To me, an arbitrary bootstrap script is both a privacy and security 
hazard without the user carefully studying the design of the script. 
It is capable of doing anything that the user is capable of doing. 
This is in addition to the possible need for "network access" which 
you already mentioned.


There are use-cases where software is compiled in secure environments, 
or otherwise without network access.


It is true that Autotools-based packages could be seen as a security 
menace because they execute arbitrary scripts, but at least they are 
usually released in a way which allows them to be validated.


Any generic instructions should make the user aware of these issues.

Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: parallelization of ./configure compiler test processes

[Bob Friesenhahn]

On Thu, 30 Mar 2023, Thomas Jahns wrote:


speed up configure scripts is much narrower. Also I think having 
quicker turnaround in the usual development environment is still 
very much valuable, if seldom used deployment targets still are 
fully functional. If one compares what the original ksh does in 
terms of temporary files and forked processes to how a modern zsh or 
bash runs the very same script, one can find there's also historical 
precedent for the kind of optimization I'm proposing.


I know that modern ksh93 (https://github.com/att/ast) provides 
built-in implementations of POSIX utilities and maps common paths to 
the built-in implementations.  Does bash do that as well?


Obviously excessive forks, temporary files, using a real disk, etc., 
cause a slow-down.



One would think that a "compiler" test should be cacheable given the same 
compiler with similar options.


That's certainly true for an unchanged configure scripts running 
from the same initial state (arguments, environment variables etc.) 
and can probably be used to good effect in e.g. CI/CD setups. For 
tools like spack, where probably a rebuild almost always means that 
some aspect of the environment has changed too (OS update, changed 
flags, newer compiler version) I'm not so sure test results can 
safely be cached. At least not without keeping track of 
substantially more state than current autoconf caching provides.


It would require some sort of a high-speed database (maybe residing in 
a co-process or a file-based database) to store known results and a 
fast hashing strategy to identify when inputs are the same as a known 
result.  It would only help if the cache-lookups are less expensive 
than the actual tests.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: parallelization of ./configure compiler test processes

[Bob Friesenhahn]

On Thu, 30 Mar 2023, Thomas Jahns wrote:


Hello Danny,

I spent some time thinking about improvements to autoconf configure scripts 
(while waiting for builds to proceed). In my view, it is currently still easier 
to seek small efficiency gains that, in sum, could still improve run-time 
substantially than parallelizing the whole would be, because there is so much 
often untapped potential:

* Use bash builtin shell commands to fork and especially exec less. In modern 
systems with comparatively fast data paths compared to anything that affects 
resource control, like changing memory mappings, dropping caches etc., syscalls 
can be a substantial source of slow down.
* Use TMPDIR to prevent temporary files from hitting disk (use /dev/shm or 
similar instead of /tmp)
* In the case of spack I've seen substantial improvements from running the 
whole build in /dev/shm and think spack should at least mention the possibility 
for systems with substantial amounts of RAM (and guess what kind of system many 
sites using spack just happen to have?).
* The gcc option -pipe is similarly helpful to get build phases to start as 
soon as possible.


The main problem with the above is that it is focused on one 
particular shell, and operating system.  While the combination is very 
popular, Autoconf is still also a portability tool.


While continued optimization is important, I suggest that a good 
strategy is to also spend more time on investigating useful caching 
features.  It is common that a given test permutation is executed more 
than once.  By implementing a smart shared cache, it should be 
possible to identify similar permutations and cache the results so 
that the next time they are encountered, the cached results will 
simply be used.  The cache could be at the user and/or whole system 
level.


Autoconf already has good support for a local cache so that a 
re-configure is much faster, and it has support for a system-wide 
shared cache.


Speed-up due to caching can be explored by using the --config-cache 
option, or using a config.cache file.


One would think that a "compiler" test should be cacheable given the 
same compiler with similar options.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: Possible regressions with trunk autoconf (vs 2.71)

[Bob Friesenhahn]

On Thu, 17 Nov 2022, Paul Eggert wrote:

Thanks for reporting that. I installed the attached patch to work around the 
bug in libpng. Of course this is just a hack, but there's some benefit to it 
and no harm that I can see.


Could you please report the issue to the libpng maintainers? The attached 
second patch should work around the immediate issue for them. I am not 
plugged into the libpng ecosystem and don't know how to send them bug 
reports. Thanks.


I have forwarded this to Cosmin Truta, the current libpng maintainer.
It may be useful to open a formal bug in the libpng bug tracker 
(presumably at Github) in case he is busy.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Bob Friesenhahn]

On Tue, 15 Nov 2022, Sam James wrote:





On 13 Nov 2022, at 00:43, Paul Eggert  wrote:

On 2022-11-11 07:11, Aaron Ballman wrote:

We believe the runtime behavior is sufficiently dangerous to
warrant a conservative view that any call to a function will be a call
that gets executed at runtime, hence a definitive signature mismatch
is something we feel comfortable diagnosing (in some form) by default.


As long as these diagnostics by default do not cause the compiler to exit with nonzero status, we 
should be OK with Autoconf-generated 'configure' scripts. Although there will be problems with 
people who run "./configure CFLAGS='-Werror'", that sort of usage has always been 
problematic and unsupported by Autoconf, so we can simply continue to tell people "don't do 
that".



Is there somewhere in the autoconf docs we actually say this?

I've seen a few instances of folks adding it themselves very
early in their configure scripts (which is a pain for distros
anyway) which then ends up affecting the rest.


Autoconf can help with this issue due to GCC and some other compilers 
providing extensions (usually a pragma) to control warnings while 
compiling the C code.  So configure can run without -Werror, but 
Autoconf could help by providing an easy way for enabling -Werror 
while compiling the application.


Of course the above does not require Autoconf since application 
developers can figure it out by themselves using preprocessor logic 
and knowledge of compiler-specific behavior.


If Autoconf is able to help, then the convoluted code can be in just 
one place (in Autoconf).


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Bob Friesenhahn]

On Thu, 10 Nov 2022, Zack Weinberg wrote:


The biggest remaining (potential) problem, that I’m aware of, is that
AC_CHECK_FUNC unconditionally declares the function we’re probing for
as ‘char NAME (void)’, and asks the compiler to call it with no
arguments, regardless of what its prototype actually is.  It is not


This does seem like the biggest problem since it would appear to 
require that new macros are used and that the configure.ac developer 
would need to supply additional syntax (where syntax does not 
currently exist) in order to succeed with linking.  It is not possible 
for Autoconf itself to anticipate the function names used by libraries 
and assume some specific prototype.


There was already the issue that when testing for functions in static 
libraries (or libraries which otherwise require full linkage) that it 
is necessary to supply the library dependencies at the same time.  It 
might also be necessary to provide the linker search paths as well.


While GCC is GNU's compiler, there is too much focus on GCC here.  Any 
compiler currently usable with Autoconf might change to conform with 
the standard such that configure scripts no longer work with it.


The only reassurance is that GCC/Clang authors can not do what they 
want to do without providing a means for Autoconf and other similar 
test-based systems to work as is since Autoconf is so important.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: Parallelization of shell scripts for 'configure' etc.

[Bob Friesenhahn]

On Thu, 16 Jun 2022, Demi Marie Obenour wrote:


Finally, a small but probably noticable improvement would come
from dropping support for ancient platforms, such as Ultrix.  A much
bigger win would be to use Bash or Zsh if they are installed, as that
allows using modern shell tricks (such as [[ "$a" =~ [0-9]+ ]] and
"${a//a/b}") that do not require forking new processes.


The configure script already tries to deduce the best shell 
(CONFIG_SHELL) to use to run the rest of the configure script.  It is 
pretty common that the shell selected is bash (if it was not already 
bash).


It has been noticed that bash is rarely the fastest shell out of the 
options available.  For example 'dash' is often used since it tends to 
execute more quickly.


If projects established a baseline for the antiquity of the targets 
they support, then the number of tests can be reduced and configure 
will run faster.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: Detecting gated functions w/ AC_CHECK_FUNCS()

[Bob Friesenhahn]

On Mon, 2 May 2022, Philip Prindeville wrote:


Hi,

I was wondering how to do discovery of functions like open_memstream() which is only 
exposed by  when compilation used -D_GNU_SOURCE or 
-D_POSIX_C_SOURCE=200809L.

It might be the case that I compile everything with a certain flag, or I might 
just compile one-off modules such as:

time.o: _ASTCFLAGS+=-D_XOPEN_SOURCE=700

What's best practices for handling situations like this?

How do I bracket a particular AC_CHECK_FUNCS() invocation with defines that 
might be critical?

I tried using:

save_CFLAGS="$CFLAGS"
CFLAGS="CFLAGS -D_POSIX_C_SOURCE=200809L"
AC_CHECK_FUNCS([open_memstream])
CFLAGS="$save_CFLAGS"


Normally one should use CPPFLAGS rather than CFLAGS for options 
pertaining to the C pre-processor.


When library function availability is checked, it is normally done 
using the linker.


When in doubt, check config.log, which will show the test program and 
steps which were used while performing the test.


It is not wise to mix C/OS standard influencing pre-processor options 
when compiling since they may require a different ABI, which could be 
provided by alternate libraries.  It might not be possible to support 
more than one ABI at a time.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: libtool-2.4.7 released [stable]

[Bob Friesenhahn]

On Thu, 24 Mar 2022, Alex Ameen wrote:


Howdy, Libtoolers!

After a long hiatus, the Libtool Team is pleased to announce the release of
libtool 2.4.7.


Excellent!


The SHA256 checksum is base64 encoded, instead of the
hexadecimal encoding that most checksum tools default to.


The above is a very strange decision which I have only seen before for 
OpenSSH.


This is a way to verify using openssl:

  openssl sha256 -binary libtool-2.4.7.tar.gz | base64

Is there a GNU tool which can do this?

Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: Wrong order of preprocessor and compiler flags

[Bob Friesenhahn]

On Thu, 24 Mar 2022, Evgeny Grin wrote:


It's not uncommon to use CFLAGS for macros or for '-I' flags.
I think it's easy to imagine other conflicting situation where the order of 
used flags is significant.


It may not be uncommon, but it is a usage bug to use CFLAGS for 
pre-processor options.  Such usages should be corrected.


Becides cases where the pre-processor may be used directly (not sure 
if there are any), it should be considered that CPPFLAGS works for 
both the C and C++ compilers but CFLAGS is only for the C compiler.


Usage of CPPFLAGS before CFLAGS looks logical for me, I think autoconf should 
be fixed.


It does feel more logical.

Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: portability of xargs

[Bob Friesenhahn]

On Tue, 15 Feb 2022, Paul Smith wrote:


On Tue, 2022-02-15 at 15:37 -0600, Bob Friesenhahn wrote:

I have been told by several people (who have much more self-esteem
than me) that a build tool called 'cmake' is far more portable than
Autotools so maybe we should make support for 32 year old systems
cmake's responsibility?


That is not accurate.  Or at least, cmake uses a much different
definition of "portable" than autoconf / automake.  Certainly cmake
cannot possibly support 32-year old systems (if that's needed).


Thanks for the nice response.  I did not for a minute think that 
what I was told was accurate.


The people who tell me it is more portable are very interested in 
targeting Microsoft Windows.



cmake is a tool that, given an input definition of build dependencies,
can generate build control files for multiple different types of build
tools.  It can generate makefiles, Ninja files, Xcode project files,
and Visual Studio project files.  Maybe others, I'm not sure.


The "Makefiles" that Cmake generates are self-referential in that 
almost all rules invoke Cmake to do the work.



The main idea of autoconf is that it allows configuring the package for
systems that the author never even heard of, much less has access to
(as long as it has a POSIX interface).  cmake only tries to generate
output files for systems it has been developed for (for example, each
new version of Visual Studio often requires a new release of cmake to
support it).


The above is a perfect description of the situation.


Of course maybe autoconf is not necessary anymore: I don't know about
that.  I do know that even though GNU make itself is relatively simple,


I find that the function of Autoconf is quite useful.  When compared 
with Cmake, it is much more user-friendly since the configure script 
responds to --help and the help output is very helpful.  The configure 
script nicely tells me what it is doing and what it found.  Autotools 
is very structured and projects work in a common way whereas I find 
that Cmake projects are heavily customized with options added by the 
project developer.  Just doing a build entirely outside of the source 
tree is extremely clumsy with Cmake.


Regardless, I don't think that Autotools developers should waste time 
on assuring compatability with systems which are no longer in active 
use.  It is much better so spend time improving areas where Autotools 
is weak.


If 'xargs' has worked consistently for 20 years, it should be ok to 
use.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: portability of xargs

[Bob Friesenhahn]

It it really expected that Autotools should support 32 year old 
systems?


This feels counter-productive to me.

I have been told by several people (who have much more self-esteem 
than me) that a build tool called 'cmake' is far more portable than 
Autotools so maybe we should make support for 32 year old systems 
cmake's responsibility?


I am fond of systems from the early/mid '90s but it seems better to 
support POSIX compliant systems with newer software.


People who have somehow figured out how to keep old hardware running 
without disk drives, electrolytic capacitors, or fans, can install 
older GNU software first in order to bootstrap sufficiently to a 
sufficient level of POSIX compliance.


The well-built systems I bought prior to 2007 are already dead or 
difficult to repair.


I do not see any reason to spend any time at all supporting an OS 
older than 2008.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: portability of xargs

[Bob Friesenhahn]

On Mon, 14 Feb 2022, Mike Frysinger wrote:


On 14 Feb 2022 19:53, Paul Eggert wrote:

On 2/14/22 19:45, Mike Frysinger wrote:

how portable is xargs ?


It can be a porting problem, unfortunately. There are several corner
cases that various implementations don't get right. I expect this is why
the GNU Coding Standards exclude xargs from the list of programs that
'configure' and Makefile rules can use.


are the corner cases known ?  if it's such that xargs doesn't always correctly
limit itself to the system limit based on other factors, i can live with that
assuming that the -n option is reliable.


This morning I read this discussion thread and did not see any actual 
problems with current (on systems that people are still using) xargs 
portability mentioned.


Microsoft Windows (e.g. POSIX environments which run under Windows 
such as Cygwin, MSYS, etc.) is surely an existing corner case which 
demands more attention than archaic systems.  It seems that the 
command line length when using Microsoft Windows may depend on the 
number of bytes in the arguments (not the number of arguments) as well 
as the number of bytes in the current environment variable data.


A problem with xargs is that without using the GNU -O or --null 
argument and null-terminated arguments, file names containing spaces 
won't be handled properly.  File names containing spaces is an issue 
for Autotools in general.  This is again an issue under Microsoft 
Windows where users typically are provided with directory paths which 
contain a space and they need to take additional administrative 
measures in order to provide directory paths which work with 
Autotools.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: abs_top_srcdir broken?

[Bob Friesenhahn]

On Mon, 18 Oct 2021, Nick Bowler wrote:


Configure scripts are always executed from the top build directory so
most of these directory variables are not needed in tests.  If required,
it is easy enough to compute absolute directories in the shell:

 case $srcdir in
 /*) my_abs_top_srcdir=$srcdir ;;
 *) my_abs_top_srcdir=`pwd`/$srcdir ;;
 esac


GraphicsMagick does this to get a full path to the top of the source 
tree:


  srcdirfull="`cd $srcdir && pwd`"

Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: Checking failing dlopen when building 32bit software

[Bob Friesenhahn]

On Mon, 11 Oct 2021, alexandre schenberg wrote:


  which made sense, as I had not yet made a symbolic link to libdl on
  /usr/lib32. Then I just did it. Yet, this error message continued to
  appear. What changed was this detection test: "checking for dlopen in
  -ldl..." that went from "no" to "yes", notwithstanding  that "checking
  for dlopen." continued to return no.

  Following suggestion on a message board, I was able to circumvent these
  "skipping incompatible" error messages  by adding a "-L/usr/lib32/
  -ldl" to the end of wine's configure parameter list.


Adding -L/usr/lib32/ was likely the correct thing to do.


  So what was left from these messages on wine, mesa and alsa was the:
  "checking for dlopen... no". It did not stop me to build Alsa. I don't
  know about mesa and wine, since I still have many other tests to deal
  it before I can try to compile them. What I am afraid of, is that this
  can make a software to refuse to run for not finding the 32bit library
  that it requires (like wine not finding a .so alsa library)


If the software does not use dlopen, then support for dynamic modules 
or dynamically loading libraries may be missing from it.  Depending on 
the software, this might severely diminish its functionality.



  Does this fear have any basis or am I looking for trouble without need?
  Can I safely ignore this libdl check?

  I also would like to understand the reason behind the "skipping
  incompatible" error messages. It seems it was looking for libdl on
  /usr/lib64/ instead /usr/lib32. If so, why? I understand that
  /usr/lib32 did not exist when the system was installed, but looking for
  a 32bit library on a 64bit dir just does not compute.


I suggest reading the documentation for 'ldconfig' and 'ld.so'.

The "skipping incompatible" message is really a warning but it becomes 
significant if the 32-bit library is not found.


Major x86-64 Linux distributions appear to be in the process of 
removing 32-bit support.  Be aware that if you get 32-bit support 
working today on your Linux distribution that it might not work in the 
next major release cycle.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: automake problem with multiple "-rpath"

[Bob Friesenhahn]

On Mon, 10 May 2021, aotto wrote:


./configure {CC=gcc -m32 -O2} --prefix=... --enable-shared --disable-static 
--with-readline-includes=... {--with-readline-library=-L.../lib -lreadline} 
--with-tcl=.../lib --with-tcl-includes=...


The above does not look good to me.  It seems that you expect the 
configure script to convert the strange '.../lib' into a 
fully-qualified path (e.g. using 'realpath path' or '(cd path && 
pwd)'.  If it did not do so, then any use of the path would fail or be 
silently ignored if the build process did any 'cd' while building. 
Most people would use ../lib rather than .../lib.


So you could do something like

  -L`pwd`/../lib

to form a fully-rooted path.


I choose Try3 
so much time spend for a stupid single problem :-(


All problems are stupid!

Notice that you posted to the 'autoconf' list about an 'automake' 
problem rather than posting to the GNU 'automake' list, although this 
could possibly be a libtool problem and thus an issue for discussion 
on the 'libtool' list.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: How to "bake in" configure args

[Bob Friesenhahn]

On Wed, 24 Mar 2021, Dan Mahoney (Gushi) wrote:


On Tue, 23 Mar 2021, Bob Friesenhahn wrote:


On Tue, 23 Mar 2021, Dan Mahoney (Gushi) wrote:


Is there a "standard" way to do this?  Google kind of fails for this.


I see that Gavin Smith already answered the question you asked, but 
GraphicsMagick took a different tact.


I didn't find that to be an "answer" so much as a request for more 
clarification.


In that case, the "answer" is that there is no "standard" way to to 
this.  It will require some added code in configure.ac to store the 
values in a header file, and also in the application to store and 
print them out.  As Richard Purdie points out, adding text strings 
which are dependent on the build environment (including the configure 
options) may cause the binaries to not be reproducible.  In other 
words, the results may then vary depending on who/where the build is 
performed.


The configure script could also perform substitutions on a template 
text file which is delivered with the application as a record for how 
it was built (rather than baking strings in the binaries).


I'm nominally not a C coder, I'm just the guy who gets to answer support 
tickets and triage bug reports and get users to figure out if they installed 
their OS package, how that was set up and compiled.


Certainly, knowing the actual values which were used in the build are 
useful.  The values used in the build may not be the same as in the 
run-time environment since the ABI "contract" provided by a library 
might still be honored even though the library used while building 
depends on different libraries than in a particular run-time 
environment.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: How to "bake in" configure args

[Bob Friesenhahn]

On Tue, 23 Mar 2021, Dan Mahoney (Gushi) wrote:


Is there a "standard" way to do this?  Google kind of fails for this.


I see that Gavin Smith already answered the question you asked, but 
GraphicsMagick took a different tact.  The configure options used are 
interesting but don't provide the answers for what the configure 
script ended up using for the build.  And so GraphicsMagick is 
providing additional data like this:


Configured using the command:
  ../GraphicsMagick/configure  'PSDelegate=/bin/true' 'CC=gcc-10' 
'CXX=g++-10' 'CFLAGS=-march=native -O2 -frename-registers -g -Wall 
-Winline -W -Wformat-security -Wpointer-arith -Wdisabled-optimization 
-Wmissing-noreturn -Wno-unknown-pragmas -Wvla' 'CXXFLAGS=-march=native 
-O2 -g -Wall -Winline -W -Wextra -Wno-unknown-pragmas' 
'LDFLAGS=-L/usr/local/lib -Wl,-rpath,/usr/local/lib' 
'--with-quantum-depth=16' '--disable-shared' '--enable-static' 
'--enable-openmp-slow' '--enable-silent-rules' '--without-xml'


Final Build Parameters:
  CC   = gcc-10
  CFLAGS   = -fopenmp -march=native -O2 -frename-registers -g -Wall 
-Winline -W -Wformat-security -Wpointer-arith -Wdisabled-optimization 
-Wmissing-noreturn -Wno-unknown-pragmas -Wvla -Wall -pthread

  CPPFLAGS = -I/usr/include/freetype2
  CXX  = g++-10
  CXXFLAGS = -march=native -O2 -g -Wall -Winline -W -Wextra 
-Wno-unknown-pragmas -pthread

  LDFLAGS  = -L/usr/local/lib -Wl,-rpath,/usr/local/lib
  LIBS = -ljbig -lwebp -lwebpmux -llcms2 -ltiff -lfreetype -ljpeg 
-lpng16 -lwmflite -lX11 -llzma -lz -lzstd -lm -lpthread


From the above, it can be seen what values were determined for 

standard Autoconf/Automake build variables (e.g. AC_DEFINE_UNQUOTED).

This is all done by using Autoconf defines suitable for including in 
source code.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: libtool wrapper

[Bob Friesenhahn]

On Tue, 23 Mar 2021, Dan Mahoney (Gushi) wrote:


Given the standard nature of autoconf/automake/libtool, Before we install, we 
have a wrapper script sitting in $srcdir/opendmarc/opendmarc, that wraps 
libtool around a compiled library in $srcdir/.libs


Here's the problem with that -- the way the program is linked, it links 
against the *system* version of libopendmarc (in /usr/local/lib), not the one 
we're about to install (which is in ../../libopendmarc/.libs)


The normal case when using Automake and libtool is that libtool is 
also used to compile/link the program, and to link with the libraries 
it needs (both in the build tree, and already installed).  A wrapper 
script/program is put in the place of where the real program would 
normally go which assures that the correct libraries are used.


Is there a way to make libtool and the like smarter about this.  I.e. "check 
if this library exists, but also know that *we will be building this 
library*, and for testing purposes, point at our version".


If the documented procedures are used, then programs in the build tree 
will be pointing at libraries in the build tree.


Is there an easy macro-ish way around this, or am I stuck creating some sort 
of fake chroot to test this.


It seems that the project is not entirely using the Autotool's way of 
doing things.  I suggest reading the Automake documentation first.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: config.sub/config.guess using nonportable $(...) substitutions

[Bob Friesenhahn]

On Mon, 8 Mar 2021, Paul Eggert wrote:

Except maybe for Solaris 10, shells that don't grok $(...) are museum pieces 
now. And anybody on Solaris 10 (which occasionally includes me, as my 
department still uses Solaris 10 on some machines) can easily run a better 
shell like /bin/ksh. It's a bit of a maintenance hassle for Ben to deal with


The script itself does start with requesting /bin/sh.  The 
config.guess script is also used in contexts outside of Autotools, 
although such usage can likely specify the shell to use when executing 
the script.


At some point, failing to support $(...) is in the same ballpark as failing 
to support "#". I can see Ben's point of view that we've reached that point 
even if I would have waited another three years, so if Ben would rather use 
$(...) I'd rather not overrule him downstream.


It seems that config.guess and Autotools packages are picking winners 
and losers.  It is not clear where the bar has been set.  When such 
decisions are made, it is useful if messaging about it is very clear.


If any component of a build infrastructure is not portable to an older 
system, then all of the components (including each dependent 
application's own configure.ac script) might as well be updated to use 
the less-portable yet more convenient modern syntax and this implies 
the ability to safely use other modern syntax as well.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: Automake's file locking

[Bob Friesenhahn]

On Wed, 3 Feb 2021, Zack Weinberg wrote:

Therefore I like the idea of merely relying on the atomicity of
file creation / file rename operations.

These files should reside inside the autom4te.cache directory. I would
not like to change all my scripts and Makefiles that do
  rm -rf autom4te.cache


Agreed.  The approach I'm currently considering is: with the
implementation of the new locking protocol, autom4te will create a
subdirectory of autom4te.cache named after its own version number, and
work only in that directory (thus preventing different versions of
autom4te from tripping over each other).  Each request will be somehow
reduced to a strong hash and given a directory named after the hash
value.  The existence of this directory signals that an autom4te
process is working on a request, and the presence of 'request',
'output', and 'traces' files in that directory signals that the cache
for that request is valid.  If the directory for a request exists but
the output files don't, autom4te will busy-wait for up to some
definite timeout before stealing the lock and starting to work on that
request itself.


This seems like a good approach to me.

There is substantially less danger from independent reconfs (on the 
same or different hosts) than there is from parallel jobs in the 
current build deciding that something should be done and trying to do 
it at the same time.


GNU make does have a way to declare that a target (or multiple 
targets) is not safe for parallel use.  This is done via a 
'.NOTPARALLEL: target' type declaration.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: Automake's file locking (was Re: Autoconf/Automake is not using version from AC_INIT)

[Bob Friesenhahn]

On Thu, 28 Jan 2021, Nick Bowler wrote:


If I understand correctly the issue at hand is multiple concurrent
rebuild rules, from a single parallel make implementation, are each
invoking autom4te concurrently and since file locking didn't work,
they clobber each other and things go wrong.


That is what would happen, but what currently happens is if the file 
locking does not work and a parallel build is used, then Autotools 
reports a hard error:


CDPATH="${ZSH_VERSION+.}:" && cd /home/bfriesen/src/graphics/GM && 
/bin/sh '/home/bfriesen/src/graphics/GM/config/missing' aclocal-1.16 
-I m4
autom4te: cannot lock autom4te.cache/requests with mode 2: Invalid 
argument

autom4te: forgo "make -j" or use a file system that supports locks
aclocal-1.16: error: autom4te failed with exit status: 1
gmake: *** [Makefile:4908: /home/bfriesen/src/graphics/GM/aclocal.m4] 
Error 1


In my case there is only one active developer so there would not be 
actual corruption.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: Automake's file locking (was Re: Autoconf/Automake is not using version from AC_INIT)

[Bob Friesenhahn]

On Thu, 28 Jan 2021, Zack Weinberg wrote:


Do you use different versions of autoconf and/or automake on the
different clients?


No.  That would not make sense.  If a client is not suitably prepared, 
then I don't enable maintainer mode.



The lock appears to be taken speculatively since it is taken before
Autotools checks that there is something to do.

...

The most common case is that there is nothing for Autotools to do
since the user is most often doing a 'make' for some other purpose.


It looks to me like the lock is taken at exactly the point where
autom4te decides that it *does* have something to do. It might be


Perhaps this experience is a side effect of my recent experience 
(regarding AC_INIT and versioning) and not the normal case.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: Automake's file locking (was Re: Autoconf/Automake is not using version from AC_INIT)

[Bob Friesenhahn]

On Thu, 28 Jan 2021, Zack Weinberg wrote:


The main reason I can think of, not to do this, is that it would make
the locking strategy incompatible with that used by older autom4te;
this could come up, for instance, if you’ve got your source directory
on NFS and you’re building on two different clients in two different
build directories.  On the other hand, this kind of version skew is
going to cause problems anyway when they fight over who gets to write
generated scripts to the source directory, so maybe it would be ok to
declare “don’t do that” and move on.  What do others think?


This is exactly what I do.  I keep the source files on a file server 
so that I can build on several different types of clients.  This used 
to even include Microsoft Windows clients using CIFS.


The lock appears to be taken speculatively since it is taken before 
Autotools checks that there is something to do.  It would be nicer if 
Autotools could check first if there is something to do, acquire the 
lock, check if there is still something to do, and then do the work.


The most common case is that there is nothing for Autotools to do 
since the user is most often doing a 'make' for some other purpose.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: Parallel configure

[Bob Friesenhahn]

On Thu, 28 Jan 2021, Zack Weinberg wrote:


On Mon, Jan 25, 2021 at 5:42 PM Bob Friesenhahn
 wrote:

The challenge here is that a considerable part of configure scripts
depend on decisions which were made before.  There is no dependency
information currently in configure scripts.


Yes, but it may not be as bad as you think.  The "check a list of
these things" macros (e.g. AC_CHECK_FUNCS) could be internally
parallelized right now.  Many of the core macros depend only on the
things that they AC_REQUIRE, and produce information that is _usually_
consumed only by AC_OUTPUT.  And we know of any macro whose internal
structure is in the preferred form


I am glad that you mention AC_CHECK_FUNCS since this is actually 
something which does definitely have dependencies.  The reason for 
this is that AC_CHECK_FUNCS uses the already built LIBS while it 
performs the tests.  When library dependencies are not working (which 
they would not be for a static build or for targets which do not have 
this notion) then it is necessary for either LIBS to already be built 
up with good stuff, or that the AC_CHECK_FUNCS guesses the list of 
additional libraries which may be needed (that can be very difficult 
to do).


While I am not sure that the GraphicsMagick configure script is a good 
example of how to write a configure script, it does provide an example 
of how LIBS gets built up incrementally using already passed tests, 
working in a least dependent to most dependent manner.  The answers it 
arrives at might not be strictly correct but it does work.


Besides parallelism, another way that configure might run faster is by 
supporting methods commonly used for bisection.  This would be a 
totally different way for configure to work.  However, the result 
might not look like "feature based" testing.  Instead it would be 
"this is the set of options which allowed the test case to fully 
compile".  The test case may then depend on several features at once 
and could in fact be everything needed for a given translation unit to 
compile.


I have been astonished at how fast Mercurial's 'hg bisect' managed to 
isolate the changeset which introduced a problem.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: Future plans for Autotools

[Bob Friesenhahn]

On Mon, 25 Jan 2021, Paul Eggert wrote:


On 1/25/21 5:37 AM, Paul Smith wrote:

The only thing that would make much of a performance difference, I
think, is if we are able to replace lots of shell invocations with
built-in make functions like wildcard, if, etc.


One other thing could be a significant performance win: if we could use GNU 
'make -j' to run most of the guts of the 'configure' script in parallel. 
Waiting for 'configure' to finish is something that slows me down a lot; 
often times 'configure' takes longer than the subsequent 'make', simply 
because 'configure' is inherently sequential.


The challenge here is that a considerable part of configure scripts 
depend on decisions which were made before.  There is no dependency 
information currently in configure scripts.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: Future plans for Autotools

[Bob Friesenhahn]

On Mon, 25 Jan 2021, John Calcote wrote:


To be honest if Automake-generated Makefile.in files only worked
for users with, say, sufficiently modern versions of GNU Make, I'm
not sure there would be any point in using Automake.



I'm not sure I see your point Nick. Why use Automake? Because I'd much
rather write
(and maintain) two lines of automake code than even a single page of GNU
make code.


Even more importantly, you already wrote those two lines of Automake 
code! :-)


The Makefile.am format is a sort of "contract" which is assumed by 
Automake users.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: Future plans for Autotools

[Bob Friesenhahn]

On Mon, 25 Jan 2021, Zack Weinberg wrote:


and enable Make to bypass the shell altogether.  Might be worth
benchmarking on a big program.  Has to be an executable, not a
library, though; for libraries, the overhead of the libtool script is
going to dominate.


As a reminder, a former Automake maintainer created a branch/fork of 
Automake and produced a version of Automake which outputs GNU Make 
Makefiles which are optimized to take advantage of GNU Make features. 
I assume that he worked on all of these sort of issues.


I don't recall where the code for this is but I am sure it can be 
found without much effort.


Yes, it might have been as much as 10 years already, but surely not 
that much has changed.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: Automake's file locking (was Re: Autoconf/Automake is not using version from AC_INIT)

[Bob Friesenhahn]

On Mon, 25 Jan 2021, Zack Weinberg wrote:


Automake "just" calls Perl's 'flock' built-in (see 'sub lock' in
Automake/XFile.pm) (this code is copied into Autoconf under the
Autom4te:: namespace).  It would be relatively straightforward to
teach it to try 'fcntl(F_SETLKW, ...)' if that fails.  Do you know
whether that would be sufficient?  If not, we may be up a creek, since
depending on CPAN modules is a non-starter.


I expect that it would be that "simple" except for of course 
everything involved with making sure that things are working properly 
for everyone.


It may be that moving forward to 'fcntl(F_SETLKW, ...)' by default and 
then falling back to legacy 'flock' would be best.  Or perhaps 
discarding use of legacy 'flock' entirely.


Most likely the decision as to what to do was based on what was the 
oldest primitive supported at the time.  The GNU/Linux manual page 
says that "the flock() call first appeared in 4.2BSD".  It also says 
"Since Linux 2.6.12, NFS clients support flock() locks by emulating 
them as fcntl(2) byte-range locks on the entire file.".  There are a 
number of warnings in the manual page regarding the danger of mixing 
locking primitives.  It was never intended that flock() work over a 
network share.


It seems unlikely that Autotools development is going to be done on a 
system lacking POSIX locking since such a system would not be 
considered a usable system for most purposes.  If a project does not 
provide a 'maintainer mode' to stop maintainer rules from firing, then 
this could impact archaic targets from the early '90s.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: Autoconf/Automake is not using version from AC_INIT

[Bob Friesenhahn]

On Sun, 24 Jan 2021, Paul Eggert wrote:


On 1/23/21 4:06 PM, Bob Friesenhahn wrote:


A tiny fork/exec is not a big deal.


It is indeed not a big deal. That being said, one can optimize away GNU 
make's fork and exec by using "@:" instead of "@true".


At the moment it is a big deal for me because the locking prototol 
that Autoconf/Automake is using does not work with NFS mounts for 
Illumos-derived systems when the client is also an Illumos-derived 
system, because Illumos failed to support the legacy locking protocol 
used when the system locking daemon was re-implemented from scratch. 
If the NFS client of the Illumos-based NFS server is GNU/Linux, then 
everything works just fine due to GNU/Linux implementing a fall-back 
mechanism to use POSIX locking if the server says it does not support 
the legacy lock protocol.


It is likely that a small patch to Automake Perl-based locking code 
could solve this issue by using the same fall-back to using POSIX 
locking rather than legacy locking the same way that GNU/Linux does. 
It may also be that using POSIX locking in the first place is the 
solution.


What happens is that any parallel builds which cause Autotools to 
invoke Perl's legacy locking code will fail, which means that I can't 
use parallel builds until it has done what it needs to do.  So the 
build goes about 20x slower.


For my personal development environment, the container ('zone') which 
is doing the NFS mount does not have to use NFS (because it is running 
on the same host as the file server) but I have not taken time to 
learn how to update the container definition.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: Autoconf/Automake is not using version from AC_INIT

[Bob Friesenhahn]

On Sun, 24 Jan 2021, Zack Weinberg wrote:


On Sun, Jan 24, 2021 at 7:27 PM Bob Friesenhahn
 wrote:


AC_SUBST([CONFIGURE_DEPENDENCIES],["$CONFIGURE_DEPENDENCIES \$(top_srcdir)/ChangeLog 
\$(top_srcdir)/version.sh"])


Why did you write it like this instead of

CONFIGURE_DEPENDENCIES = $(top_srcdir)/ChangeLog $(top_srcdir)/version.sh


It appears that I followed the Automake documentation which still says 
to use the approach I used:


https://www.gnu.org/software/automake/manual/html_node/Rebuilding.html

Notice this documentation appears to be patterned on what 
GraphicsMagick has been doing (or vice-versa) and the documentation 
now suggests providing version info via a 'version.m4' file.  It is 
not clear how this can help unless the version.m4 itself is modified. 
If the version.m4 invoked an external script then it seems it would 
not help.



(Also, I thought having configure not be updated when the information
provided to AC_INIT has not changed was what you wanted to happen!)


It is good if each each 'make' cycle reaches a terminal conclusion and 
assures that all targets are successfully concluded.  Even if the 
content of a target is not changed, its timestamp should be updated so 
that make is happy.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: Autoconf/Automake is not using version from AC_INIT

[Bob Friesenhahn]

On Mon, 25 Jan 2021, Peter Johansson wrote:


Hi Bob,

On 24/1/21 10:06 am, Bob Friesenhahn wrote:
I did try this type of solution.  As I recall, it did not help because the 
terminal target is Automake's regeneration rules, which are apparently 
optimized to not modify the target files (e.g. configure) if there was no 
change.


This seems like a very annoying optimization. IIUC, that means if I'd touch 
the timestamp of 'configure.ac' without changing its content, I'd end up in 
this hole of 'configure.ac' being newer than 'configure' but 'configure' not 
being updated. That doesn't seem to be the case in one of my projects. If I 
just 'touch configure.ac && make' all downstream files are updated as 
expected (except 'config.h', which is a known behavior), so I suspect you 
have something else going with the dependencies. Impossible to guess what 
without seeing the relevant Makefile snippet.


The key part of the simplified solution is (was) this:

AC_SUBST([CONFIGURE_DEPENDENCIES],["$CONFIGURE_DEPENDENCIES \$(top_srcdir)/ChangeLog 
\$(top_srcdir)/version.sh"])

Although these are declared as "dependencies", if one of them changed 
it did not necessarily result in configure being updated.  If the 
information provided to AC_INIT was the same as before it did not seem 
to result in configure being updated.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: Autoconf/Automake is not using version from AC_INIT

[Bob Friesenhahn]

On Sat, 23 Jan 2021, Zack Weinberg wrote:


I’m sorry this has been such a frustrating experience for you, and I’m
also sorry I didn’t react to this thread earlier.  I thought you had
already found an approach that _did_ work for you.


I thought so to.  While developing GraphicsMagick, I use a different 
versioning scheme (append a date to the version) and use the ChangeLog 
file as the master for the date.  But the ChangeLog file might be 
edited several times in a day without the "version" changing. After 
the second edit, there are problems.  The problem becomes obvious just 
by touching the ChangeLog file.



If I understand your problem correctly, it’s fundamentally a
limitation in Make itself: there’s no way to tell Make to pay
attention to a file’s _contents_, as well as its timestamp, when
deciding whether targets that depend on that file are out of date.
There’s not a whole lot the Autotools can do about that limitation,
but I do know some workarounds that might suit.


It is definitely related to make's limitations, but also due to what 
Autotools does.



First, there _is_ a general-purpose workaround for this limitation in
Make.  It’s ugly and you may not like it, but it’s battle-tested in
e.g. GCC’s Makefiles.  It looks like this:

# some versions of `touch` do not correctly set the timestamp
STAMP = echo timestamp >
build/gencondmd.c: s-conditions; @true
s-conditions: $(MD_DEPS) build/genconditions$(build_exeext)
   $(RUN_GEN) build/genconditions$(build_exeext) $(md_file) > tmp-condmd.c
   $(SHELL) $(srcdir)/../move-if-change tmp-condmd.c build/gencondmd.c
   $(STAMP) s-conditions


I did try this type of solution.  As I recall, it did not help because 
the terminal target is Automake's regeneration rules, which are 
apparently optimized to not modify the target files (e.g. configure) 
if there was no change.  Since the target was never updated, the rule 
runs again.


The solution I thought was working was based on real file timestamps, 
(which I thought would be robust) but it is not since Autotools does 
not update the timestamp on the file it would regenerate.



The ‘build/gencondmd.c: s-conditions’ rule does get run every time you
type ‘make’ while ‘s-conditions’ has a timestamp newer than
‘build/gencondmd.c’, which is why that rule’s commands are ‘@true’ --
do nothing and print nothing.  It does fork and exec one shell per
rule of this form; as far as I know there is no way to do better.


A tiny fork/exec is not a big deal.  What becomes annoying is when it 
is continually recurring because the Autotool's regeneration rule 
never updated a target.  I would rather face the cost of running 
configure again (once) due to a time-stamp change than every time make 
is executed.


When it is apparently decided that configure may need to be 
regenerated, it goes and does something, but apparently decides that 
nothing has changed so it can skip updating the output.  Therefore, 
the retries are perpetual until configure does get regenerated.



So I think you are actually safe continuing to use AM_INIT_AUTOMAKE
with two arguments that are shell variable expansions, the way you’re
doing it now, and ignoring the -Wobsolete warning.  I am not sure how
I have managed never to notice this note before now.  I’ve filed
https://savannah.gnu.org/support/index.php?110431 saying that AC_INIT
should start accepting shell variables in its arguments.  I’m not sure
what other consequences this may have, but you can make aclocal and
automake shut up about AC_INIT by passing a dummy version argument:

AC_INIT([GraphicsMagick], [DUMMY-VERSION-NUMBER])
. ${srcdir}/version.sh
AM_INIT_AUTOMAKE(
 [$PACKAGE_NAME],
 ["${PACKAGE_VERSION}${PACKAGE_VERSION_ADDENDUM}"],
 [' '])


Well, that is interesting.

I have some memory that shell code in configure.ac which is provided 
prior to AC_INIT is ignored and is not output to configure.  If my 
memory is correct, then accepting shell variables would be a major 
change since AC_INIT would not be the start of everything.


I discovered that the AC_INIT with arguments is much more rigid and 
unyielding than using environment variables.  Due to this, I had to 
make changes to other files because my interim version scheme does not 
intend to change things like installation directories.


I may well persue this some more, but not in the main-line development 
code that some OS distributions like Debian have started using like 
normal releases.  It is better for a side project.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: Autoconf/Automake is not using version from AC_INIT

[Bob Friesenhahn]

I am about to give up on using the new style AC_INIT in the form of

AC_INIT(m4_esyscmd([./version.sh packagename]),
m4_esyscmd([./version.sh packageversion]),
m4_esyscmd([./version.sh packagebugreport]),
m4_esyscmd([./version.sh packagetarname]),
m4_esyscmd([./version.sh packageurl]))

and the "new" single-argument form of AM_INIT_AUTOMAKE.

Although I have spent a couple of days trying to get this approach to 
work, no combination of dependency declarations, stamp files, etc., 
has resulted in success.


Everyone has been very helpful, but the suggestions have not lead to 
success.


The problem is continually that there is no way to deal with make's 
use of timestamps along with the behavior of Automake's Makefiles and 
Autoconf's self-maintenance.  The terminal target produced is not the 
one needed.


The cost of the new approach dwarfs the supposed benefits (the only 
benefits appear to add some version-specific message strings to the 
generated configure and to quench an Automake deprecation warning). 
The benefits appear to be quite insignificant.


Regardless of what I do, there is this sort of behavior every time I 
type 'make' if the timestamp of an input influencing the version has 
been updated (either the files which are consulted when producing the 
version, or a file produced based on the version), but the version 
itself has not changed:


scooby:~/build/GM-16-static-debug-noopenmp% make
CDPATH="${ZSH_VERSION+.}:" && cd /home/bfriesen/src/graphics/GM && 
/bin/bash '/home/bfriesen/src/graphics/GM/config/missing' autoconf

make  all-am
make[1]: Entering directory 
'/scratch/bfriesen/build/GM-16-static-debug-noopenmp'
CDPATH="${ZSH_VERSION+.}:" && cd /home/bfriesen/src/graphics/GM && 
/bin/bash '/home/bfriesen/src/graphics/GM/config/missing' autoconf
make[1]: Leaving directory 
'/scratch/bfriesen/build/GM-16-static-debug-noopenmp'


Given that while developing code I may execute make hundreds of times 
per day, this behavior is not acceptable to me.


Perhaps it might work if version content was expressed as m4 macros in 
order to force configure to be re-generated, but this sort of 
exploration would take another day to try.


So I am likely switch back to the former shell include script method 
which has worked flawlessly since 2003.


Hopefully the Automake project won't just pull the rug out from under 
me.  I was hoping to make the project more robust against existing 
deprecation threats in case I don't survive, but it looks like I did 
not succeed.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: Future plans for Autotools

[Bob Friesenhahn]

On Wed, 20 Jan 2021, Nate Bargmann wrote:


Thanks for your effort over this past year, Zack.  As a user of
Autoconf, your work, as is that of all contributors, is much
appreciated.

One strength of the Autotools that I think stands above the rest is the
fact that a user of a distributed package does not need to install any
of the Autotools packages.  On the odd occasion I build a cmake or qmake
based project locally I always need to install those build bootstrap
systems.  This, I think, was a stroke of genius from the start on the
part of Autoconf.  I think this should always be a primary goal of the
project.


This capability to be able to configure and build the tarball package 
without needing more than a compiler is great.  However, this 
statement is not actually true because a full Unix shell environment 
is needed in order to run the product of Autotools.


People who prefer CMake continually point out that Autotools is 
written primarily for "Unix".  If they want to build packages using 
Autotools under Microsoft Windows, then they need to install a Unix 
emulation environment such as MSYS or Cygwin.  Then the user learns 
that the configure and build seems to take 20x longer than under 
GNU/Linux.


The desire to support Microsoft Windows as well causes Autotools to be 
less desireable.


This (and the desire to get rid of m4 and ugly stuff like sed) is why 
I suggested development of a special slimmed-down portable "shell" 
which has built in extensions for Autoconf and avoids the need for 
thousands of fork/exec cycles.  Autoconf macros can then be based on 
libraries of script code rather than libraries of m4 code. 
Unfortunately, with this approach it may be necessary to install 
another package (just like with CMake) before starting.


The implementation of Autoconf is over-burdened with syntax.  It 
contains more "syntax" than anything else I have ever seen.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: Future plans for Autotools

[Bob Friesenhahn]

On Wed, 20 Jan 2021, Zack Weinberg wrote:


Now we've all had a while to recover from the long-awaited Autoconf
2.70 release, I'd like to start a conversation about where the
Autotools in general might be going in the future.  Clearly any future
development depends on finding people who will do the work, but before
we worry about that I think we might want to figure out what work we
_want_ to do.


Zack, your text was excellent and I agree with all of it.

Autotools is in great danger of becoming irrelevant, at least for new 
software development.  A lot of people feel hostile toward it.


It seems to me that Autoconf is too difficult to work on.  There is 
too much to become expert at in order for new volunteers to make an 
impact.  The same is true for libtool.


In my opinion, a new "language" designed specifically to meet the 
needs of Autoconf should be developed and Autoconf should be 
re-implemented using it.  There should be no more need to run external 
utilities like 'sed', or 'awk' or other things which can be 
implemented internally in a way which does not suffer from the white 
space and delimiter issues that shell script does.


It seems that the core precept that Automake should produce portable 
makefiles should be re-evaluated if most systems provide GNU make, or 
can easily be updated have it.  There is a fork of Automake which was 
re-done to be based on GNU Make. This assumes that makefiles written 
in GNU make can noticeably improve things.


I like your idea of supporting other underlying build tools besides 
'make'.  Make's dependence on matching rules and file time stamps is 
problematic and it does not scale.  It is unfortunate that GNU 
produced a much more powerful 'make' tool (a paradigm invented in 
1976), but not a new build tool with fresh ideas to improve build 
quality and reduce build times on modern systems.


The macro definitions provided by Autoconf have been proven by the 
test of time and allow the underlying implementation to be changed. 
Only surrounding shell script might need to be changed if the 
underlying implementation changes.


The support for 'distcheck' is excellent.

Regardless, thanks for your ideas and the red alert.

Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: Autoconf/Automake is not using version from AC_INIT

[Bob Friesenhahn]

On Thu, 14 Jan 2021, Peter Johansson wrote:


I suspect it would be possible to solve by splitting the timestamps into two 
different files. One is the VERSION file determining when autoconf needs to 
be run and a timestamp file determines when the version.sh script needs be 
run. Something like:


That is interesting, and perhaps something I may try when I have the 
time.


In the mean time I am using this simple solution, which works because 
I know what version.sh uses to produce its version (data from itself, 
and from ChangeLog).  I added this to configure.ac:


  AC_SUBST([CONFIGURE_DEPENDENCIES],["$CONFIGURE_DEPENDENCIES
\$(top_srcdir)/ChangeLog \$(top_srcdir)/version.sh"])

Since the two files always exist, there is no intermediate stuff to 
generate.


I was previously using something similar, but just for config.status:

  AC_SUBST([CONFIG_STATUS_DEPENDENCIES],['$(top_srcdir)/ChangeLog
$(top_srcdir)/version.sh'])

If the version stamp info came from git or hg, then intermediate 
generated files would surely be required.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: Autoconf/Automake is not using version from AC_INIT

[Bob Friesenhahn]

On Tue, 12 Jan 2021, Peter Johansson wrote:
The problem is that there is no dependency in the Makefile telling that 
autoconf need to be rerun when the version has changed. Automake has the 
variable 'CONFIGURE_DEPENDENCIES' for this purpose, so adding


CONFIGURE_DEPENDENCIES = ChangeLog

would solve the issue but will cause a rerun of autoconf every time you touch 
ChangeLog. Rather you want a stamp file, whose timestamp only changes when 
the output of 'version.sh packageversion' changes. Something along the lines:


$(srcdir)/.version: ChangeLog
    cd $(srcdir) && ./version packageversion > .version-tmp && move-if-change 
.version-tmp .version


EXTRA_DIST = $(srcdir)/.version


This seemed like a great idea, but upon trying out, I saw that the 
rule gets invoked each time I type 'make'.  This results in activity 
whereas before 'make' would simply report that there is nothing to do.


swdev:~/build/GM-16-static% gmake
CDPATH="${ZSH_VERSION+.}:" && cd /home/bfriesen/src/graphics/GM && /bin/sh 
'/home/bfriesen/src/graphics/GM/config/missing' autoconf
gmake  all-am
gmake[1]: Entering directory '/scratch/bfriesen/build/GM-16-static'
CDPATH="${ZSH_VERSION+.}:" && cd /home/bfriesen/src/graphics/GM && /bin/sh 
'/home/bfriesen/src/graphics/GM/config/missing' autoconf
gmake[1]: Leaving directory '/scratch/bfriesen/build/GM-16-static'

This seems like a Catch-22 situation.  If the VERSION file timestamp 
does not get updated, it will produce this noise, and if does get 
updated, then there is a whole reconf-config-build cycle.


Is there any solution for that?

Otherwise I have a less fancy means which works without the extra 
noise.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: Autoconf/Automake is not using version from AC_INIT

[Bob Friesenhahn]

On Wed, 13 Jan 2021, Peter Johansson wrote:


I don't see any way without a specific file holding the timestamp on when 
the version was last updated.


This is very helpful advice (and adds to valuable advice offered in private 
emails by others).  I don't really like hidden files but I do have a 
version.h header file which could already be used for this purpose.  The 
version.h header file is currently produced from version.h.in using 
config.status and it gets copied to the source directory (if necessary) if 
the file has changed.


I think that will have the unwanted effect that autoconf is triggered when 
building from a tarball. Since version.h is not included in the tarball, it 
will be built by the user and have a newer timestamp than configure, and 
hence the rule is triggered. I think the advice one of the automake 
maintainers (probably Ralf) gave many years ago is that files listed in 
CONFIGURE_DEPENDENCIES should be distributed.


For this project, both version.h and version.h.in are already included 
in the tarball.  Hopefully this will be a benefit to this case.


I agree that consumers of tarballs should not see unexpected behavior 
and should be granted as much of the original developer's powers as 
possible.


Once again, thanks for the helpful advice.

Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: Autoconf/Automake is not using version from AC_INIT

[Bob Friesenhahn]

On Tue, 12 Jan 2021, Peter Johansson wrote:


The problem is that there is no dependency in the Makefile telling that 
autoconf need to be rerun when the version has changed. Automake has the 
variable 'CONFIGURE_DEPENDENCIES' for this purpose, so adding


CONFIGURE_DEPENDENCIES = ChangeLog

would solve the issue but will cause a rerun of autoconf every time you touch 
ChangeLog. Rather you want a stamp file, whose timestamp only changes when 
the output of 'version.sh packageversion' changes. Something along the lines:


$(srcdir)/.version: ChangeLog
    cd $(srcdir) && ./version packageversion > .version-tmp && move-if-change 
.version-tmp .version


EXTRA_DIST = $(srcdir)/.version

I don't see any way without a specific file holding the timestamp on when the 
version was last updated.


This is very helpful advice (and adds to valuable advice offered in 
private emails by others).  I don't really like hidden files but I do 
have a version.h header file which could already be used for this 
purpose.  The version.h header file is currently produced from 
version.h.in using config.status and it gets copied to the source 
directory (if necessary) if the file has changed.


Bob

--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Autoconf/Automake is not using version from AC_INIT

[Bob Friesenhahn]

I recently updated GraphicsMagick to use the 5 argument form of 
AC_INIT and the one argument form of AM_INIT_AUTOMAKE.  I also used 
m4_esyscmd to get version info from an external script.  The 
invokation looks like this:


AC_INIT(m4_esyscmd([./version.sh packagename]),
m4_esyscmd([./version.sh packageversion]),
m4_esyscmd([./version.sh packagebugreport]),
m4_esyscmd([./version.sh packagetarname]),
m4_esyscmd([./version.sh packageurl]))

Today I noticed that 'make dist' is producing the wrong tarball 
package version.  Instead of producing the expected version, the 
tarball version matches the date of the configure.ac file.


This is what comes out of the version.sh script:

./version.sh packageversion
1.4.020210110%

The version.sh script bases the package version on the most recent 
entry in the ChangeLog file.


This is what is claimed to be the tarball version several times 
already:


  GraphicsMagick-1.4.020210106.tar.gz

This is the timestamp on the Autotools files which appear to 
reflect the claimed version:


% ls -lg configure.ac Makefile.am configure
-rw-r--r--   1 home   12435 Jan  6 11:42 Makefile.am
-rwxr-xr-x   1 home  987623 Jan  6 11:48 configure*
-rw-r--r--   1 home  122830 Jan  6 11:42 configure.ac

What is the trick to ensuring that autoconf and Automake do use the 
version supplied to AC_INIT?  It seems that now the configure script 
needs to be re-generated but nothing seems to force that.


Looking at Autoconf itself, I see dreadful looking things such as an 
extra GNUmakefile and targets which create hidden files which go into 
the tarball.  If this sort of thing is necessary, then I will revert 
my few days of work.


Thanks,

Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: AC_INIT produces unexpected "PACKAGE" and "VERSION" strings in config.h

[Bob Friesenhahn]

I am now able to answer my own question.  The new form of 
AM_INIT_AUTOMAKE adds this unwanted stuff if one does not pass 
no-define as another option:


"By default this macro AC_DEFINE’s PACKAGE and VERSION. This can be 
avoided by passing the no-define option (see List of Automake 
options)"


I am not sure what the value of adding another redundant definition is 
but it seems that is what Automake decided to do.


The problem is that I have a subordinate package which also uses 
VERSION but the definition is not the same.


Bob

On Tue, 5 Jan 2021, Bob Friesenhahn wrote:

I am *still* working to update GraphicsMagick to support the 5-part AC_INIT 
plus new-style AM_INIT_AUTOMAKE.  I am using Autoconf 2.69 and Automake 
1.16.3.


Something which is very much unwanted is now the generated config.h has added 
these


/* Name of package */
#define PACKAGE "GraphicsMagick"

/* Version number of package */
#define VERSION "1.4.020210102"

These definitions are unexpected.

What produces these definitions and how can I get rid of them?

Bob



--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

AC_INIT produces unexpected "PACKAGE" and "VERSION" strings in config.h

[Bob Friesenhahn]

I am *still* working to update GraphicsMagick to support the 5-part 
AC_INIT plus new-style AM_INIT_AUTOMAKE.  I am using Autoconf 2.69 and 
Automake 1.16.3.


Something which is very much unwanted is now the generated config.h 
has added these


/* Name of package */
#define PACKAGE "GraphicsMagick"

/* Version number of package */
#define VERSION "1.4.020210102"

These definitions are unexpected.

What produces these definitions and how can I get rid of them?

Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

[sr #110403] autoconf-2.70 trips bug in here-doc handling in OmniOS /bin/sh

[Bob Friesenhahn]

Follow-up Comment #11, sr #110403 (project autoconf):

I see that https://www.illumos.org/issues/13405 addresses updating Illumos
ksh93 to a recent version.  The description says that the task is 'hard' but
the task is showing progress made.

Regardless, a note about the bug is certainly useful since a fix would not be
deployed and available to all for some time.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

Re: Getting srcdir in script executed using m4_esyscmd in AC_INIT

[Bob Friesenhahn]

On Tue, 5 Jan 2021, Zack Weinberg wrote:



Something I found which surprised me is that Automake has added a GNU
COPYING file to my non-GNU non-GPL package.  Once the file appeared in
the source directory, it seems that it continued to be used and
included in spite of the Automake options provided.

While I see more detail sprinkled around the generated files, it seems
that this COPYING file may be the biggest issue.


Hmm.  If you remove COPYING, make sure that you have `foreign` in
either `AUTOMAKE_OPTIONS` or the options list passed to
`AM_INIT_AUTOMAKE`, and then re-run automake --add-missing, does
COPYING come back?  My understanding is that automake --add-missing is
supposed to install a copy of the GPL *only if* it's in `gnu` mode and
can't find any other statement of licensing.


The COPYING file did not come back.  I now notice that an INSTALL file 
was added as well.


As far as I am aware, at no point were the Automake options not 
expressed in some way (via configure.ac or Makefile.am) but I used 
Autotools automatic maintenance after editing files (via make) and 
perhaps they were added during a transition point.


Regardless, updating a project to use the recommended AC_INT strategy 
is not without some danger since it is more rigid than the previous 
shell-variable based approach.  This is particularly the case for the 
project version and how the project version is applied when creating 
the tarball.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: Getting srcdir in script executed using m4_esyscmd in AC_INIT

[Bob Friesenhahn]

On Mon, 4 Jan 2021, Zack Weinberg wrote:


Something which surprises me is that the distribution tarballs became
noticeably larger.


This is expected. The bulk of the increase is probably due to the test
programs used to probe for C and/or C++ 2011 support in the compilers.
There were also some fixes for compatibility problems that involved
emitting more code throughout the script. I can explain the
rationale for any piece of the diff between the old and new configure
scripts that you're curious about.


To be clear, the size difference was intended to be due to the list of 
parameters passed to AC_INIT and AM_INIT_AUTOMAKE and re-autotooling. 
In fact this is still using Autoconf 2.69.


Something I found which surprised me is that Automake has added a GNU 
COPYING file to my non-GNU non-GPL package.  Once the file appeared in 
the source directory, it seems that it continued to be used and 
included in spite of the Automake options provided.


While I see more detail sprinkled around the generated files, it seems 
that this COPYING file may be the biggest issue.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: Getting srcdir in script executed using m4_esyscmd in AC_INIT

[Bob Friesenhahn]

Zack,

I am pretty close to done with updating GraphicsMagick to use the 
recommended Autoconf and Automake initialization syntax.  Thanks again 
for your help.


Something which surprises me is that the distribution tarballs became 
noticeably larger.


The .tar.gz package increased from 9,675,006 to 9,683,225 bytes (8,219 
bytes difference when compressed).  Perhaps it is not much but the 
size difference seems large given that only 23 lines of original 
source code were added.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: Getting srcdir in script executed using m4_esyscmd in AC_INIT

[Bob Friesenhahn]

On Sun, 3 Jan 2021, Zack Weinberg wrote:


The trick here is that these shell commands will be executed when you
run autoconf, *not* when you run configure.  And you have to run
autoconf with the current working directory equal to the top of the
source tree *anyway*.  So the answer is ". will be the top of the
source tree."  This is why automake's rule for regenerating configure
from configure.ac does `cd $(top_srcdir) && $(AUTOCONF)`.


Yes, it seemed like that should be the case.  Just before you read 
your email I realized that the problem was that my script was executed 
in two different ways, and the older way was executing it (while 
executing configure) in the current directory.



Autoconf itself does something similar and it works reliably:
(quoting https://git.savannah.gnu.org/cgit/autoconf.git/tree/configure.ac#n22)

AC_INIT([GNU Autoconf],
   m4_esyscmd([build-aux/git-version-gen .tarball-version]),
   [bug-autoc...@gnu.org])

I presume this is *not* working reliably for you or you wouldn't have
asked the question, so could you go into a little more detail about
how you invoked autoconf and/or configure and what went wrong?


The above is what I was using as an example. :-)

GraphicsMagick needs to substitute quite a lot more version info so I 
was also doing this in the body of configure.ac:


# Source file containing package/library versioning information.
. ${srcdir}/version.sh

What I did was to make the same script accept arguments.  Sourcing the 
script is ok but not if it does not compute the same values.


Thank you for your help.

Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Getting srcdir in script executed using m4_esyscmd in AC_INIT

[Bob Friesenhahn]

I am trying to update the Autoconf and Automake initializations in 
GraphicsMagick to the current standard.  There is an external script 
which produces all of the version information.  This script needs to 
access a file (called ChangeLog) in the top of the source directory.


I am using this syntax in configure.ac:

AC_INIT(m4_esyscmd([./version.sh packagename]),
m4_esyscmd([./version.sh packageversion]),
m4_esyscmd([./version.sh packagebugreport]))

This works fine when building in the source directory.

The problem I am encountering is that in the context of AC_INIT and 
m4_esyscmd, I do not know how to obtain the path to the top of the 
source directory.


Can someone please give me a clue as to how to determine the top of 
the source directory?


Thanks,

Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: Autoconf version number after 2.70

[Bob Friesenhahn]

On Thu, 31 Dec 2020, Paul Eggert wrote:


I'm more of an Autoconf user than I am an Autoconf developer, and from the 
user point of view I'd rather keep things simple, and stick with 2.71 when it 
comes out, and then to 2.72 when it comes out, etc.


+1 on this.

There is no reason to "ride herd" on a herd that does not exist.

Dealing with change and multiple options is hard so keep things simple 
for us users.  The simple approach is to keep doing what worked 
fine before.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: [sr #110403] autoconf-2.70 trips bug in here-doc handling in OmniOS /bin/sh

[Bob Friesenhahn]

On Thu, 24 Dec 2020, Bruno Haible wrote:


I would recommend to just document the problem and workaround in two places:
1) in the OmniOS community,
2) at https://gitlab.com/ghwiki/gnow-how/-/wikis/Platforms/Configuration for
GNU people.


That seems reasonable.


It's not worth the complexity in Autoconf for a short-lived bug in a
small-community system, when a workaround is so easy to put in place.

References:
[1] https://en.wikipedia.org/wiki/Comparison_of_OpenSolaris_distributions
[2] trends.google.com


This Google reference (which is likely based on Google Search data) is 
very annoying to me and it seems irrelevant.  There is no need to 
diminish a viable free operating system.


In a similar spirit, I should point out that Illumos is doing better 
than CLISP according to trends.google.com since the limited 
popularlity is stable and not dwindling. ;-)


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

[sr #110403] autoconf-2.70 trips bug in here-doc handling in OmniOS /bin/sh

[Bob Friesenhahn]

Follow-up Comment #9, sr #110403 (project autoconf):

Since the shell delivered with OmniOSce is provided by Illumos, the
appropriate bug tracker would be at
https://www.illumos.org/projects/illumos-gate/issues

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110403] autoconf-2.70 AC_TYPE_INTMAX_T test failure under OmniOS

[Bob Friesenhahn]

Follow-up Comment #6, sr #110403 (project autoconf):

I wonder why autoconf-2.69b does not exhibit the issue, and in fact I have not
seen any other issues with configure scripts on this system?  This system has
been one of my core development systems for quite some time now.

Note that this system has a config.site script at the default location, but
that is normal for my systems.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110403] autoconf-2.70 AC_TYPE_INTMAX_T test failure under OmniOS

[Bob Friesenhahn]

Follow-up Comment #4, sr #110403 (project autoconf):

I just verified that this test passes for autoconf-2.69b.  This is the test
result using autoconf-2.69b, which is what I had tested on this system
previously:

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

474 tests behaved as expected.
49 tests were skipped.


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110403] autoconf-2.70 AC_TYPE_INTMAX_T test failure under OmniOS

[Bob Friesenhahn]

Follow-up Comment #3, sr #110403 (project autoconf):

The external host name appears to be "IP65-66-246-71.simplesystems.org". 
Sorry for not making it more memorable in DNS.

Previously we determined that the ksh93-based shell behaves poorly if
/usr/xpg4/bin is in the path.  So I removed it from my path.

My path setting is
/usr/local/bin:/opt/DTT/bin:/opt/local/bin:/opt/local/sbin:/usr/gnu/bin:/usr/bin:/usr/sbin:/usr/ucb

The compiler used comes from /opt/local/bin/gcc

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110403] autoconf-2.70 AC_TYPE_INTMAX_T test failure under OmniOS

[Bob Friesenhahn]

Additional Item Attachment, sr #110403 (project autoconf):

File name: autoconf-2.70-test537.tar.gz   Size:905 KB
   




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

Re: Request to revert the C version change

[Bob Friesenhahn]

On Wed, 16 Dec 2020, Todd C. Miller wrote:


Perhaps you are hitting this bug that breaks C99 flag detection?
   https://savannah.gnu.org/support/?110396


What are the impacts of that?

I just opened this new one.  Is it related?

sr #110403: autoconf-2.70 AC_TYPE_INTMAX_T test failure under OmniOS

https://savannah.gnu.org/support/index.php?110403

This test used to work fine on the same system, which has not been 
changed throughout the release cycle.  I must admit that I did not 
test the last release candidate before formal release, but I did test 
the other ones.


Regardless, something does not feel right so I will pass on using this 
release of Autoconf for software releases.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

[sr #110403] autoconf-2.70 AC_TYPE_INTMAX_T test failure under OmniOS

[Bob Friesenhahn]

URL:
  

 Summary: autoconf-2.70 AC_TYPE_INTMAX_T test failure under
OmniOS
 Project: Autoconf
Submitted by: bfriesen
Submitted on: Wed 16 Dec 2020 02:40:22 PM CST
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
Operating System: Solaris

___

Details:

While running the autoconf-2.70 test suite under OmniOS I encountered a new
failure that I have not seen before.  This failure did not occur with at least
some of the release candidates.

A testsuite.log file is attached.



___

File Attachments:


---
Date: Wed 16 Dec 2020 02:40:22 PM CST  Name: testsuite.log.gz  Size: 19KiB  
By: bfriesen



___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

Re: Hidden files in autoconf 2.70 distribution?

[Bob Friesenhahn]

On Wed, 9 Dec 2020, Bruce Korb wrote:

Tho the instance is particular to gnulib, it is of a more general interest, 
too.


Yes.  I have always been against approaches which tie release tarballs 
to the version control system used since this would created dependency 
and make some people more equal than others.  Release tarballs are a 
product of the version control system and the release process but it 
seems wrong for the tarball to contain additional content as an 
artifact of the version control system or the process used.


Any end user should be able to pick up the contents of a tarball and 
do 'make dist' and 'make distcheck' based only on the contents of the 
release tarball and without access to the original version control 
system.  Hopefully this is still the case.


Bob



On 12/9/20 6:21 AM, Zack Weinberg wrote:

This conversation should happen on the Gnulib mailing list; both
git-version-gen and maint.mk are maintained there.  I have no
particular opinion about whether it is appropriate to use dot-files
for this purpose.

(Context that got trimmed off the top: Bob is concerned about the
files named ".prev-version", ".version", and ".tarball-version" in the
autoconf 2.70 release tarball.)




--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: Hidden files in autoconf 2.70 distribution?

[Bob Friesenhahn]

On Tue, 8 Dec 2020, Zack Weinberg wrote:


Yes, that’s intentional. Those files record information copied out of the
git history. See build-aux/git-version-gen and maint.mk.


I don't recall seeing "hidden" files in a GNU package (or really any 
tarball distribution) before.  It seems like the GNU coding standards 
should be addressing such things.


The files appeared in autoconf-2.69c and were not in autoconf-2.69b.

Files starting with a '.' are treated as hidden according to Unix 
conventions, but not typically on operating systems not adhering to 
Unix conventions.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Hidden files in autoconf 2.70 distribution?

[Bob Friesenhahn]

I notice that the autoconf-2.70 tarball contains "hidden" files.  Is 
this intentional?


The "hidden" files are ".prev-version", ".version", and 
".tarball-version".


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: [PATCH] similar treatment for CYGWIN and MSYS2

[Bob Friesenhahn]

On Wed, 28 Oct 2020, Zack Weinberg wrote:


On Mon, Oct 26, 2020 at 10:18 AM Jannick  wrote:

Attached for your consideration a patch such that MSYS2 and CYGWIN are
treated the same.


Merged, thank you.


--- a/lib/autoconf/fortran.m4
+++ b/lib/autoconf/fortran.m4
@@ -666,7 +666,7 @@ while test $[@%:@] != 1; do
  ;;
-lkernel32)
  case $host_os in
- *cygwin*) ;;
+ *cygwin* | *msys* ) ;;
  *) ac_cv_[]_AC_LANG_ABBREV[]_libs="$ac_cv_[]_AC_LANG_ABBREV[]_libs
$ac_arg"


Should we have mingw* here too?


MinGW seems like a bare compiler whereas Cygwin and MSYS provide a 
compiler plus a rather-similar Unix-like run-time environment.


I recommend against it.

Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: determine base type of a typedef

[Bob Friesenhahn]

On Fri, 23 Oct 2020, Vivien Kraus wrote:


Is it not possible to always use "%lld" and always convert the
arguments to (long long int)?


The way I have been doing things for many years is to get the size of 
the underlying type and then include a cast in the printf arguments to 
a type of the same size.  The need to add a cast is a bit messy, but 
then then again, just about everything related to printf is messy.


So create a define for the time_t formatter, and a define/typedef for 
the type to cast to.


The approach that Paul Eggert suggests is very interesting, but it 
might not provide absolute proof of the C type since the 
compiler/linker might allow success if the types are the same size.  A 
printf syntax checker might not use the same rules.


Anything involving executing code should be avoided as much as 
possible since it hurts cross compilation.


Anything involving recent C standards should be avoided since it harms 
portability.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: verifying autoconf-2.69c.tar.xz.sig

[Bob Friesenhahn]

On Sun, 4 Oct 2020, Andreas Kusalananda Kähäri wrote:


On Sat, Oct 03, 2020 at 10:28:05PM -0400, Thien-Thi Nguyen wrote:

Additionally:

$ sha256sum autoconf-2.69c.tar.xz
923c2ecce25c55f6c7ce3a2c68cf066be13140edf6cb41083128b43763fa1723  
autoconf-2.69c.tar.xz

What do other people see?


Yes, the SHA256 is the same that I see.  The file is signed with the
wrong key though (not the key mentioned in the "autoconf-2.69c released
[beta]" email message to the list).


I see the same here.

The sad thing is that Autoconf is very security-sensitive software. 
We are placing extreme trust in it given that our personal accounts 
could be compromised by running autoconf or the generated configure 
script, the host computer could be taken over during 'make install', 
and a security defect could result in many user accounts/computers 
being compromised.  It is theoretically possible for Autoconf to 
result in code being stealthily injected into the built binaries.


It is important to get these things right!

A discussion of Autotools and security is certainly warranted.  There 
are many moving parts which are assimilated from various places. 
Some of these places might be based on signed packages but other 
places might just be whatever happened to be pulled in a git checkout. 
Git repositories are only as secure as the people authorized to push 
to them, and the security of the server where they are hosted.


As an example, my own project gets the latest config.guess and 
config.sub from a git repository using the pattern


"https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob_plain;f=config/${file};hb=HEAD;

I am trusting that the gnulib repository (and its gitweb front end) is 
inherently secure but without any proof of it.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: autoconf-2.69c released [beta]

[Bob Friesenhahn]

On Wed, 30 Sep 2020, Zack Weinberg wrote:


In particular, the AC_*_IFELSE macros have been available since
version 2.55, which was released in 2002(!)


Well, this configure script was first implemented in 1996 to replace 
something called 'imake'.  I am sure that there must be many more 
things to improve in it since (given an existing huge work-load) I 
don't actively re-visit the Autoconf documentation and the script to 
see what should be changed to modernize it.  I do know that it should 
have a lot more quoting.



Under OpenIndiana I still get 6 test failures.


Are these test failures of GraphicsMagick's test suite, or of
autoconf's own test suite?  I don't have access to an OpenIndiana
system but I would still be interested in more detail.  If it's
autoconf's own testsuite, a tarball of `tests/testsuite.dir` in the
build tree is usually enough information for me to figure out what's
wrong.


These are Autoconf test suite failures.  You should still have access 
to an OpenIndiana system since I see that you last accessed my 
OpenIndiana system on August 4th!.  Access for yourself and Paul 
Eggert has not been taken away.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: autoconf-2.69c released [beta]

[Bob Friesenhahn]

On Sun, 27 Sep 2020, Gavin Smith wrote:


That should be:

if test "$ac_cv_have_C__func__" != 'yes' ; then
AC_CACHE_CHECK(for C compiler __func__ support, ac_cv_have_C__func__,
[AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[]],
[[const char *func=__func__;
return (func != 0 ? 0 : 1);
]])],
[ac_cv_have_C__func__='yes'],
[ac_cv_have_C__func__='no']])])

if test "$ac_cv_have_C__func__" = 'yes' ; then
AC_DEFINE(HAS_C__func__,1,Define if C compiler supports __func__)
fi
fi


Gavin, thanks very much for your help.  Just in case someone reads 
this discussion later, I found that there was a small syntax error in 
the above.  The following is what finally worked for me (a small 
change after ac_cv_have_C__func__='no'):


# Test for C compiler __func__ support
if test "$ac_cv_have_C__func__" != 'yes' ; then
AC_CACHE_CHECK(for C compiler __func__ support, ac_cv_have_C__func__,
[AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[]],
[[const char *func=__func__;
return (func != 0 ? 0 : 1);
]])],
[ac_cv_have_C__func__='yes'],
[ac_cv_have_C__func__='no'])])

if test "$ac_cv_have_C__func__" = 'yes' ; then
 AC_DEFINE(HAS_C__func__,1,Define if C compiler supports __func__)
fi
fi

I now have the GraphicsMagick configure script updated and apparently 
working fine locally with Autoconf 2.69c.


There are still some deprecation warnings from an included m4 module.

Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: autoconf-2.69c released [beta]

[Bob Friesenhahn]

On Sun, 27 Sep 2020, Gavin Smith wrote:


It might help if you could post what the AC_TRY_COMPILE statements were
changed into.  If I understand correctly the definition in
autoconf/general.m4


That would certainly help and it is perhaps likely that there is some 
syntax weakness in the original.  See below.


Since the problem also occurs with Autoconf 2.69 autoupdate, that is 
what I use for the test case.


Input:

# Test for C compiler __func__ support
if test "$ac_cv_have_C__func__" != 'yes' ; then
AC_CACHE_CHECK(for C compiler __func__ support, ac_cv_have_C__func__,
[AC_TRY_COMPILE(
,
changequote(<<, >>)dnl
<<
const char *func=__func__;
return (func != 0 ? 0 : 1);

,

changequote([, ])dnl
ac_cv_have_C__func__='yes',
ac_cv_have_C__func__='no')])

if test "$ac_cv_have_C__func__" = 'yes' ; then
 AC_DEFINE(HAS_C__func__,1,Define if C compiler supports __func__)
fi
fi

After Autoconf 2.69 autoupdate:

# Test for C compiler __func__ support
if test "$ac_cv_have_C__func__" != 'yes' ; then
AC_CACHE_CHECK(for C compiler __func__ support, ac_cv_have_C__func__,
[AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[]], [[changequote(<<, >>)dnl
<<
const char *func=__func__;
return (func != 0 ? 0 : 1);

]])],[changequote(, )dnl

ac_cv_have_C__func__='yes'],[ac_cv_have_C__func__='no'])])

if test "$ac_cv_have_C__func__" = 'yes' ; then
 AC_DEFINE(HAS_C__func__,1,Define if C compiler supports __func__)
fi
fi

Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: autoconf-2.69c released [beta]

[Bob Friesenhahn]

On Sun, 27 Sep 2020, Paul Eggert wrote:


On 9/27/20 11:23 AM, Bob Friesenhahn wrote:

Is 'autoupdate' supposed to be safe to use?


I would never trust the output of 'autoupdate', no. It's meant to be 
suggestions and/or indications of problems, and is not meant to be 
authoritative. Perhaps this should be stated more clearly in the 
documentation.


That was my recollection from long ago, but things change.  The 
Autoconf utilities recommend executing 'autoupdate'.


With 2.69 (and 2.69c), each one of my AC_TRY_COMPILE() statements was 
re-written into a form which blows m4's recursion limits.  Perhaps I 
have somehow formatted them incorrectly, but some of them have been 
working fine since perhaps even 1998.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: autoconf-2.69c released [beta]

[Bob Friesenhahn]

On Sun, 27 Sep 2020, Bob Friesenhahn wrote:


A great many macros (still used to provide backward compatibility) are now 
declared as obsolete.  I ran 'autoupdate' and see that AC_TRY_COMPILE 
statements were changed to use new syntax.  The problem is that with the 
replacement code it inserted I get this m4 error:


libtoolize: found LT_INIT invocation
m4:configure.ac:1045: recursion limit of 1024 exceeded, use -L to change


I see that if I use 'autoupdate' from 2.69 that it also produces a 
configure.ac which recurses.  Is 'autoupdate' supposed to be safe to 
use?


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: autoconf-2.69c released [beta]

[Bob Friesenhahn]

Today I am trying autoconf-2.69c with GraphicsMagick's configure.ac 
and am only encountering utter failure.


A great many macros (still used to provide backward compatibility) are 
now declared as obsolete.  I ran 'autoupdate' and see that 
AC_TRY_COMPILE statements were changed to use new syntax.  The problem 
is that with the replacement code it inserted I get this m4 error:


libtoolize: found LT_INIT invocation
m4:configure.ac:1045: recursion limit of 1024 exceeded, use -L to change it
autom4te: error: /usr/gnu/bin/m4 failed with exit status: 1
aclocal: error: echo failed with exit status: 1
m4:configure.ac:1045: recursion limit of 1024 exceeded, use -L to change it
autom4te: error: /usr/gnu/bin/m4 failed with exit status: 1
autoheader: error: '/usr/local/bin/autom4te' failed with exit status: 1
m4:configure.ac:1045: recursion limit of 1024 exceeded, use -L to change it
autom4te: error: /usr/gnu/bin/m4 failed with exit status: 1

I am also concerned that the first active line after executing 
'autoupdate' is this:


AC_PREREQ([2.69c])

Presumably this means that version 2.69c is required to re-autoconf 
the configure script.  I certainly could not impose this overwhelming 
burden on my users.  If the resulting output can not be used with the 
prevailing version (2.69) then I can not use it!  I don't see now a 
new release can obviate the stable release which preceded it and is 
still in primary use!


Under OpenIndiana I still get 6 test failures.

Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: Debian archive rebuild with Autoconf 2.69c

[Bob Friesenhahn]

Zack,

I recommend also contacting Jonathan Perkin of the NetBSD 'pkgsrc' 
project.  The NetBSD 'pkgsrc' project (See 
https://en.wikipedia.org/wiki/Pkgsrc and https://www.pkgsrc.org/) 
actually supports far more operating systems than NetBSD and Jonathan 
Perkin does builds for many of the supported systems.


My understanding is that it possible to initiate a 'pkgsrc' build of 
tens of thousands of packages in a single go.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: Warning category skew between Autoconf and Automake - workaround in autoreconf?

[Bob Friesenhahn]

On Thu, 10 Sep 2020, Zack Weinberg wrote:


Clearly ChannelDefs.pm should be brought back into sync between the
two projects, but that will only fix the problem after *both* Autoconf
and Automake do a release.  So I’m wondering whether it would make
sense to merge this distributor’s patch to avoid supplying -Wcross to
automake -- perhaps generalized to arbitrary warning categories.  What
do you think?


Has it ever been an expectation that Autoconf and Automake are of a 
similar vintage?  Even if a newer Automake is released, it is not 
required to be used.


It seems like the patch may be required.

Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: Autoconf bug reports gone missing?

[Bob Friesenhahn]

On Mon, 27 Jul 2020, Zack Weinberg wrote:

Could you please forward me, off-list, the acknowledgement email that
you received?  I'm a little worried that there's some _other_ bug
tracker that I don't even know about.


Done.


Thanks for testing.  I will look into these bugs further.  It would
speed up the process considerably if you were able to provide me with
an unprivileged ssh account on an OpenIndiana system, I don't
currently have access to that variant of (the operating system
formerly known as) Solaris.


This is likely something that I will be able to do.  If you will send 
me your public ssh key then I will put it on my list of things to do.


Illumos (which OpenIndiana, OmniOS/OmniOSce, and several other 
distributions are derived from) has already diverged quite a bit from 
the OpenSolaris it was derived from and OpenSolaris had already 
diverged quite a bit from Solaris 10.  Unfortunately, my Solaris 10 
system is down with a failed CPU fan (and I have not been inspired to 
try to fix it yet) or else I could make it available.


Testing on Illumos-based systems will not be the same as testing under 
Solaris 11.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Autoconf bug reports gone missing?

[Bob Friesenhahn]

Today I sent three reports to the autoconf bug list (which I am not 
subscribed to any more).  Only one of them produced an acknowledgement 
email with a bug report number.


The two reports which did not produce an acknowledgement email 
included a gzipped testsuite.log file.


Are Autoconf bug reports with testsuite.log files automatically 
discarded or are these reports pending moderation?


Thanks,

Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

[GNU Autoconf 2.69b] testsuite: 329 failed

[Bob Friesenhahn]

Running the Autoconf test suite on an OpenIndiana system produced one 
test failure.


Please note that /usr/gnu/bin is in the executable path prior to the 
normal system paths so GNU utilities may be used rather than the 
Illumos ones.


I could run the test suite again without GNU utilities in the path.

See the attached testsuite log file.

Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

testsuite.log.gz
Description: Binary data

Re: feedback on 2.69b

[Bob Friesenhahn]

On Fri, 24 Jul 2020, Peter Eisentraut wrote:


It looks like it's not easy to disable these tests even with low-level 
hackery.  It would be better if there were still a way to set the preferred 
level of C and C++ in an official way.


Wow!  I am glad that you got here first.

Particularly as applies to C++, it is useful to be able to set an 
upper bar (and lower bar) for the C++ version requested because C++11 
is in many ways not similar to older C++.  I am already aware that 
some of my own software will not compile with C++11 because of removed 
deprecated features which I have not attended to yet in the code. 
Furthermore, the ABI often changes between C++ versions and it is 
useful to be able to specify the C++ version for purposes of the ABI.


It is true that the person running the configure script can usually 
supply additional options which request a particular standards 
version, and it would be important that Autoconf respect such requests 
if they were supplied.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: M4sh tests 77 and 78 vs /bin/sh -> dash

[Bob Friesenhahn]

On Mon, 23 Mar 2020, Paul Eggert wrote:


On 3/23/20 1:20 PM, Zack Weinberg wrote:

Autotools and C still have their niche, and that niche is code that
_does_  need to be extremely cross platform.


If cross-platform is the main goal, Java is often a better choice these days. 
:-)


Python 2.7.17 seems to be pretty portable for the moment. :-)

It would be fine to add an option (default off) to make Autoconf pickier 
about the shell, and letting people try the option who want to try it. We 
coould change the default later as experience rolls in.


It would be useful if Automake's 'distcheck' would arrange to execute 
configure under different available shells to make sure that the 
results are the same.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: M4sh tests 77 and 78 vs /bin/sh -> dash

[Bob Friesenhahn]

On Mon, 23 Mar 2020, Zack Weinberg wrote:


Given that Debian is _deliberately_ configuring dash without LINENO
support in order to work around configure scripts containing bashisms,
I think we should make changes in this area cautiously and with a lot
of public notice.  It's my personal opinion that we should push
configure-script authors in the direction of not using bash
extensions, maybe even at the expense of performance.


In my experience, bash is so popular as a command-line shell (and 
sometimes/often as a scripting shell) that configure-script authors do 
not know any better.  They are not aware that they are using 
bash-specific syntax since they often do not read documentation and 
just use what appears to work.  This applies to other shells as well, 
since it just depends on the shell that the developer used.


I do see Paul Eggert's follow on email which suggests that configure 
scripts should not inhibit the developer.


It is indeed true that some configure scripts are for convenience 
rather than portability, and it is ok to mix syntax in the script 
since the script does not fail unless syntax it does not understand is 
actually executed.  It might be ok to introduce a bash-specific shell 
function if it was only going to be executed by bash.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: debugging autoconf tests (was: gl_CACHE_VAL_SILENT)

[Bob Friesenhahn]

On Sat, 14 Mar 2020, Zack Weinberg wrote:


All of the worst autoconf-related bugs I've had to deal with in the
past decade or so, showed up in CI environments that I did _not_ have
interactive access to.  I only got the transcript of the build.  I had
to specifically add code to dump the contents of config.log, and then
track things down further by adding extra AC_MSG_* within the problem
macro.  You can probably imagine how frustrating this can be,
especially when the cycle time is a half-hour or more.  I haven't had


It would be useful if Autoconf/Automake provided a standard way for an 
uninformed user to be able to provide a minimal tarball or report 
which includes essential information for a maintainer to be able to 
understand the issue and provide assistance.  The current paradigm 
assumes that the uninformed user is going to have enough understanding 
that they would be able to find and study artifacts like config.log or 
a test suite report and take corrective action.


Configure is very easy to use until things go wrong.

Some behavior of Autotools is very confusing for users.  In 
particular, it is pretty common for generated files to be provided to 
users (e.g. in a tarball, or via git) and then the auto-maintaining 
features of Autotools fail because they are unable to find the 
specific version of aclocal, etc., required to assure that the build 
files are up to date.  Sometimes the build files are fine but the time 
stamps are wrong due to how the source control system works.  This 
causes users to become afraid of Autotools.


Anything which encourages users to not be afraid to build from source 
code (rather than depending on binary packages built by others) is 
useful to the future of free software.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: M4sh tests 77 and 78 vs /bin/sh -> dash

[Bob Friesenhahn]

On Fri, 13 Mar 2020, Michael Orlitzky wrote:


I get similar results here, bash adds about a second. With large scripts
the improvement is lost in the noise, but it's still a free lunch.


When using a parallel compile on a modern multi-core system, I find 
that from-scratch build timing (for GraphicsMagick, which is mostly C 
code) is dominated in this order:


 1) configure
 2) linker
 3) compilation

Linker time depends on the linker used.

The associated test suite takes longer to run than building the 
software.


It is amazing how compiling is not necessary the slowest part any 
more.


Given C++ code with lots of templates, compiling is still surely the 
bottleneck.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: M4sh tests 77 and 78 vs /bin/sh -> dash

[Bob Friesenhahn]

I am really not sure why the time output looks so funky but here are 
some timings of the GraphicsMagick configure script using /bin/dash 
and /bin/bash on an Ubuntu 18.04 LTS system.  The timing difference is 
not as much as I remember from years ago.  The difference might be due 
to configure script design improvements, Bash implementation 
improvements, and the fact that this is a much faster system.


/bin/dash
8.31user 2.37system 0:10.22elapsed 104%CPU (0avgtext+0avgdata 
71316maxresident)k

0inputs+30016outputs (0major+1529930minor)pagefaults 0swaps

/bin/bash
9.38user 3.07system 0:11.71elapsed 106%CPU (0avgtext+0avgdata 
71368maxresident)k

0inputs+31856outputs (0major+2007933minor)pagefaults 0swaps

Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: M4sh tests 77 and 78 vs /bin/sh -> dash

[Bob Friesenhahn]

On Fri, 13 Mar 2020, Sébastien Hinderer wrote:


Is the time spent in the shell such a big part of configure's total
execution time?

I am also wondering how widely config.status is known by non-experts. I
guess in the situation where the time spent ocnfiguring matters, e.g.
when you are developing, running ocnfig.status would be enough.


For developers, who need to configure over and over again, using 
configure's --config-cache option helps quite a lot.


The best way to see if a shell actually appears to work and the amount 
of time spent in configure is to do something like


env CONFIG_SHELL=/bin/dash ./configure

and see how its timing compares with /bin/bash, or some other shell.

Some shells such as Sun/Solaris legacy /bin/sh just plain don't work 
(but there are viable alternatives via other paths).


It is not clear if bash is any slower than other shells at executing 
algorithmic things like loops, but it was noticed to be slower at 
parsing large numbers of simple commands and Autoconf configure 
scripts are often almost 1MB of script.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: M4sh tests 77 and 78 vs /bin/sh -> dash

[Bob Friesenhahn]

On Thu, 12 Mar 2020, Zack Weinberg wrote:


I agree in principle.

On further investigation, there is a concrete reason why autoconf 2.69
prefers SHELL=/bin/bash to SHELL=/bin/dash, namely that dash doesn't
support $LINENO, necessitating a complicated and fragile workaround
(see _AS_LINENO_PREPARE in lib/m4sugar/m4sh.m4).  This has been the
behavior for a very long time (since roughly 2008).  Moreover, the
changed behavior of autoconf trunk was not intentional; it's because
commit 2b59b6f8a79b8bf77e178ff4e5aa0ede433d39cf missed a direct use of
$as_echo in _AS_DETECT_BETTER_SHELL, causing _AS_DETECT_BETTER_SHELL
*not to work at all*!


This is a good find.  It explains a lot.


I'm still looking into why tests/testsuite malfunctions when run by
dash, but right now I am inclined to say that the bug in
_AS_DETECT_BETTER_SHELL should be fixed and then we should
independently discuss whether it makes sense to prefer dash to bash.
It *would* discourage people from writing bashisms in their
configure.ac's and it *is* 30% faster than bash (on my computer,
according to "time make check"), but not supporting $LINENO is a big
loss.


Years ago when we were investigating slowness of configure it was 
determined that Bash is the "world's slowest shell" since it was 
considerably slower than all other shells tested.  The difference was 
often more significant outside of GNU/Linux.  This likely has not 
changed.


One reason why some projects are discarding use of Autoconf (and 
moving to CMake and Meson/Ninja) is due to how long it takes to 
execute a configure script.  Given modern multicore CPUs, it often 
takes as much (or more) time to run the configure script than to 
compile the software.  If configure can select the fastest shell which 
works reliably, then Autoconf's reputation will improve.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: M4sh tests 77 and 78 vs /bin/sh -> dash

[Bob Friesenhahn]

On Thu, 12 Mar 2020, Zack Weinberg wrote:


does not, assuming the stock `autoreconf` is from Autoconf 2.69.
This is because `make check` in this sequence re-runs configure
via `config.status --recheck`, which doesn’t recalculate *everything*.
In particular, the value of @SHELL@ will remain at whatever the first
run of ./configure picked.  @SHELL@ controls which shell is used to
run tests/testsuite from `make check`.  And, on a system where /bin/sh
is dash (and /bin/bash also exists), autoconf 2.69’s
`_AS_DETECT_BETTER_SHELL` picks /bin/bash for @SHELL@,
but autoconf trunk’s `_AS_DETECT_BETTER_SHELL` picks /bin/sh.


It would be useful if Autoconf does not require bash. If it requires 
bash and can not work with a reasonably POSIX-conformant shell 
(perhaps even ash/dash, bosh, or ksh), then there is a problem.  The 
automatic use of bash is a crutch which may be hiding problems.


This is a reason why verifying that Debian or Gentoo packages build 
with the new Autoconf does not verify that Autoconf is "ok".


In the past, when it was thought that libtool was feature complete and 
about ready for release it was then discovered that many non-portable 
artifacts had crept in and libtool was not ok on non-GNU/Linux systems 
until those non-portable artifacts were fixed.


If Autoconf were to reqire GNU bash and GNU sed, and Automake were to 
require GNU make, and libtool were to require GNU binutils and GCC, 
then Autotools should become a historical artifact.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: Making Autoconf 2.70 happen in the near future

[Bob Friesenhahn]

On Tue, 10 Mar 2020, Zack Weinberg wrote:


The git commits are more a factor of who has the personal ability to
make commits than whether the commits are the most important changes
needed.


What you say is true, but I only have a finite amount of time to put
into this, and I currently think that additional testing will be a
more effective use of that time than finding unreviewed patches within
the past eight years' worth of mailing list archives.  To put it
another way, would you rather see me find unreviewed patches or would
you rather see me run a Debian archive rebuild with a 2.70 release
candidate as /usr/bin/autoconf?


Running a Debian archive rebuild will produce useful information but 
Autoconf is fundamentally a portability tool and testing it on one of 
the best supported and most popular GNU/Linux distributions does not 
demonstrate portability.


The concern is that patches for interesting "new" systems may have 
been missed, or that less popular systems and targets may have changed 
their behavior in the mean-time, or that non-portable dependance on 
GNU tools has crept in.  It would be particularly unfortunate 
if the system or target which was missed is based on free software and 
that patches were submitted.


Hopefully people using less popular systems have not given up on 
Autoconf and will notice this discussion.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: Making Autoconf 2.70 happen in the near future

[Bob Friesenhahn]

On Mon, 9 Mar 2020, Zack Weinberg wrote:


I’ve seen people suggest that there is a backlog of patches that have
been submitted to this mailing list but not reviewed, but considering
that there’s already more git commits in between 2.69 and now than
there were between 2.68 and 2.69, I think it would be reasonable to
call 2.70 feature-complete at this point.  That backlog can become the
meat of 2.71. :-)


Without capturing this backlog and taking a look at the issues solved, 
how can you know if current git is reasonably acceptable, or if there 
is a vital issue remaining which is resolved by a patch?


The git commits are more a factor of who has the personal ability to 
make commits than whether the commits are the most important changes 
needed.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: Android and iOS triplets are not recognized

[Bob Friesenhahn]

On Wed, 4 Mar 2020, Jeffrey Walton wrote:


Android and iOS triplets are still not recognized.

I'm using config.guess and confg.sub dated 2020- 2020-01-01. It is the
latest fetched using
https://www.gnu.org/software/gettext/manual/html_node/config_002eguess.html.

According to the docs at
https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Specifying-Target-Triplets.html:

   Autoconf-generated configure scripts ... target triplet, which has the form:
   ‘cpu-vendor-os’, where os can be ‘system’ or ‘kernel-system’

OK, sounds good.

Unfortunately, none of these are recognized:


What does 'none of these are recognized' mean?  If you execute 
config.guess does it not produce a useful tripplet?  Is the problem 
you are complaining about an issue with config.guess, or how Autoconf 
deals with its output?



These devices have been around for about a decade. There is no reason
to fail to recognize them after 10 years.


Autoconf itself has not been released since 2012.  This feels like a 
long time to me, although not quite a decade.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: No macro for C11/C18?

[Bob Friesenhahn]

On Fri, 24 Jan 2020, Christian Biesinger wrote:


Hi there!

I noticed that autoconf has a macro to enable C99 (AC_PROG_CC_C99),
but apparently no such macro for C11 or C18. I was wondering if a
patch for that would be acceptable in principle or if this is missing
intentionally?


Given that the last Autoconf release was in 2012, it should not 
surprise if C18 was missing, and C11 as well.


The only concern might be if enabling more modern C standard versions 
might cause unexpected failures.  For example, if a recent GCC is used 
on a system with older headers which are not ready for C11 or C18, 
then there are likely to be unexpected failures.  The test would need 
to be rigorous in order to detect such cases and fall back to the 
newest working version.  If the software really does need such a new C 
standard vesion in order to work properly, then there is a problem.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: STDCXX issue

[Bob Friesenhahn]

On Mon, 20 Jan 2020, Sébastien Hinderer wrote:


Vincent Blondel (2020/01/20 15:10 +0100):

both ..._stdcxxx.m4 files are in the m4 subfolder ... is that not
enough ?


As far as I know each .m4 file needs to be included explicitly.


That does appear to be the case.  For example, my configure.ac uses 
acx_pthread.m4 and so the aclocal.m4 file includes this line


m4_include([m4/acx_pthread.m4])

Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: STDCXX issue

[Bob Friesenhahn]

On Mon, 20 Jan 2020, Vincent Blondel wrote:


BUT when doing the configure script  I get the same error ...

$ ./configure
./configure: line 2428: syntax error near unexpected token
`AX_CXX_COMPILE_STDCXX'
./configure: line 2428: `AX_REQUIRE_DEFINED(AX_CXX_COMPILE_STDCXX)'


It appears that this macro comes from the Autoconf archive rather than 
from Autoconf itself.  The failure indicates that the macro definition 
was not provided and so no substitution occured.  You likely need to 
provide the .m4 file containing this macro definition as part of the 
package since it might not be available installed on the system.


Google appears to be a wealth of information on this topic.

Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: Autotools lint tool

[Bob Friesenhahn]

On Sun, 6 Oct 2019, Richard Ash wrote:


On Thu, 3 Oct 2019 17:06:18 -0500 (CDT)
Bob Friesenhahn  wrote:


Many existing common tests found in Autoconf scripts can just be
removed since standards have made them unnecessary.


At the risk of being contrary, this is one of the things which a
"linter" for autotools should be able to tell the user (it may need to
make an assumption about the target OS list of course, just as you
have)!


Unless the test is done via a standard macro (e.g. testing for a 
well-known function), it would be very difficult for automated 
analysis to intuit what the shell script code is trying to do.


Project maintainers should check configure script output for tests 
which made sense 20 years ago but are now no longer needed.  Usually 
source code changes are warranted due to removing a test.


Standardization of interfaces has proven to be a success.  However, 
new interfaces are continually added and many of them are not part of 
a published standard or on a track to become one.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: Autotools lint tool

[Bob Friesenhahn]

On Wed, 2 Oct 2019, Warren Young wrote:


That’s not reality, though we are approaching it slowly.  “Real” 
Unix is all but dead now, the Linuxes are converging on a few major 
types, and the fragmentation in the BSDs seems to have reached a 
practical limit.  Alternatives like macOS and Windows WSL hew to one 
of the above standards.  The OS compatibility problems we have these 
days are nowhere near as bad as those in which the Autotools were 
created.


“Real” Unix seems to be doing fine to me.  It is available in free 
software form with a strong developer base.


I do agree with your notion of convergence on common standards, and 
that is what has been happening continually since the late 1980s.


It is no longer necessary to test for 'echo' since 'printf' is now 
commonly available (for a long time) and works reliably.


Many existing common tests found in Autoconf scripts can just be 
removed since standards have made them unnecessary.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: Check if a macro has already been defined with AC_DEFINE

[Bob Friesenhahn]

On Fri, 30 Aug 2019, Quaquaraqua wrote:


Hi there,
how can we check if a macro has been previously defined with AC_DEFINE ?

For instance, something like the following piece of code:

AX_OPENMP dnl it sets AC_DEFINE(HAVE_OPENMP,1) in case of success
...
m4_ifdef([[HAVE_OPENMP]], dnl how to check if HAVE_OPENMP has been defined?
   [ ... do something ... ],
   [ ... do something else ... ]
)

I'm aware that, as workaround, AX_OPENMP can take two optional arguments, 
ACTION-IF-FOUND and ACTION-IF-NOT-FOUND but I am
restricted to use them atm.


It seems that cached test results are normally stored in variables of 
the form "ac_cv_have_FOO".  Check the generated config.status script 
for the exact name to test.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: testsuite could basename the "Generated from"

[Bob Friesenhahn]

On Tue, 27 Aug 2019, Luke Mewburn wrote:

I notice that autoconf generating configure, and automake generating
Makefile.in both store the basename of the source file in the comments.

Currently I'm using the following to simulate this in testsuite.at
after AT_INIT():
m4_cleardivert([HEADER-COMMENT])dnl
m4_divert_text([HEADER-COMMENT],[dnl
@%:@ Generated from m4_bpatsubst(__file__,[^.*/\(.*\)],[[\1]]) by 
m4_PACKAGE_STRING])dnl

I think that AT_INIT() should do this by default.

If this is a good idea, I'll consider submitting a patch for AT_INIT()
in autoconf.


I think that this falls into the current trend that reproducible 
builds are a good thing.  Anything which normalizes the output (even 
for temporary/transient files) seems like a good idea.  The only 
exception is if it is necessary to know the origin and it is not 
intuitively obvious.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: Conventions on build variables

[Bob Friesenhahn]

On Mon, 26 Aug 2019, Sébastien Hinderer wrote:


For instance, regarding variables such as CC or CFLAGS, when they are
passed to configure, should they be recorded somewhere so that a future
invocation of make takes them into account?


Yes, they should normally be recorded in the Makefile so that they are used
in the build.


Okay. Still, I guess if make is invoked with a different value of CC it
is then expected that this new value takes precedence over then one
stored in the Makefile, right?


I would expect that to be true, but I would also expect that the new 
CC or CFLAGS might not be compatible with what configure figured out 
using the original settings.



Similarly, I kind of remember that if, say, make install is invoked with
a different value of PREFIX that value must be taken into acocunt and
that it is required that PREFIX can have different values during make
and make isntall. I am wondering whether there is a document which
specifies clearly for which variable this is expected to work that way
and couldn't find anything relevant on the web site of the FSF.


You are likely thinking of 'DESTDIR', which is different than prefix. 
DESTDIR comes from the build environment and not from the Makefile or 
configure script.



Otherwise you need to make sure that the necessary
artifacts are in Makefile.in.


I don't mind taking care of this, I am just unsure at the moment about
what exactly is expected.


If you are preparing your own Makefile, then following the GNU coding 
standards as well as the standard definitions documented in the GNU 
make manual will help quite a lot.  The standard INSTALL text file 
documents many of these conventions.


You will find available substitutions stored in the generated 
config.status script.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: Conventions on build variables

[Bob Friesenhahn]

On Thu, 8 Aug 2019, Sébastien Hinderer wrote:


Dear all,

Are there some conventions about the properties a build system should
have regarding certain standard build variables?

For instance, regarding variables such as CC or CFLAGS, when they are
passed to configure, should they be recorded somewhere so that a future
invocation of make takes them into account?


Yes, they should normally be recorded in the Makefile so that they are 
used in the build.  If you use Automake in conjunction with Autoconf, 
this is done automatically.  Otherwise you need to make sure that the 
necessary artifacts are in Makefile.in.



Is there a document describing how a build system is expected to behave
with respect to these variables?


The standard INSTALL file (which is inluded with autoconf and 
automake) describes these variables.  Look for the GNU coding 
standards on the fsf.org site for more details.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf