Re: automake compile problems
Hi Eric,
Thank you for your continued support and patience here.
I note you say : [top-posting is a bit harder to read on a technical list, so
I'll stick
with the easier-to-read inline posting] -- and I agree - but via hotmail I am
not sure how to actually make it easier to respond inline, apologies!
I took the prebuilt tar, ftpd it up to my machine, configure ran, then I ran
make. The result was :
nano-2.9.7: >make
CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh
/workarea/source/nanopre/nano-2.9.7/missing aclocal-1.15 -I m4
aclocal-1.15: /workarea/source/nanopre/nano-2.9.7/missing 81: FSUM7351 not found
WARNING: 'aclocal-1.15' is missing on your system.
You should only need it if you modified 'acinclude.m4' or
'configure.ac' or m4 files included by 'configure.ac'.
The 'aclocal' program is part of the GNU Automake package:
<http://www.gnu.org/software/automake>
It also requires GNU Autoconf, GNU m4 and Perl in order to run:
<http://www.gnu.org/software/autoconf>
<http://www.gnu.org/software/m4/>
<http://www.perl.org/>
FSUM8226 make: Error code 127
make: './aclocal.m4' removed.
As you can see, it seems to want automake 1.15 or higher, and I only have 1.10.
Why is make this way round still requiring aclocal 1.15?
Thanks again,
Andy
From: Eric Blake
Sent: 30 May 2018 20:51
To: Andy Armstrong; automake@gnu.org
Subject: Re: automake compile problems
On 05/30/2018 02:23 PM, Andy Armstrong wrote:
> Hi Eric,
[top-posting is a bit harder to read on a technical list, so I'll stick
with the easier-to-read inline posting]
>
>
> That could well be a far better approach. I am not sure how to perform cross
> platform builds, especially taking into account the interesting platform
> uniqueness such as codepage etc.
I'm not proposing cross-building (which is indeed a possibility, but a
much more technically challenging one to get correct, so it's never my
first suggestion), so much as having two machines:
- development machine: has autotools installed, has nano.git
[https://git.savannah.gnu.org/cgit/nano.git] checked out (or however you
are currently trying to build the latest nano); probably GNU/Linux, and
most likely using ASCII encoding
- build machine: your mainframe with EBCDIC encoding
On the development machine, run all of the prep steps, including any
required 'autoconf' and 'automake' steps, prior to './configure && make
dist', which creates nano-$vers.tar.$suff (where $suff is typically .gz
or .xz, depending on what compression the developers liked)
Then copy nano-*tar* file to the build machine (whether by ftp, or by a
shared network drive, or by whatever other means you have at your disposal)
Then on the build machine, unpack the tarball (perhaps involving some dd
invocations to transliterate from ASCII to EBCDIC as needed - but do so
in a manner which preserves timestamps - I honestly don't know what
steps are required in transferring an ASCII-encoded tarball into use on
an EBCDIC machine)
Now, on the build machine, you only have to type './configure && make';
you don't have to run autoconf or automake (well, as long as you didn't
mess up timestamps such that make thinks configure.ac is newer than
configure, or some similar spurious change in dependency).
In fact, the parts about the development machine have often already
taken place without requiring you to anything:
https://ftp.gnu.org/gnu/nano/ includes nano-2.9.7.tar.xz, which was
built precisely in the same manner that you would build it, by a
developer who had autotools on their machine and ultimately ran 'make dist'.
So, rather than building from nano.git, just build the pre-built tarball.
> I have not used the 'make dist' argument before, but it would prerequisite
> that I chose the appropriate configure and make arguments to compile for the
> platform I am targeting.thoughts?
'make dist' is SUPPOSED to produce an idempotent and complete tarball
(modulo noise like changes in timestamps), independent of what configure
options you used (if it doesn't, that's a bug in the particular package
you are trying to build). 'make distcheck' tries to check that this is
actually the case, by forcefully creating a tarball, faking a PATH with
no autotools, and performing a VPATH build from the tarball, to exercise
what an end user without autotools is likely to encounter (not all
developers use 'make distcheck' the way they should, but it's part of
the GNU Coding Standards, and automake tries to promote it for developers).
> I am not even sure of the official 'name' of the system I am targeting? s390?
> omvs? To be clear, I am targeting USS on zSystems, not Linux on z. Thoughts?
> Best practices?
Running config.guess (which is included in many different tarballs,
again because automake finds it useful) should give
Re: automake compile problems
On 05/30/2018 02:23 PM, Andy Armstrong wrote: Hi Eric, [top-posting is a bit harder to read on a technical list, so I'll stick with the easier-to-read inline posting] That could well be a far better approach. I am not sure how to perform cross platform builds, especially taking into account the interesting platform uniqueness such as codepage etc. I'm not proposing cross-building (which is indeed a possibility, but a much more technically challenging one to get correct, so it's never my first suggestion), so much as having two machines: - development machine: has autotools installed, has nano.git [https://git.savannah.gnu.org/cgit/nano.git] checked out (or however you are currently trying to build the latest nano); probably GNU/Linux, and most likely using ASCII encoding - build machine: your mainframe with EBCDIC encoding On the development machine, run all of the prep steps, including any required 'autoconf' and 'automake' steps, prior to './configure && make dist', which creates nano-$vers.tar.$suff (where $suff is typically .gz or .xz, depending on what compression the developers liked) Then copy nano-*tar* file to the build machine (whether by ftp, or by a shared network drive, or by whatever other means you have at your disposal) Then on the build machine, unpack the tarball (perhaps involving some dd invocations to transliterate from ASCII to EBCDIC as needed - but do so in a manner which preserves timestamps - I honestly don't know what steps are required in transferring an ASCII-encoded tarball into use on an EBCDIC machine) Now, on the build machine, you only have to type './configure && make'; you don't have to run autoconf or automake (well, as long as you didn't mess up timestamps such that make thinks configure.ac is newer than configure, or some similar spurious change in dependency). In fact, the parts about the development machine have often already taken place without requiring you to anything: https://ftp.gnu.org/gnu/nano/ includes nano-2.9.7.tar.xz, which was built precisely in the same manner that you would build it, by a developer who had autotools on their machine and ultimately ran 'make dist'. So, rather than building from nano.git, just build the pre-built tarball. I have not used the 'make dist' argument before, but it would prerequisite that I chose the appropriate configure and make arguments to compile for the platform I am targeting.thoughts? 'make dist' is SUPPOSED to produce an idempotent and complete tarball (modulo noise like changes in timestamps), independent of what configure options you used (if it doesn't, that's a bug in the particular package you are trying to build). 'make distcheck' tries to check that this is actually the case, by forcefully creating a tarball, faking a PATH with no autotools, and performing a VPATH build from the tarball, to exercise what an end user without autotools is likely to encounter (not all developers use 'make distcheck' the way they should, but it's part of the GNU Coding Standards, and automake tries to promote it for developers). I am not even sure of the official 'name' of the system I am targeting? s390? omvs? To be clear, I am targeting USS on zSystems, not Linux on z. Thoughts? Best practices? Running config.guess (which is included in many different tarballs, again because automake finds it useful) should give the 'official' name of your system, at least in terms that the autotools cater to. Admittedly, very few people use USS on zSystems while ALSO trying to use lots of GNU software, so it's highly likely that you have a LOT of non-portable assumptions to overcome when porting open source software to your platform (such as the 10-year-old autoconf bug you just reported, where we regressed from something that worked to something that tickles a latent bug in m4's eval that has been present even longer). And actually fixing those bugs may require patching configure.ac or Makefile.am, at which point the 2-machine approach requires making the tweak, rerunning 'make dist', and copying over the new tarball for each tweak you want to test. But having the separation between devel and build machine, even if it involves a lot of iterative copying, may still be easier than trying to have the build machine BE the development machine, where you have to get an entire ecosystem of software running before you can directly build from git instead of from tarballs. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
Re: automake compile problems
Hi Eric, That could well be a far better approach. I am not sure how to perform cross platform builds, especially taking into account the interesting platform uniqueness such as codepage etc. I have not used the 'make dist' argument before, but it would prerequisite that I chose the appropriate configure and make arguments to compile for the platform I am targeting.thoughts? I am not even sure of the official 'name' of the system I am targeting? s390? omvs? To be clear, I am targeting USS on zSystems, not Linux on z. Thoughts? Best practices? Andy From: Eric Blake Sent: 30 May 2018 18:01 To: Andy Armstrong; automake@gnu.org Subject: Re: automake compile problems On 05/30/2018 11:12 AM, Andy Armstrong wrote: > To give some context to what I am doing, here is the timeline: > > > I did have Automake version 1.10, but my ultimate goal here is to compile the > nano text editor, which requires at least automake 1.15 and autoconf 2.69. That's if you are modifying the source files and actually developing nano on your mainframe. But what's wrong with the (often simpler) approach of using a more typical development box, probably using GNU/Linux, with modern autotools already installed, and running 'make dist' on the nano package there, then copying the tarball over? Once you've done that, './configure && make' should work without requiring either automake or autoconf installed on the mainframe. After all, the point of the autotools is to build self-contained tarballs that no longer require the presence of the autotools. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
Re: automake compile problems
On 05/30/2018 11:12 AM, Andy Armstrong wrote: To give some context to what I am doing, here is the timeline: I did have Automake version 1.10, but my ultimate goal here is to compile the nano text editor, which requires at least automake 1.15 and autoconf 2.69. That's if you are modifying the source files and actually developing nano on your mainframe. But what's wrong with the (often simpler) approach of using a more typical development box, probably using GNU/Linux, with modern autotools already installed, and running 'make dist' on the nano package there, then copying the tarball over? Once you've done that, './configure && make' should work without requiring either automake or autoconf installed on the mainframe. After all, the point of the autotools is to build self-contained tarballs that no longer require the presence of the autotools. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
Re: automake compile problems
Hi Eric, This is on USS (Unix System Services part of an IBM Mainframe). Make is indeed the version shipped with the vendor as seen below: make -V make - Version z/OS Shell and Utilities v2.3 Built-in Rules (cannot be changed): OS:=OPENMVS .IMPORT .IGNORE : ROOTDIR .MAKEFILES:makefile Makefile .SOURCE : .NULL @B = $(@:b) @D = $(@:d) @F = $(@:f) %B = $(%:b) %D = $(%:d) %F = $(%:f) *B = $(*:b) *D = $(*:d) *F = $(*:f) Sent: 30 May 2018 15:13 To: Andy Armstrong; automake@gnu.org Subject: Re: automake compile problems On 05/30/2018 04:07 AM, Andy Armstrong wrote: > Hi all, > > > I want to compile version 1.16 of automake. On which system? > > > I run ./configure, which creates the Makefile. I run 'make' which results in > the following: > > > automake-1.16: >make > make: Makefile: line 3012: Warning -- FSUM9432 Duplicate entry > [t/get-sysconf.sh] in target list That's not GNU make. What version and vendor of make is it? It may mean that automake has regressed, and is no longer outputting makefiles that are portable to your specific make binary. But that's just a warning. Is there an actual failure? > make: Makefile: line 3189: Warning -- FSUM9433 Duplicate entry [lib/ylwrap] > in prerequisite list > @rm -f ./m4/amversion.m4-t ./m4/amversion.m4 > make: Error -- @rm: EDC5129I No such file or directory. > FSUM8226 make: Error code -1 Okay, that's an actual failure, but it's not obvious on what the context is that might have caused it. Is there an earlier version of automake that built on your platform? Does using GNU make instead of your vendor's default make let you get further? -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
Re: automake compile problems
On Wed, 30 May 2018, Eric Blake wrote: On 05/30/2018 04:07 AM, Andy Armstrong wrote: Hi all, I want to compile version 1.16 of automake. On which system? Must be IBM, and perhaps z/OS: https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.bpxa800/fsum9432.htm Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: automake compile problems
On 05/30/2018 04:07 AM, Andy Armstrong wrote: Hi all, I want to compile version 1.16 of automake. On which system? I run ./configure, which creates the Makefile. I run 'make' which results in the following: automake-1.16: >make make: Makefile: line 3012: Warning -- FSUM9432 Duplicate entry [t/get-sysconf.sh] in target list That's not GNU make. What version and vendor of make is it? It may mean that automake has regressed, and is no longer outputting makefiles that are portable to your specific make binary. But that's just a warning. Is there an actual failure? make: Makefile: line 3189: Warning -- FSUM9433 Duplicate entry [lib/ylwrap] in prerequisite list @rm -f ./m4/amversion.m4-t ./m4/amversion.m4 make: Error -- @rm: EDC5129I No such file or directory. FSUM8226 make: Error code -1 Okay, that's an actual failure, but it's not obvious on what the context is that might have caused it. Is there an earlier version of automake that built on your platform? Does using GNU make instead of your vendor's default make let you get further? -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
automake compile problems
Hi all, I want to compile version 1.16 of automake. I run ./configure, which creates the Makefile. I run 'make' which results in the following: automake-1.16: >make make: Makefile: line 3012: Warning -- FSUM9432 Duplicate entry [t/get-sysconf.sh] in target list make: Makefile: line 3012: Warning -- FSUM9432 Duplicate entry [t/pm/Cond2.pl] in target list make: Makefile: line 3012: Warning -- FSUM9432 Duplicate entry [t/pm/Cond3.pl] in target list make: Makefile: line 3012: Warning -- FSUM9432 Duplicate entry [t/pm/Condition.pl] in target list make: Makefile: line 3012: Warning -- FSUM9432 Duplicate entry [t/pm/Condition-t.pl] in target list make: Makefile: line 3012: Warning -- FSUM9432 Duplicate entry [t/pm/DisjCon2.pl] in target list make: Makefile: line 3012: Warning -- FSUM9432 Duplicate entry [t/pm/DisjCon3.pl] in target list make: Makefile: line 3012: Warning -- FSUM9432 Duplicate entry [t/pm/DisjConditions.pl] in target list make: Makefile: line 3012: Warning -- FSUM9432 Duplicate entry [t/pm/DisjConditions-t.pl] in target list make: Makefile: line 3012: Warning -- FSUM9432 Duplicate entry [t/pm/Version.pl] in target list make: Makefile: line 3012: Warning -- FSUM9432 Duplicate entry [t/pm/Version2.pl] in target list make: Makefile: line 3012: Warning -- FSUM9432 Duplicate entry [t/pm/Version3.pl] in target list make: Makefile: line 3012: Warning -- FSUM9432 Duplicate entry [t/pm/Wrap.pl] in target list make: Makefile: line 3012: Warning -- FSUM9432 Duplicate entry [t/instspc.tap] in target list make: Makefile: line 3012: Warning -- FSUM9432 Duplicate entry [t/aclocal.sh] in target list make: Makefile: line 3012: Warning -- FSUM9432 Duplicate entry [t/aclocal-I-order-1.sh] in target list make: Makefile: line 3012: Warning -- FSUM9432 Duplicate entry [t/aclocal-I-order-2.sh] in target list make: Makefile: line 3012: Warning -- FSUM9432 Duplicate entry [t/aclocal-I-order-3.sh] in target list make: Makefile: line 3012: Warning -- FSUM9432 Duplicate entry [t/aclocal-I-and-install.sh] in target list make: Makefile: line 3012: Warning -- FSUM9432 Duplicate entry [t/aclocal-acdir.sh] in target list make: Makefile: line 3012: Warning -- FSUM9432 Duplicate entry [t/aclocal-amflags.sh] in target list make: Makefile: line 3012: Warning -- FSUM9432 Duplicate entry [t/aclocal-autoconf-version-check.sh] in target list make: Makefile: line 3012: Warning -- FSUM9432 Duplicate entry [t/aclocal-comments-respected.sh] in target list make: Makefile: line 3012: Warning -- FSUM9432 Duplicate entry [t/aclocal-deleted-header-aclocal-amflags.sh] in target list make: Makefile: line 3012: Warning -- FSUM9432 Duplicate entry [t/aclocal-deleted-header.sh] in target list make: Makefile: line 3012: Warning -- FSUM9432 Duplicate entry [t/aclocal-deps-subdir.sh] in target list make: Makefile: line 3012: Warning -- FSUM9432 Duplicate entry [t/aclocal-deps.sh] in target list make: Makefile: line 3012: Warning -- FSUM9432 Duplicate entry [t/aclocal-dirlist.sh] in target list make: Makefile: line 3012: Warning -- FSUM9432 Duplicate entry [t/aclocal-dirlist-globbing.sh] in target list make: Makefile: line 3012: Warning -- FSUM9432 Duplicate entry [t/aclocal-dirlist-abspath.sh] in target list make: Makefile: line 3012: Warning -- FSUM9432 Duplicate entry [t/aclocal-install-absdir.sh] in target list make: Makefile: line 3012: Warning -- FSUM9432 Duplicate entry [t/aclocal-install-fail.sh] in target list make: Makefile: line 3012: Warning -- FSUM9432 Duplicate entry [t/aclocal-install-mkdir.sh] in target list make: Makefile: line 3012: Warning -- FSUM9432 Duplicate entry [t/aclocal-m4-include-are-scanned-aclocal-amflags.sh] in target list make: Makefile: line 3012: Warning -- FSUM9432 Duplicate entry [t/aclocal-m4-include-are-scanned.sh] in target list make: Makefile: line 3012: Warning -- FSUM9432 Duplicate entry [t/aclocal-m4-sinclude.sh] in target list make: Makefile: line 3012: Warning -- FSUM9432 Duplicate entry [t/aclocal-macrodir.tap] in target list make: Makefile: line 3012: Warning -- FSUM9432 Duplicate entry [t/aclocal-macrodirs.tap] in target list make: Makefile: line 3012: Warning -- FSUM9432 Duplicate entry [t/aclocal-missing-macros.sh] in target list make: Makefile: line 3012: Warning -- FSUM9432 Duplicate entry [t/aclocal-no-extra-scan.sh] in target list make: Makefile: line 3012: Warning -- FSUM9432 Duplicate entry [t/aclocal-no-force.sh] in target list make: Makefile: line 3012: Warning -- FSUM9432 Duplicate entry [t/aclocal-no-install-no-mkdir.sh] in target list make: Makefile: line 3012: Warning -- FSUM9432 Duplicate entry [t/aclocal-no-symlinked-overwrite.sh] in target list make: Makefile: line 3012: Warning -- FSUM9432 Duplicate entry [t/aclocal-no-unused-required.sh] in target list make: Makefile: line 3012: Warning -- FSUM9432 Duplicate entry [t/aclocal-path.sh] in target list make: Makefile: line 3012: Warning -- FSUM9432 Duplicate entry
