I am using gcov for analyzing coverage of .c file. on compilation it is generation .gcna but on execution it is not generating gcda file.
I already applied -fprofile-arcs -ftest-coverage flags in my run.sh script. And using library -lgcov -coverage.
I am running it on arm compiled environment
Related
Problem description:
I have an Xcode workspace that references two Xcode projects. The first Xcode project (lib.xcodeproj) builds an iOS static library while the second project (app.xcodeproj) builds an iOS app that consumes the static library. app.xcodeproj references lib.xcodeproj, i.e. lib.xcodeproj is listed in app.xcodeprojs Link Binary With Libraries build phase.
So, the setup is as follows:
MyApp.xcworkspace
|
+-app.xcodeproj---+
| | Referenced via build phase
+-lib.xcodeproj <-+
If I open this workspace in Xcode and build an archive out of it (Productmenu -> Archive) everything compiles as expected and I end up with an .xcarchive. The same applies if I build via command line (xcodebuild archive -workspace MyApp.xcworkspace ...).
However, dumping the content of the dSYM file that is generated as part of the archive reveals that it does not contain the debugging symbols of the static library (lib.xcodeproj). To be more specific, executing the command
dwarfdump MyApp.xcarchive\dSYMs\MyApp.app.dSYM\Contents\Resources\DWARF\MyApp > dwarfdump.txt
generates a text file that confirms that all debugging symbols of the app itself are there but the debugging symbols of the static library are not.
This only happens when creating archives. Producing a build via Product menu -> Build produces a dSYM file containing all debugging symbols of the app AND the static library.
Now, this isn't exactly new. That behavior was already observed ages ago and I found three different SO posts describing the same behavior (here, here and here). However, these posts are more than 7 years ago!
What I would like to know:
How do other people create archives of apps that are using static libraries created in the same workspace?
Seems that without scripting and just with Xcode itself this is an unsolvable problem.
Analysis (for the curious reader):
I've analyzed this issue and strongly suspect it is a long lasting Xcode issue. Here's what I found:
Building the workspace via xcodebuild build -workspace MyApp.xcworkspace ... produces the following sequence of log entries:
CompileC <static library file 1>
CompileC <static library file 2>
...
Libtool <instructions to create the static library>
...
CompileC <app file 1>
CompileC <app file 2>
...
GenerateDSYMFile <instructions to create the dSYM file>
...
CodeSign <instructions to sign the app>
Building the workspace via xcodebuild archive -workspace MyApp.xcworkspace ... produces the following sequence of log entries:
CompileC <static library file 1>
CompileC <static library file 2>
...
Libtool <instructions to create the static library>
Strip <instructions to strip the debugging symbols from the static library>
...
CompileC <app file 1>
CompileC <app file 2>
...
GenerateDSYMFile <instructions to create the dSYM file>
Strip <instructions to strip the debugging symbols from the app>
...
CodeSign <instructions to sign the app>
From these two sequences we see that when an archive is created we get calls to the strip tool. This tool strips out the debugging symbols from a binary. So, when the dSYM file gets created the static library simply does not contain any debugging symbols anymore.
When GenerateDSYMFile is executed, all that is left are the debugging symbols within the app. These symbols are then also stripped. BUT they are stripped after the dSYM file already exists and not before as is the case with the static library.
Now, there are build settings designed to influence that behavior. I found the following and tested whether they have an effect:
Strip Debug Symbols During Copy (COPY_PHASE_STRIP): Made no difference, the sequence is unchanged
Strip Linked Product (STRIP_INSTALLED_PRODUCT): Made no difference, the sequence is unchanged
Strip Style (STRIP_STYLE): Changes the argument that is passed to the strip tool. But I cannot prevent the information from being stripped nonetheless.
So, with that information I dare to make the statement that the build process used by Xcode for this constellation is simply incorrect. The correct way would be to run GenerateDSYMFile and only after that run strip for the static library and the app.
Background:
On a Windows 10 PC, I have a c++ codebase. Using CMAKE I generate an Mingw-w64 project (using Eclipse IDE) and a Visual Studio 2017 project. I like compiling my projects with different build systems as each gives different warnings and errors.
As part of the Mingw build, I can enable clang-tidy checks using CMAKE's CXX_CLANG_TIDY. This works well, producing a co-compile showing many interesting warnings from clang-tidy.
When I installed mingw-w64, llvm and VS I was careful not to allow these to populate the PATH environment variable, so a regular command prompt won't run gcc, clang, or CL or any associated tools. The environment is set up by a batch file before launching Eclipse or Visual Studio.
This has worked well for years (I'm still using clang 7.0.1). Both IDE's compile the same code base just fine...
Until I upgrade to Visual Studio 2019, including it's own copy of clang 10.0.0.
Now, my original clang 7.0.1 has stopped working! As I only use clang-tidy it took a while to narrow this down, but the original clang is looking for the system headers in the new clang's include location. The headers it finds are too new and the build fails.
I have found many things to try on SO and elsewhere (although any pointers are welcome) like supplying a --sysroot switch, so this question is more specific:
Question:
When there are no apparent environment variables to point to a specific clang location, where does clang find it's default target triple and therefore it's -internal-isystem paths? Why does my previously-working clang installation now look for it's system headers in a more recently installed clang location?
With a Windows command prompt:
cd C:\Program Files\LLVM\bin (my original clang location)
C:\Program Files\LLVM\bin>clang test.cpp -v
clang version 7.0.1 (tags/RELEASE_701/final)
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\Program Files\LLVM\bin
"C:\\Program Files\\LLVM\\bin\\clang.exe" -cc1 -triple x86_64-pc-windows-msvc19.26.28806 -emit-obj -mrelax-all -mincremental-linker-compatible -disable-free -disable-llvm-verifier -discard-value-names -main-file-name test.cpp -mrelocation-model pic -pic-level 2 -mthread-model posix -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -dwarf-column-info -debugger-tuning=gdb -momit-leaf-frame-pointer -v -resource-dir "C:\\Program Files\\LLVM\\lib\\clang\\7.0.1" -internal-isystem "C:\\Program Files\\LLVM\\lib\\clang\\7.0.1\\include" -internal-isystem "C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\Community\\VC\\Tools\\MSVC\\14.26.28801\\include" -internal-isystem "C:\\Program Files (x86)\\Windows Kits\\10\\Include\\10.0.18362.0\\ucrt" -internal-isystem "C:\\Program Files (x86)\\Windows Kits\\10\\include\\10.0.18362.0\\shared" -internal-isystem "C:\\Program Files (x86)\\Windows Kits\\10\\include\\10.0.18362.0\\um" -internal-isystem "C:\\Program Files (x86)\\Windows Kits\\10\\include\\10.0.18362.0\\winrt" -fdeprecated-macro -fdebug-compilation-dir "C:\\Program Files\\LLVM\\bin" -ferror-limit 19 -fmessage-length 120 -fno-use-cxa-atexit -fms-extensions -fms-compatibility -fms-compatibility-version=19.26.28806 -std=c++14 -fdelayed-template-parsing -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o "C:\\Users\\Foo\\AppData\\Local\\Temp\\test-c0aac1.o" -x c++ test.cpp
clang -cc1 version 7.0.1 based upon LLVM 7.0.1 default target x86_64-pc-win32
#include "..." search starts here:
#include <...> search starts here:
C:\Program Files\LLVM\lib\clang\7.0.1\include
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.26.28801\include
C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\ucrt
C:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\shared
C:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\um
C:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\winrt
End of search list.
In file included from test.cpp:1:
In file included from C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.26.28801\include\string:9:
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.26.28801\include\yvals_core.h:462:2: error:
STL1000: Unexpected compiler version, expected Clang 9.0.0 or newer.
#error STL1000: Unexpected compiler version, expected Clang 9.0.0 or newer.
Where C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.26.28801\include is the installed-only-today clang 10.0.0 location, so clearly not compiled into clang.exe.
Where does clang get it's defaults from?
The only "ground truth" is the code of clang itself.
With multiple versions of MSVC installed, clang will use different tricks to setup environment when initializing MSVC toolchain driver (see MSVCToolChain::MSVCToolChain() at the link above)
To solve a similar case I used VCToolsInstallDir environment variable to direct clang to old MSVC include paths.
I am trying to run lcov and gcov on android platform for unit test coverage.
I am able to generate .gcno file and .gcda file successfully via the flags.
Android.mk
LOCAL_CFLAGS += -g -O0 --coverage
-fprofile-arcs -ftest-coverage
LDFLAGS += -fprofile-arcs -ftest-coverage
LOCAL_LDLIBS := --coverage
And I have made sure gcov and gcc are same version in my case 4.9 but I get this weird
error:file.gcno:version '402*', prefer '409*'
BR
M S Kha
I am trying to compile the freetype2 library for arm7, using Xcode's command line tools in OSX. I am using the following parameterisation of the project's configure script:
Compiling FreeType for iPhone?
These errors were produced when running the script:
configure:3426: /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/gcc -E conftest.c
In file included from conftest.c:10:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/llvm-gcc-4.2/bin/../lib/gcc/i686-apple-darwin10/4.2.1/include/limits.h:15:25: error: limits.h: No such file or directory
configure:3426: /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/gcc -E -traditional-cpp conftest.c
conftest.c:12: error: assert.h: No such file or directory
configure:3426: /lib/cpp conftest.c
/Volumes/DATA/filestore/development/libs/c/freetype2/extract/2.5.3/builds/unix/configure: line 1600: /lib/cpp: No such file or directory
configure:3465: result: /lib/cpp
configure:3485: /lib/cpp conftest.c
/Volumes/DATA/filestore/development/libs/c/freetype2/extract/2.5.3/builds/unix/configure: line 1600: /lib/cpp: No such file or directory
I can see that the missing files actually do exist in the directories output in the error messages.
CFLAGS and LDFLAGS contain the following parameter, which should allow for the inclusion of system header files:
-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/
The other odd thing that I noticed with these error messages, is that the architecture identifier in the directory structures is i686-apple-darwin10. The -arch armv7 compiler flag is being used, so why are i686-apple-darwin10 directories being inspected at all?
* UPDATED *
I also tried parameterising the configure script as per another example:
https://stackoverflow.com/a/12594507/1704014
The following error terminated its execution:
checking for suffix of native executables... ld: library not found for -lcrt1.10.6.o
collect2: ld returned 1 exit status
configure: error: native C compiler is not working
This also indicates that a different target architecture (OSX 10.6) is being built against, not arm7.
Any help much appreciated.
The problem in my OSX build environment was the Xcode command line tools installation. I reinstalled the latest distribution of the tools, and was able to compile successfully from then on.
To build the freetype2 library for arm7 and arm7s architectures, I found the following suggested commands useful:
https://stackoverflow.com/a/12594507/1704014
Can someone tell me, where to find a detailed guide, how to build the Boost-Libraries for using it on the iPhone-Device.
I've allready build the libs for Mac and can use them in my project (only on iPhone-Simulator). While building the project for iPhone-Device, XCode haunts me a warning: "file is not of required architecture" ond some other errors.
Please Help
Start a new project in Xcode using the iPhone Static Library project template.
Then import the source and headers, and compile it that way. The result should be an iPhone compatible static library
I started here:
http://lists.boost.org/boost-build/2009/02/21326.php
With most of Boost you probably don't need to actually compile it, just include the useful headers. In my case, I just did the compiler define in my own Xcode project.
Hey I have updated Pete Goodliffes script in my openFrameworks addon:
It currently has arm64, armv7, i386, x86_64
Boost 1.59.0 or previous
libc++ / std=c++11 -- Now optional release for libstdc++
Precompiled and Script to build yourself (so if you need libstdc++ quite easy to change)
Supports Xcode 7
[https://github.com/danoli3/ofxiOSBoost][1]
For boost libraries which have only headers files (.hpp) you can just set header search path from your project to them.
For boost libraries with sources you can build static libraries for both ios phone/simulator with next simple steps:
Download and unpack a boost release archive (from https://www.boost.org/users/download/) e.g.: https://boostorg.jfrog.io/artifactory/main/release/1.77.0/source/boost_1_77_0.tar.bz2
Run bootstrap.sh with needed libraries to build for instance 'context' (format =library1,library2,...):
./bootstrap.sh --with-libraries=context
Add toolsets with correct paths to installed SDKs to project-config.jam:
# IOS ARM64
using clang : iphoneos
: xcrun clang -arch arm64 -stdlib=libc++ -std=c++11 -miphoneos-version-min=12.0 -fvisibility-inlines-hidden -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk
;
# IOS x86_64
using clang : iphonesimulator
: xcrun clang -arch x86_64 -stdlib=libc++ -std=c++11 -miphoneos-version-min=12.0 -fvisibility-inlines-hidden -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk
;
Create and run build.sh script (where lib name is libboost_<name>.a):
lib=libboost_context.a
dir='stage/lib'
# Build arm64
./b2 -a -j4 toolset=clang-iphoneos binary-format=mach-o abi=aapcs link=static stage
mv $dir/$lib $dir/arm64_$lib
# Build x86_64
./b2 -a -j4 toolset=clang-iphonesimulator binary-format=mach-o abi=sysv link=static stage
mv $dir/$lib $dir/x86_64_$lib
# Make fat
lipo -create $dir/arm64_$lib $dir/x86_64_$lib -output $dir/$lib
Now you have next compiled static libraries in "/stage/lib" dir for boost context: arm64_libboost_context.a, x86_64_libboost_context.a and fat one libboost_context.a.
We use boost too. To simplify its inclusion into new applications I have created a Xcode project you can drop into your workspace to include boost. It is based on a Makefile so you need the Xcode commandline tools installed.
The project is here https://github.com/Cogosense/iOSBoostFramework.
Clone the project into your workspace, then click on Menu File->"Add Files to workspace". Select iOSBoostFramework/iOSBoostFramework.xcodeproj in the file finder and click add.
The Makefile in the iOSBoostFramework directory controls what is built and how it is built. There is support for Xcode workspace dependencies, bitcode generation, and only the target architectures selected by Xcode are built.
The following libraries are built test, thread, atomic, signals, filesystem, regex, program_options, system date_time, serialization, exception, locale, and random.
All the separate libraries and architectures are combined, the final build output is a FAT boost.framework Framework bundle which can be linked into the application.
The version of boost is specified in the Makefile (currently 1.64.0), it is downloaded, built for all active architectures and installed in the BUILT_PRODUCTS_DIR specified by xcode.
The previous answer helped me when I wanted to build boost for the arm simulator. When you have a Mac with M1 processor and want to use the simulator, you cannot use the arm64 build for the iPhone.
I added this to the project-config.jam:
# IOS Arm Simulator
using clang : iphonesimulatorarm64
: xcrun clang -arch arm64 -stdlib=libc++ -std=c++11 -miphoneos-version-min=10.0 -fvisibility-inlines-hidden -target arm64-apple-ios10.0-simulator -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk ;
Then pass toolset=clang-iphonesimulatorarm64 to the b2 command.