#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@…>

In 0198f032b59ce3a32bfa13571c39d7bd93f66bb9/macports-ports (master):

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

comment:3 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 in reply to:  3 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@…>

In c3fe13081a1b21ff1fed2d30a9d4f90b1c35636b/macports-ports (master):

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

comment:6 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@…>

In 751ed025f8e5d08cd309bb206924edc3ee6085e2/macports-ports (master):

gperftools: avoid use of libunwind across-the-board

  • Mirrors previous setup of port, when building via autotools

See: #67572

comment:8 in reply to:  6 ; 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 in reply to:  8 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 failuresgperftools @2.10: Build failure on arm64: error: expected unqualified-id

comment:12 Changed 18 months ago by Christopher Nielsen <mascguy@…>

In cd2dc2f2c4de20004f72cd8aa08ba6247ac3e6f6/macports-ports (master):

gperftools: fix cmake arm detection logic
See: #67572

comment:13 Changed 18 months ago by mascguy (Christopher Nielsen)

Resolution: fixed
Status: assignedclosed

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.

Note: See TracTickets for help on using tickets.