Opened 18 months ago
Closed 18 months ago
#67572 closed defect (fixed)
gperftools @2.10: Build failure on arm64: error: expected unqualified-id
Reported by: | mascguy (Christopher Nielsen) | Owned by: | mascguy (Christopher Nielsen) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.8.1 |
Keywords: | arm64 | Cc: | neverpanic (Clemens Lang) |
Port: | gperftools |
Description
Apparently the CMake-based arch check for ARM differs from the autotools version, causing the check to fail during configure:
-- Performing Test ARM -- Performing Test ARM - Failed
Resulting in a build failure:
In file included from .../gperftools/work/gperftools-2.10/src/profiler.cc:38: .../gperftools/work/gperftools-2.10/src/getpc.h:189:49: error: expected unqualified-id return (void*)signal_ucontext.PC_FROM_UCONTEXT; // defined in config.h ^
Should be relatively easy to fix though.
Change History (13)
comment:1 Changed 18 months ago by neverpanic (Clemens Lang)
Cc: | neverpanic added |
---|
comment:2 Changed 18 months ago by Christopher Nielsen <mascguy@…>
comment:3 follow-up: 4 Changed 18 months ago by ryandesign (Ryan Carsten Schmidt)
Since that change is based on configure.build_arch
, I wonder what will happen with a universal build.
comment:4 Changed 18 months ago by mascguy (Christopher Nielsen)
Replying to ryandesign:
Since that change is based on
configure.build_arch
, I wonder what will happen with a universal build.
Yep, universal testing is on my list too. But the committed fix doesn't work anyway, so I need to scrutinize the ARM check logic. (One key difference, is that I added libunwind
to the mix: It's supposed to provide more reliable stack tracing, but also introduces another variable vis-a-vis the previous port iteration.)
Will look at this more closely tomorrow.
comment:5 Changed 18 months ago by Christopher Nielsen <mascguy@…>
comment:6 follow-up: 8 Changed 18 months ago by mascguy (Christopher Nielsen)
We'll soon know whether the latest fix - avoiding use of libunwind
for ARM, universal or not - fixes the issue.
If not, I might need some assistance from a kind soul with an ARM Mac, as I have no way to test such changes locally.
comment:7 Changed 18 months ago by Christopher Nielsen <mascguy@…>
comment:8 follow-up: 10 Changed 18 months ago by mascguy (Christopher Nielsen)
Replying to mascguy:
We'll soon know whether the latest fix - avoiding use of
libunwind
for ARM, universal or not - fixes the issue.If not, I might need some assistance from a kind soul with an ARM Mac, as I have no way to test such changes locally.
Unfortunately removing libunwind
from the mix doesn't help ARM.
Comparing the project's arch check logic, it looks like it's identical between autotools and cmake: Essentially it's just compiling the following C file:
int main (void) { return __arm__ ; return 0; }
So I'm stumped, unless there's a difference in the various C/CXX flags passed during compilation of that file. (Which is certainly possible, with cmake now in the mix.)
But if anyone with an ARM machine is interested in assisting, that would be great!
comment:9 Changed 18 months ago by ryandesign (Ryan Carsten Schmidt)
Performing C++ SOURCE FILE Test ARM failed with the following output: Change Dir: /opt/bblocal/var/macports/build/_opt_bblocal_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_gperftools/gperftools/work/build/CMakeFiles/CMakeTmp Run Build Command(s):/usr/bin/make -f Makefile cmTC_967db/fast && /Library/Developer/CommandLineTools/usr/bin/make -f CMakeFiles/cmTC_967db.dir/build.make CMakeFiles/cmTC_967db.dir/build Building CXX object CMakeFiles/cmTC_967db.dir/src.cxx.o /usr/bin/clang++ -DARM -pipe -Os -Wno-deprecated-declarations -Wno-error=unknown-warning-option -Wno-unknown-warning-option -DNDEBUG -I/opt/bblocal/include -stdlib=libc++ -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk -arch arm64 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk -mmacosx-version-min=13.0 -std=gnu++17 -MD -MT CMakeFiles/cmTC_967db.dir/src.cxx.o -MF CMakeFiles/cmTC_967db.dir/src.cxx.o.d -o CMakeFiles/cmTC_967db.dir/src.cxx.o -c /opt/bblocal/var/macports/build/_opt_bblocal_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_gperftools/gperftools/work/build/CMakeFiles/CMakeTmp/src.cxx /opt/bblocal/var/macports/build/_opt_bblocal_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_gperftools/gperftools/work/build/CMakeFiles/CMakeTmp/src.cxx:1:21: error: use of undeclared identifier '__arm__' int main() { return __arm__; } ^ 1 error generated. make[1]: *** [CMakeFiles/cmTC_967db.dir/src.cxx.o] Error 1 make: *** [cmTC_967db/fast] Error 2
__arm__
is not defined on Apple Silicon Macs, but __arm64
and __arm64__
are:
% cc -dM -E - < /dev/null | grep __arm #define __arm64 1 #define __arm64__ 1
comment:10 Changed 18 months ago by ryandesign (Ryan Carsten Schmidt)
Looking at the config.h from @2.10_2 (using cmake) on an Apple Silicon Mac:
/* How to access the PC from a struct ucontext */ #define PC_FROM_UCONTEXT
CMake is determining this with code in cmake/PCFromUContext.cmake.
Compared to config.h from @2.10_0 (using autotools) on the same Mac:
/* How to access the PC from a struct ucontext */ #define PC_FROM_UCONTEXT uc_mcontext->__ss.__pc
Autotools is determining this with code in m4/pc_from_ucontext.m4.
Apple Silicon support was added to m4/pc_from_ucontext.m4 3 years ago but was never added to cmake/PCFromUContext.cmake.
comment:11 Changed 18 months ago by ryandesign (Ryan Carsten Schmidt)
Keywords: | arm64 added; arm removed |
---|---|
Summary: | gperftools: arm: cmake arch check broken, causing build failures → gperftools @2.10: Build failure on arm64: error: expected unqualified-id |
comment:12 Changed 18 months ago by Christopher Nielsen <mascguy@…>
comment:13 Changed 18 months ago by mascguy (Christopher Nielsen)
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Ryan, thanks for digging into this, and providing more insight into the detection logic. Much appreciated!
Now that the ARM build has been fixed, I requeued builds for bear
, which was blocked by this. Closing as fixed.
In 0198f032b59ce3a32bfa13571c39d7bd93f66bb9/macports-ports (master):