Discrepancy with issues found in scan-build vs. xcode - objective-c

I am using scan-build (checker-258) from the command line to do static analysis on my iOS project and find that uncovers far fewer issues than xcode (about 60% less). If I set xcode 4.2 to use scan-build from checker-258 it finds all the issues (and more). This may be because the command line version us using the old (not modern) run time as it is finding issues like:
error: synthesized property 'foo' must either be named the same as a compatible ivar or must explicitly name an ivar
#synthesize foo;
^
Here is the command I'm using to run the analysis:
scan-build --use-cc=`which clang` -k -o scan-reports xcodebuild -target MyTarget -project myproject.xcodeproj -sdk iphonesimulator5.0 -configuration Debug clean build
Thanks in advance.

Yes, the version of the static analyzer that ships with Xcode 4.2 is older than the version on the clang website. There are instructions here on how to use the newer version within Xcode: http://clang-analyzer.llvm.org/xcode.html

Try to use this command: scan-build -k -V -o scan-reports xcodebuild clean build -configuration Debug -sdk iphoneos5.0 -xcconfig="myConfig.xcconfig"
Where myconfig contains the CODE_SIGNING_IDENTITY="", PROVISIONING_PROFILE=""

Related

CMake build fails with Xcode 12 and CMAKE_IOS_INSTALL_COMBINED=YES

EDIT This is a known CMake issue.
With Xcode 11 (specifically Xcode 11.2.1) I used to be able to cross-compile my project for iOS with this command:
cd /path/to/project
mkdir build
cd build
cmake .. -G Xcode -DCMAKE_SYSTEM_NAME=iOS \
"-DCMAKE_OSX_ARCHITECTURES=arm64;x86_64" \
-DCMAKE_XCODE_ATTRIBUTE_ONLY_ACTIVE_ARCH=NO \
-DCMAKE_IOS_INSTALL_COMBINED=YES \
-DCMAKE_INSTALL_PREFIX=install
cmake --build . --config Release --target install
This created a build with two slices, one slice for the arm64 architecture (for running on a real device) and one slice for the x86_64 architecture (for running in a simulator on an Intel-based dev environment).
After upgrading to Xcode 12 (specifically Xcode 12.3) this no longer works. The build consistently fails with this error message (line break added by me):
error: unable to attach DB: error: accessing build database "/path/to/project/build/ios/build/XCBuildData/build.db":
database is locked Possibly there are two concurrent builds running in the same filesystem location.
The issue seems to be a post-build rule that CMake creates for the install target. In that post-build rule a second build is initiated while the first one is still in progress.
if test "$CONFIGURATION" = "Release"; then :
cd /path/to/project/build/ios
/usr/local/Cellar/cmake/3.19.2/bin/cmake -DBUILD_TYPE=$CONFIGURATION -DEFFECTIVE_PLATFORM_NAME=$EFFECTIVE_PLATFORM_NAME -P cmake_install.cmake
fi
The build succeeds when I no longer set CMAKE_IOS_INSTALL_COMBINED to YES, but then the resulting build only contains one slice (arm64 in my case, presumably because this is the first architecture that is listed in CMAKE_OSX_ARCHITECTURES).
I'm considering making a separate build for each architecture, and then stitching the slices together manually. Before I go down that road, has anyone been able to find a more elegant solution?
Environment: macOS 11.1, Xcode 12.3, CMake 3.19.2
The CMake 3.19 release notes contain this hint:
The Xcode generator now uses the Xcode “new build system” when generating for Xcode 12.0 or higher. See the CMAKE_XCODE_BUILD_SYSTEM variable. One may use -T buildsystem=1 to switch to the legacy build system.
The workaround, for the moment, is therefore to add the -T option to the build system generation command line:
cmake .. -G Xcode -T buildsystem=1
-DCMAKE_SYSTEM_NAME=iOS \
"-DCMAKE_OSX_ARCHITECTURES=arm64;x86_64" \
-DCMAKE_XCODE_ATTRIBUTE_ONLY_ACTIVE_ARCH=NO \
-DCMAKE_IOS_INSTALL_COMBINED=YES \
-DCMAKE_INSTALL_PREFIX=install
This should work as long as Xcode still supports the legacy build system. The Xcode 12 Release Notes have this to say on the matter:
The legacy build system is deprecated, and will be removed in a future release. (62742902)
So the -T buildsystem=1 option can only be considered a temporary workaround.

iOS 14, lipo error while creating library for both device and simulator

We have been using lipo command to create a framework which works on both device and simulator when integrated in other project.
following are the build commands used to generate device and simulator builds
xcodebuild -target SampleSDK ONLY_ACTIVE_ARCH=NO -configuration ${CONFIGURATION} -sdk iphonesimulator BUILD_DIR="${BUILD_DIR}" BUILD_ROOT="${BUILD_ROOT}" OBJROOT="${OBJROOT}/DependentBuilds"
xcodebuild -target SampleSDK ONLY_ACTIVE_ARCH=NO -configuration ${CONFIGURATION} -sdk iphoneos BUILD_DIR="${BUILD_DIR}" BUILD_ROOT="${BUILD_ROOT}" OBJROOT="${OBJROOT}/DependentBuilds"
after this we are copying swift modules from iphonesimulator(if it exists) to the copied framework dir
cp -R "$BUILD_DIR/${CONFIGURATION}-iphonesimulator/${PRODUCT_NAME}/Modules/SampleSDK.swiftmodule/" "${UNIVERSAL_OUTPUTFOLDER}/${PRODUCT_NAME}/Modules/${PROJECT_NAME}.swiftmodule/"
and then lipo command
lipo -create "$BUILD_DIR/${CONFIGURATION}-iphonesimulator/${PRODUCT_NAME}/${PROJECT_NAME}" "${BUILD_DIR}/${CONFIGURATION}-iphoneos/${PRODUCT_NAME}/${PROJECT_NAME}" -output "${UNIVERSAL_OUTPUTFOLDER}/${PRODUCT_NAME}/${PROJECT_NAME}"
the above command is failing with following error
fatal error: lipo: /path/to/Library/Developer/Xcode/DerivedData/Sample-bhfmlauxsdympmdjkjyvujaljevg/Build/Products/Debug-iphonesimulator/SampleSDK.framework/SampleSDK and /Users/rramshettysiddaraju/Library/Developer/Xcode/DerivedData/Sample-bhfmlauxsdympmdjkjyvujaljevg/Build/Products/Debug-iphoneos/SampleSDK.framework/SampleSDK have the same architectures (arm64) and can't be in the same fat output file
I tried one of the answers in stackoverflow, about adding user-defined setting VALID_ARCHS and then removing it. but that didnt work
The reason for the error is that Xcode 12 includes a slice for the "arm64" architecture when building for the simulator (in addition to the usual "i386" and "x86_64" architectures for Xcode <12). This is probably for supporting the simulator on (future) Macs using Apple Silicon processors. As your device build also includes the "arm64" architecture, lipo does not know which of the two "arm64" slices you want and refuses to create a combined fat binary framework.
As a workaround, you can either exclude the "arm64" architecture from the simulator build by appending the EXCLUDED_ARCHS build variable:
xcodebuild -target SampleSDK ONLY_ACTIVE_ARCH=NO -configuration ${CONFIGURATION} -sdk iphonesimulator BUILD_DIR="${BUILD_DIR}" BUILD_ROOT="${BUILD_ROOT}" OBJROOT="${OBJROOT}/DependentBuilds" EXCLUDED_ARCHS="arm64"
Alternatively, use lipo -remove to remove the "arm64" architecture from the simulator build before combining the simulator and device frameworks into one:
lipo -remove arm64 "$BUILD_DIR/${CONFIGURATION}-iphonesimulator/${PRODUCT_NAME}/${PROJECT_NAME}" -output "$BUILD_DIR/${CONFIGURATION}-iphonesimulator/${PRODUCT_NAME}/${PROJECT_NAME}"
In the long run, you might be better off building an XCFramework, which should support devices and simulators without the need for using lipo. But I haven’t tested this yet.
styv is right.
You can also set Excluded Architectures in the Xcode Build Settings
#xtyv's suggestion is spot on: using an XCFramework is the way to go.
Here is a Makefile to generate an XCFramework (apply substitutions and add other architectures accordingly to your scenario):
ARCHS = aarch64-apple-ios aarch64-apple-ios-sim
LIB = lib<library_name>.a
XCFRAMEWORK = <framework_name>-iOS.xcframework
all: $(XCFRAMEWORK)
.PHONY: $(ARCHS)
$(ARCHS): %:
cargo build --target $#
$(XCFRAMEWORK): $(ARCHS)
xcodebuild -create-xcframework $(addprefix -library , $(foreach arch, $(ARCHS),$(wildcard target/$(arch)/debug/$(LIB)))) -headers <header_file> -output $#

OCLint reports compiler errors due to its inability to find #import-ed header files

I am trying to integrate OCLint 0.13 to check lint violations in my ObjC based iOS project.
As per this guide I created an aggregate target in Xcode to run a xcodebuild clean build followed by oclint-xcodebuild to generate a compile_commands.json. I am able to run the clang command from the generated compile_commands.json file. However, in html report generated by oclint-json-compilation-database command, while processing file like NEORepos/Public/ResourceObservables/NEOAggregatedObservable.h, I see compiler errors like 'NEOObservables/NEOObservable.h' file not found even though the said header file is present at NEOObservables/Public/Observables/NEOObservable.h.
How can I get rid of these compiler errors which are preventing some of my source files from being linted?
Running the clang command from compile_commands.json generates the .o file, but OCLint doesn't seem to be able to compile using the json file.
I also tried adding a few more -I include paths, but it didn't help. All suggestions and pointers are welcome.
Here's a piece of (edited) log...
xcode_clean_build_command = xcodebuild -workspace 'Neo.xcworkspace' -scheme 'NeoSampleApp' -configuration 'Debug' clean build -dry-run -derivedDataPath /Users/username/Documents/git/ios-neo_linter/build/Neo -sdk iphonesimulator CLANG_ENABLE_MODULE_DEBUGGING=NO CODE_SIGNING_ALLOWED=NO CODE_SIGN_IDENTITY='' CODE_SIGNING_REQUIRED=NO ENABLE_BITCODE=NO COMPILER_INDEX_STORE_ENABLE=NO | tee xcodebuild.log
...
/oclint-xcodebuild
...
Generating the compile_commands.json ...
Picking NEORepos/Public/ResourceObservables/NEOAggregatedObservable.m
Picking NeoSampleApp/main.m
...
Shortlisted files for linting (2 out of 283) and creating a new compile_commands.json
...
Compiling /Users/username/Documents/git/ios-neo_linter/NEORepos/Public/ResourceObservables/NEOAggregatedObservable.m - Failed
Compiling /Users/username/Documents/git/ios-neo_linter/NeoSampleApp/main.m - Success
Analyzing /Users/username/Documents/git/ios-neo_linter/NeoSampleApp/main.m - Done
...
Generating lint report (if any)...
...
Executing command: oclint-json-compilation-database -e Pods -v -- -list-enabled-rules -no-analytics -enable-global-analysis -verbose --report-type html -o oclint.html -extra-arg=-Wno-everything
...
/usr/local/bin/oclint -p /Users/username/Documents/git/ios-neo_linter -list-enabled-rules -no-analytics -enable-global-analysis -verbose --report-type html -o oclint.html -extra-arg=-Wno-everything /Users/username/Documents/git/ios-neo_linter/NEORepos/Public/ResourceObservables/NEOAggregatedObservable.m /Users/username/Documents/git/ios-neo_linter/NeoSampleApp/main.m
The compiler error was due to the -dry-run flag that I was using. Since it was doing a dry run, it was not creating .hmap files that were needed (at least not in the right location) leading to <blah>.h file not found errors.
However, without -dry-run I would have to do a full build which is not acceptable for me. Will update if I find a solution with optimal performance.

Problems when compiling Objective C with Clang (Ubuntu)

I'm learning Objective-C language. Since I don't have a Mac, I'm compiling and running my code within Ubuntu 11.04 platform.
Until now, I was using gcc to compile. I've installed GNUStep and all was working. But then I started to try some Objective-C 2.0 features, like #property and #synthesize, that gcc does not allow.
So I tried to compile the code with Clang, but it seems that it is not correctly linking my code with the GNUStep libraries, not even with a simple Hello world program.
For example, if I compile the following code:
#import <Foundation/Foundation.h>
int main(void) {
NSLog(#"Hello world!");
return 0;
}
The output of the compiler is:
/tmp/cc-dHZIp1.o: In function `main':
test.m:(.text+0x1f): undefined reference to `NSLog'
/tmp/cc-dHZIp1.o: In function `.objc_load_function':
test.m:(.text+0x3c): undefined reference to `__objc_exec_class'
collect2: ld returned 1 exit status
clang: error: linker (via gcc) command failed with exit code 1 (use -v to see invocation)
The command I'm using to compile is
clang -I /usr/include/GNUstep/ test.m -o test
with the -I directive to include the GNUStep libraries (otherwise, Clang is not able to find Foundation.h).
I've googled my problem, and visited both GNUStep and Clang web pages, but I haven't found a solution to it. So any help will be appreciated.
Thanks!
The problem was that the library gnustep-base was not being used by the linker. So the solution to this was using the option -Xlinker, that sends arguments to the linker used by clang:
clang -I /usr/include/GNUstep/ -Xlinker -lgnustep-base test.m -o test
The statement "-X linker -lgnustep-base" made the magic. However, I had problems with this command related to the class that represents a string in Objective-C:
./test: Uncaught exception NSInvalidArgumentException, reason: GSFFIInvocation:
Class 'NXConstantString'(instance) does not respond to forwardInvocation: for
'hasSuffix:'
I could solve it adding the argument "-fconstant-string-class=NSConstantString":
clang -I /usr/include/GNUstep/ -fconstant-string-class=NSConstantString \
-Xlinker -lgnustep-base test.m -o test
In addition, I've tried with some Objective-C 2.0 pieces of code and it seems to work.
Thank you for the help!
You can try gcc compiler:
First of all install GNU Objective-C Runtime: sudo apt-get install gobjc
then compile: gcc -o hello hello.m -Wall -lobjc
You are not able to use ObjC 2.0 features because you're missing a ObjC-runtime supporting those. GCC's runtime is old and outdated, it doesn't support ObjC 2.0. Clang/LLVM doesn't have a acompanied runtime, you need to install the ObjC2-runtime from GNUstep (which can be found here: https://github.com/gnustep/libobjc2 ) and reinstall GNUstep using this runtime.
Here are some bash scripts for different Ubuntu versions, that do everything for you:
http://wiki.gnustep.org/index.php/GNUstep_under_Ubuntu_Linux
And please don't try to reinvent GNUstep make, instead, use it:
http://www.gnustep.org/resources/documentation/Developer/Make/Manual/gnustep-make_1.html
If you really don't think so, here is some excerpt from there:
1.2 Structure of a Makefile
Here is an example makefile (named GNUmakefile to emphasis the fact that it relies on special features of the GNU make program).
#
# An example GNUmakefile
#
# Include the common variables defined by the Makefile Package
include $(GNUSTEP_MAKEFILES)/common.make
# Build a simple Objective-C program
TOOL_NAME = simple
# The Objective-C files to compile
simple_OBJC_FILES = simple.m
-include GNUmakefile.preamble
# Include in the rules for making GNUstep command-line programs
include $(GNUSTEP_MAKEFILES)/tool.make
-include GNUmakefile.postamble
This is all that is necessary to define the project.
In your case replace all occurrences of simple with test and you're done
1.3 Running Make
Normally to compile a package which uses the Makefile Package it is purely a matter of typing make from the top-level directory of the package, and the package is compiled without any additional interaction.

GHUnit CLI Build: Availability.h errors

I am trying to do a command line build of a GHUnit target which builds fine inside Xcode. I am running the following command to build:
GHUNIT_CLI=1 xcodebuild -target
BasicBrowserUnitTest -configuration
Debug -sdk iphonesimulator4.0 build
It gets along pretty nice, until it finds an error in Availability.h, an SDK header:
/Xcode4
GM/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator4.0.sdk/usr/include/AvailabilityInternal.h:56:42:
error: operator '<' has no left
operand
Obviously, I haven't made any changes to Apple's stuff, why am I getting this error and how do I fix it?
The problem is that I wasn't specifying the correct SDK version:
GHUNIT_CLI=1 xcodebuild -target
BasicBrowserUnitTest -configuration
Debug -sdk iphonesimulator4.0 build
Needed to be:
GHUNIT_CLI=1 xcodebuild -target
BasicBrowserUnitTest -configuration
Debug -sdk iphonesimulator4.3
build
Or in this case, the latest SDK version.