CUDA Programming and xCode - xcode

I'm completely new to Mac OS X and the main reason why I bought my new MacBook Pro R15 Retina Edition is to start studying CUDA API.
But I can't get my project build.
For example, when I create a new CUDA project, I go in the project properties and make the following changes :
Compiler for C/C++/Objective-C : LLVM GCC 4.2
Other Linker Flag : -lcuda, -lcudart
Header Search Path : /usr/local/cuda/include
Library Search Path : /usr/local/cuda/lib
When I start adding the necessary libraries in my code, everything runs fine. My code gets no typing error.
When I build the project, I get linking errors (paths shortened and message broken up for readability):
Ld /my_test_project/Build/Products/Debug/test normal x86_64 cd /Users/Admin/Documents/test setenv MACOSX_DEPLOYMENT_TARGET 10.7 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++
-arch x86_64
-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk
-L/my_test_project/Build/Products/Debug
-L/usr/local/cuda/lib -F/my_test_project/Build/Products/Debug
-filelist /my_test_project/Build/Intermediates/test.build/Debug/test.build/Objects-normal/x86_64/test.LinkFileList
-mmacosx-version-min=10.7
-lcudart
-lcuda
-o /my_test_project/Build/Products/Debug/test
ld: file not found: #rpath/CUDA.framework/Versions/A/CUDA for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation)
What's weird, is that when I go to the described path, I see the CUDA executable. The file is there!
When I use the cuComplex.h, which uses the library, every single mathematical expression (such as log, cos, sin, etc...) is an "undefined variable". However, the cuComplex.h library has inside it the library.
The driver, the SDK and toolkit are well installed and everything works like a charm. I can get the SDK examples working. But I think I miss a detail to get the whole thing working.

I have the same problem with CUDA 5.0 and Xcode 4.4.1 installed on Mountain Lion. The reason is that libcuda.dylib links CUDA.framework with rpath, which you can inspect with otool.
otool -L /usr/local/cuda/lib/libcuda.dylib
/usr/local/cuda/lib/libcuda.dylib:
/usr/local/cuda/lib/libcuda.dylib (compatibility version 1.1.0, current version 5.0.17)
#rpath/CUDA.framework/Versions/A/CUDA (compatibility version 1.1.0, current version 5.0.17)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.0)
However, Xcode does not seem to recognize CUDA.framework under /Library/Frameworks. The reason is unknown. You have to add it yourself to your project.
In your project property page, click Build Phases -> Link with Libraries. Select CUDA.framework. Add it using "Add Others" if it does not appear in the list. This way you get it linked.
If you are writing Makefiles, you want to add this to fully automate the linking stage:
-F/Library/Frameworks -framework CUDA

As an alternative that worked better for my setup is to change the path at libcuda like this:
sudo install_name_tool -change #rpath/CUDA.framework/Versions/A/CUDA \
/Library/Frameworks/CUDA.framework/CUDA \
/usr/local/cuda/lib/libcuda.dylib
As usual, don't paste a sudo command into your terminal if you don't understand what it does.

I had the same problem compiling the CUDA 6.5 examples on OS X 10.10, with Xcode 6.1. The problem happened in the examples whose Makefiles contained the line:
ALL_LDFLAGS += -Xlinker -framework -Xlinker CUDA
The fix was to tell the linker about /Library/Frameworks, so that the above was replaced with 2 lines:
ALL_LDFLAGS += -Xlinker -F/Library/Frameworks
ALL_LDFLAGS += -Xlinker -framework -Xlinker CUDA
Presumably your question is answered at this point, but this page is almost literally the only google result for "ld: framework not found CUDA" and hopefully this can save others some time.

I had a similar CUDA linking issue with CUDA 8.0 and OSX 10.12 while compiling the sample files. Adding the following to the make files solved the problem.
LDFLAGS += -Xlinker -F/Library/Frameworks

Related

g77 : ld: warnings on version-min, and on object file

I need help compiling old legacy fortran with g77 :
(1) The system on OS X 10.12.6, XCode 9.2, and g77 -v returns "Reading specs from /usr/local/lib/gcc/i686-apple-darwin8.8.1/3.4.0/specs Configured with: ../gcc-3.4.0/configure --enable-languages=f77 Thread model: posix gcc version 3.4.0)"
(2) When compiling with a number of legacy flags :
"g77 -ffixed-line-length-132 -fbounds-check -fvxt -ftypeless-boz -finit-local-zero -fno-automatic *.f -o a.out"
I get these linker warnings :
"ld: warning: -macosx_version_min not specified, assuming 10.6"
"ld: warning: object file (/var/folders/6t/mmq9jmq88xjfvk0059b07_yh0000gn/T//ccBEadOC.o) was built for newer OSX version (10.12) than being linked (10.6)"
I think the solution is to set macosx_version_min to 10.12.6 but do not know how to do this.
All help gratefully received : the problem arose when I did a macports update which broke things which were working fine under 10.12.6 yesterday, albeit with the warning "ld: warning: -macosx_version_min not specified, assuming 10.6".
The same code still compiles and runs just fine on a UNIX server with g77-v reporting "gcc version 3.4.6 20060404 (Red Hat 3.4.6-19.el6)"
I'm hoping there's an answer starting "here's how to specify macox_version_min"
Thank you all !

Compiling C Library for iOS 9 From Command Line, Xcode 7-beta 2

I am having trouble compiling a C library (gmp) for iOS 9 using the latest Xcode 7-beta clang. I am trying to produce bitcode to get all the warnings in Xcode to stop (and I would like to produce these libraries in bitcode). However, I can't even compile the library in the first place. ./configure fails, and after looking at the config.log, it seems ld is the problem as it is failing with "ld: library not found for -lSystem". Here is the command I have used to compile gmp in the past :
./configure CC=clang CPP="/Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xct‌​oolchain/usr/bin/clang -E" CPPFLAGS="-isysroot /Applications/Xcode-beta.app/Contents/Developer/Platforms/iPhoneOS.platform/Deve‌​loper/SDKs/iPhoneOS.sdk/ -L /Applications/Xcode-beta.app/Contents/Developer/Platforms/iPhoneOS.platform/Deve‌​loper/SDKs/iPhoneOS.sdk/usr/lib/ -miphoneos-version-min=7.0 -arch armv7 -target arm-apple-darwin
The
-L /Applications/Xcode-beta.app/Contents/Developer/Platforms/iPhoneOS.platform/Deve‌​loper/SDKs/iPhoneOS.sdk/usr/lib/
flag I added is to see if that would help with ld finding the required libraries to link, but it fails with the same error whether I include that option or not. I have not include the option to compile into bitcode in the above command, as I I can't even get it to compile in the first place using the same command I used to use. I have noticed that when I add the gmp .a files to xcode under "link binary with libraries", that ld can't find the libraries. I must manually add the project to the ld search path in the project settings for ld to find the libraries. This wasn't necessary in Xcode 6, so is it just ld being buggy in the current beta, or is there anything I can do?
Okay, here is what worked. Set your xcode development to use the new compilers using
sudo xcode-select -s /Applications/Xcode-beta.app
Then, I used this configure :
./configure CC=clang CPP="/Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -E" CPPFLAGS="-isysroot /Applications/Xcode-beta.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/ -fembed-bitcode -miphoneos-version-min=7.0 -arch armv7 -target arm-apple-darwin" --host=aarch64-apple-darwin --disable-assembly --enable-static --disable-shared --disable-thread-safe --enable-cxx
The above works when compiling mpfr and mpc also.

MAKE on new iMAC with CLANG, but Makefile refers to GCC

I seek some help with 2 Makefiles for 2 different software that are much older than my iMAC machine. I think the software assumes the C compiler to be GCC, while my new iMAC has CLANG as default I think...
I know there are some other threads on this general topic such as at : Compile program using a Makefile with gcc instead of clang
But I wonder if there are Makefile specific modifications for these 2 software that you can suggest I perform. I dont have any experience with modifying Makefiles or flags etc.
The 2 Makefiles and the software that they come from can be all accessed from the folder at Dropbox. Thank you!
My make attempt for mdust looks like this:
Checked http://b110-wiki.dkfz.de/confluence/display/nextrnai/Step-by-step+installation+on+MAC for details on
Installation of mdust
Mdust can be downloaded via this link.
Unpack the file. In the folder created open fastafile.c and delete the third line #include (malloc.h is not needed under Mac OS X, but leads to an error with make). Finally typemake (ignore warnings) which creates the mdust script required by NEXT-RNAi (compilation requires prior installation of Apple Developer Tools / Xcode).
tar -xvzf mdust.tar.gz
cd mdust
emacs fastafile.c (delete line include )
make
So I opened fastafile.c with vi and deleted the
line include
But now, when I try make, I think I see CLANG Vs gcc compiler issues.
DCook04-2:mdust anand$ make
gcc -O2 -Wall -I. -I- -D_REENTRANT -c fastafile.c -o fastafile.o
clang: error: '-I-' not supported, please use -iquote instead
make: *** [fastafile.o] Error 1
My make attempt for RECON may have worked, only warning, no errors per STDOUT. Longer STDOUT, so in folder with link above, and obviously named file.
More info that's hopefully relevant:
DCook04-2:src anand$ gcc -v
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin12.5.0
Thread model: posix
DCook04-2:src anand$ clang -v
Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin12.5.0
Thread model: posix

Clang Code Coverage - Mac OS X - Linker Error

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

How does Xcode generate the list of framework directories used in the final linking step?

question:
How does Xcode generate the list of framework directories (-F flags in the call to ld) when building a Cocoa app? I keep getting a warning for an old directory which (I think) I have removed from the project settings.
details:
I moved a working Xcode project from one directory to another. I had to fix some broken references to frameworks that now have a different relative path. Everything appears to be working, except for a single warning on the final linker step:
ld: warning: directory '../Some/Path/To/Framework' following -F not found
../Some/Path/To/Framework is definitely part of the old setup. The external frameworks were stored in a directory that was one level up from the project file.
The full text of the call to ld looks something like this (lightly sanitized):
Ld /Volumes/Projects/Builds/Debug/MyApp.app/Contents/MacOS/MyApp normal i386
cd /Volumes/Projects/MyApp
setenv MACOSX_DEPLOYMENT_TARGET 10.6
/Developer/usr/bin/gcc-4.2 -arch i386 -isysroot /Developer/SDKs/MacOSX10.6.sdk
-L/Volumes/Projects/Builds/Debug -F/Volumes/Projects/Builds/Debug
-F../Some/Path/To/Framework
-F/Correct/Path/To/Framework
-filelist /Volumes/Projects/Builds/MyApp.build/Debug/MyApp.build/
Objects-normal/i386/MyApp.LinkFileList
-mmacosx-version-min=10.6
-framework Cocoa
-framework FRAMEWORK
-framework Carbon
-framework Quartz
-o /Volumes/Projects/Builds/Debug/MyApp.app/Contents/MacOS/MyApp
The warning is triggered by that old value for -F. I have searched through all of the build settings, and everything points to /Correct/Path/To/Framework, not ../Some/Path/To/Framework. I have also cleaned the entire build, but to no avail.
Check your build settings. The framework search paths are under Framework Search Paths, or build variable FRAMEWORK_SEARCH_PATHS.

Resources