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

Re: Option autoconf option --debug no longer working

, 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 n

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

Re: Option autoconf option --debug no longer working

> 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_

Re: Option autoconf option --debug no longer working

ed 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 a

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

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 c

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

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

Re: automake problem with multiple "-rpath"

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 > &g

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

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

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

Patch for AC_FC_MODULE_OUTPUT_FLAG

8c7102b3706f1f5e2561d3bf63d5a5491d2d6ca8 Mon Sep 17 00:00:00 2001 From: Thomas Jahns <ja...@dkrz.de> 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.m

Swapping ac_link after LT_INIT

-- 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 ja...@dkrz.de URL:www.dkrz.de Geschäftsführer: Prof. Dr. Thomas Ludwig Sitz der

Re: What is the best/recommended technique for referencing development libraries?

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

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

Re: AC_PROG_CC wrongly setting $GCC=yes while clang is used

On 09/09/14 00:26, Russ Allbery wrote: Bastien Chevreux b...@chevreux.org 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

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

config.guess problem with pgcc

in autoconf. Regards, Thomas From 400897893790901d904663640b53cf0fd6316237 Mon Sep 17 00:00:00 2001 From: Thomas Jahns ja...@dkrz.de 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

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

Re: AC_PROG_INSTALL and AC_PROG_MKDIR_P fallbacks

it a go. Regards, Thomas From e61ebcd649a0260c9a143a5ddebfb0199581ee45 Mon Sep 17 00:00:00 2001 From: Thomas Jahns ja...@dkrz.de 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

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

Re: Testing for unknown flags in different compilers

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

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

Re: Passing -fno-lto by default?

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

Re: Empty else part in AS_IF

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 Bundesstra￟e 45a D-20146 Hamburg

Re: avis-client-c: ceilf, linking with -lm

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

Re: fortran module name mangling

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

Re: fortran module name mangling

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

Re: About libdir for 64-bit

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 ja...@dkrz.de

Re: Invocation of compiler by AC_LINK_IFELSE

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

Re: About libdir for 64-bit

. 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 ja...@dkrz.de smime.p7s

Re: Cross-platform availability of header files

. 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

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

FCLIBS do not contain objects required for AC_FC_MAIN to succeed

. 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