Errors compiling 2022f on macOS
Hi, I’m getting errors when running make on the 2022f release, on my macOS Monterrey (12.6.1) machine. There are two separate errors. When I run `make` with no arguments, I get the following: cc -DTZDIR='"/usr/share/zoneinfo"' -c -o zic.o zic.c zic.c:1194:11: error: implicit declaration of function 'getrandom' is invalid in C99 [-Werror,-Wimplicit-function-declaration] s = getrandom(entropy_buffer, sizeof entropy_buffer, 0); ^ 1 error generated. After some digging, I tried running `make CFLAGS="-DHAVE_GETRANDOM=0”`, which then presents a different error: cc -DTZDIR='"/usr/share/zoneinfo"' -o zic -DHAVE_GETRANDOM=0 zic.o Undefined symbols for architecture x86_64: "_libintl_gettext", referenced from: _main in zic.o _close_file in zic.o _usage in zic.o _warning in zic.o _infile in zic.o _adjleap in zic.o _associate in zic.o ... "_libintl_setlocale", referenced from: _main in zic.o "_libintl_textdomain", referenced from: _main in zic.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) I’m not a C programmer so I’m out of my depth with trying to diagnose workarounds. Possibly there’s just another CFLAGS argument I need to provide, or I’ve got something else weird in my environment? Some extra bits of context: These errors also happen on latest `main` branch (commit 9f1f40cd). I can compile 2022e without issue. The getrandom error appears in commit 0733c65c ("Improve randomness of zic temp file names”). The linking error appears in commit e5b2ee63 ("Use C23 __has_include if available”). masOS 12.6.1 / Make 3.81 / clang 14.0.0 Also, the Makefile comment for the HAVE_GETRANDOM flag says "-DHAVE_GETRANDOM if getgrandom works (e.g., GNU/Linux)*” — is “getgrandom” a typo? Cheers, Gil
AFAICT getrandom does not exist on Darwin/macOS; I can reproduce the first problem. I can’t reproduce the second problem on macOS 13. debbie 3:36PM tz ?2 % make CFLAGS="-DHAVE_GETRANDOM=0" cc -DTZDIR='"/usr/share/zoneinfo"' -DHAVE_GETRANDOM=0 -c -o zic.o zic.c cc -DTZDIR='"/usr/share/zoneinfo"' -o zic -DHAVE_GETRANDOM=0 zic.o cc -DTZDIR='"/usr/share/zoneinfo"' -DHAVE_GETRANDOM=0 -c -o zdump.o zdump.c cc -DTZDIR='"/usr/share/zoneinfo"' -DHAVE_GETRANDOM=0 -c -o localtime.o localtime.c cc -DTZDIR='"/usr/share/zoneinfo"' -DHAVE_GETRANDOM=0 -c -o asctime.o asctime.c cc -DTZDIR='"/usr/share/zoneinfo"' -DHAVE_GETRANDOM=0 -c -o strftime.o strftime.c cc -DTZDIR='"/usr/share/zoneinfo"' -o zdump -DHAVE_GETRANDOM=0 zdump.o localtime.o asctime.o strftime.o cc -DTZDIR='"/usr/share/zoneinfo"' -DHAVE_GETRANDOM=0 -c -o difftime.o difftime.c rm -f libtz.a ar -rc libtz.a localtime.o asctime.o difftime.o strftime.o : libtz.a Debbie
On Oct 29, 2022, at 3:29 PM, Gilmore Davidson via tz <tz@iana.org> wrote:
Hi, I’m getting errors when running make on the 2022f release, on my macOS Monterrey (12.6.1) machine.
There are two separate errors. When I run `make` with no arguments, I get the following:
cc -DTZDIR='"/usr/share/zoneinfo"' -c -o zic.o zic.c zic.c:1194:11: error: implicit declaration of function 'getrandom' is invalid in C99 [-Werror,-Wimplicit-function-declaration] s = getrandom(entropy_buffer, sizeof entropy_buffer, 0); ^ 1 error generated.
After some digging, I tried running `make CFLAGS="-DHAVE_GETRANDOM=0”`, which then presents a different error:
cc -DTZDIR='"/usr/share/zoneinfo"' -o zic -DHAVE_GETRANDOM=0 zic.o Undefined symbols for architecture x86_64: "_libintl_gettext", referenced from: _main in zic.o _close_file in zic.o _usage in zic.o _warning in zic.o _infile in zic.o _adjleap in zic.o _associate in zic.o ... "_libintl_setlocale", referenced from: _main in zic.o "_libintl_textdomain", referenced from: _main in zic.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation)
I’m not a C programmer so I’m out of my depth with trying to diagnose workarounds. Possibly there’s just another CFLAGS argument I need to provide, or I’ve got something else weird in my environment?
Some extra bits of context:
These errors also happen on latest `main` branch (commit 9f1f40cd). I can compile 2022e without issue. The getrandom error appears in commit 0733c65c ("Improve randomness of zic temp file names”). The linking error appears in commit e5b2ee63 ("Use C23 __has_include if available”). masOS 12.6.1 / Make 3.81 / clang 14.0.0
Also, the Makefile comment for the HAVE_GETRANDOM flag says "-DHAVE_GETRANDOM if getgrandom works (e.g., GNU/Linux)*” — is “getgrandom” a typo?
Cheers, Gil
On 2022-10-29 15:29, Gilmore Davidson via tz wrote:
cc -DTZDIR='"/usr/share/zoneinfo"' -c -o zic.o zic.c zic.c:1194:11: error: implicit declaration of function 'getrandom' is invalid in C99 [-Werror,-Wimplicit-function-declaration] s = getrandom(entropy_buffer, sizeof entropy_buffer, 0); ^
Thanks for reporting the problem. Please try the attached patch, which I installed in the development repository. Alternatively as you mentioned, you can work around this problem by appending -DHAVE_GETRANDOM=0 to CFLAGS.
cc -DTZDIR='"/usr/share/zoneinfo"' -o zic -DHAVE_GETRANDOM=0 zic.o Undefined symbols for architecture x86_64: "_libintl_gettext", referenced from:
This looks like a not uncommon configuration issue on macOS. You might try reinstalling gettext. See <https://github.com/EOSIO/eos/issues/2392>, which suggests: brew reinstall gettext brew unlink gettext && brew link gettext --force --overwrite (I don't use brew so don't know what this means.) Deborah reports not being able to reproduce the problem on macOS; perhaps it's a macOS versioning issue if it's not a brew issue? Alternatively, you can work around this second problem by appending "-DHAVE_GETTEXT=0" to CFLAGS. The attached patch tries to improve the commentary a bit in this area.
Also, the Makefile comment for the HAVE_GETRANDOM flag says "-DHAVE_GETRANDOM if getgrandom works (e.g., GNU/Linux)*” — is “getgrandom” a typo?
Thanks, also fixed in the attached patch.
On 30 Oct 2022, at 14:53, Paul Eggert <eggert@cs.ucla.edu> wrote:
Thanks for reporting the problem. Please try the attached patch, which I installed in the development repository. Alternatively as you mentioned, you can work around this problem by appending -DHAVE_GETRANDOM=0 to CFLAGS.
Thanks Paul, that patch worked for me.
Deborah reports not being able to reproduce the problem on macOS; perhaps it's a macOS versioning issue if it's not a brew issue?
Alternatively, you can work around this second problem by appending "-DHAVE_GETTEXT=0" to CFLAGS. The attached patch tries to improve the commentary a bit in this area.
I’ve reinstalled gettext as you suggested and still get the error, so I suspect it’s something wonky with my system. Using “-DHAVE_GETTEXT=0” is a valid workaround though, so I’ll run with that. Thanks again.
On 2022-10-29 21:31, Gilmore Davidson wrote:
Thanks Paul, that patch worked for me.
You're welcome. In further testing I found that some compilers complained about the first "#if HAVE_GETRANDOM". That's valid C code but the compilers warned that HAVE_GETRANDOM is not defined as a macro and that it defaults to zero there. I installed the attached further patch to pacify these compilers.
Haha I just happened to have gettext installed on my system; it’s not a standard part of macOS. It would probably be best to compile it out by default on Darwin systems. Debbie
On Oct 29, 2022, at 8:53 PM, Paul Eggert via tz <tz@iana.org> wrote:
On 2022-10-29 15:29, Gilmore Davidson via tz wrote:
cc -DTZDIR='"/usr/share/zoneinfo"' -c -o zic.o zic.c zic.c:1194:11: error: implicit declaration of function 'getrandom' is invalid in C99 [-Werror,-Wimplicit-function-declaration] s = getrandom(entropy_buffer, sizeof entropy_buffer, 0); ^
Thanks for reporting the problem. Please try the attached patch, which I installed in the development repository. Alternatively as you mentioned, you can work around this problem by appending -DHAVE_GETRANDOM=0 to CFLAGS.
cc -DTZDIR='"/usr/share/zoneinfo"' -o zic -DHAVE_GETRANDOM=0 zic.o Undefined symbols for architecture x86_64: "_libintl_gettext", referenced from:
This looks like a not uncommon configuration issue on macOS. You might try reinstalling gettext. See <https://github.com/EOSIO/eos/issues/2392>, which suggests:
brew reinstall gettext brew unlink gettext && brew link gettext --force --overwrite
(I don't use brew so don't know what this means.) Deborah reports not being able to reproduce the problem on macOS; perhaps it's a macOS versioning issue if it's not a brew issue?
Alternatively, you can work around this second problem by appending "-DHAVE_GETTEXT=0" to CFLAGS. The attached patch tries to improve the commentary a bit in this area.
Also, the Makefile comment for the HAVE_GETRANDOM flag says "-DHAVE_GETRANDOM if getgrandom works (e.g., GNU/Linux)*” — is “getgrandom” a typo?
Thanks, also fixed in the attached patch. <0001-Fix-GET_RANDOM-default-on-macOS.patch>
On 2022-10-29 23:47, Deborah Goldsmith wrote:
I just happened to have gettext installed on my system; it’s not a standard part of macOS. It would probably be best to compile it out by default on Darwin systems.
It's not compiled by default on Darwin; it's compiled only if the build host has <libintl.h>. From this thread: https://github.com/pyenv/pyenv/issues/1877 it appears that it's common for a macOS build host to have misconfigured copies of arm64 and x86_64 libraries - possibly because migration assistance copied over an old homebrew system, and possibly with different versions on x86_64 vs arm64 - and where <libintl.h> therefore compiles (because the same libintl.h works for multiple architectures and versions) but the resulting program doesn't link. My guess is that Gilmore has such a system and this broke zic linking, whereas you have a clean system where zic linked fine. What a mess, huh? To try to work around the problem, and partly in response to your suggestion, I installed the attached patch into the development repository on GitHub. Unfortunately, a downside of this patch is that zic by default now lacks internationalization support on macOS. This means user-friendly behavior like the following shell transcript, which is routine on GNU/Linux: $ export LC_ALL=fr_FR.utf8 $ echo "Cette entrée n'est pas valide." | zic - "entrée standard", ligne 1: Ligne d'entrée de type inconnu won't work on macOS by default. If you think the attached patch is headed in the wrong direction, I'll revert it and instead ask users like Gilmore with messed-up build hosts to build with 'make CFLAGS="-DHAVE_GETTEXT=0"', which they already have to do with 2022f.
On Oct 30, 2022, at 10:40 AM, Paul Eggert via tz <tz@iana.org> wrote:
Unfortunately, a downside of this patch is that zic by default now lacks internationalization support on macOS.
Unfortunately, a downside of macOS not providing an implementation of the gettext API (the first implementation of which was, I think, in Solaris) is that zic by default lacks internationalization support on macOS. That statement may also hold true for some other UN*Xes. NetBSD has a BSD-licensed implementation from the Citrus Project: https://en.wikipedia.org/wiki/Citrus_Project http://citrus.bsdclub.org and I think Radar has an entry from some guy at Apple pointing that out and suggesting that Mac OS X, as it was called at the time the Radar was filed, consider providing it.
On 2022-10-30 13:57, Guy Harris wrote:
That statement may also hold true for some other UN*Xes.
My impression is that users of NetBSD, OpenBSD etc. are less likely to run into this problem, because they don't have the complication of configuration issues inherent to macOS's brew-based system that is combined with automatic migration and multiple-architecture binaries and libraries. Gilmore wrote he's OK with reverting the patch so I'm now inclined to revert it, though I'd also like to hear Deborah's opinion.
On Oct 30, 2022, at 4:16 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 2022-10-30 13:57, Guy Harris wrote:
That statement may also hold true for some other UN*Xes.
My impression is that users of NetBSD, OpenBSD etc. are less likely to run into this problem, because they don't have the complication of configuration issues inherent to macOS's brew-based system that is combined with automatic migration and multiple-architecture binaries and libraries.
The statement to which I was referring is
Unfortunately, a downside of macOS not providing an implementation of the gettext API (the first implementation of which was, I think, in Solaris) is that zic by default lacks internationalization support on macOS.
I.e., the only *BSD on which you'll get internationalization by default is NetBSD; the others won't give you libintl out of the box, just as macOS won't - you'd have to install it yourself. So you'll get $ echo "Ceci n'est pas une pipe." | LC_ALL=fr_FR.utf8 zic - "standard input", line 1: input line of unknown type $ echo "Ceci n'est pas une pipe." | LC_ALL=fr_FR.UTF-8 zic - "standard input", line 1: input line of unknown type with the built-in zic, just as you will with the zic that ships with macOS, and you'll get that with a zic you compile from source unless you have installed libintl. (And you'll probably also need a version of the tzcode that has .pc files and installs them. I'm not seeing any files with translations for "standard input" or "input line of unknown type" in the current Git repository for tz.) I.e., I'm not seeing "versions of zic that a user builds from source, on a system with libintl installed, will, by default, now lack internationalization support on macOS" as a change that will, in practice, disadvantage many people.
On 2022-10-30 16:42, Guy Harris wrote:
the only *BSD on which you'll get internationalization by default is NetBSD; the others won't give you libintl out of the box, just as macOS won't - you'd have to install it yourself.
That's OK. The localized diagnostics aren't essential, as most people who run zic are computer nerds who are likely to be able to read English-language diagnostics (and/or feed them into Google Translate). The idea, though, is that it's nicer if zic isn't by default offputting to everybody else. That being said, the idea that internationalization ought to be easy seems to be foreign enough to so many platforms, that perhaps we should enable gettext by default only on glibc and Solaris where it's known to work out of the box. Even NetBSD (where gettext is not an option) requires you to link with -lintl, which is a configuration hassle.
On 31 Oct 2022, at 04:40, Paul Eggert <eggert@cs.ucla.edu> wrote:
it appears that it's common for a macOS build host to have misconfigured copies of arm64 and x86_64 libraries - possibly because migration assistance copied over an old homebrew system, and possibly with different versions on x86_64 vs arm64 - and where <libintl.h> therefore compiles (because the same libintl.h works for multiple architectures and versions) but the resulting program doesn't link. My guess is that Gilmore has such a system and this broke zic linking
That wouldn’t surprise me in the least. My current system has accumulated many years of possible junk via upgrades.
If you think the attached patch is headed in the wrong direction, I'll revert it and instead ask users like Gilmore with messed-up build hosts to build with 'make CFLAGS="-DHAVE_GETTEXT=0"', which they already have to do with 2022f
That patch worked for me. I can now run `make` with no arguments and no errors. But I’m also fine with running the flags if the patch is reverted.
I think it would be best to optimize for build hosts that are not messed up; it won’t be common. I would suggest reverting the patch. Debbie
On Oct 30, 2022, at 10:40 AM, Paul Eggert <eggert@CS.UCLA.EDU> wrote:
On 2022-10-29 23:47, Deborah Goldsmith wrote:
I just happened to have gettext installed on my system; it’s not a standard part of macOS. It would probably be best to compile it out by default on Darwin systems.
It's not compiled by default on Darwin; it's compiled only if the build host has <libintl.h>.
From this thread:
https://github.com/pyenv/pyenv/issues/1877
it appears that it's common for a macOS build host to have misconfigured copies of arm64 and x86_64 libraries - possibly because migration assistance copied over an old homebrew system, and possibly with different versions on x86_64 vs arm64 - and where <libintl.h> therefore compiles (because the same libintl.h works for multiple architectures and versions) but the resulting program doesn't link. My guess is that Gilmore has such a system and this broke zic linking, whereas you have a clean system where zic linked fine.
What a mess, huh?
To try to work around the problem, and partly in response to your suggestion, I installed the attached patch into the development repository on GitHub.
Unfortunately, a downside of this patch is that zic by default now lacks internationalization support on macOS. This means user-friendly behavior like the following shell transcript, which is routine on GNU/Linux:
$ export LC_ALL=fr_FR.utf8 $ echo "Cette entrée n'est pas valide." | zic - "entrée standard", ligne 1: Ligne d'entrée de type inconnu
won't work on macOS by default.
If you think the attached patch is headed in the wrong direction, I'll revert it and instead ask users like Gilmore with messed-up build hosts to build with 'make CFLAGS="-DHAVE_GETTEXT=0"', which they already have to do with 2022f.<0001-Require-explicit-DHAVE_GETTEXT-on-macOS.patch>
participants (4)
-
Deborah Goldsmith -
Gilmore Davidson -
Guy Harris -
Paul Eggert