Symbol scanning produces errors with Makefile project due to missing argument to -arch flag

Answered

Hiya

Whenever automatic symbol scanning is invoked in my Makefile project I get multiple errors of the form 

Compiler exited with error code 1: /usr/bin/c++ -xc++ -DUSE_TYPED_RSET -DUNIX -Ddarwin -O3 -g -Wall -std=c++11 -arch -fno-common -c -fpch-preprocess -v -dD -E
Apple clang version 15.0.0 (clang-1500.3.9.4)
Target: unknown-apple-darwin23.4.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
clang: error: invalid arch name '-arch -fno-common'

This is because the -arch parameter to the build should be followed by the architecture name, in my case `arm64`.

The project is https://github.com/mdavidsaver/pvxs which requires https://github.com/epics-base/epics-base to compile (set EPICS_BASE=/path/to/epics-base in your environment) and the libeevent distribution.  The Makefile is quite complex but it builds correctly from the CLion Makefile build system with both standard and gnu toolchains with no errors, and from the command-line with make -j8 all.  

So it would seem that there is a difference in the way that Make is invoked from the CLion Makefile build system (or command-line) and when CLion does its automatic symbol scan, such that the variable containing the target architecture is not set in the latter case causing the error we see in the output.  

Can anyone help me debug this issue by providing details as to how CLion invokes make during a symbol scan or any other reasons you may think of for this error?  Interestingly, all other output from the regular build process sets the architecture variable and flags correctly. Its only when the symbol scan is invoked by CLion that the problem appears.  

The way I'm invoking the symbol scan is by executing the `Reload Makefile Project` action with the Makefile configuration Build target set to all and the Clean target set to clean inc.   The Reload completes successfully but an error notification pops up and following its Display link shows the error text I included above.

0
1 comment

Discussed in CPP-38163. Just to set the record straight here, too: the problem turned out to be CPP-37029.

0

Please sign in to leave a comment.