gperftools @2.10: Build failure on arm64: error: expected unqualified-id

[mascguy (Christopher Nielsen)]

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.

[Christopher Nielsen <mascguy@…>]

In 0198f032b59ce3a32bfa13571c39d7bd93f66bb9/macports-ports (master):

gperftools: arm: bypass broken cmake arch check
See: #67572

[ryandesign (Ryan Carsten Schmidt)]

Since that change is based on configure.build_arch, I wonder what will happen with a universal build.

[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.

[Christopher Nielsen <mascguy@…>]

In c3fe13081a1b21ff1fed2d30a9d4f90b1c35636b/macports-ports (master):

gperftools: arm: don't use libunwind
See: #67572

[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.

[Christopher Nielsen <mascguy@…>]

In 751ed025f8e5d08cd309bb206924edc3ee6085e2/macports-ports (master):

gperftools: avoid use of libunwind across-the-board

• Mirrors previous setup of port, when building via autotools

See: #67572

[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!

[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

[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.

[Christopher Nielsen <mascguy@…>]

In cd2dc2f2c4de20004f72cd8aa08ba6247ac3e6f6/macports-ports (master):

gperftools: fix cmake arm detection logic
See: #67572

[mascguy (Christopher Nielsen)]

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.