Re: Option autoconf option --debug no longer working
I meant
$cache = $tmp
unless defined $cache and len $cache;
of course. Sorry for the confusion.
Regards, Thomas
> On Sep 4, 2023, at 17:26 , Thomas Jahns wrote:
>
> Also, may I question the decision to use
>
> $cache = $tmp
>unless $cache;
>
> which results in falsy values for $cache like '0' to be ignored while ''
> works as expected?
>
> My recommendation would be to use
>
> $cache = $tmp
>unless defined $cache and -n $cache;
>
> instead.
>
> Kind regards, Thomas
>
>> On Sep 4, 2023, at 15:23 , Thomas Jahns wrote:
>>
>> Of course there was a dependency. But I think I managed to find a suitable
>> change that again preserves the temporaries. Please see the attached patch
>> vs. cb6fbab55de1e9660e110857ae248a70a8b48c5b and tell me if that needs
>> further improvements or is acceptable as is.
>>
>> Kind regards, Thomas
>>
>>
>>
>>> On Sep 4, 2023, at 14:57 , Thomas Jahns wrote:
>>>
>>> Following up on this, I think this is because autom4te calls mktmpdir
>>> before parsing command line arguments:
>>>
>>> ## -- ##
>>> ## Main program. ##
>>> ## -- ##
>>>
>>> mktmpdir ('am4t');
>>> load_configuration ($ENV{'AUTOM4TE_CFG'} || "$pkgdatadir/autom4te.cfg");
>>> load_configuration ("$ENV{'HOME'}/.autom4te.cfg")
>>> if exists $ENV{'HOME'} && -f "$ENV{'HOME'}/.autom4te.cfg";
>>> load_configuration (".autom4te.cfg")
>>> if -f ".autom4te.cfg";
>>> parse_args;
>>>
>>> In this order it creates the am4t... directory with the UNLINK option
>>> always being 1, i.e. !$debug while previously Autom4te::General had a
>>> custom END block that deleted the temporary files conditionally and hence
>>> used the value of $debug set by Autom4te::General::getopt.
>>>
>>> I'm not sure if load_configuration somehow needs the temporary directory or
>>> if parse_args could be moved to precede all of the main program. I'll try
>>> that next but wanted to keep you informed of my ongoing investigation.
>>>
>>> Kind regards, Thomas
>>>
>>>
>>>
>>>> On Sep 4, 2023, at 13:15 , Thomas Jahns >>> <mailto:ja...@dkrz.de>> wrote:
>>>>
>>>> Dear autoconf maintainers,
>>>>
>>>> when trying to port another piece of software to use autoconf 2.71 I
>>>> noticed a problem I wanted to debug with the autoreconf --debug option.
>>>> But it seems autoconf now deletes the temporary files in all paths.
>>>>
>>>> While the 2.69 version I'm currently using preserves files in /tmp, when
>>>> swapping the PATH to use autoconf 2.71, autoconf always unlinks the files
>>>> there (and removes the temporary directory) as verified with strace -f -e
>>>> rmdir,unlink on Linux x86_64.
>>>>
>>>> I tried
>>>>
>>>> autoconf --debug --verbose
>>>>
>>>> in a minimal autoconf directory like this:
>>>>
>>>> $ autoconf --debug --verbose 2>&1 | grep /tmp
>>>> autom4te: formatting traces for `/tmp/am4tYtdOcp/dependencies': include,
>>>> m4_include
>>>> autom4te: formatting traces for `/tmp/am4tYtdOcp/warnings': _m4_warn
>>>> autom4te: reading /tmp/am4tYtdOcp/warnings
>>>> $ ls /tmp/am4tYtdOcp
>>>> dependencies traces.m4 warnings
>>>> $ module load autoconf-2.71-gcc-6.3.0-rj5ute2
>>>> $ autoconf --debug --verbose 2>&1 | grep /tmp
>>>> autom4te: formatting traces for '/tmp/am4toeE5oa/warnings': _m4_warn
>>>> autom4te: reading /tmp/am4toeE5oa/warnings
>>>> autom4te: formatting traces for '/tmp/am4toeE5oa/patterns':
>>>> m4_pattern_allow, m4_pattern_forbid
>>>> $ ls /tmp/am4toeE5oa/
>>>> ls: cannot access '/tmp/am4toeE5oa/': No such file or directory
>>>> $ cat configure.ac
>>>> AC_INIT([hello], [1.0])
>>>> AC_CONFIG_AUX_DIR([build-aux])
>>>> AC_OUTPUT
>>>> $ strace -f -e rmdir,unlink autoconf --debug --verbose 2>&1 | grep -E
>>>> 'unlink|rmdir|/tmp'
>>>> autom4te: formatting traces for '/tmp/am4tciBmIE/dependencies': include,
>>>> m4_include
>>>> autom4te: formatting traces for '/tmp/am4tciBmIE/warnings': _m4_warn
>>>> autom4te: reading /tmp/am4tciBmIE/warnings
>>>> unlink("traces.m4") = 0
>>>> unlink("dependencies") = 0
>>>> unlink("warnings") = 0
>>>> rmdir("/tmp/am4tciBmIE")= 0
>>>> $ ls /tmp/am4tciBmIE
>>>> ls: cannot access '/tmp/am4tciBmIE': No such file or directory
>>>>
>>>> Kind regards,
>>>> Thomas
smime.p7s
Description: S/MIME cryptographic signature
Re: Option autoconf option --debug no longer working
Also, may I question the decision to use
$cache = $tmp
unless $cache;
which results in falsy values for $cache like '0' to be ignored while ''
works as expected?
My recommendation would be to use
$cache = $tmp
unless defined $cache and -n $cache;
instead.
Kind regards, Thomas
> On Sep 4, 2023, at 15:23 , Thomas Jahns wrote:
>
> Of course there was a dependency. But I think I managed to find a suitable
> change that again preserves the temporaries. Please see the attached patch
> vs. cb6fbab55de1e9660e110857ae248a70a8b48c5b and tell me if that needs
> further improvements or is acceptable as is.
>
> Kind regards, Thomas
>
>
>
>> On Sep 4, 2023, at 14:57 , Thomas Jahns wrote:
>>
>> Following up on this, I think this is because autom4te calls mktmpdir before
>> parsing command line arguments:
>>
>> ## -- ##
>> ## Main program. ##
>> ## -- ##
>>
>> mktmpdir ('am4t');
>> load_configuration ($ENV{'AUTOM4TE_CFG'} || "$pkgdatadir/autom4te.cfg");
>> load_configuration ("$ENV{'HOME'}/.autom4te.cfg")
>> if exists $ENV{'HOME'} && -f "$ENV{'HOME'}/.autom4te.cfg";
>> load_configuration (".autom4te.cfg")
>> if -f ".autom4te.cfg";
>> parse_args;
>>
>> In this order it creates the am4t... directory with the UNLINK option always
>> being 1, i.e. !$debug while previously Autom4te::General had a custom END
>> block that deleted the temporary files conditionally and hence used the
>> value of $debug set by Autom4te::General::getopt.
>>
>> I'm not sure if load_configuration somehow needs the temporary directory or
>> if parse_args could be moved to precede all of the main program. I'll try
>> that next but wanted to keep you informed of my ongoing investigation.
>>
>> Kind regards, Thomas
>>
>>
>>
>>> On Sep 4, 2023, at 13:15 , Thomas Jahns >> <mailto:ja...@dkrz.de>> wrote:
>>>
>>> Dear autoconf maintainers,
>>>
>>> when trying to port another piece of software to use autoconf 2.71 I
>>> noticed a problem I wanted to debug with the autoreconf --debug option. But
>>> it seems autoconf now deletes the temporary files in all paths.
>>>
>>> While the 2.69 version I'm currently using preserves files in /tmp, when
>>> swapping the PATH to use autoconf 2.71, autoconf always unlinks the files
>>> there (and removes the temporary directory) as verified with strace -f -e
>>> rmdir,unlink on Linux x86_64.
>>>
>>> I tried
>>>
>>> autoconf --debug --verbose
>>>
>>> in a minimal autoconf directory like this:
>>>
>>> $ autoconf --debug --verbose 2>&1 | grep /tmp
>>> autom4te: formatting traces for `/tmp/am4tYtdOcp/dependencies': include,
>>> m4_include
>>> autom4te: formatting traces for `/tmp/am4tYtdOcp/warnings': _m4_warn
>>> autom4te: reading /tmp/am4tYtdOcp/warnings
>>> $ ls /tmp/am4tYtdOcp
>>> dependencies traces.m4 warnings
>>> $ module load autoconf-2.71-gcc-6.3.0-rj5ute2
>>> $ autoconf --debug --verbose 2>&1 | grep /tmp
>>> autom4te: formatting traces for '/tmp/am4toeE5oa/warnings': _m4_warn
>>> autom4te: reading /tmp/am4toeE5oa/warnings
>>> autom4te: formatting traces for '/tmp/am4toeE5oa/patterns':
>>> m4_pattern_allow, m4_pattern_forbid
>>> $ ls /tmp/am4toeE5oa/
>>> ls: cannot access '/tmp/am4toeE5oa/': No such file or directory
>>> $ cat configure.ac
>>> AC_INIT([hello], [1.0])
>>> AC_CONFIG_AUX_DIR([build-aux])
>>> AC_OUTPUT
>>> $ strace -f -e rmdir,unlink autoconf --debug --verbose 2>&1 | grep -E
>>> 'unlink|rmdir|/tmp'
>>> autom4te: formatting traces for '/tmp/am4tciBmIE/dependencies': include,
>>> m4_include
>>> autom4te: formatting traces for '/tmp/am4tciBmIE/warnings': _m4_warn
>>> autom4te: reading /tmp/am4tciBmIE/warnings
>>> unlink("traces.m4") = 0
>>> unlink("dependencies") = 0
>>> unlink("warnings") = 0
>>> rmdir("/tmp/am4tciBmIE")= 0
>>> $ ls /tmp/am4tciBmIE
>>> ls: cannot access '/tmp/am4tciBmIE': No such file or directory
>>>
>>> Kind regards,
>>> Thomas
--
Thomas Jahns
HPC-Group
DKRZ GmbH, Department: Application software
Deutsches Klimarechenzentrum
Bundesstraße 45a
D-20146 Hamburg
Phone: +49-40-460094-151
Fax: +49-40-460094-270
Email: Thomas Jahns
smime.p7s
Description: S/MIME cryptographic signature
Re: Option autoconf option --debug no longer working
Okay, attached patch didn't work, I'll try an inline copy:
From a0f86d54b51710ca0843dff6d7a9f7378d5ab780 Mon Sep 17 00:00:00 2001
From: Thomas Jahns
Date: Mon, 4 Sep 2023 15:17:28 +0200
Subject: [PATCH] autom4te: Parse arguments before creating temporary
directory.
* The order before always used the default value of $debug in the
mktempdir call of General.pm.
---
bin/autom4te.in | 29 ++---
1 file changed, 18 insertions(+), 11 deletions(-)
diff --git a/bin/autom4te.in b/bin/autom4te.in
index 71d7e6a6..9f408cf2 100644
--- a/bin/autom4te.in
+++ b/bin/autom4te.in
@@ -383,16 +383,6 @@ Try '$me --help' for more information."
$melt = 1
if $freeze;
- # Names of the cache directory, cache directory index, trace cache
- # prefix, and output cache prefix. If the cache is not to be
- # preserved, default to a temporary directory (automatically removed
- # on exit).
- $cache = $tmp
-unless $cache;
- $icache = "$cache/requests";
- $tcache = "$cache/traces.";
- $ocache = "$cache/output.";
-
# Normalize the includes: the first occurrence is enough, several is
# a pain since it introduces a useless difference in the path which
# invalidates the cache. And strip '.' which is implicit and always
@@ -454,6 +444,22 @@ Try '$me --help' for more information."
@ARGV = @argv;
}
+# setup_cache
+#
+# define cache-related variables which depend on both, command-line
+# arguments and the actual temporary directory
+sub setup_cache
+{
+ # Names of the cache directory, cache directory index, trace cache
+ # prefix, and output cache prefix. If the cache is not to be
+ # preserved, default to a temporary directory (automatically removed
+ # on exit).
+ $cache = $tmp
+unless $cache;
+ $icache = "$cache/requests";
+ $tcache = "$cache/traces.";
+ $ocache = "$cache/output.";
+}
# handle_m4 ($REQ, @MACRO)
#
@@ -997,13 +1003,14 @@ sub freeze ($)
## Main program. ##
## -- ##
-mktmpdir ('am4t');
load_configuration ($ENV{'AUTOM4TE_CFG'} || "$pkgdatadir/autom4te.cfg");
load_configuration ("$ENV{'HOME'}/.autom4te.cfg")
if exists $ENV{'HOME'} && -f "$ENV{'HOME'}/.autom4te.cfg";
load_configuration (".autom4te.cfg")
if -f ".autom4te.cfg";
parse_args;
+mktmpdir ('am4t');
+setup_cache;
# Freezing does not involve the cache.
if ($freeze)
--
2.30.2
> On Sep 4, 2023, at 15:23 , Thomas Jahns wrote:
>
> Of course there was a dependency. But I think I managed to find a suitable
> change that again preserves the temporaries. Please see the attached patch
> vs. cb6fbab55de1e9660e110857ae248a70a8b48c5b and tell me if that needs
> further improvements or is acceptable as is.
>
> Kind regards, Thomas
>
>
>
>> On Sep 4, 2023, at 14:57 , Thomas Jahns wrote:
>>
>> Following up on this, I think this is because autom4te calls mktmpdir before
>> parsing command line arguments:
>>
>> ## -- ##
>> ## Main program. ##
>> ## -- ##
>>
>> mktmpdir ('am4t');
>> load_configuration ($ENV{'AUTOM4TE_CFG'} || "$pkgdatadir/autom4te.cfg");
>> load_configuration ("$ENV{'HOME'}/.autom4te.cfg")
>> if exists $ENV{'HOME'} && -f "$ENV{'HOME'}/.autom4te.cfg";
>> load_configuration (".autom4te.cfg")
>> if -f ".autom4te.cfg";
>> parse_args;
>>
>> In this order it creates the am4t... directory with the UNLINK option always
>> being 1, i.e. !$debug while previously Autom4te::General had a custom END
>> block that deleted the temporary files conditionally and hence used the
>> value of $debug set by Autom4te::General::getopt.
>>
>> I'm not sure if load_configuration somehow needs the temporary directory or
>> if parse_args could be moved to precede all of the main program. I'll try
>> that next but wanted to keep you informed of my ongoing investigation.
>>
>> Kind regards, Thomas
>>
>>
>>
>>> On Sep 4, 2023, at 13:15 , Thomas Jahns >> <mailto:ja...@dkrz.de>> wrote:
>>>
>>> Dear autoconf maintainers,
>>>
>>> when trying to port another piece of software to use autoconf 2.71 I
>>> noticed a problem I wanted to debug with the autoreconf --debug option. But
>>> it seems autoconf now deletes the temporary files in all paths.
>>>
>>> While the 2.69 version I'm currently using preserves files in /tmp, when
>>> swap
Re: Option autoconf option --debug no longer working
Of course there was a dependency. But I think I managed to find a suitable
change that again preserves the temporaries. Please see the attached patch vs.
cb6fbab55de1e9660e110857ae248a70a8b48c5b and tell me if that needs further
improvements or is acceptable as is.
Kind regards, Thomas
> On Sep 4, 2023, at 14:57 , Thomas Jahns wrote:
>
> Following up on this, I think this is because autom4te calls mktmpdir before
> parsing command line arguments:
>
> ## -- ##
> ## Main program. ##
> ## -- ##
>
> mktmpdir ('am4t');
> load_configuration ($ENV{'AUTOM4TE_CFG'} || "$pkgdatadir/autom4te.cfg");
> load_configuration ("$ENV{'HOME'}/.autom4te.cfg")
> if exists $ENV{'HOME'} && -f "$ENV{'HOME'}/.autom4te.cfg";
> load_configuration (".autom4te.cfg")
> if -f ".autom4te.cfg";
> parse_args;
>
> In this order it creates the am4t... directory with the UNLINK option always
> being 1, i.e. !$debug while previously Autom4te::General had a custom END
> block that deleted the temporary files conditionally and hence used the value
> of $debug set by Autom4te::General::getopt.
>
> I'm not sure if load_configuration somehow needs the temporary directory or
> if parse_args could be moved to precede all of the main program. I'll try
> that next but wanted to keep you informed of my ongoing investigation.
>
> Kind regards, Thomas
>
>
>
>> On Sep 4, 2023, at 13:15 , Thomas Jahns > <mailto:ja...@dkrz.de>> wrote:
>>
>> Dear autoconf maintainers,
>>
>> when trying to port another piece of software to use autoconf 2.71 I noticed
>> a problem I wanted to debug with the autoreconf --debug option. But it seems
>> autoconf now deletes the temporary files in all paths.
>>
>> While the 2.69 version I'm currently using preserves files in /tmp, when
>> swapping the PATH to use autoconf 2.71, autoconf always unlinks the files
>> there (and removes the temporary directory) as verified with strace -f -e
>> rmdir,unlink on Linux x86_64.
>>
>> I tried
>>
>> autoconf --debug --verbose
>>
>> in a minimal autoconf directory like this:
>>
>> $ autoconf --debug --verbose 2>&1 | grep /tmp
>> autom4te: formatting traces for `/tmp/am4tYtdOcp/dependencies': include,
>> m4_include
>> autom4te: formatting traces for `/tmp/am4tYtdOcp/warnings': _m4_warn
>> autom4te: reading /tmp/am4tYtdOcp/warnings
>> $ ls /tmp/am4tYtdOcp
>> dependencies traces.m4 warnings
>> $ module load autoconf-2.71-gcc-6.3.0-rj5ute2
>> $ autoconf --debug --verbose 2>&1 | grep /tmp
>> autom4te: formatting traces for '/tmp/am4toeE5oa/warnings': _m4_warn
>> autom4te: reading /tmp/am4toeE5oa/warnings
>> autom4te: formatting traces for '/tmp/am4toeE5oa/patterns':
>> m4_pattern_allow, m4_pattern_forbid
>> $ ls /tmp/am4toeE5oa/
>> ls: cannot access '/tmp/am4toeE5oa/': No such file or directory
>> $ cat configure.ac
>> AC_INIT([hello], [1.0])
>> AC_CONFIG_AUX_DIR([build-aux])
>> AC_OUTPUT
>> $ strace -f -e rmdir,unlink autoconf --debug --verbose 2>&1 | grep -E
>> 'unlink|rmdir|/tmp'
>> autom4te: formatting traces for '/tmp/am4tciBmIE/dependencies': include,
>> m4_include
>> autom4te: formatting traces for '/tmp/am4tciBmIE/warnings': _m4_warn
>> autom4te: reading /tmp/am4tciBmIE/warnings
>> unlink("traces.m4") = 0
>> unlink("dependencies") = 0
>> unlink("warnings") = 0
>> rmdir("/tmp/am4tciBmIE")= 0
>> $ ls /tmp/am4tciBmIE
>> ls: cannot access '/tmp/am4tciBmIE': No such file or directory
>>
>> Kind regards,
>> Thomas
smime.p7s
Description: S/MIME cryptographic signature
Re: Option autoconf option --debug no longer working
Following up on this, I think this is because autom4te calls mktmpdir before
parsing command line arguments:
## -- ##
## Main program. ##
## -- ##
mktmpdir ('am4t');
load_configuration ($ENV{'AUTOM4TE_CFG'} || "$pkgdatadir/autom4te.cfg");
load_configuration ("$ENV{'HOME'}/.autom4te.cfg")
if exists $ENV{'HOME'} && -f "$ENV{'HOME'}/.autom4te.cfg";
load_configuration (".autom4te.cfg")
if -f ".autom4te.cfg";
parse_args;
In this order it creates the am4t... directory with the UNLINK option always
being 1, i.e. !$debug while previously Autom4te::General had a custom END block
that deleted the temporary files conditionally and hence used the value of
$debug set by Autom4te::General::getopt.
I'm not sure if load_configuration somehow needs the temporary directory or if
parse_args could be moved to precede all of the main program. I'll try that
next but wanted to keep you informed of my ongoing investigation.
Kind regards, Thomas
> On Sep 4, 2023, at 13:15 , Thomas Jahns wrote:
>
> Dear autoconf maintainers,
>
> when trying to port another piece of software to use autoconf 2.71 I noticed
> a problem I wanted to debug with the autoreconf --debug option. But it seems
> autoconf now deletes the temporary files in all paths.
>
> While the 2.69 version I'm currently using preserves files in /tmp, when
> swapping the PATH to use autoconf 2.71, autoconf always unlinks the files
> there (and removes the temporary directory) as verified with strace -f -e
> rmdir,unlink on Linux x86_64.
>
> I tried
>
> autoconf --debug --verbose
>
> in a minimal autoconf directory like this:
>
> $ autoconf --debug --verbose 2>&1 | grep /tmp
> autom4te: formatting traces for `/tmp/am4tYtdOcp/dependencies': include,
> m4_include
> autom4te: formatting traces for `/tmp/am4tYtdOcp/warnings': _m4_warn
> autom4te: reading /tmp/am4tYtdOcp/warnings
> $ ls /tmp/am4tYtdOcp
> dependencies traces.m4 warnings
> $ module load autoconf-2.71-gcc-6.3.0-rj5ute2
> $ autoconf --debug --verbose 2>&1 | grep /tmp
> autom4te: formatting traces for '/tmp/am4toeE5oa/warnings': _m4_warn
> autom4te: reading /tmp/am4toeE5oa/warnings
> autom4te: formatting traces for '/tmp/am4toeE5oa/patterns': m4_pattern_allow,
> m4_pattern_forbid
> $ ls /tmp/am4toeE5oa/
> ls: cannot access '/tmp/am4toeE5oa/': No such file or directory
> $ cat configure.ac
> AC_INIT([hello], [1.0])
> AC_CONFIG_AUX_DIR([build-aux])
> AC_OUTPUT
> $ strace -f -e rmdir,unlink autoconf --debug --verbose 2>&1 | grep -E
> 'unlink|rmdir|/tmp'
> autom4te: formatting traces for '/tmp/am4tciBmIE/dependencies': include,
> m4_include
> autom4te: formatting traces for '/tmp/am4tciBmIE/warnings': _m4_warn
> autom4te: reading /tmp/am4tciBmIE/warnings
> unlink("traces.m4") = 0
> unlink("dependencies") = 0
> unlink("warnings") = 0
> rmdir("/tmp/am4tciBmIE")= 0
> $ ls /tmp/am4tciBmIE
> ls: cannot access '/tmp/am4tciBmIE': No such file or directory
>
> Kind regards,
> Thomas
>
>
>
--
Thomas Jahns
HPC-Group
DKRZ GmbH, Department: Application software
Deutsches Klimarechenzentrum
Bundesstraße 45a
D-20146 Hamburg
Phone: +49-40-460094-151
Fax: +49-40-460094-270
Email: Thomas Jahns
smime.p7s
Description: S/MIME cryptographic signature
Option autoconf option --debug no longer working
Dear autoconf maintainers,
when trying to port another piece of software to use autoconf 2.71 I noticed a
problem I wanted to debug with the autoreconf --debug option. But it seems
autoconf now deletes the temporary files in all paths.
While the 2.69 version I'm currently using preserves files in /tmp, when
swapping the PATH to use autoconf 2.71, autoconf always unlinks the files there
(and removes the temporary directory) as verified with strace -f -e
rmdir,unlink on Linux x86_64.
I tried
autoconf --debug --verbose
in a minimal autoconf directory like this:
$ autoconf --debug --verbose 2>&1 | grep /tmp
autom4te: formatting traces for `/tmp/am4tYtdOcp/dependencies': include,
m4_include
autom4te: formatting traces for `/tmp/am4tYtdOcp/warnings': _m4_warn
autom4te: reading /tmp/am4tYtdOcp/warnings
$ ls /tmp/am4tYtdOcp
dependencies traces.m4 warnings
$ module load autoconf-2.71-gcc-6.3.0-rj5ute2
$ autoconf --debug --verbose 2>&1 | grep /tmp
autom4te: formatting traces for '/tmp/am4toeE5oa/warnings': _m4_warn
autom4te: reading /tmp/am4toeE5oa/warnings
autom4te: formatting traces for '/tmp/am4toeE5oa/patterns': m4_pattern_allow,
m4_pattern_forbid
$ ls /tmp/am4toeE5oa/
ls: cannot access '/tmp/am4toeE5oa/': No such file or directory
$ cat configure.ac
AC_INIT([hello], [1.0])
AC_CONFIG_AUX_DIR([build-aux])
AC_OUTPUT
$ strace -f -e rmdir,unlink autoconf --debug --verbose 2>&1 | grep -E
'unlink|rmdir|/tmp'
autom4te: formatting traces for '/tmp/am4tciBmIE/dependencies': include,
m4_include
autom4te: formatting traces for '/tmp/am4tciBmIE/warnings': _m4_warn
autom4te: reading /tmp/am4tciBmIE/warnings
unlink("traces.m4") = 0
unlink("dependencies") = 0
unlink("warnings") = 0
rmdir("/tmp/am4tciBmIE")= 0
$ ls /tmp/am4tciBmIE
ls: cannot access '/tmp/am4tciBmIE': No such file or directory
Kind regards,
Thomas
smime.p7s
Description: S/MIME cryptographic signature
Re: INSTALL nits
On Aug 17, 2023, at 15:41 , Zack Weinberg wrote: > What are the most common things people need to do in a "bootstrap" > script that *aren't* covered by `autoreconf -i`? in our package we apply some patches to libtool ltmain.sh, mostly for weirdnesses of commercial compilers. Thomas
Re: parallelization of ./configure compiler test processes
On Mar 30, 2023, at 17:48 , Bob Friesenhahn wrote: > > 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. I should have clarified that I was particularly thinking of the kind of system spack is typically used for: massively parallel server machines running Linux attached to (usually) high-throughput, high-latency network filesystems. Sure, autoconf itself has much broader appeal, but the context in which Danny presumably wants to 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. > 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. 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. Kind regards, Thomas smime.p7s Description: S/MIME cryptographic signature
Re: parallelization of ./configure compiler test processes
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. I'm writing this, because I feel that quite a few bright minds went for the all-or-nothing goal of successful parallelization only to end up with something, if at all, that did not make it into general use, when smaller, incremental improvements can be introduced with much less risk in terms of correctness. And, especially in the context of a package manager that has almost full control about what factors into the build but is outside the source tree of each package, I feel it's very useful to think about the whole machinery to be up for improvements. Regarding parallelization for autoconf in particular, I think autoconf could very much benefit from having first more explicit effects of each macro, i.e. which variables end up being set, which file will be appended to etc. To my knowledge this is mostly well documented for the human reader, but not programmatically available in the M4 phase at all. E.g. if the script generation "knew" that some test macro invocations only affected confdefs.h via some atomic write, and no macro affecting some shell variable of consequence was in between, those tests could indeed safely be performed in parallel, as far as I can see. Also, there is a discussion of this particular topic on this mailing list started by Paul Eggert on June 14, 2022, Message-ID: Kind regards, Thomas > On Mar 29, 2023, at 22:12 , Danny McClanahan wrote: > > Hello autoconf, > > I work on a cross-platform package manager named spack (https://spack.io) > which builds lots of gnu software from source and has fantastic support for > autotools projects. Because spack provides a shell script `cc` to wrap the > compiler, each invocation of `cc` for feature tests executed by `./configure` > takes a little bit longer than normal, so configuring projects that > necessarily have a lot of feature tests takes much longer in spack > (particularly `gettext`, which we use as a benchmark in this change: > https://github.com/spack/spack/pull/26259). However, we can fix that > additional overhead ourselves without any changes in autoconf, by generating > our `cc` wrapper instead of doing any logic in the shell script. The reason I > messaged this board is because of a separate idea that the above situation > made me start thinking about: *parallelizing feature test executions*, in > order to speed up `./configure`. > > So a few questions: > 1. Are there any intrinsic blockers to parallelizing the generated feature > tests that execute in an autotools `./configure` script? >- For example, I've been told that feature tests currently write to a > single output file, which would get clobbered if we were to naively > parallelize the test execution, but I was hoping that each test could be made > to write to a temp file instead if that's true. > 2. Which codebase (autoconf, automake, m4, ?) does the work of generating the > script that executes tests in serial, and where in that codebase does this > occur? >- I've been perusing clones of the autoconf and automake codebases and > I've been unable to locate the logic that actually executes each test in > sequence. > 3. How should we expose the option to execute tests in parallel? >- In order to serve the purpose of improving `./configure` invocation > performance, we would probably want to avoid requiring an `autoreconf` (spack > avoids executing `autoreconf` wherever possible). >- Possibly an option `autoreconf > --experimental-also-generate-parallel-tests`, which would enable the end user > to execute `./configure --experimental-execute-parallel-tests`? > > Please feel free to link me to any existing content/discussions on this if > I've missed them, or redirect me to another mailing list. I'm usually pretty > good at figuring things out on my own but have been having some difficulty > getting started here. > >
Re: about variable ac_link and gcc
Hi Changqing, you probably want to call configure like this /path/to/configure LIBS=-ltirpc for the test to work. Regards, Thomas smime.p7s Description: S/MIME Cryptographic Signature
Re: automake problem with multiple "-rpath"
On 5/10/21 7:14 PM, aotto wrote: To be honest I don't want to set the -rpath at all… what I have : #1 libtclreadline.so depend on libreadline.so #2 everything is in the SAME directory #3 the directory is already KNOWN to ld.so > ls -ald *readline* -rw-r--r-- 1 dev1usr users 478680 29. Apr 22:28 libreadline.a lrwxrwxrwx 1 dev1usr users 18 29. Apr 22:28 libreadline.so -> libreadline.so.4.0 lrwxrwxrwx 1 dev1usr users 18 29. Apr 22:28 libreadline.so.4 -> libreadline.so.4.0 -rw-r--r-- 1 dev1usr users 432556 29. Apr 22:28 libreadline.so.4.0 -rwxr-xr-x 1 dev1usr users 67656 10. Mai 18:55 libtclreadline-3.0.0.so -rwxr-xr-x 1 dev1usr users 1109 10. Mai 18:55 libtclreadline.la lrwxrwxrwx 1 dev1usr users 23 10. Mai 18:55 libtclreadline.so -> libtclreadline-3.0.0.so -- important : libtclreadline.so -> libtclreadline-3.0.0.so and libreadline.so -> libreadline.so.4.0 error: libreadline.so.4.0 not found The EXE dlopen "libtclreadline" and the FIRST soft-link to "libtclreadline-3.0.0.so" is resolved and "libtclreadline-3.0.0.so" is dlopend'd, but the "libtclreadline.so" depend on "libreadline.so" this is a link to "libreadline.so.4.0" What does ldd libtclreadline.so give? Regards, Thomas smime.p7s Description: S/MIME Cryptographic Signature
Re: automake problem with multiple "-rpath"
Hi, you are confusing the -rpath /some/path option to libtool, which tells libtool where a library will be installed and the -Wl,-rpath,/some/other/path option to ld. If you replaced -rpath .../lib by -Wl,-rpath,.../lib everything should work as expected. Also relative rpath values will probably not work as expected unless the library and executabl in question are from one package. Also these are options to be used by whoever packages/installs the software and thus have no place in Makefile.am verbatim but rather should be added to LDFLAGS or similar during configure. Regards, Thomas > On May 10, 2021, at 10:29 , aotto wrote: > > Hi, > > problem: I want to start a software WITHOUT the environment is set - this > include LD_LIBRARY_PATH > (HELP: the '...' down in the text are from me to shorten the output) > > > ./cct > > couldn't load file ".../libtclreadline.so": libreadline.so.4.0: cannot open > shared object file: No such file or directory > > analyze: > > > ls -al .../libtclreadline.so > lrwxrwxrwx 1 dev1usr users 23 10. Mai 09:39 .../libtclreadline.so -> > libtclreadline-3.0.0.so > > The file is available BUT point with as SOFT-LINK to LOCAL file > > -> seems that -rpath . (local directory is NOT available) > -> seems that WITHOUT local directory in LD_LIBRARY_PATH the softlink (from > automake) seems NOT to work > > - > solution #1, setup LD_LIBRARY_PATH after software cct has started > > adding LD_LIBRARY_PATH after cct was started does NOT help because 'ld.so' > seems to use the LD_LIBRARY_PATH before > cct was started. > > -> HOW I tell 'ld.so' to accept a new LD_LIBRARY_PATH after start from cct ? > > - > stepping deeper I start to analyze the build of libtclreadline, an automake > software > > I install the "automake" software tclreadline with the following build-plan: > > #1 tclreadline source build and install into staging-area > #2 staging-area tested and verified, finally copied into destination-area > > with: staging-area != destination-area > > problem: The '-rpath' from the 'staging-area' does not fit into the > 'destination-area' > > TRY for solution: > > #1 add line 'libtclreadline_la_LDFLAGS = -release > $(MAJOR).$(MINOR).$(PATCHLEVEL) -rpath .../lib' to Makefile.am > > # output > > /bin/sh ./libtool --tag=CC --mode=link gcc -m32 -O2 -g -O2 -release 3.0.0 > -rpath .../linuxi386/lib -o libtclreadline.la -rpath > .../var/pkg/install/TclRl_3_0/lib tclreadline.lo -lncurses -L... -lreadline > > libtool: warning: ignoring multiple '-rpath's for a libtool library > > staging area : -rpath .../var/pkg/install/TclRl_3_0/lib > destination-area : -rpath .../linuxi386/lib > > #1 As you see NO multiple -rpath are NOT allowed > #2 Same for '-rpath .' local directory is not allowed at all !! > > conclusion: > > #1 I can NOT set the LD_LIBRARY_PATH after start (preferred solution) > #2 I can NOT set the right -rpath to the automake created library > > question > > #1 what to do? > #1 tclreadline is just an example other automake software likely have the > same problem. >I prefer NO solution where I have to modify ALL Makefile.am files because > of the >-rpath problem. > > > mfg > > > -- Thomas Jahns HPC-Group DKRZ GmbH, Department: Application software Deutsches Klimarechenzentrum Bundesstraße 45a D-20146 Hamburg Phone: +49-40-460094-151 Fax: +49-40-460094-270 Email: Thomas Jahns smime.p7s Description: S/MIME cryptographic signature
Re: Force 32 bit build
Hello, On 5/6/21 7:45 PM, aotto wrote: I want to write a "autoconf/automake" script for an application ONLY for 32 bit on 64 bit Linux. This meant that the default for configure must be 32 bit and nothing else. I know that a user can do "configure CC="gcc -m32"... etc but this is NOT what I want. I want that the 'configure' script set the 32bin once at start and fix. I think that's a bad use of autoconf which is meant to provide a portability shim for any kind of system, be it 32 or 64 bits. Also, specifically on Linux there are two 32 bit modes (i386 and x32). Regarding your problem: your first try uses commands that precede the AC_INIT and will consequently be ignored by autoconf. You should probably put those before AC_PROG_CC, but after AC_INIT. What do you mean by being too late in the second attempt? Still: I very much recommend against trying to force a particular system property that might easily go away (modern x86_64 Linux installations often don't include 32 bit headers anymore, Ubuntu for example has stopped support of its i386 variant). Better invest your time in creating software that works with any number of address bits. Kind regards, Thomas - my FIRST try fails, the "CCT-MARK" does NOT show up in configure : # CCT-MARK # https://www.gnu.org/software/automake/manual/html_node/Cross_002dCompilation.html # force 32 bit only export CFLAGS="$CFLAGS -m32 -O2" export CXXFLAGS="$CXXFLAGS -m32 -O2" export LDFLAGS="$LDFLAGS -m32 -O2" # set CCT3 VERSION information also in: AC_INIT() AC_CANONICAL_TARGET AM_INIT_AUTOMAKE([gnu tar-ustar no-dist-gzip dist-bzip2 -Wno-portability subdir-objects]) --- my SECOND try fails to, the "CCT-MARK" show up but too late : # set CCT3 VERSION information also in: AC_INIT() # CCT-MARK # https://www.gnu.org/software/automake/manual/html_node/Cross_002dCompilation.html # force 32 bit only export CFLAGS="$CFLAGS -m32 -O2" export CXXFLAGS="$CXXFLAGS -m32 -O2" export LDFLAGS="$LDFLAGS -m32 -O2" AC_CANONICAL_TARGET AM_INIT_AUTOMAKE([gnu tar-ustar no-dist-gzip dist-bzip2 -Wno-portability subdir-objects]) The "CCT-MARK" section is AFTER the ac_ definition, I think this mean that tests are done with 64 bit. created 'configure' script === ... ## ## ## Main body of script. ## ## ## ac_ext=c ac_cpp='$CPP $CPPFLAGS' ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5' ac_link='$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS >&5' ac_compiler_gnu=$ac_cv_c_compiler_gnu # CCT-MARK # https://www.gnu.org/software/automake/manual/html_node/Cross_002dCompilation.html # force 32 bit only export CFLAGS="$CFLAGS -m32 -O2" export CXXFLAGS="$CXXFLAGS -m32 -O2" export LDFLAGS="$LDFLAGS -m32 -O2" ... = > Question, what I have to do to force 32 bit ? mfg. smime.p7s Description: S/MIME Cryptographic Signature
Re: Check perl module
On 09/24/16 11:59, Gavin Smith wrote: On 24 September 2016 at 09:55, Rudra Banerjee wrote: But this is giving error: ./configure: line 4071: syntax error near unexpected token `Image::ExifTool,' ./configure: line 4071: `AX_PROG_PERL_MODULES( Image::ExifTool, ,)' What is going wrong here? This error shows that the AX_PROG_PERL_MODULES macro has not been expanded in the configure script. You have to make sure that that macro is available to autoconf when it runs. Maybe you need to use aclocal for this. As a matter of style, you also might want to quote Image::ExitTool and remove empty arguments as in: AX_PROG_PERL_MODULES([Image::ExifTool]) Thomas ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: ax_lib_hdf5 bug with library ordering, static libraries
Hello, On 08/30/2016 10:38 PM, Harald Anlauf wrote: I have a system where HDF5 installation seems to differ from what the autoconf package ax_lib_hdf5 expects: [...] AX_LIB_HDF5([serial]) as exhibited by the AX_ prefix, AX_LIB_HDF5 is not part of autoconf but of the autoconf macro archive[1]. As such, the primary method to contact the maintainers is to file a patch at Savannah[2] or contact the maintainers as spelled out at[3]. Regards, Thomas [1] https://www.gnu.org/software/autoconf-archive/ [2] https://savannah.gnu.org/projects/autoconf-archive/ [3] https://www.gnu.org/software/autoconf-archive/Introduction.html smime.p7s Description: S/MIME Cryptographic Signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Patch for AC_FC_MODULE_OUTPUT_FLAG
Hello,
I found AC_FC_MODULE_OUTPUT_FLAG does not know the -mdir option to nagfor and
added that. And while I was at it, I also did some change to make the shell code
a little safer. Can you include the patch as is or is it missing something?
Regards, Thomas
From 8c7102b3706f1f5e2561d3bf63d5a5491d2d6ca8 Mon Sep 17 00:00:00 2001
From: Thomas Jahns
Date: Thu, 8 Oct 2015 10:12:41 +0200
Subject: [PATCH] Add module output directory flag for NAG compiler.
* Also use autoconf macros instead of verbatim shell code and make tests
safer.
---
lib/autoconf/fortran.m4 | 22 +-
1 file changed, 9 insertions(+), 13 deletions(-)
diff --git a/lib/autoconf/fortran.m4 b/lib/autoconf/fortran.m4
index fd3d5b1..bd4245a 100644
--- a/lib/autoconf/fortran.m4
+++ b/lib/autoconf/fortran.m4
@@ -1818,7 +1818,7 @@ ac_cv_fc_module_output_flag=unknown
ac_fc_module_output_flag_FCFLAGS_save=$FCFLAGS
# Flag ordering is significant: put flags late which some compilers use
# for the search path.
-for ac_flag in -J '-J ' -fmod= -moddir= +moddir= -qmoddir= '-mod ' \
+for ac_flag in -J '-J ' -fmod= -moddir= +moddir= -qmoddir= '-mdir ' '-mod ' \
'-module ' -M '-Am -M' '-e m -J '; do
FCFLAGS="$ac_fc_module_output_flag_FCFLAGS_save ${ac_flag}sub"
AC_COMPILE_IFELSE([[
@@ -1834,25 +1834,21 @@ for ac_flag in -J '-J ' -fmod= -moddir= +moddir= -qmoddir= '-mod ' \
use conftest_module
call conftest_routine
end program]],
- [ac_cv_fc_module_output_flag="$ac_flag"])
+ [ac_cv_fc_module_output_flag=$ac_flag])
cd ..
- if test "$ac_cv_fc_module_output_flag" != unknown; then
- break
- fi])
+ AS_IF([test x"$ac_cv_fc_module_output_flag" != xunknown],[break])])
done
FCFLAGS=$ac_fc_module_output_flag_FCFLAGS_save
cd ..
rm -rf conftest.dir
AC_LANG_POP([Fortran])
])
-if test "$ac_cv_fc_module_output_flag" != unknown; then
- FC_MODOUT=$ac_cv_fc_module_output_flag
- $1
-else
- FC_MODOUT=
- m4_default([$2],
-[AC_MSG_ERROR([unable to find compiler flag to write module information to])])
-fi
+AS_IF([test x"$ac_cv_fc_module_output_flag" != xunknown],
+ [FC_MODOUT=$ac_cv_fc_module_output_flag
+ $1],
+ [FC_MODOUT=
+ m4_default([$2],
+[AC_MSG_ERROR([unable to find compiler flag to write module information to])])])
AC_SUBST([FC_MODOUT])
# Ensure trailing whitespace is preserved in a Makefile.
AC_SUBST([ac_empty], [""])
--
1.9.1
smime.p7s
Description: S/MIME Cryptographic Signature
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
Swapping ac_link after LT_INIT
Hello, when using libtool, it figures out most dependent libraries from installed .la files. So command-lines in Makefiles become nice and short, listing only direct dependencies. But for autoconf, link tests don't normally use libtool, so if the libraries are to be tested (and happen to be static, installed in non-standard places, whatever), various flags need to be passed to configure that later go unused. From my point of view, the straight-forward way to proceed would be to redefine the various ac_link settings of CC/FC/CXX/F77, but it seems (after a cursory research on the web) no corresponding macro is part of libtool or autoconf. Since the topic has already been discussed here[1], and a TeX Live maintainer proposed a solution used there, I was wondering what became of that? Regards, Thomas [1] http://lists.gnu.org/archive/html/autoconf/2010-06/msg00064.html -- Thomas Jahns HD(CP)^2 Abteilung Anwendungssoftware Deutsches Klimarechenzentrum GmbH Bundesstraße 45a • D-20146 Hamburg • Germany Phone: +49 40 460094-151 Fax:+49 40 460094-270 Email: Thomas Jahns URL:www.dkrz.de Geschäftsführer: Prof. Dr. Thomas Ludwig Sitz der Gesellschaft: Hamburg Amtsgericht Hamburg HRB 39784 smime.p7s Description: S/MIME Cryptographic Signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: What is the best/recommended technique for referencing development libraries?
On 12/11/14 04:20, Patrick Doyle wrote: But now I would like to compile a custom version of libzbar, and tell my custom gstzbar plugin to reference that library instead of the one install in /usr/lib. What's the best/recommended way to do this? So you want to link something in /usr/local instead of /usr/lib and use run-time loading. That means you want to use dynamic linking, which is outside the scope of autoconf itself but addressed much more reliably with libtool. I recommend you use that. Regards, Thomas -- Thomas Jahns HD(CP)^2 Abteilung Anwendungssoftware Deutsches Klimarechenzentrum GmbH Bundesstraße 45a • D-20146 Hamburg • Germany Phone: +49 40 460094-151 Fax:+49 40 460094-270 Email: Thomas Jahns URL:www.dkrz.de Geschäftsführer: Prof. Dr. Thomas Ludwig Sitz der Gesellschaft: Hamburg Amtsgericht Hamburg HRB 39784 smime.p7s Description: S/MIME Cryptographic Signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Clarification request: AC_PREFIX_DEFAULT([.]) and AC_CONFIG_SUBDIRS collide.
Hello, I noticed having a default prefix of . causes AC_CONFIG_SUBDIRS to fail. Is this a bug in AC_PREFIX_DEFAULT (or its documentation) or in AC_CONFIG_SUBDIRS? Regards, Thomas P.S.: the failure looks like this config.status: executing depfiles commands === configuring in yaxt (/path/to/package_top/directory_sub) configure: running /bin/sh ./configure --disable-option-checking '--prefix=.' --cache-file=/dev/null --srcdir=. configure: error: expected an absolute directory name for --prefix: . configure: error: ./configure failed for directory_sub smime.p7s Description: S/MIME Cryptographic Signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: AC_PROG_CC wrongly setting $GCC=yes while clang is used
On 09/09/14 00:26, Russ Allbery wrote: > Bastien Chevreux writes: >> Would it be worthwhile to forward this to the GNU compiler maintainers >> so that they could maybe correct their course by maybe introducing a >> define which is ‘reserved’ for telling that, yes, this is indeed a GNU >> compiler? > > That's what __GNUC__ was for. However, from the perspective of the > authors of the other compilers, this is a bug -- they want to be able to > compile code that uses GCC extensions, which is why they're implementing > those extensions. So they *want* their compiler to be detected as capable > of supporting GCC extensions. > > So, if GCC added a new define, the other compilers would just start > defining that symbol as well. > > I'm afraid the only hope you have, if you depend on extensions that are > not implemented by other compilers, is to test explicitly for those > extensions. It should also be noted that among those compilers which define __GNUC__ but may not have all the features some author expects are earlier versions of gcc. I'd rather not rely on $GCC for anything and rather test the feature instead. Regards, Thomas smime.p7s Description: S/MIME Cryptographic Signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: AC_PROG_CC wrongly setting $GCC=yes while clang is used
On 09/08/14 06:24, Paul Smith wrote: > In particular, this: > > configure:3666: checking whether we are using the GNU C compiler > configure:3685: clang -c -mmacosx-version-min=10.6conftest.c >&5 > configure:3685: $? = 0 > configure:3694: result: yes > > Appears to show that clang is defining the __GNUC__ built-in compiler > flag, presumably for compatibility with GCC source code. So IF there's > any real problem here, which I'm not sure there is, the problem is in > clang claiming to be something it's not. Happens just the same for icc and since the Intel compiler supports enough of the pragma's and non-std features of gcc, this works out fine for me so far. Regards, Thomas smime.p7s Description: S/MIME Cryptographic Signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: config.guess problem with pgcc
Hello Eric,
On 08/20/14 18:10, Eric Blake wrote:
>> -eval `$CC_FOR_BUILD -E $dummy.c 2>/dev/null | grep '^LIBC'` + eval
>> `$CC_FOR_BUILD -E $dummy.c 2>/dev/null | sed -n '/^LIBC/{s/LIBC *=
>> *\(.*\)$/LIBC='"'"'\1'"'"'/;p;}'`
>
> Thanks for the patch. We like to keep to 80-column lines where possible;
> also, that sed expression is rather verbose, when compared to the
> equivalent:
>
> eval `$CC_FOR_BUILD -E $dummy.c 2>/dev/null \ | sed -n 's/^LIBC *=
> */LIBC=/p'`
>
> I'll apply the shortened version in your name, if you agree that it still
> works.
I'm okay with that. I verified that your shorter version still works as
intended.
Regards, Thomas
--
Thomas Jahns
DKRZ GmbH, Department: Application software
Deutsches Klimarechenzentrum
Bundesstraße 45a
D-20146 Hamburg
Phone: +49-40-460094-151
Fax: +49-40-460094-270
Email: Thomas Jahns
smime.p7s
Description: S/MIME Cryptographic Signature
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
config.guess problem with pgcc
Hello,
I've found and fixed a problem where pgcc -E translates its input to contain
extra spaces. Since config.guess expects the preprocessor output to be a well
formed shell variable assignment, I've added some sed code to ensure this.
Please consider the attached patch for inclusion in autoconf.
Regards, Thomas
From 400897893790901d904663640b53cf0fd6316237 Mon Sep 17 00:00:00 2001
From: Thomas Jahns
Date: Wed, 20 Aug 2014 17:42:49 +0200
Subject: [PATCH] Fix for pgcc -E output.
* PGI's pre-processor transforms 'LIBC=gnu' to 'LIBC = gnu'.
---
build-aux/config.guess |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/build-aux/config.guess b/build-aux/config.guess
index 120cc0d..6da3ed2 100755
--- a/build-aux/config.guess
+++ b/build-aux/config.guess
@@ -2,7 +2,7 @@
# Attempt to guess a canonical system name.
# Copyright 1992-2013 Free Software Foundation, Inc.
-timestamp='2013-05-16'
+timestamp='2014-08-20'
# This file is free software; you can redistribute it and/or modify it
# under the terms of the GNU General Public License as published by
@@ -149,7 +149,7 @@ Linux|GNU|GNU/*)
LIBC=gnu
#endif
EOF
- eval `$CC_FOR_BUILD -E $dummy.c 2>/dev/null | grep '^LIBC'`
+ eval `$CC_FOR_BUILD -E $dummy.c 2>/dev/null | sed -n '/^LIBC/{s/LIBC *= *\(.*\)$/LIBC='"'"'\1'"'"'/;p;}'`
;;
esac
--
1.7.10.4
smime.p7s
Description: S/MIME Cryptographic Signature
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
Re: AC_PROG_INSTALL and AC_PROG_MKDIR_P fallbacks
Hello, On 08/09/14 09:51, Paul Eggert wrote: > Thanks, but I don't see how that patch addresses the quoting issues mentioned > in: > > http://lists.gnu.org/archive/html/bug-autoconf/2013-02/msg00013.html > > http://lists.gnu.org/archive/html/bug-autoconf/2013-02/msg00014.html it doesn't because I wasn't sure how to do that reliably: the stuff automake does for e.g. autoconf assumes that the contents of the potentially escaped variable contain a single file path and nothing more. This is unfortunately untrue for ac_install_sh, which already contains a command with option, spaces and everything. The way automake handles this works, because in Makefiles another round of substition happens. I didn't want to count on that. Regards, Thomas smime.p7s Description: S/MIME Cryptographic Signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: AC_PROG_INSTALL and AC_PROG_MKDIR_P fallbacks
On 08/08/14 01:00, Peter Johansson wrote: > I think you're welcome to send in a patch given the response I got from Paul > Eggert and Eric Blake when I reported similar thing last year > > http://lists.gnu.org/archive/html/bug-autoconf/2013-02/msg00012.html Thanks, from that thread I can also see that the fix needs to be in the program macros because then nothing's lost if the problem with funny path characters applies, i.e. I'm too timid to modify ac_install_sh but rather mangle the value of MKDIR_P if and only if it is a relative path. Please see my attached patch (tested on FreeBSD 10) for AC_PROG_MKDIR_P. A patch for AC_PROG_INSTALL would have to be identical but I don't have a system to test. Our AIX machines have a working install program and the same is true for FreeBSD. If anyone has a suggestion for a platform to test this on (preferably available for install to a VM) I'd give it a go. Regards, Thomas From e61ebcd649a0260c9a143a5ddebfb0199581ee45 Mon Sep 17 00:00:00 2001 From: Thomas Jahns Date: Fri, 8 Aug 2014 13:18:56 +0200 Subject: [PATCH] Fix relative path in ac_install_sh for MKDIR_P. --- lib/autoconf/programs.m4 | 12 +++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/lib/autoconf/programs.m4 b/lib/autoconf/programs.m4 index 32f737a..0f214bf 100644 --- a/lib/autoconf/programs.m4 +++ b/lib/autoconf/programs.m4 @@ -687,7 +687,17 @@ if test -z "$MKDIR_P"; then # value for MKDIR_P within a source directory, because that will # break other packages using the cache if that directory is # removed, or if the value is a relative name. -MKDIR_P="$ac_install_sh -d" +# 1. extract (relative) path of install script from ac_install_sh +MKDIR_P=`echo "$ac_install_sh" | sed 's:\(.*\)/.*:\1:'` +AS_CASE(["$MKDIR_P"], + # 2. leave as-is if no path component or already absolute ... + ["" | [\\/]* | ?:[\\/]*],[], + # ... or convert to absolute if relative + [MKDIR_P=`cd "$MKDIR_P" && pwd` + test -d "$MKDIR_P" || + AC_MSG_FAILURE([Cannot derive absolute path from relative of path of "$ac_install_sh"]) + ]) +MKDIR_P="$MKDIR_P"`echo "$ac_install_sh" | sed 's:.*\(/.*\):\1:'`" -d" fi fi dnl status.m4 does special magic for MKDIR_P instead of AC_SUBST, -- 1.7.10.4 smime.p7s Description: S/MIME Cryptographic Signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
AC_PROG_INSTALL and AC_PROG_MKDIR_P fallbacks
Hello, on a friends Mac I noticed a problem with AC_PROG_MKDIR_P which I believe to also apply to AC_PROG_INSTALL (albeit not on his system): both fall back on $ac_install_sh which resolves to the relative path $ac_aux_dir/install-sh if configure was called with a relative path. This of course does not work when using MKDIR_P from a sub-directory. I'd like to provide a patch but I'd first like to discuss the ramifications of changing the definition of ac_install_sh in lib/autoconf/general.m4 or patching the two above macros in lib/autoconf/programs.m4. Thomas smime.p7s Description: S/MIME Cryptographic Signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: configure speedup proposal: add --assume-c99 and --assume-posix2008 flags
On 03/23/14 19:00, Russ Allbery wrote: > Some of the problems with snprintf are also quite serious. For example, > Solaris 9 (which I believe is otherwise C99-conforming) would return -1 > when given NULL, 0 as the first arguments to snprintf, which makes it > impossible to use snprintf safely in many programs. IIRC Solaris 9 also doesn't have stdint.h (but a sufficiently good inttypes.h for most purposes). Thomas -- Thomas Jahns DKRZ GmbH, Department: Application software Deutsches Klimarechenzentrum Bundesstraße 45a D-20146 Hamburg Phone: +49-40-460094-151 Fax: +49-40-460094-270 Email: Thomas Jahns smime.p7s Description: S/MIME Cryptographic Signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Testing for unknown flags in different compilers
Hello all, On 02/19/14 22:05, Dale Visser wrote: > I have been working on a changes whereby an autoconf user can invoke a macro > like > > AC_WARN_ADD([-Wextra]) > > to add user-specified flags to the compiler/linker invocations. Ideally we > would like I'm unclear what tool(s) you want to affect (is the flag going to be added to CFLAGS, CXXFLAGS, FCFLAGS? depending on language mode or CFLAGS only? if the latter shouldn't the name have something like CC in it). Also this is going to cause all sorts problems for compilers that use -W for something else entirely, for example on PowerPC xlc has -W, so simply adding some arbitrary -Wsomecharactersequence might easily cause catastrophic results later on. I suggest your macro at least try to make sure your compiler is GNU CC before modifying CFLAGS in any way. Also users should have an option to deselect this because software tends to get distributed to systems where system headers cause one warning or another. In my opinion you are trying to solve a development issue with a tool that has the explicit purpose of being useful for non-developers. Regards, Thomas -- Thomas Jahns DKRZ GmbH, Department: Application software Deutsches Klimarechenzentrum Bundesstraße 45a D-20146 Hamburg Phone: +49-40-460094-151 Fax: +49-40-460094-270 Email: Thomas Jahns smime.p7s Description: S/MIME Cryptographic Signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Passing -fno-lto by default?
On Feb 6, 2014, at 22:00 , Russ Allbery wrote: Why would one not instead build the object and then use objdump on it to look at the exported symbols? It's still not ideally portable, but it seems like it should be more portable than trying to grep the assembly output. could perhaps even nm solve that? Then using libtool, which tries to find a BSD nm if available, would perhaps suffice. Thomas -- Thomas Jahns DKRZ GmbH, Department: Application software Deutsches Klimarechenzentrum Bundesstraße 45a D-20146 Hamburg Phone: +49-40-460094-151 Fax: +49-40-460094-270 Email: Thomas Jahns smime.p7s Description: S/MIME cryptographic signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Passing -fno-lto by default?
On 02/06/14 16:48, Markus Trippelsdorf wrote:
> When using gcc with Link Time Optimization (-flto) enabled there are
> certain configuration tests that always fail. For example the following
> test taken from Firefox's configure.in:
> ac_cv_visibility_default=no
> if ${CC-cc} -fvisibility=hidden -Werror -S conftest.c -o conftest.s
> >/dev/null 2>&1; then
> if ! egrep '\.(hidden|private_extern).*foo' conftest.s >/dev/null; then
> ac_cv_visibility_default=yes
> ...
> which greps the assembler output, will not succeed with -flto (because
> it produces GIMPLE output in special sections).
this is broken on so many levels: 1. it totally relies on gcc which is a nice,
if not the nicest, compiler but the scope of autotools is a bit broader, 2. it
relies on the compiler being able to produce assembly equivalents which is
probably possible for any compiler but very far from portable 3. it relies on
the assembly following a particular symbol convention which is probably far from
universal. With cases like this I propose to ask what the intended purpose was
in the first place and look for a saner approach. I can see that JIT software
has special needs but I can see no good way to approach this in a framework
aimed at virtualizing build environments.
> Now my question is if it wouldn't be desirable to have autoconf pass the
> -fno-lto flag automatically by default (instead of requiring each
> project to add it by hand when needed)?
I'm very much opposed to autoconf adding arbitrary compiler flags, especially
those which remove desirable features. Doing so "only" intermediately means the
configure tests essentially run with another environment putting their validity
unnecessarily into question.
My recommendation would be to put some mechanism into your configure.ac that
substitutes/adds to CFLAGS after the configure tests and before AC_OUTPUT and
which is controlled solely by the users. I have this in several of my projects
because profiling/tracing tools frequently must be used as compiler wrappers but
are not up to pass the tests or need extra flags that cannot be used in the
tests.
Thomas
smime.p7s
Description: S/MIME Cryptographic Signature
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
Re: Empty else part in AS_IF
On 10/09/13 21:31, Eric Blake wrote: > On 10/09/2013 01:18 PM, Julien LIE wrote: >> The following piece of code: >> >> AS_IF([test x"$var" != xfalse], [$test=1], [m4_ifdef([AM_CONDITIONAL], >> [AM_CONDITIONAL([TEST], [false])])]) >> >> gives the following configure code with autoconf 2.69: >> >> if test x"$var" != xfalse; then : $test=1 > > That's unusual shell syntax (it does NOT do a variable assignment; did you > mean 'test=1' instead of trying to execute the program whose name is the > expansion of $test concatenated with '=1'?) > >> else >> >> fi >> >> which is not a valid syntax. > > Indeed. The problem is that autoconf cannot tell if a non-empty literal > will expand to empty text (m4_ifdef results in no output). You'll have to > workaround it yourself: > > AS_IF([test x"$var" != xfalse], [$test=1], [: m4_ifdef(...)]) > > >> >> Is it the expected behaviour of AS_IF when the else part is empty? > > Yes, it's expected that autoconf can't predict which macros expand to > nothing. It's a dark corner case, where it costs far more m4 time to try > and work around it (and probably get things wrong in the process) than it > does to just say "don't do that". The better(TM) approach is to let m4 figure out that the else part is empty by not quoting the m4_ifdef, thereby deferring its evaluation. AS_IF([test x"$var" != xfalse], [$test=1], m4_ifdef([AM_CONDITIONAL], [AM_CONDITIONAL([TEST], [false])])) Should give the expected result. I haven't investigated if an additional level of quoting around [AM_CONDITIONAL([TEST], [false])], i.e. using [[AM_CONDITIONAL([TEST], [false])]] instead would improve matters in case of more complicated content. Regards, Thomas -- Thomas Jahns DKRZ GmbH, Department: Application software Deutsches Klimarechenzentrum Bundesstrae 45a D-20146 Hamburg Phone: +49-40-460094-151 Fax: +49-40-460094-270 Email: Thomas Jahns smime.p7s Description: S/MIME Cryptographic Signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: FOO_LIBS
Hello, On 09/30/13 09:56, Harlan Stenn wrote: > Any idaes how I could do this? Are there better options? I had almost the same problem where adding MPI libraries would complicate non-MPI programs in a package that had some HPC binary plus related auxiliary binaries. I then went on to write such functionality as you propose, where the check for package FOO which might depend on packages BAR and BAZ resulted in setting FOO_C_LIBS/FOO_FC_LIBS to the appropriate prefix for LIBS. Feel free to have a look at the m4 source in the tarball at https://www.dkrz.de/redmine/projects/scales-ppm/files The macros you might be interested in are dnl ACX_OPTION_SEARCH_LIBS(FUNCTION, SEARCH-LIBS, dnl [ACTION-IF-FOUND], [ACTION-IF-NOT-FOUND], [OTHER-LIBRARIES], dnl [EXTRA-FLAGS], [PREAMBLE]) dnl dnl Search for a library defining FUNC, if it's not already available. dnl Do not add said library to default LIBS output variable. dnl Use $ac_lib or $ac_res in ACTION if needed. Uses OTHER-LIBRARIES dnl unconditionally, which might provoke linker errors. and dnl ACX_OPTION_SEARCH_LIBS_MULTI(FUNCTION, SEARCH-LIBS, dnl [ACTION-IF-FOUND], [ACTION-IF-NOT-FOUND], [OTHER-LIBRARIES], dnl [EXTRA-FLAGS], [PREAMBLE], [CALL-CODE]) dnl dnl Search for a library defining FUNC, if it's not already available. dnl Do not add said library to default LIBS output variable. dnl Use $ac_lib or $ac_res in ACTION if needed. dnl dnl If CALL-CODE is present it will be compiled to make the function dnl call, otherwise AC_LANG_CALL will be used with FUNCTION as dnl argument. dnl dnl Tries first to link without any OTHER-LIBRARY, then successively dnl tries each library in the list. where [OTHER-LIBRARY] is a set of flag combinations in the second _MULTI version like might be specified as: [[-fsome-flag-for-libbar -lbar],[-Lsome-other-flag -lbaz]] The whole thing (i.e. the higher level macros using the two above) is unfortunately quite complicated (because it deals with Fortran (with INCLUDE files and module USE) and C (and could be easily extended to Fortran 77 and C++) and also emits appropriate --with-foo arguments and FOO_* argument variables. It also addresses complicated cases where some library can depend on some subset of set of libraries which in turn can have equally complicated dependencies and the package might be a multi-part where some library files are needed for a single function to work. As a side-note: All of these packages have a habit of preparing wrappers for the compiler and declare the problem thus solved. That strategy unfortunately breaks down the moment you try to use two packages simultaneously. Regards, Thomas -- Thomas Jahns DKRZ GmbH, Department: Application software Deutsches Klimarechenzentrum Bundesstraße 45a D-20146 Hamburg Phone: +49-40-460094-151 Fax: +49-40-460094-270 Email: Thomas Jahns smime.p7s Description: S/MIME Cryptographic Signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: avis-client-c: ceilf, linking with -lm
Hi, On 09/16/13 12:25, Daniel Pocock wrote: > Ubuntu error: > > /bin/bash ../../libtool --tag=CC --mode=link gcc -Wall -pedantic -pthread > -g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wformat > -Werror=format-security -lm -Wl,-Bsymbolic-functions -fPIE -pie -Wl,-z,relro > -Wl,-z,now -o tests tests.o check_messages.o check_security.o check_client.o > check_collections.o check_invoke.o check_uri.o ../../src/lib/libavis.la > ../../packages/check/src/libcheck.la > libtool: link: gcc -Wall -pedantic -pthread -g -O2 -fPIE -fstack-protector > --param=ssp-buffer-size=4 -Wformat -Werror=format-security > -Wl,-Bsymbolic-functions -fPIE -pie -Wl,-z -Wl,relro -Wl,-z -Wl,now -o > .libs/tests tests.o check_messages.o check_security.o check_client.o > check_collections.o check_invoke.o check_uri.o -lm > ../../src/lib/.libs/libavis.so ../../packages/check/src/.libs/libcheck.a > -pthread > ../../src/lib/.libs/libavis.so: undefined reference to `ceilf' > collect2: error: ld returned 1 exit status > make[4]: *** [tests] Error 1 > make[4]: Leaving directory `/tmp/buildd/avis-client-c-1.2.4/src/test' You have the order of libraries incorrect: -lm is a dependency of libavis and therefore needs to be specified afterwards. But from the launchpad page one can see that's only half the story. Anyhow: it's unrelated to autotools. Regards, Thomas -- Thomas Jahns DKRZ GmbH, Department: Application software Deutsches Klimarechenzentrum Bundesstraße 45a D-20146 Hamburg Phone: +49-40-460094-151 Fax: +49-40-460094-270 Email: Thomas Jahns smime.p7s Description: S/MIME Cryptographic Signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: fortran module name mangling
Hello, On 08/19/13 12:59, Bastien ROUCARIES wrote: > Hi did you try cfortran ? I'm a quite well versed user of cfortran.h. But with respect to calling Fortran from C it's only useful so far for external procedures, not module procedures. That's something I'd like to improve: generating module procedure names in addition to external procedure names. > I plan to modernize it, so please test it and report any error. In that case: you got mail. Regards, Thomas -- Thomas Jahns DKRZ GmbH, Department: Application software Deutsches Klimarechenzentrum Bundesstraße 45a D-20146 Hamburg Phone: +49-40-460094-151 Fax: +49-40-460094-270 Email: Thomas Jahns smime.p7s Description: S/MIME Cryptographic Signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: fortran module name mangling
Hello, On Aug 17, 2013, at 13:07 , Frederik Beaujean wrote: I want to call a subroutine in a fortran module in C++ and discovered the AC_FC_FUNC macro. It seems it does not work with fortran modules. So the result it produces is useless. For concreteness, I want to call nestRun from the multinest library defined in fortran as module Nested ... contains subroutine nestRun(...) ... end subroutine nestRun end module Nested On linux with gfortran 4.6 and autoconf 2.68, I try AC_FC_FUNC(nestRun) echo "mangled name:" $nestRun and obtain mangled name: nestrun_ but the actual name in the library is __nested_MOD_nestrun Until now, the "recommended" procedure in multinest is to manually check for either of the gnu or intel compiler and enter the mangled routine name by hand. But this is hardly portable, as I just tried it out on the old gfortran 4.2 on a mac, and the mangled name is different from the above. I'd like to collaborate on this but I only have the following compilers available to test for: - PGI versions from 9.x on - Intel versions 10.x and later - IBM XL Fortran 12.1.0.x and later - NAG 5.1 and later - SX but I have no control over the version on the system (and several versions of gfortran of course), so if one could find others with Lahey and other Fortran 90 or more modern compilers, that would be a plus. Regards, Thomas -- Thomas Jahns DKRZ GmbH, Department: Application software Deutsches Klimarechenzentrum Bundesstraße 45a D-20146 Hamburg Phone: +49-40-460094-151 Fax: +49-40-460094-270 Email: Thomas Jahns smime.p7s Description: S/MIME cryptographic signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Invocation of compiler by AC_LINK_IFELSE
On 07/18/13 12:59, Miguel Guedes wrote: > I am using AC_LANG_PROGRAM wrapped inside AC_LINK_IFELSE to test for > libboost_system and it invokes gcc/g++ in the following way: > > configure:3975: g++ -o conftest -g -O2 -lboost_system conftest.cpp > > The above results in a few errors and doesn't link even though the > library in question is present in the system. This is because the source > file should be at the front in the call to g++, e.g.: > > g++ conftest.cpp -o conftest -g -O2 -lboost_system > > What can be done to overcome this limitation? Can the parameter order be > customized somehow or perhaps some other macro be used? this is probably a user error. Would you mind showing the contents of the LIBS and LDFLAGS variables? You probably put your -lboost_system into LDFLAGS but it has to go into LIBS. Ciao, Thomas -- Thomas Jahns DKRZ GmbH, Department: Application software Deutsches Klimarechenzentrum Bundesstraße 45a D-20146 Hamburg Phone: +49-40-460094-151 Fax: +49-40-460094-270 Email: Thomas Jahns smime.p7s Description: S/MIME Cryptographic Signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: About libdir for 64-bit
On 07/17/13 22:11, Russ Allbery wrote: > Probing sizeof(long) with the configure compiler does a fairly good job > for the most common cases, which is why that's what the macro I posted > does. In particular, it works for the common cases of -m32 and -m64 on > hosts with both library paths. How does that distinguish x32 and i386? Or the n32 and o32 formats on IRIX? Regards, Thomas -- Thomas Jahns DKRZ GmbH, Department: Application software Deutsches Klimarechenzentrum Bundesstraße 45a D-20146 Hamburg Phone: +49-40-460094-151 Fax: +49-40-460094-270 Email: Thomas Jahns smime.p7s Description: S/MIME Cryptographic Signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: About libdir for 64-bit
Hello, On 07/16/13 11:23, Sergio Belkin wrote: > I have a configure.ac with following: > > AS_CASE([$host], [x86_64*|sparc64*|s390x*|ppc64*], [libdir=$prefix/lib64], > [libdir=$prefix/lib]) how does this work for users having -m32 (gcc) or -q32 (xlc) set in their compiler flags? > I'done it in order to make easy the install of package and choose the > libdir according to arch. But I've found that I can't override if I run > ./configure llibdir=/whatever and even distros like Debian put libraries in > /usr/lib//x86_64-linux-gnu > > is there a way to fix it? I couldn't propose anything. Is there even a method to reliably infer the ABI from the compiler? Regards, Thomas -- Thomas Jahns DKRZ GmbH, Department: Application software Deutsches Klimarechenzentrum Bundesstraße 45a D-20146 Hamburg Phone: +49-40-460094-151 Fax: +49-40-460094-270 Email: Thomas Jahns smime.p7s Description: S/MIME Cryptographic Signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Cross-platform availability of header files
On 03/15/2013 02:19 AM, Zack Weinberg wrote: > I've been doing research into the cross-platform availability of > header files that are commonly probed for in Autoconf scripts. > Results so far are here: > http://www.owlfolio.org/possibly-useful/notes-on-the-cross-platform-availability-of-header-files/ > Based on what I've learned, I have some questions for y'all: although you didn't ask: aio.h does not need to be probed for: unistd.h defines _POSIX_ASYNCHRONOUS_IO when it's available. See <http://pubs.opengroup.org/onlinepubs/007904875/basedefs/unistd.h.html> for some other features that don't require autoconf to check for, sys/mman.h is in the same category. With respect to your comment on identifiers with leading underscore: to be conformant to e.g. C89 standards, an implementation must not define anything without said leading underscore, but in cases where the non-standard functionality is required to implement standard-mandated functionality, it's easiest to have it available with a leading underscore. In case you still need it, I could check AIX 6.1 for any header you want to know about or provide an ls -R of /usr/include, although some of that are packaged products and e.g. aio requires the installation of an optional kernel extension package although I'm not sure if the header is available even when said package is not installed. Regards, Thomas -- Thomas Jahns DKRZ GmbH, Department: Application software Deutsches Klimarechenzentrum Bundesstraße 45a D-20146 Hamburg Phone: +49-40-460094-151 Fax: +49-40-460094-270 Email: Thomas Jahns smime.p7s Description: S/MIME Cryptographic Signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: FCLIBS do not contain objects required for AC_FC_MAIN to succeed
Hello, On 09/10/2012 04:07 PM, Thomas Jahns wrote: > Since I feel both macros should just work[1], I propose to extend > _AC_FC_LIBRARY_LDFLAGS to build two output variables instead of one: FCLIBS as > it is now and another also containing the required object files to be used for > the tests in AC_FC_MAIN. after some further thinking I feel it's perhaps even better to simply link the tests performed in AC_FC_MAIN with the Fortran linker. > I'd like to contribute a corresponding patch if the above idea seems > acceptable > for the autoconf maintainers but I'd also like to look into another solution > if > this seems more appropriate. I'd also welcome name suggestions for the > additional output variable. This offer still holds. Regards, Thomas -- Thomas Jahns DKRZ GmbH, Department: Application software Deutsches Klimarechenzentrum Bundesstraße 45a D-20146 Hamburg Phone: +49-40-460094-151 Fax: +49-40-460094-270 Email: Thomas Jahns smime.p7s Description: S/MIME Cryptographic Signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
FCLIBS do not contain objects required for AC_FC_MAIN to succeed
Hello, please notice that I focus on modern Fortran below, but all arguments are equally valid for the F77 part of the macros concerned. I encountered a bug where some Fortran compilers (ifort and nagfor to be precise) add object files to the link and AC_FC_MAIN will not find the Fortran name of the primary entry point because these are missing from FCLIBS. On the other hand AC_FC_DUMMY_MAIN requires FCLIBS to not contain the Fortran main symbol because otherwise all link tests in AC_FC_DUMMY_MAIN will fail because of multiple definition of main. I noticed this because of the following turn of events 1. Our projects creates a library of C and Fortran code to be used by both C and Fortran programs 2. Initially the library was built statically only, therefore I used AC_FC_DUMMY_MAIN and linked the C programs with the C compiler 3. Then I introduced libtool to also be able to build a shared library. Since the library contains Fortran and C code, the shared object also depends on the Fortran libraries (i.e. libraries for Fortran in addition to the Fortran run-time libraries that FCLIBS contains) and I decided to change the linking of C programs to use the Fortran compiler driver (i.e. set prog_LINK = $(FCLINK) in Makefile.am). To facilitate this switch I needed the AC_FC_MAIN check to work more reliably than currently I therefore hacked the _AC_FC_LIBRARY_LDFLAGS macro to also include .o files not matching crt*.o in FCLIBS. 4. Therefore my configure.ac ended up having both: AC_FC_MAIN and AC_FC_DUMMY_MAIN and configure runs failed for the above two compilers. Since I feel both macros should just work[1], I propose to extend _AC_FC_LIBRARY_LDFLAGS to build two output variables instead of one: FCLIBS as it is now and another also containing the required object files to be used for the tests in AC_FC_MAIN. I'd like to contribute a corresponding patch if the above idea seems acceptable for the autoconf maintainers but I'd also like to look into another solution if this seems more appropriate. I'd also welcome name suggestions for the additional output variable. Regards, Thomas Jahns [1] Independent of whether it would be a better design decision to not also have the Fortran parts in the same shared object. Separating both parts will be something I'll look into in the future but at this time too much functionality is Fortran-only to justify having a separate library for the benefit of a few C test programs only. -- Thomas Jahns DKRZ GmbH, Department: Application software Deutsches Klimarechenzentrum Bundesstraße 45a D-20146 Hamburg Phone: +49-40-460094-151 Fax: +49-40-460094-270 Email: Thomas Jahns smime.p7s Description: S/MIME Cryptographic Signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
