Re: How to speed up 'automake'
On Mon, May 23, 2022 at 1:48 PM Karl Berry wrote: > > I was going to bisect but if it doesn't fail for me in the first place... > :( > > Thanks. Indeed, reconfiguring etc. got rid of those errors. > > Now a bunch (12) of the Python tests are failing for me, presumably > because of previous Python changes not playing nicely with my older > Python version (2.7.5 on CentOS 7). Sigh. Not looking forward to > figuring that out. > > Anyway, that's surely independent of empty dependency files, > so I pushed Jan's change. Thanks! --karl Thanks, Karl. FYI, with that, all tests passed for me on Fedora 35.
Re: How to speed up 'automake'
I was going to bisect but if it doesn't fail for me in the first place... :( Thanks. Indeed, reconfiguring etc. got rid of those errors. Now a bunch (12) of the Python tests are failing for me, presumably because of previous Python changes not playing nicely with my older Python version (2.7.5 on CentOS 7). Sigh. Not looking forward to figuring that out. Anyway, that's surely independent of empty dependency files, so I pushed Jan's change. Thanks! --karl
Re: How to speed up 'automake'
> On 22 May 2022, at 02:32, Karl Berry wrote: > > Unrelated to Jan's depend.am change, but it turns out that a previous > change broke make distcheck (768 failures). I don't feel right about > committing anything else until that is fixed. > > Error below. Jim (or anyone), can you easily advise? I haven't delved > into this part of things before. (Not sure how many of the failures are > due to these errors, but I suspect most.) --thanks,karl. > > FAIL: contrib/t/multilib > .. > configure.ac:4: warning: _AM_PROG_RM_F is m4_require'd but not m4_defun'd > aclocal.m4:139: AM_INIT_AUTOMAKE is expanded from... > configure.ac:4: the top level > configure.ac:4: warning: _AM_PROG_XARGS_N is m4_require'd but not m4_defun'd > aclocal.m4:139: AM_INIT_AUTOMAKE is expanded from... > configure.ac:4: the top level > configure:2411: error: possibly undefined macro: _AM_PROG_RM_F > If this token and others are legitimate, please use m4_pattern_allow. > See the Autoconf documentation. > configure:2412: error: possibly undefined macro: _AM_PROG_XARGS_N Hm. master is OK for me: ``` PASS: contrib/t/multilib.sh [...] PASS: t/depcomp-lt-auto.tap 84 - [absolute VPATH, nostatic] make distclean Testsuite summary for GNU Automake 1.16i # TOTAL: 2988 # PASS: 2879 # SKIP: 70 # XFAIL: 39 # FAIL: 0 # XPASS: 0 # ERROR: 0 ``` I was going to bisect but if it doesn't fail for me in the first place... :( signature.asc Description: Message signed with OpenPGP
Re: How to speed up 'automake'
Unrelated to Jan's depend.am change, but it turns out that a previous change broke make distcheck (768 failures). I don't feel right about committing anything else until that is fixed. Error below. Jim (or anyone), can you easily advise? I haven't delved into this part of things before. (Not sure how many of the failures are due to these errors, but I suspect most.) --thanks,karl. FAIL: contrib/t/multilib .. configure.ac:4: warning: _AM_PROG_RM_F is m4_require'd but not m4_defun'd aclocal.m4:139: AM_INIT_AUTOMAKE is expanded from... configure.ac:4: the top level configure.ac:4: warning: _AM_PROG_XARGS_N is m4_require'd but not m4_defun'd aclocal.m4:139: AM_INIT_AUTOMAKE is expanded from... configure.ac:4: the top level configure:2411: error: possibly undefined macro: _AM_PROG_RM_F If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure:2412: error: possibly undefined macro: _AM_PROG_XARGS_N
Re: How to speed up 'automake'
Fancy doing it? Jim agreed :) Yeah, sorry. Other priority things have intervened :(. I have a mild hope of getting to it by tomorrow. If someone else wants to make the commit, certainly fine by me :). -k
Re: How to speed up 'automake'
> On 3 May 2022, at 22:57, Karl Berry wrote: > >I see no reason why mv would be so crucial. > > Hmm, I guess you're right. Thanks for the analysis. > > The purpose of the stamp files is to avoid partial files being written > (and screwing up future makes), but if the file is zero bytes, it seems > that problem cannot happen. > > Jim, do you agree? I'll install the change if yes. --thanks, karl. > Fancy doing it? Jim agreed :) Best, sam signature.asc Description: Message signed with OpenPGP
Re: How to speed up 'automake'
On Tue, May 3, 2022 at 2:57 PM Karl Berry wrote: > > I see no reason why mv would be so crucial. > > Hmm, I guess you're right. Thanks for the analysis. > > The purpose of the stamp files is to avoid partial files being written > (and screwing up future makes), but if the file is zero bytes, it seems > that problem cannot happen. > > Jim, do you agree? I'll install the change if yes. --thanks, karl. Oops. Read this after writing the longer reply. Yes. Thanks!
Re: How to speed up 'automake'
On Tue, May 3, 2022 at 3:55 PM Nick Bowler wrote: > > On 2022-05-02, Karl Berry wrote: > > - @echo '# dummy' >$@-t && $(am__mv) $@-t $@ > > + @: >>$@ > > > > 1) does it actually speed anything up? > > The answer seems to be a resounding "yes". I tried one of my packages > on an old slow PC, and changing this one line in Makefile.in cuts almost > 5 seconds off of the depfiles generation step in config.status. > > (All .deps directories manually deleted between runs as otherwise the > rule commands will not be executed). > > Before (x5): > % time config.status Makefile depfiles > real 0m15.320s > real 0m15.210s > real 0m15.210s > real 0m15.210s > real 0m15.220s > > After (x5): > % time config.status Makefile depfiles > real 0m10.650s > real 0m10.550s > real 0m10.550s > real 0m10.550s > real 0m10.650s > > That 5 seconds is a relatively small part of total configure runtime but > it is noticeable. > > So if make implementations have no problem including empty files (I tried > a few and all seem OK with it) then it seems like a win. > > > 2) without the mv I fear we are no longer noticing write failure > > I think it's OK. All shells that I know of set a failure status when > redirection fails, at least for simple commands like that. FYI, in general, the $@-t dance is not really about error detection so much as persistent-error avoidance. For most uses of this idiom, we must be careful that we don't end up with the target ($@) containing the results of an incomplete or corrupted write **AND** an up-to-date timestamp (the "persistent" part), so we update atomically only after successful result creation into $@-t. However, in this case, we don't care about the contents of that file: just the timestamp, so eliminating the intermediate $@-t is a fine move.
Re: How to speed up 'automake'
On 2022-05-02, Karl Berry wrote: > - @echo '# dummy' >$@-t && $(am__mv) $@-t $@ > + @: >>$@ > > 1) does it actually speed anything up? The answer seems to be a resounding "yes". I tried one of my packages on an old slow PC, and changing this one line in Makefile.in cuts almost 5 seconds off of the depfiles generation step in config.status. (All .deps directories manually deleted between runs as otherwise the rule commands will not be executed). Before (x5): % time config.status Makefile depfiles real 0m15.320s real 0m15.210s real 0m15.210s real 0m15.210s real 0m15.220s After (x5): % time config.status Makefile depfiles real 0m10.650s real 0m10.550s real 0m10.550s real 0m10.550s real 0m10.650s That 5 seconds is a relatively small part of total configure runtime but it is noticeable. So if make implementations have no problem including empty files (I tried a few and all seem OK with it) then it seems like a win. > 2) without the mv I fear we are no longer noticing write failure I think it's OK. All shells that I know of set a failure status when redirection fails, at least for simple commands like that. One possible gotcha is that redirections on the : command are not always reliably performed by older shells. There might not be any real world problem because configure sets SHELL in the Makefile to one that probably does not exhibit any problem. If it matters, performing the redirection with "exec" instead of ":" should work in every shell and have pretty much identical performance. Cheers, Nick
Re: How to speed up 'automake'
I see no reason why mv would be so crucial. Hmm, I guess you're right. Thanks for the analysis. The purpose of the stamp files is to avoid partial files being written (and screwing up future makes), but if the file is zero bytes, it seems that problem cannot happen. Jim, do you agree? I'll install the change if yes. --thanks, karl.
Re: How to speed up 'automake'
On Monday 2022-05-02 22:52, Karl Berry wrote: >- @echo '# dummy' >$@-t && $(am__mv) $@-t $@ >+ @: >>$@ > >2) without the mv I fear we are no longer noticing write failure. -k I see no reason why mv would be so crucial. Case 1. Lack of permission. The ">" operation is the one that fails, $? is set. mv is never executed due to &&. 09:53 f3:/etc $ >/etc/passwd bash: /etc/passwd: Permission denied 09:53 f3:/etc $ echo $? 1 (dash) $ >/etc/passwd dash: 1: cannot create /etc/passwd: Permission denied $ echo $? 2 Case 2. Disk is chock-full. The ">" operation is the one that fails, $? is set once again. 09:35 f3:/mnt $ : >>9x bash: 9x: No space left on device 09:35 f3:/mnt $ echo $? 1 (dash) $ : >>x2 dash: 5: cannot create x2: No space left on device $ echo $? 2 Case 3. ">" succeeds and the disk becomes full while "echo" executes. (bash builtin) 09:56 f3:/mnt $ echo foo >x9; echo $? bash: echo: write error: No space left on device 1 (dash builtin) $ echo foo >x9; echo $? dash: 1: echo: echo: I/O error 1 (separate program) $ /bin/echo foo >x9; echo $? /bin/echo: write error: No space left on device 1 >1) does it actually speed anything up? I created a dummy project with 50001 dummy .c files on short order. On i5-1135G7 CPU with bash, ./configure runs in (unscientifically measured) 144s wall seoncds. After modifying the innards of Makefile.in with the proposed change, ./configure now runs in 101s.
Re: How to speed up 'automake'
- @echo '# dummy' >$@-t && $(am__mv) $@-t $@ + @: >>$@ 1) does it actually speed anything up? 2) without the mv I fear we are no longer noticing write failure. -k
Re: How to speed up 'automake'
On Monday 2022-05-02 15:31, Jan Engelhardt wrote: >> If empty files are ok (assuming they are needed at all), can they be produced >> with a minimum number of executions of a 'touch' command? > >Better yet, they can be produced with the ">>" shell builtin, skipping >spawning the touch program. (We need to use >>, because > truncates, >and configure does not truncate deps files for a good reason - doing >so would be like `make clean`) touch wasn't even used. but mv was, which should become redundant too. (The use '>' with 'mv' may have to do with desires for atomicity reasons when you do make -j) diff --git a/lib/am/depend.am b/lib/am/depend.am index ecc6180a6..3a493c3de 100644 --- a/lib/am/depend.am +++ b/lib/am/depend.am @@ -18,7 +18,7 @@ am__mv = mv -f $(am__depfiles_remade): @$(MKDIR_P) $(@D) - @echo '# dummy' >$@-t && $(am__mv) $@-t $@ + @: >>$@ am--depfiles: $(am__depfiles_remade) .PHONY: am--depfiles
Re: How to speed up 'automake'
On May 2, 2022, at 15:07 , Jan Engelhardt wrote: > > > On Monday 2022-05-02 14:20, Thomas Jahns wrote: > Is there a way to speed 'automake' up? [...let] ephemeral builds [..] use /dev/shm [...] >>> >>> There ought to be little difference [...] automake, that's nowhere near as >>> IO-heavy as untarring kernel source archives. It's much more a CPU-bound >>> task. >> >> I found tmpfs to be faster when there were multiple smallish (less than an fs >> block) writes to the same file, particularly by different programs. This may >> be more important in the context of all autotools taken together than >> automake >> alone. Also not all file systems take full advantage of all methods to >> prevent >> the system from hitting disk like XFS does, i.e. results depend on what you >> compare to. > > But you're just acknowledging that the slowness comes from the _fs_, are you > not? Yes, sure, I was expclity stating in my initial reply that using tmpfs might not be what the OP asked for but instead what might actually solve their problem of slow builds. I also like having programs make efficient use of system resources, but sometimes throwing machine resources at a problem can be the most appropriate course of action. > Indeed, if a source code package consists of 1 files, then configure > produces another 10k files for the stuff in the ".deps" directories. > There is not much autotooling can do here, as I believe pregenerating > those 10k files all with "# dummy" content is to support the least common > demoniator of /usr/bin/make. > > I wonder, rather than emitting those 8 bytes to .Po/.Plo/.Tpo/etc. files, > could > we emit 0 bytes instead? Then filesystems would have to write only the inode > and forego extent allocation for the data portion (and save some disk space > too, as each 8-byte file in practice reserves something like 4K on > non-packing/non-compressing filesystems). That might be something to investigate: could autoconf detect GNU parallel and call config.status in some way that automatically creates multiple instances? Running config.status is usually not the longest part of an autoconf run but one that might be reasonably simple to parallelize. Thomas smime.p7s Description: S/MIME cryptographic signature
Re: How to speed up 'automake'
On Monday 2022-05-02 15:18, Bob Friesenhahn wrote: > On Mon, 2 May 2022, Jan Engelhardt wrote: >> >> Indeed, if a source code package consists of 1 files, then configure >> produces another 10k files for the stuff in the ".deps" directories. >> There is not much autotooling can do here, as I believe pregenerating >> those 10k files all with "# dummy" content is to support the least common >> demoniator of /usr/bin/make. > > In a configure script I see the option: > > --disable-dependency-tracking > speeds up one-time build > > so what tangible benefits does --disable-dependency-tracking actually provide? I remember that option. That disables .deps entirely or so. Distributions, including openSUSE use it because they (barring exceptional circumstances) do not modify (non-BUILT_SOURCES) source files between two invocations of make. Great for the ephmereal build root that was initially talked about, not so cool for developers that switch between editor and compiler every so often :) > If empty files are ok (assuming they are needed at all), can they be produced > with a minimum number of executions of a 'touch' command? Better yet, they can be produced with the ">>" shell builtin, skipping spawning the touch program. (We need to use >>, because > truncates, and configure does not truncate deps files for a good reason - doing so would be like `make clean`)
Re: How to speed up 'automake'
On Mon, 2 May 2022, Jan Engelhardt wrote: Indeed, if a source code package consists of 1 files, then configure produces another 10k files for the stuff in the ".deps" directories. There is not much autotooling can do here, as I believe pregenerating those 10k files all with "# dummy" content is to support the least common demoniator of /usr/bin/make. In a configure script I see the option: --enable-dependency-tracking do not reject slow dependency extractors --disable-dependency-tracking speeds up one-time build so what tangible benefits does --disable-dependency-tracking actually provide? If empty files are ok (assuming they are needed at all), can they be produced with a minimum number of executions of a 'touch' command? 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 speed up 'automake'
On Monday 2022-05-02 14:20, Thomas Jahns wrote: Is there a way to speed 'automake' up? >>> >>> [...let] ephemeral builds [..] use /dev/shm [...] >> >> There ought to be little difference [...] automake, that's nowhere near as >> IO-heavy as untarring kernel source archives. It's much more a CPU-bound >> task. > >I found tmpfs to be faster when there were multiple smallish (less than an fs >block) writes to the same file, particularly by different programs. This may >be more important in the context of all autotools taken together than automake >alone. Also not all file systems take full advantage of all methods to prevent >the system from hitting disk like XFS does, i.e. results depend on what you >compare to. But you're just acknowledging that the slowness comes from the _fs_, are you not? Anyway... Indeed, if a source code package consists of 1 files, then configure produces another 10k files for the stuff in the ".deps" directories. There is not much autotooling can do here, as I believe pregenerating those 10k files all with "# dummy" content is to support the least common demoniator of /usr/bin/make. I wonder, rather than emitting those 8 bytes to .Po/.Plo/.Tpo/etc. files, could we emit 0 bytes instead? Then filesystems would have to write only the inode and forego extent allocation for the data portion (and save some disk space too, as each 8-byte file in practice reserves something like 4K on non-packing/non-compressing filesystems).
Re: How to speed up 'automake'
> On Apr 30, 2022, at 01:31 , Jan Engelhardt wrote: > > On Friday 2022-04-29 22:59, Thomas Jahns wrote: >> On 4/27/22 3:49 PM, R. Diez wrote: >>> Is there a way to speed 'automake' up? >> >> While you are probably looking for system-independent advice, the best >> results >> I've had with speeding up ephemeral builds is to simply use /dev/shm for >> backing storage on Linux, i.e. first try to put build directories there >> ($XDG_RUNTIME_DIR is also fine on modern Linux). If the installation is not >> needed later on, you can also put the installation path there. > > There ought to be little difference, both use the page cache, except > that using tmpfs carries the usual volatility risks (not backed by a > real device, susceptible to power loss, etc., blocks other serious > processes from using resources, and tmpfs objects may get moved to > swapspace, which isn't great at all considering you get to pick up > pieces from the swap partition in the event of a power loss.) > > tmpfs may be interesting from a psychological point of view and/or > when there are a *lot* of files. But automake, that's nowhere near as > IO-heavy as untarring kernel source archives. It's much more > a CPU-bound task. Very much depends on what the programs do: I found tmpfs to be faster when there were multiple smallish (less than an fs block) writes to the same file, particularly by different programs. This may be more important in the context of all autotools taken together than automake alone. Also not all file systems take full advantage of all methods to prevent the system from hitting disk like XFS does, i.e. results depend on what you compare to. Thomas smime.p7s Description: S/MIME cryptographic signature
Re: How to speed up 'automake'
automake --verbose --warnings=all --add-missing --copy Since you're talking about cron, I'm guessing the terminal output is being redirected to a file? Because if it's going to an actual tty, that can consume a surprising amount of time. Is there a way to speed 'automake' up? Only real idea I have is to run automake under the Perl profiler and see what comes up. As in, install Devel::NYTProf from CPAN and then run perl -d:NYTProf /path/to/automake/executable Best, Karl
Re: How to speed up 'automake'
On Friday 2022-04-29 22:59, Thomas Jahns wrote: > On 4/27/22 3:49 PM, R. Diez wrote: >> Is there a way to speed 'automake' up? > > While you are probably looking for system-independent advice, the best results > I've had with speeding up ephemeral builds is to simply use /dev/shm for > backing storage on Linux, i.e. first try to put build directories there > ($XDG_RUNTIME_DIR is also fine on modern Linux). If the installation is not > needed later on, you can also put the installation path there. There ought to be little difference, both use the page cache, except that using tmpfs carries the usual volatility risks (not backed by a real device, susceptible to power loss, etc., blocks other serious processes from using resources, and tmpfs objects may get moved to swapspace, which isn't great at all considering you get to pick up pieces from the swap partition in the event of a power loss.) tmpfs may be interesting from a psychological point of view and/or when there are a *lot* of files. But automake, that's nowhere near as IO-heavy as untarring kernel source archives. It's much more a CPU-bound task.
Re: How to speed up 'automake'
On 4/27/22 3:49 PM, R. Diez wrote: Is there a way to speed 'automake' up? While you are probably looking for system-independent advice, the best results I've had with speeding up ephemeral builds is to simply use /dev/shm for backing storage on Linux, i.e. first try to put build directories there ($XDG_RUNTIME_DIR is also fine on modern Linux). If the installation is not needed later on, you can also put the installation path there. This assumes your development system has a few GB of RAM to spare, but nowadays RAM is cheap. Thomas smime.p7s Description: S/MIME Cryptographic Signature
Re: How to speed up 'automake'
> That is why I am looking at speeding up the Autotools steps. > > When I run this command, I get the following trace: > > time automake --verbose --warnings=all --add-missing --copy > … > automake: thread 0: creating Makefile.in > > real 0m0,684s > user 0m0,621s > sys 0m0,085s > > It takes almost 0.7 seconds to generate the makefile The manual is providing the following information. “… Generate Makefile.in for configure from Makefile.am. …” > for a rather small project: around 50 .c and .cpp files, some of them in a > library, no libtool or anything fancy. Larger projects take longer. I suggest to take further looks at corresponding software run time characteristics. Can the command parameter “--verbose” (and tracing) be omitted for other program executions? > Is there a way to speed 'automake' up? Some software design possibilities might still be applicable. How many efforts would you like to invest for desirable improvements? Regards, Markus
How to speed up 'automake'
Hi all:
I have this cross-compiling Autoconf/Automake project:
https://github.com/rdiez/JtagDue/tree/master/Project
This is just an example project, I have others that are bigger, and I rebuild
many of them automatically overnight. That is why I am looking at speeding up
the Autotools steps.
When I run this command, I get the following trace:
time automake --verbose --warnings=all --add-missing --copy
automake: thread 0: running WARNINGS=none autoconf
--trace=AC_CANONICAL_BUILD:\$f:\$l::\$d::\$n::\${::}%
--trace=AC_CANONICAL_HOST:\$f:\$l::\$d::\$n::\${::}%
--trace=AC_CANONICAL_TARGET:\$f:\$l::\$d::\$n::\${::}%
--trace=AC_CONFIG_AUX_DIR:\$f:\$l::\$d::\$n::\${::}%
--trace=AC_CONFIG_FILES:\$f:\$l::\$d::\$n::\${::}%
--trace=AC_CONFIG_HEADERS:\$f:\$l::\$d::\$n::\${::}%
--trace=AC_CONFIG_LIBOBJ_DIR:\$f:\$l::\$d::\$n::\${::}%
--trace=AC_CONFIG_LINKS:\$f:\$l::\$d::\$n::\${::}%
--trace=AC_FC_SRCEXT:\$f:\$l::\$d::\$n::\${::}%
--trace=AC_INIT:\$f:\$l::\$d::\$n::\${::}%
--trace=AC_LIBSOURCE:\$f:\$l::\$d::\$n::\${::}%
--trace=AC_REQUIRE_AUX_FILE:\$f:\$l::\$d::\$n::\${::}%
--trace=AC_SUBST_TRACE:\$f:\$l::\$d::\$n::\${::}%
--trace=AM_AUTOMAKE_VERSION:\$f:\$l::\$d::\$n::\${::}%
--trace=AM_CONDITIONAL:\$f:\$l::\$d::\$n::\${::}%
--trace=AM_EXTRA_RECURSIVE_TARGETS:\$f:\$l::\$d::\$n::\${::}%
--trace=AM_GNU_GETTEXT:\$f:\$l::\$d::\$n::\${::}%
--trace=AM_GNU_GETTEXT_INTL_SUBDIR:\$f:\$l::\$d::\$n::\${::}%
--trace=AM_INIT_AUTOMAKE:\$f:\$l::\$d::\$n::\${::}%
--trace=AM_MAINTAINER_MODE:\$f:\$l::\$d::\$n::\${::}%
--trace=AM_PROG_AR:\$f:\$l::\$d::\$n::\${::}%
--trace=AM_PROG_MKDIR_P:\$f:\$l::\$d::\$n::\${::}%
--trace=LT_SUPPORTED_TAG:\$f:\$l::\$d::\$n::\${::}%
--trace=_AM_COND_ELSE:\$f:\$l::\$d::\$n::\${::}%
--trace=_AM_COND_ENDIF:\$f:\$l::\$d::\$n::\${::}%
--trace=_AM_COND_IF:\$f:\$l::\$d::\$n::\${::}%
--trace=_AM_SUBST_NOTMAKE:\$f:\$l::\$d::\$n::\${::}%
--trace=_LT_AC_TAGCONFIG:\$f:\$l::\$d::\$n::\${::}%
--trace=m4_include:\$f:\$l::\$d::\$n::\${::}%
--trace=m4_sinclude:\$f:\$l::\$d::\$n::\${::}%
--trace=sinclude:\$f:\$l::\$d::\$n::\${::}%
automake: thread 0: reading
/home/rdiez/rdiez/LocalSoftware/Autotools/autoconf-2.71-automake-1.16.5-libtool-2.4.6-bin/share/automake-1.16/am/header-vars.am
automake: thread 0: reading Makefile.am
automake: thread 0: reading
/home/rdiez/rdiez/LocalSoftware/Autotools/autoconf-2.71-automake-1.16.5-libtool-2.4.6-bin/share/automake-1.16/am/configure.am
automake: thread 0: reading
/home/rdiez/rdiez/LocalSoftware/Autotools/autoconf-2.71-automake-1.16.5-libtool-2.4.6-bin/share/automake-1.16/am/progs.am
automake: thread 0: reading
/home/rdiez/rdiez/LocalSoftware/Autotools/autoconf-2.71-automake-1.16.5-libtool-2.4.6-bin/share/automake-1.16/am/libs.am
automake: thread 0: reading
/home/rdiez/rdiez/LocalSoftware/Autotools/autoconf-2.71-automake-1.16.5-libtool-2.4.6-bin/share/automake-1.16/am/library.am
automake: thread 0: reading
/home/rdiez/rdiez/LocalSoftware/Autotools/autoconf-2.71-automake-1.16.5-libtool-2.4.6-bin/share/automake-1.16/am/program.am
automake: thread 0: reading
/home/rdiez/rdiez/LocalSoftware/Autotools/autoconf-2.71-automake-1.16.5-libtool-2.4.6-bin/share/automake-1.16/am/compile.am
automake: thread 0: reading
/home/rdiez/rdiez/LocalSoftware/Autotools/autoconf-2.71-automake-1.16.5-libtool-2.4.6-bin/share/automake-1.16/am/depend.am
automake: thread 0: reading
/home/rdiez/rdiez/LocalSoftware/Autotools/autoconf-2.71-automake-1.16.5-libtool-2.4.6-bin/share/automake-1.16/am/depend2.am
automake: thread 0: Sources ending in .S become .o
automake: thread 0: Sources ending in .S become .obj
automake: thread 0: reading
/home/rdiez/rdiez/LocalSoftware/Autotools/autoconf-2.71-automake-1.16.5-libtool-2.4.6-bin/share/automake-1.16/am/lang-compile.am
automake: thread 0: Sources ending in .c become .o
automake: thread 0: Sources ending in .c become .obj
automake: thread 0: Sources ending in .cpp become .o
automake: thread 0: Sources ending in .cpp become .obj
automake: thread 0: reading
/home/rdiez/rdiez/LocalSoftware/Autotools/autoconf-2.71-automake-1.16.5-libtool-2.4.6-bin/share/automake-1.16/am/texinfos.am
automake: thread 0: reading
/home/rdiez/rdiez/LocalSoftware/Autotools/autoconf-2.71-automake-1.16.5-libtool-2.4.6-bin/share/automake-1.16/am/data.am
automake: thread 0: reading
/home/rdiez/rdiez/LocalSoftware/Autotools/autoconf-2.71-automake-1.16.5-libtool-2.4.6-bin/share/automake-1.16/am/inst-vars.am
automake: thread 0: reading
/home/rdiez/rdiez/LocalSoftware/Autotools/autoconf-2.71-automake-1.16.5-libtool-2.4.6-bin/share/automake-1.16/am/tags.am
automake: thread 0: reading
/home/rdiez/rdiez/LocalSoftware/Autotools/autoconf-2.71-automake-1.16.5-libtool-2.4.6-bin/share/automake-1.16/am/distdir.am
automake: thread 0: reading
/home/rdiez/rdiez/LocalSoftware/Autotools/autoconf-2.71-automake-1.16.5-libtool-2.4.6-bin/share/automake-1.16/am/footer.am
automake: thread 0: reading
