Recent changes have broken build on Fedora Linux

[mcisho]

The last time I issued this sequence of commands was January 16, when the build was successful. Today it isn't successful, on two different machines both running Fedora 35 x64.

[xxx@laptop ~]$ git clone https://github.com/SDL-Hercules-390/hyperion.git /home/xxx/Source/Hercules.SDL/hyperion
Cloning into '/home/xxx/Source/Hercules.SDL/hyperion'...
remote: Enumerating objects: 55949, done.
remote: Counting objects: 100% (1589/1589), done.
remote: Compressing objects: 100% (683/683), done.
remote: Total 55949 (delta 951), reused 1327 (delta 905), pack-reused 54360
Receiving objects: 100% (55949/55949), 61.73 MiB | 915.00 KiB/s, done.
Resolving deltas: 100% (43602/43602), done.
[xxx@laptop ~]$ cd /home/xxx/Source/Hercules.SDL/hyperion
[xxx@laptop hyperion]$ git checkout develop
Branch 'develop' set up to track remote branch 'develop' from 'origin'.
Switched to a new branch 'develop'
[xxx@laptop hyperion]$ ./util/bldlvlck
This utility will check the level of various utilities needed to build
hercules. Checking is done against versions that are KNOWN to work.
This doesn't mean a build will NOT succeed with older versions
of the utilities, but will give a hint as to what package may need
an upgrade if the build ever fails with some odd reason.

Machine architecture is x86_64

OK  autoconf requires 2.64, found 2.69

OK  automake requires 1.9, found 1.16.2

OK  bash requires 3.2, found 5.1.8

OK  cmake requires 3.2, found 3.22.2

OK  flex requires 2.5, found 2.6.4

OK  gawk requires 3.0, found 5.1.0

OK  gcc requires 6.2.0, found gcc 11.2.1

OK  grep requires 1, found 3.6

OK  ld requires 2.22, found 2.37.10

OK  libtool requires 2.4.6, found 2.4.6

OK  ltdl.h required include file, found

OK  m4 requires 1.4.6, found 1.4.19

OK  make requires 3.79, found 4.3

OK  perl requires 5.6, found 5.34.0

OK  sed requires 3.02, found 4.8

[xxx@laptop hyperion]$ ./configure \
    --prefix=/home/xxx/Hercules.run \
    --enable-optimization="-O2" \
    --disable-object-rexx \
    --disable-regina-rexx
configure: error: cannot find required auxiliary files: compile
[xxx@laptop hyperion]$ 

Any clues welcome!

Ian

[Fish-Git]

Hi Ian!

I noticed that Bill (@wrljet) made a commit (dabbf1918dfa934c68110b4b2eb3552cb6540bd2) that was supposed to be a simple one line change to configure.ac.

But it looks like Bill used autoconf 2.71 to generate his autoconf changes with, whereas it looks like the configure script and all the other impacted autoconf files (i.e. the makefile.in files) before he made his commit were all generated using autoconf 2.69.

As a result, MUCH ended up being changed in the configure script.

That is to say, the configure script that Bill committed ended up changing much more than just the simple one line change that was the only thing originally intended to be changed.

Since the error you reported looks like it's coming from the configure script, my suggestion would be to try running ./autogen.sh to generate your own set of autoconf files (including a new configure script) that hopefully will work better for you on your particular system.

If that works, then we can work with Bill to try and figure out why the configure script generated from autoconf 2.71 apparently doesn't work for you.  (which, if it turns out to be true, would not be Bill's fault!*`()`**)

---

*`()`** IMHO, Bill should get a Medal of Honor or a Purple Heart or something for all the shit he has had to go through dealing with autoconf!

[Fish-Git]

FYI:  For what it's worth, I'm also getting the same thing on my Neon 5.23 system too, and, as suspected, doing a ./autogen.sh resolves the problem. (The autoconf on my system is 2.69)

So it looks like the configure script we have that autoconf 2.71 generates is bad.  :(

[mcisho]

Doing an ./autogen.sh resolved the problem, and my system also has autoconf 2.69.

I bought a book about autotools many years ago, and despite reading it I'm still none the wiser, so I fully agree re Bill.

[wrljet]

So it looks like the configure script we have that autoconf 2.71 generates is bad. :(

On the very last system I tested on (MacOS), I edited configure.ac to removed a commented-out line. So then reran autogen.sh. Tested it. It worked. And then got lazy and committed the changes from that system.

The problem is not autoconf 2.71 itself, but the fact I forgot what I was doing and committed those changes from the MacOS. Which isn't Linux based and uses a different scheme for the shared libraries, etc.

So the resulting configure was just no good on Linux.

I have redone the autogen on a Debian based system and re-committed. (but didn't test anything)

Sorry for the fick-up. Bill

[wrljet]

re: autoconf and friends... overly complex, convoluted, and bloated.

I have exhausted my considerable vocabulary of 4-letter words (in more than one language) working on the impenetrable thing.

[mcisho]

Thanks, commit 774a1ae fixed the problem.

Ian