I could successfully get code coverage information on our C++ code base on Linux using the GCC features of GCOV and the LCOV tool.
But I am having trouble in Mac OS X.
As Apple does not have the classic GCC compiler anymore, and we fear that the LLVM-GCC compiler would one day disappear too (LLVM-GCC is not even available as an option in Xcode 5.0) - we have decided to use Clang to compile our code.
While using the Clang compiler I am passing in these flags -->
-g -fprofile-arcs -ftest-coverage to generate the Code Coverage information.
I can see the .gcno files getting generated along with the object files.
When it comes to linking - "-lgcov” linker flag which works with GCC is not supported.
The code coverage on Clang / LLVM is now supported by the “profile_rt” library.
Unfortunately it’s a bit tricky to find this library because Apple for whatever reason decided not to include it in the default library path. Instead you’ll have to manually navigate to /usr/lib/ to link against it:
And as specified am linking against libprofile_rt.a library.
But i have linker issues.
But i keep getting these linker errors
Undefined symbols for architecture x86_64:
"_llvm_gcov_init", referenced from:
___llvm_gcov_init in Iso9660Reader.o
___llvm_gcov_init in AutoExtractCreator.o
___llvm_gcov_init in TempFilePath.o
___llvm_gcov_init in TempPath.o
___llvm_gcov_init in ReadDirectory.o
___llvm_gcov_init in OpenDirectory.o
___llvm_gcov_init in SpltPath.o
...
ld: symbol(s) not found for architecture x86_64
I also tried linking against the dynamic library - libprofile_rt.dylib found in
/usr/lib folder - But i still get the same issue.
This is Clang Version running on Mountain Lion.
clang --version
Apple LLVM version 5.0 (clang-500.2.75) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin12.5.0
Thread model: posix
I also have Xcode 5.0 and Developer Tools installed.
I solved this.
I was missing the following Linker Flags
-Wall -fprofile-arcs -ftest-coverage
Other Linker Flag -fprofile-arcs fixes the issue for me.
Build Settings > Other Linker Flags > -fprofile-arcs
The above answer did not work for me on OSX Yosemite (10.10.3) with Xcode 6.3.1. It seems that Apple moved these libraries around. I was able to get it to work with the following compile options:
-lclang_rt.profile_osx
-L/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/6.1.0/lib/darwin
Related
I want to compile the following project that's hosted on GitHub. I'm on MacOs High Sierra 10.13.5.
When I run make on the solver directory, it gives the following error after running gcc with the -static option:
g++ -o dapcstp src/bbnode.o src/bbtree.o src/bounds.o src/cputime.o
src/heur.o src/inst.o src/main.o src/options.o src/prep.o
src/procstatus.o src/sol.o src/stats.o src/timer.o src/util.o -static -
lboost_timer -lboost_system -lboost_chrono -lboost_program_options -
lboost_filesystem
ld: library not found for -lcrt0.o
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
make: *** [dapcstp] Error 1
In the answer to ld: library not found for -lcrt0.o on OSX 10.6 with gcc/clang -static flag it says the following:
This option will not work on Mac OS X unless all libraries (including libgcc.a) have also been compiled with -static. Since neither a static version of libSystem.dylib nor crt0.o are provided, this option is not useful to most people.
Is there a way I could circumvent this limitation and compile the project correctly on Mac ?
Looking at the project, the -static option is superfluous and counterproductive (even on system where static linking is supported). You can just remove it.
I'm trying to use the Undefined Behavior Sanitizer by building like this
gcc -fsanitize=undefined add.c -o add
also
clang -fsanitize=undefined -O add.c -o add
In both cases, I'm getting a file not found error:
ld: file not found: /Library/Developer/CommandLineTools/usr/bin/../lib/clang/8.0.0/lib/darwin/libclang_rt.ubsan_osx_dynamic.dylib
This is the output I get when running gcc -v and clang -v
Apple LLVM version 8.0.0 (clang-800.0.42.1)
Target: x86_64-apple-darwin15.6.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 8.0.0 (clang-800.0.42.1)
Target: x86_64-apple-darwin15.6.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
According to this news release, it is available in GCC and also the original homepage for it says it's been merged into LLVM. The linked to article says GCC 4.9 has it, which I assume I have (at least --the version numbering seems different but the article was written a few years ago and I have updated my system several times).
Question: how can I build an executable to use UBSan?
According to blog Friday Q&A 2015-07-03: Address Sanitizer
by Mike Ash:
Any idea why Apple clang doesn't support -fsanitize=undefined?
When I try that I get:
clang -fsanitize=undefined ub.c
...
ld: file not found: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/
bin/../lib/clang/8.0.0/lib/darwin/libclang_rt.ubsan_osx_dynamic.dylib
Spencer at 2016-12-21 01:23:59:
If you use -fsanitize=address,undefined it works. Hopefully this
helps anyone else who finds this post search for that error like I did.
Its not an ideal solution for us since they are separate components, and we have limited control over the environment and tools. We had to suspend some Address Sanitizer testing because Asan produces incorrect results with GCC inline assembly and use of ebp/rbp as a general purpose register. And here, the environment and tools are provided by Travis CI.
A bug report was filed with LLVM at Issue 33201, Apple Clang bundled with Xcode 8 does not reject -fsanitize=undefined when it should. It may be closed as off-topic since its an Apple Clang bug (we don't have an iTunes account to file the bug with Apple).
In order to use the undefined behavior sanitizer, I had to install and build LLVM with clang as well as libcxx and libcxxabi, even though my MacOS already came with a version of clang. (with the result that I now I have two versions of clang installed on my computer). From the llvm getting started page
cd where-you-want-llvm-to-live
svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm
cd where-you-want-llvm-to-live
cd llvm/tools
svn co http://llvm.org/svn/llvm-project/cfe/trunk clang
cd where-you-want-llvm-to-live
svn co http://llvm.org/svn/llvm-project/libcxx/trunk libcxx
svn co http://llvm.org/svn/llvm-project/libcxxabi/trunk libcxxabi
Now, I can use the undefined behavior sanitizer by running
/usr/local/bin/clang -fsanitize=undefined -O add.c -o add
I have a Fortran 90 program which uses lapack subroutines, and is successfully running on my Ubuntu system. Now I want to run it on Mac (OS X Version 10.11.4). I am using gfortran compiler as a part of gcc, installed from homebrew repositories, and lapack library, installed in /usr/local/lib/.
When I try to compile my code, I get the following error:
gfortran my_prog.f90 -L/usr/local/lib/ -llapack
Undefined symbols for architecture x86_64:
"_daxpy_", referenced from:
_zggbal_ in liblapack.a(zggbal.o)
...
"_ztrmv_", referenced from:
_zlarft_ in liblapack.a(zlarft.o)
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
After some google search I understood that the problem is because the linking. When I compile it like this, everything works well:
gfortran my_prog.f90 -llapack
Also when llapack from framework accelerate is used, the compiler doesn't complain.
gfortran my_prog.f90 -framework accelerate
The libraries are of x86-64 architecture:
lipo -info *.a
input file libfftw3.a is not a fat file
input file liblapack.a is not a fat file
Non-fat file: libfftw3.a is architecture: x86_64
Non-fat file: liblapack.a is architecture: x86_64
LAPACK is not the only one which gives me an error, later the same problem appears with FFTW3. Could you please give me a hint to the solution to this problem?
FFTW is not part of the accelerate framework. If you want to use it, you need to add -lfftw3 to the compile options as well.
If the libraries are not in the default LIBRARY_PATH, you might need to specify -L/path/to/fftw/libs as well. The same holds for the include path if you are using its modules -I/path/to/fftw/includes.
Note that the vDSP part of the library also provides FFT implementations. You might not need FFTW at all.
I'm trying to build binutils for generating MIPS code on Mac OS X.
I found this site (http://www.theairportwiki.com/index.php/Building_a_cross_compile_of_GCC_for_MIPS_on_OS_X) from How to build GCC 4.8.x on Mac OS X host for MIPS target, and followed the instructions.
I install the gcc-4.8 from brew, and installed source code of binutils and gcc. This is the compilation option setup.
$ export CC=/usr/local/bin/gcc-4.8
$ export CXX=/usr/local/bin/g++-4.8
$ export CPP=/usr/local/bin/cpp-4.8
$ export LD=/usr/local/bin/gcc-4.8
$ export PREFIX=/opt/cross/gcc-mips
$ export CFLAGS=-Wno-error=deprecated-declarations
Then I configure, and make the bintuils.
The issue is that after building static libraries I have an error message that archive is not built for x86_64, and then I have a bunch of undefined symbol error.
ignoring file ./../intl/libintl.a, file was built for archive which is not the architecture being linked (x86_64): ./../intl/libintl.a
Undefined symbols for architecture x86_64:
"__bfd_abort", referenced from:
_fix_new_internal in write.o
_size_seg in write.o
Googling to find that I need to setup AR (archive) variable also from https://github.com/tpoechtrager/osxcross/issues/11. I added export AR=/usr/local/bin/gcc-ar-4.8, but I have another error message because gcc-ar-4.8 doesn't work.
/usr/local/bin/gcc-ar-4.8
/usr/local/bin/gcc-ar-4.8: Cannot find plugin 'liblto_plugin.so'
Googling again to find that gcc-ar doesn't work with Mac OS X (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56893).
gcc-ar is for use with newer GNU binutils only as that is the only ar which supports plugins.
Apple's ar does not support plugins (though it could be made to; it will be a different plugin interface than the GNU BFD
plugin interface which GCC supports right now).
I just created a dumb 'liblto_plugin.so' file in /usr/local/Cellar/gcc48/4.8.4/libexec/gcc/x86_64-apple-darwin14.3.0/4.8.4 directory to suppress the error message, but in this case it looks like that /usr/ar is invoked when I use /usr/bin/gcc-ar-4.8 to get the same architecture and undefined symbols error.
How to solve these issues? How to build cross compiler tools (gcc and binutils) on Mac OS X?
The static library generator for Mac OS X is not ar, but libtool -static. There is another SO post about this - Static library link issue with Mac OS X: symbol(s) not found for architecture x86_64.
The binutils has multiple libraries that are linked statically. So I replaced all the ar rc command with libtool -static -o to get the static libraries that do not cause errors.
In doing so, I had to make two modifications also.
Some library generate libtool script to conflict the Mac OS X's libtool, I had to rename the script.
Some object files do not contain symbols, I had to remove the objects.
Then I could get the binaries without any issue.
I want to set up a project to take my .hs code, and my main .c program, and result in a statically linked executable through the use of LLVM compiler. I can get things working via ghc command line options to build a .hs, produce the stubs, and compile and link a driver application using ghc entirely. However, I get various issues within Xcode.
My first issue was that I of course need to use 32 bit compiling environment in Xcode. That solved, I had to fiddle with paths to explicitly include the HsFFI.h. That solved, I get a linker error:
Ld "build/Debug/FFI Test.app/Contents/MacOS/FFI Test" normal i386
cd "/Users/rcl/TestXCodeProjects/FFI Test"
setenv MACOSX_DEPLOYMENT_TARGET 10.6
/Developer/usr/bin/clang -arch i386
-isysroot /Developer/SDKs/MacOSX10.6.sdk
"-L/Users/rcl/TestXCodeProjects/FFI Test/build/Debug"
"-L/Users/rcl/TestXCodeProjects/FFI Test/FFI Test"
"-F/Users/rcl/TestXCodeProjects/FFI Test/build/Debug"
-filelist "/Users/rcl/TestXCodeProjects/FFI Test/build/FFI Test.build/
Debug/FFI Test.build/Objects-normal/i386/FFI Test.LinkFileList"
-mmacosx-version-min=10.6 -framework Cocoa
"/Users/rcl/TestXCodeProjects/FFI Test/FFI Test/ForeignExportCost.a"
-o "/Users/rcl/TestXCodeProjects/FFI Test/build/Debug/FFI Test.app/
Contents/MacOS/FFI Test"
Undefined symbols for architecture i386:
"_hs_init", referenced from:
-[FFI_TestAppDelegate applicationDidFinishLaunching:] in FFI_TestAppDelegate.o
"_simpleFunction", referenced from:
-[FFI_TestAppDelegate applicationDidFinishLaunching:] in FFI_TestAppDelegate.o
"_hs_exit", referenced from:
-[FFI_TestAppDelegate applicationDidFinishLaunching:] in FFI_TestAppDelegate.o
ld: symbol(s) not found for architecture i386
clang: error: linker command failed with exit code 1 (use -v to see invocation)
The "simpleFunction" is in "ForeignExportCost.a" library which I compile using ghc like this:
ghc -no-hs-main -fPIC -c ForeignExportCost.hs
ghc -no-hs-main -shared ForeignExportCost.o -o ForeignExportCost.a
What am I missing or doing wrong?
Ugh - it looks like the answer to my question is detailed here, telling me how to painfully add a ton of .a's to my project. And this blog post gave some helpful tips to getting on the way.
Although if someone tells me "hey wait, there's an easier way than iteratively figuring out failed deps" that would be awesome. Because I want to reuse this framework several times and this is a real pain of a way to get things up and going!