Update for autoconf 2.70

[martinwhitaker]

Advanced warning that I will be pushing an update to support building with autoconf 2.70. Hopefully this won't cause any problems on older systems. I'll only fix the master branch to start with.

[caryr]

FYI. To get things to build I needed to do the following manual steps:

In the source directory.

./autoconf

In the build directory.

./config.status --recheck
./config.status

[svenka3]

@caryr That was useful for my build today on a Mac, thanks! One small thing - I had to so

sh autoconf.sh 

Regards

[caryr]

The only thing running the script adds is the -f flag to autoconf which should only be needed if your current configure script was some how newer than the change @martinwhitaker made. Did you try to manually hack things first which changed the date of configure verses the new configure.ac?

It also runs gperf, but that should not be needed in a directory you have already been working in. That's only needed in freshly cloned directories.

[svenka3]

OK, today I tried on a different CentOS7 machine and skipped the autoconf step, it worked just fine (with the 2 config.status commands you showed).

Thanks

[caryr]

That may work, I did not check exactly what Martin did. If he updated the .ac file instead of just renaming from .in then it should have eventually triggered a autoconf build.

[svenka3]

Sorry I spoke too fast. On a old CentOS 7 laptop latest master branch fails to build for few targets.

Here is what I did

sh autoconf.sh
./config.sttaus --recheck
./config.status 

sudo make

tgt-vpp/Makefile (and more)

Errors from gcc not using C99 mode.

I am manually editing those Makwfiles to add it. Not sure if this is the right way to fix.

[svenka3]

I got it working finally after editing makefiles under

tgt-vvp
tgt-vlog95
driver

[caryr]

Can you explain what needed to be changed in the Makefiles and the errors that forced this change.

[martinwhitaker]

I suspect the problem is that autoconf 2.70 has made AC_PROG_CC_C99 obsolete. If we need to support old compilers, we'll have to add in a conditional on the autoconf version.

[steveicarus]

I think we can start requiring newer compilers. C99 is so last century;-)

…

On Mon, Jan 4, 2021 at 11:58 AM martinwhitaker ***@***.***> wrote: I suspect the problem is that autoconf 2.70 has made AC_PROG_CC_C99 obsolete. If we need to support old compilers, we'll have to add in a conditional on the autoconf version. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#463 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAACKMWQCPTV65SZBY5VNCLSYIMYDANCNFSM4VQN53JQ> .

-- Steve Williams "The woods are lovely, dark and deep. steve@icarus.com <steveicarus@gmail.com> But I have promises to keep, http://www.icarus.com and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep."

[caryr]

Hey, I still party like it is 1999 from time to time ;-). Of course I think the oldest compiler I use is only a decade old so agree we can probably step to C11. It's a bigger step than I would have liked, but if C99 has issues then I'm okay updating. If we are going to update the C version what about C++? There are many new things in C++11 that I have purposely not been using. Maybe it's time to switch development to C/C++11 as the minimum requirement. I have no problem keeping the 11 branch as is and release 12 in the next year or so supporting C/C++11. Yes I know there is C++17/20, but I think we can all agree lots of systems still in use would break doing that. I still have a Ubuntu 14.04 machine I use occasionally and I'm guessing some of the C++11 functionality may not be fully supported by the compilers of that era.

[martinwhitaker]

It's not C99 that's a problem, it's compilers that default to something older and need to be told to support C99. I did think that wouldn't be a problem in 2021 - but seems I was wrong :-(

[svenka3]

Yes indeed the default mode of compiler seems old. Is there any more information you need from my end on this? For now I've local changes done to Makefile.

[caryr]

Okay, then it seems completely broken that autoconf does not correctly check for C99. Is there a bug filed for that or is there some justification why it is no longer supported/been obsoleted.

[martinwhitaker]

It's stated in the release notes, but I haven't found any justification for it.

[caryr]

I did a little research and it looks like in 2.70 when checking for the C compiler it automatically sets the highest standard version supported by the compiler. So to fix this we need to determine the autoconf version and if it is less than 2.70 use AC_PROG_CC_C99.

To make it easy on their users they should have kept the macro but made it work as follows:

I'm not certain what AC_PROG_CC_C99 returned if it could not support C99, but it should work exactly the same from an error stand point and since this is already handled by AC_PROG_CC it should return nothing for the non-error case. They should have also added AC_PROG_CC_C11 with this same functionality and of course the other obsoleted related flags should be updated.

Making us check the autoconf version and then do things differently based on the version is bad. Given 2.70 is so new maybe no one has reported this as an issue. I tried to search, but did not find anything, though I never did figure out how to search or even look at their bug database. @martinwhitaker can you push to see if we can get them to implement sane functionality and get a 2.71 release to resolve this? 2.70 seems broken from a compatibility standpoint.

[martinwhitaker]

I've fixed configure.ac to support both old and new versions of autoconf. It looks to be doing the right thing in CI.

[caryr]

Since this is complete I am closing this discussion.