Opened 4 years ago
Closed 4 years ago
#62158 closed defect (fixed)
py-protobuf3: install failures for macOS 10.8 through 10.11: compilation error related to PROTOBUF_MAYBE_CONSTEXPR MapFieldBase(ConstantInitialized)
Reported by: | mascguy (Christopher Nielsen) | Owned by: | Schamschula (Marius Schamschula) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | |
Keywords: | Cc: | ||
Port: | py-protobuf3 |
Description (last modified by mascguy (Christopher Nielsen))
It looks like this port is failing to install for some macOS releases, blocking builds for a fair number of downstream ports:
/usr/bin/clang -Wno-unused-result -Wsign-compare -Wunreachable-code -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -pipe -Os -arch x86_64 -isysroot/ -I. -I../src -I/opt/local/Library/Frameworks/Python.framework/Versions/3.9/include/python3.9 -c google/protobuf/pyext/map_container.cc -o build/temp.macosx-10.10-x86_64-3.9/google/protobuf/pyext/map_container.o -Wno-write-strings -Wno-invalid-offsetof -Wno-sign-compare -Wno-unused-variable -std=c++11 -Wno-shorten-64-to-32 -Wno-deprecated-register -stdlib=libc++ -Wno-shorten-64-to-32 In file included from google/protobuf/pyext/map_container.cc:39: ../src/google/protobuf/map_field.h:332:37: error: constexpr constructor never produces a constant expression [-Winvalid-constexpr] explicit PROTOBUF_MAYBE_CONSTEXPR MapFieldBase(ConstantInitialized) ^ ../src/google/protobuf/map_field.h:335:9: note: non-literal type 'internal::WrappedMutex' cannot be used in a constant expression mutex_(GOOGLE_PROTOBUF_LINKER_INITIALIZED), ^ 1 error generated. error: command '/usr/bin/clang' failed with exit code 1 Command failed: cd "/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_python_py-protobuf3/py39-protobuf3/work/protobuf-3.14.0/python" && /opt/local/Library/Frameworks/Python.framework/Versions/3.9/bin/python3.9 setup.py --no-user-cfg --cpp_implementation install --prefix=/opt/local/Library/Frameworks/Python.framework/Versions/3.9 --root=/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_python_py-protobuf3/py39-protobuf3/work/destroot Exit code: 1 Error: Failed to destroot py39-protobuf3: command execution failed
Ignore the fact that this port is compiling code during phase destroot
, as that's covered by issue:56534.
These specific failures are occurring on macOS 10.8, 10.9, 10.10, and 10.11.
Change History (18)
comment:1 Changed 4 years ago by mascguy (Christopher Nielsen)
Owner: | set to tobypeterson |
---|---|
Status: | new → assigned |
comment:2 Changed 4 years ago by mascguy (Christopher Nielsen)
Summary: | py-protobuf3: install failures: compilation error related to PROTOBUF_MAYBE_CONSTEXPR MapFieldBase(ConstantInitialized) → py-protobuf3: install failures for macOS 10.10 and 10.11: compilation error related to PROTOBUF_MAYBE_CONSTEXPR MapFieldBase(ConstantInitialized) |
---|
comment:3 Changed 4 years ago by mascguy (Christopher Nielsen)
Description: | modified (diff) |
---|---|
Summary: | py-protobuf3: install failures for macOS 10.10 and 10.11: compilation error related to PROTOBUF_MAYBE_CONSTEXPR MapFieldBase(ConstantInitialized) → py-protobuf3: install failures for macOS 10.8 through 10.11: compilation error related to PROTOBUF_MAYBE_CONSTEXPR MapFieldBase(ConstantInitialized) |
comment:4 Changed 4 years ago by mascguy (Christopher Nielsen)
comment:5 Changed 4 years ago by mascguy (Christopher Nielsen)
Perhaps this ticket should be assigned to Marius...?
comment:6 Changed 4 years ago by mascguy (Christopher Nielsen)
Owner: | changed from tobypeterson to Schamschula |
---|
comment:7 Changed 4 years ago by Schamschula (Marius Schamschula)
So I update a port to the current upstream release version, which builds correctly on my build machine (Mojave). I push the update, only to find out later that El Capitan and below have an issue.
If you want to run older macOS versions, you are likely to run into this type of issue. Upstream developers, in this case Google, often only support the latest OS versions, breaking backwards compatibility.
Making things work on older systems takes a bit of detective work, which requires access to a machine running the older OS. I don't have a machine running anything below Mojave. The only possible way for me to test on older systems is to blindly throw possible fixes at the CI systems.
Of course we're also running into the opposite problem: very old packages need a lot of updates to run on new systems, e.g. the arm64 platform.
comment:8 Changed 4 years ago by mascguy (Christopher Nielsen)
KenC and I - among other folks - are running a suite of macOS VMs, from 10.6 through present. Parallels 16 runs them all beautifully, and only requires a one-time $50 purchase.
comment:9 Changed 4 years ago by mascguy (Christopher Nielsen)
If you're willing to take a look at this ASAP, and propose some fixes, I'm willing to assist with testing on 10.8 through 10.11.
comment:10 Changed 4 years ago by Schamschula (Marius Schamschula)
I'm aware of being able to run VMs (and have installers all the way back to Snow Leopard Server). I have done so in the past. I don't have time and energy to do so.
comment:11 Changed 4 years ago by Schamschula (Marius Schamschula)
I just think this is a bad idea to ask anyone revbumping dependent ports to check if they build on 11 macOS versions (12 counting arm64 Big Sur), and fix everything while they're at it.
I'm thinking of updates to ghostscript, for example. Things are often broken before the revbump.
comment:12 Changed 4 years ago by Schamschula (Marius Schamschula)
Yes, Ken has been most helpful for a long time in insuring that things work on older systems.
comment:13 Changed 4 years ago by mascguy (Christopher Nielsen)
In the near-term, I'm offering to assist with testing on these older macOS releases. Can you propose some fixes?
comment:14 Changed 4 years ago by Schamschula (Marius Schamschula)
This issue has been reported upstream https://github.com/protocolbuffers/protobuf/issues/8150
comment:15 Changed 4 years ago by Schamschula (Marius Schamschula)
See https://trac.macports.org/ticket/61751 for a possible solution.
comment:16 Changed 4 years ago by mascguy (Christopher Nielsen)
Yes, I was going to suggest blacklisting clang versions older than 9, and/or updating the c++ requirements to 2014.
comment:17 Changed 4 years ago by Schamschula (Marius Schamschula)
comment:18 Changed 4 years ago by Schamschula (Marius Schamschula)
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
FYI, this port was building successfully across-the-board, until the following change was committed: