Error: possibly undefined macro: m4_esyscmd

[ntq2503]

Hi,

I'm trying to install on macOS Big Sur 11.2.3 and ran into this issue after running ./autogen.sh.

All of my autotools are installed and up-to-date:

autoconf 2.71
automake 1.16.3_1
zeromq 4.3.4
czmq 4.2.0

Error message:
configure.ac:1: warning: AC_INIT: unsafe as a filename: "prime_server-[m4_esyscmd([./version.sh])]"
configure.ac:23: warning: The preprocessor macro `STDC_HEADERS' is obsolete.
configure.ac:23: Except in unusual embedded environments, you can safely include all
configure.ac:23: ISO C90 headers unconditionally.
configure.ac:41: warning: $as_echo is obsolete; use AS_ECHO(["message"]) instead
lib/m4sugar/m4sh.m4:692: _AS_IF_ELSE is expanded from...
lib/m4sugar/m4sh.m4:699: AS_IF is expanded from...
./lib/autoconf/general.m4:2249: AC_CACHE_VAL is expanded from...
./lib/autoconf/general.m4:2270: AC_CACHE_CHECK is expanded from...
m4/ax_pthread.m4:88: AX_PTHREAD is expanded from...
configure.ac:41: the top level
configure.ac:1: error: possibly undefined macro: m4_esyscmd
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
autoreconf: error: /usr/local/Cellar/autoconf/2.71/bin/autoconf failed with exit status: 1

I've tried looking everywhere online but haven't found a solution to this. Please advise!

Thank you so much!

[alexey-gl]

I have the same issue

[nilsnolde]

I have the same issue, see #101 (comment)

Also, there's the solution with cmake in the comment. I guess it'd be good to add CMake to the README @kevinkreiser in case the autoconf route is failing, I'll do a quick sketch..

[danpaz]

Using the alternative cmake build, I ran into an issue with missing headers on MacOS Big Sur. @kevinkreiser pointed me at the CI build script which specifies DCMAKE_OSX_SYSROOT. Running cmake like this and then building worked for me:

cmake --build build -DCMAKE_OSX_SYSROOT="/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk"

Opened #105 with an update to the readme.

[kevinkreiser]

sorry for not offering up this find sooner, it for some reason didnt occur to me that these were the same issue 🤦‍♂️

[ntq2503]

Using the alternative cmake build, I ran into an issue with missing headers on MacOS Big Sur. @kevinkreiser pointed me at the CI build script which specifies DCMAKE_OSX_SYSROOT. Running cmake like this and then building worked for me:

cmake --build build -DCMAKE_OSX_SYSROOT="/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk"

I tried running that but got this error:
Unknown argument -CMAKE_OSX_SYSROOT=/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk

Do you or @kevinkreiser happen to know why? Thank you!

[danpaz]

@ntq2503 I think you have a typo in the cmake argument, -DCMAKE_OSX_SYSROOT instead of -CMAKE_OSX_SYSROOT.

[nilsnolde]

@ntq2503

the not-working autotools way annoyed the life out of me.. I found a way it's working for my arch linux:

libtoolize --force
aclocal
autoheader
automake --force-missing --add-missing
autoconf

(from arch linux forum)

No idea if that's fixing mac installations too. Would you mind giving it a shot?

[kevinkreiser]

@nilsnolde we might be able to modify autogen.sh to do this then if we can figure out exactly which bit fixed it

[nilsnolde]

just had a look at autogen.sh for the first time 😅 let me try real quick.

[nilsnolde]

@kevinkreiser after a dozen git pulls, I still don't know what the hell is going wrong.. with the following autogen.sh I can build with autotools:

#!/bin/bash
libtoolize --force
aclocal -I m4
autoheader --warnings=no-portability
autoconf --warnings=no-portability
automake --force-missing --add-missing

it's still giving the same error in the autoconf step. But it produces the configure script! And building & installing works as well. Also, if autogen.sh is run a second time there is no error.. I couldn't find a configuration that works without error on the first try..

It does produce not-quite-right looking libs, but the symlinking doesn't care (valhalla_service built alright):

-rw-r--r-- 1 root root  11M 19. Apr 17:09 /usr/lib/libprime_server.a
-rwxr-xr-x 1 root root 1,1K 19. Apr 17:09 /usr/lib/libprime_server.la
lrwxrwxrwx 1 root root   24 19. Apr 17:09 /usr/lib/libprime_server.so -> libprime_server.so.0.0.0
lrwxrwxrwx 1 root root   24 19. Apr 17:09 /usr/lib/libprime_server.so.0 -> libprime_server.so.0.0.0
-rwxr-xr-x 1 root root 7,4M 19. Apr 17:09 /usr/lib/libprime_server.so.0.0.0

No matter in what sequence (or which ones I left out) I ran the above commands with autoreconf it wouldn't work (I guess bcs autoreconf does the whole command chain yet again..).

Maybe you wanna try the above autogen.sh? We could also simply add it to a troubleshooting section in the readme if you're not comfortable with the solution of getting rid of autoreconf.. I'd like to get to the bottom of this, but that'd probably require my first-born..

[stari4ek]

I do not have libtoolize installed.
Updating autogen.sh to:

#!/bin/bash
aclocal -I m4
autoheader --warnings=no-portability
autoconf --warnings=no-portability
automake --force-missing --add-missing

fixes it for me.
I am on macOS Catalina 10.15.7

[kevinkreiser]

@stari4ek nice! I'll see if that works on other platforms and get it updated if so

[nilsnolde]

did you ever get around to try my suggestion @kevinkreiser ? for the github actions mac runner this fails on 10.15 catalina (also, as you know, the brew one is not working atm). guess that'll sooner or later become a problem on circle ci as well, couldn't find out what mac os version they're using, I guess < 10.15. there's still the cmake build of course. is there a particular reason why you don't want to entirely switch to cmake?

[kevinkreiser]

no i havent.. since i recently did a bunch of CI stuff for https://github.com/vthiery/cpp-statsd-client/ i think i might just convert this project to using github actions. then ill run into the problem as you point out and ill be forced to do it, what do you t hink? i am really liking github actions!

[nilsnolde]

Haha sure, sounds good.

[kevinkreiser]

i realize i didnt fully answer your question

guess that'll sooner or later become a problem on circle ci as well, couldn't find out what mac os version they're using, I guess < 10.15. there's still the cmake build of course. is there a particular reason why you don't want to entirely switch to cmake?

circle ci for valhalla was broken when using brew but i fixed it by building prime_server from source instead of using brew at all. for macos i dont care about using cmake vs autotools but for linux i absolutely stand by autotools as it plays very nicely with debian packaging. that is one of the main things i regret about cmake for valhalla. i would have liked to have continued to do ppa packages for valhalla but maintaining such a large library in both autotools and cmake doesnt make sense. instead i should update the cmake to make both shared and static libraries, apparently it is possible.. and then figure out how to update my debian packaging tooling to work with cmake. the first time i learned to do that it took a hell of a lot of work though so i have just kind of been relying on docker as a means of "releasing" public binaries. frankly i kind of hate it though.. maybe i should just go to ubuntu snaps instead of ppa but frankly i feel like ppa still beats snaps in terms of usage

[nilsnolde]

Right, I knew I missed smth.. always forget the packaging stuff.. cmake packaging sounds very painful 😅 or maybe Debian packaging is..

[julianskartor]

Hi! I'm wondering if the fix for this will be included in any release anytime soon?

[kevinkreiser]

@julianskartor since this was a build tooling issue i had never considered it important enough to release but I can do so if you mean github release

[julianskartor]

@kevinkreiser I see. After a closer inspection of the commits on top of 0.7.0, it seems there's no API/functional changes? Since this problem only affects my local development I can probably just use specific commit hash instead 👍