Hi, I've been encountering this bug for some time and created a GH PR [1] to fix it. In a nutshell the Objective-C compiler defaults to GCC unless $OBJC is set. Can someone please help merge the fix? Thank you! [1] https://github.com/gentoo/gentoo/pull/23197
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a792e455bfcba4b7a462d1cadb1eab2ed1c3f7fc commit a792e455bfcba4b7a462d1cadb1eab2ed1c3f7fc Author: Adrian Ratiu <adrian.ratiu@collabora.com> AuthorDate: 2021-12-06 12:30:24 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-01-04 10:07:39 +0000 dev-libs/protobuf: fix Objective-C compiler selection During the protobuf configure phase, autotools gives priority to GCC if $OBJC is unset, thus leading to cases where GCC is used for Objective-C even though Clang is used for the rest of the build, so we set OBJC to correctly picks up CC values. Closes: https://bugs.gentoo.org/830584 Signed-off-by: Adrian Ratiu <adrian.ratiu@collabora.com> Closes: https://github.com/gentoo/gentoo/pull/23197 Signed-off-by: Sam James <sam@gentoo.org> dev-libs/protobuf/protobuf-3.16.0.ebuild | 3 ++- dev-libs/protobuf/protobuf-3.17.0.ebuild | 3 ++- dev-libs/protobuf/protobuf-3.17.1.ebuild | 3 ++- dev-libs/protobuf/protobuf-3.17.2.ebuild | 3 ++- dev-libs/protobuf/protobuf-3.17.3.ebuild | 3 ++- dev-libs/protobuf/protobuf-3.19.1.ebuild | 3 ++- dev-libs/protobuf/protobuf-9999.ebuild | 3 ++- 7 files changed, 14 insertions(+), 7 deletions(-)
sorry, this was on my list to look at and it slipped my mind. Thank you!
configure.ac has AC_PROG_OBJC, but it does not seem to be used for anything. Objective C bindings are in "objectivec" directory, but compilation of files from this directory is not included in Autotools build system. Objective C bindings also seem to be support only iOS / macOS: https://github.com/protocolbuffers/protobuf/tree/master/objectivec (or https://github.com/protocolbuffers/protobuf/blob/master/objectivec/README.md): > Requirements > ------------ > > The Objective C implementation requires: > > - Objective C 2.0 Runtime (32bit & 64bit iOS, 64bit OS X). > - Xcode 10.3 (or later). > - The library code does *not* use ARC (for performance reasons), but it all can > be called from ARC code. Please attach 2 build logs (with MAKEOPTS="-j1" for readability): one without OBJC="$(tc-getBUILD_CC)" and one with OBJC="$(tc-getBUILD_CC)".
AC_PROG_OBJC maybe has some effect on macOS: configure.ac: > # Enable ObjC support for conformance directory on OS X. > OBJC_CONFORMANCE_TEST=0 > case "$target_os" in > darwin*) > OBJC_CONFORMANCE_TEST=1 > ;; > esac > AM_CONDITIONAL([OBJC_CONFORMANCE_TEST], [test $OBJC_CONFORMANCE_TEST = 1]) conformance/Makefile.am: > if OBJC_CONFORMANCE_TEST > > bin_PROGRAMS += conformance-objc > > conformance_objc_SOURCES = conformance_objc.m ../objectivec/GPBProtocolBuffers.m > ... > endif
I think it's just that they have a hook/wrapper for e.g. gcc to detect when it's being called unexpectedly and they'd prefer it weren't. But would be interested to know if they're really using objc, as I don't ever really think about that, despite my macOS Prefix usage (due to GCC support lacking right now for Blocks and we need help to get LLVM bootstrapping in Prefix for macOS).
Also we want to know what platform is used by reporter. Apparently KEYWORDS in dev-libs/protobuf ebuilds contain "~x64-macos"... Autotools build system (used by ebuild) on macOS would try to compile only 2 .m files for conformance-objc. Only Bazel build system (not used by ebuild) seems to support Objective C bindings. gentoo.git::profiles/prefix/darwin/macos/make.defaults (https://gitweb.gentoo.org/repo/gentoo.git/tree/profiles/prefix/darwin/macos/make.defaults) has: > # on OSX one should have objc available > USE="objc objc++" So maybe there would be compilation failure on Gentoo macOS Prefix with sys-devel/gcc[-objc], but maybe we do not have to care about this situation (sys-devel/gcc[-objc] on macOS). toolchain-funcs.eclass does not yet have dedicated getter functions for Objective C / Objective C++ compilers. E.g. meson.eclass has: > c = $(_meson_env_array "$(tc-getCC)") > cpp = $(_meson_env_array "$(tc-getCXX)") > ... > objc = $(_meson_env_array "$(tc-getPROG OBJC cc)") > ... > objcpp = $(_meson_env_array "$(tc-getPROG OBJCXX c++)" But probably better would be: "$(tc-getPROG OBJC "${CC:-gcc}")" "$(tc-getPROG OBJCXX "${CXX:-g++}")" We should add tc-getOBJC() and tc-getOBJCXX() (and tc-getBUILD_OBJC(), tc-getBUILD_OBJCXX()) to toolchain-funcs.eclass, and then switch dev-libs/protobuf ebuilds to use tc-getOBJC().
Some implementation of tc-getOBJC() and tc-getOBJCXX() etc. will be useful (at least for meson.eclass), but if users want to switch from GCC to Clang and they only set CC and CXX, but forget about OBJC and OBJCXX, then it is users' mistake... In dev-libs/protobuf, maybe I will make AC_PROG_OBJC conditional on value of "$target_os".
Reporter: If you do not use macOS, you may test this change: --- configure.ac +++ configure.ac @@ -80,7 +80,7 @@ ACX_USE_SYSTEM_EXTENSIONS m4_ifdef([AM_PROG_AR], [AM_PROG_AR]) AM_CONDITIONAL(GCC, test "$GCC" = yes) # let the Makefile know if we're gcc -AC_PROG_OBJC +AS_CASE([$target_os], [darwin*], [AC_PROG_OBJC]) # test_util.cc takes forever to compile with GCC and optimization turned on. AC_MSG_CHECKING([C++ compiler flags...])
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #8) > Reporter: > If you do not use macOS, you may test this change: > > --- configure.ac > +++ configure.ac > @@ -80,7 +80,7 @@ > ACX_USE_SYSTEM_EXTENSIONS > m4_ifdef([AM_PROG_AR], [AM_PROG_AR]) > AM_CONDITIONAL(GCC, test "$GCC" = yes) # let the Makefile know if we're > gcc > -AC_PROG_OBJC > +AS_CASE([$target_os], [darwin*], [AC_PROG_OBJC]) > > # test_util.cc takes forever to compile with GCC and optimization turned on. > AC_MSG_CHECKING([C++ compiler flags...]) I.e. without OBJC assignment in ebuild.
Thanks for the patch and for following up on this. I will report back once I test it. For context: We do not use macOS nor Objective-C and we're targeting just Gentoo Linux and its derivative ChromiumOS. The only interest here is to have consistent compiler / toolchain usage during builds, to avoid unexpectedly mixing GCC/Binutils with Clang/LLVM tools. As Sam correctly observed, to detect such usages local compiler / tools wrappers are added to fail the build and print a ps tree to allow identifying offenders. The vast majority of packages do not have this problem, it's just a few outliers out of which protobuf is part of.
@arfrever.fta: I tried the configure.ac patch without having OBJC set in the ebuild but unfortunately it fails the build with the following error: ``` configure: error: conditional "am__fastdepOBJC" was never defined. Usually this means the macro was only invoked conditionally. ``` I tried some variations like the following which also fail, as well as dropping AC_PROG_OBJC entirely. My autoconf foo is just not good. :) ``` diff --git a/configure.ac b/configure.ac index fb5f9d09f..b867b0bc1 100644 --- a/configure.ac +++ b/configure.ac @@ -80,7 +80,11 @@ AC_LANG([C++]) ACX_USE_SYSTEM_EXTENSIONS m4_ifdef([AM_PROG_AR], [AM_PROG_AR]) AM_CONDITIONAL(GCC, test "$GCC" = yes) # let the Makefile know if we're gcc -AC_PROG_OBJC +ase "$target_os" in + darwin*) + AC_PROG_OBJC + ;; +esac ``` The only solution which works for now is setting OBJC in the ebuild. Honestly I don't think a one-liner variable in the ebuild is too bad, but if we can find a working autoconf solution I'm not against it. Any suggestions?
Apparently there is some limitation of Automake: https://lists.gnu.org/archive/html/bug-automake/2002-11/msg00020.html Workaround seems to be to define am__fastdepOBJC Automake conditional in "default" argument of AS_CASE: > AS_CASE([$target_os], [darwin*], [AC_PROG_OBJC], [AM_CONDITIONAL([am__fastdepOBJC], [false])])
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #12) > Apparently there is some limitation of Automake: > https://lists.gnu.org/archive/html/bug-automake/2002-11/msg00020.html > > Workaround seems to be to define am__fastdepOBJC Automake conditional in > "default" argument of AS_CASE: > > > AS_CASE([$target_os], [darwin*], [AC_PROG_OBJC], [AM_CONDITIONAL([am__fastdepOBJC], [false])]) I'm not convinced this is better, tbh.
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #12) > Apparently there is some limitation of Automake: > https://lists.gnu.org/archive/html/bug-automake/2002-11/msg00020.html > > Workaround seems to be to define am__fastdepOBJC Automake conditional in > "default" argument of AS_CASE: > > > AS_CASE([$target_os], [darwin*], [AC_PROG_OBJC], [AM_CONDITIONAL([am__fastdepOBJC], [false])]) I can confirm this works too, so now we have two working solutions. I'm in favor of keeping the simpler one by setting $OBJC in the ebuild, but I'm also fine with the new one.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0a5ea2310336c80c6e1c37ac3b2e2a03ec04fd21 commit 0a5ea2310336c80c6e1c37ac3b2e2a03ec04fd21 Author: Arfrever Frehtes Taifersar Arahesis <Arfrever@Apache.Org> AuthorDate: 2022-01-10 09:00:00 +0000 Commit: Yixun Lan <dlan@gentoo.org> CommitDate: 2022-01-29 15:18:21 +0000 dev-libs/protobuf: Disable check for Objective C compiler on non-macOS systems. Closes: https://bugs.gentoo.org/830584 Signed-off-by: Arfrever Frehtes Taifersar Arahesis <Arfrever@Apache.Org> Signed-off-by: Yixun Lan <dlan@gentoo.org> dev-libs/protobuf/protobuf-3.16.0.ebuild | 4 +++- dev-libs/protobuf/protobuf-3.17.0.ebuild | 4 +++- dev-libs/protobuf/protobuf-3.17.1.ebuild | 4 +++- dev-libs/protobuf/protobuf-3.17.2.ebuild | 4 +++- dev-libs/protobuf/protobuf-3.17.3.ebuild | 4 +++- dev-libs/protobuf/protobuf-3.19.1.ebuild | 4 +++- 6 files changed, 18 insertions(+), 6 deletions(-)
