I have come back to working on a school project after a short hiatus. However, I can't get it to build anymore. We were provided with the following cmake file:
cmake_minimum_required(VERSION 2.8)
PROJECT(astro)
SET(VTK_DIR /Users/hank/Hartree/VTK/install/lib/cmake/vtk-6.0)
find_package(VTK REQUIRED)
include(${VTK_USE_FILE})
add_executable(astro MACOSX_BUNDLE astro)
SET(CMAKE_CXX_LINK_FLAGS "-framework OpenGL")
if(VTK_LIBRARIES)
target_link_libraries(astro ${VTK_LIBRARIES})
else()
target_link_libraries(astro vtkHybrid)
endif()
After running cmake and trying to compile the project with make, I get the following error:
*** No rule to make target >'/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Deve>loper/SDKs/MacOSX10.12.sdk/System/Library/Frameworks/OpenGL.framework', >needed by 'astro.app/Contents/MacOS/astro'. Stop.
I think I updated my os and xcode during my break from the project, and that caused the issue. I don't know a whole lot about cmake or makefiles, but I think that somehow the path to openGL is getting messed up. Poking through my file system I have found the paths
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk,
and
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk,
and I have been able to find the OpenGL frameworks in those directories, but there is no MacOSX10.12.sdk directory.
I found the following similar questions here and here. However, I have not been using Qt, and when I run xcode-select -pit prints the correct path /Applications/Xcode.app/Contents/Developer
Any ideas how to fix this?
I received exactly the same error when installing an application from source code. I solved this problem by duplicate the "MacOSX10.13.sdk" directory in
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/
and rename it "MacOSX10.12.sdk".
I am not an expert in MacOSX or cmake, therefore my answer may not be the best solution and may even cause problems, but it does solve this problem for me. If anyone knows the correct way to do, I'd like to know it.
Here are what I tried:
At beginning, cmake can not find "CMAKE_OSX_SYSROOT" after configuration.
I first changed the cmake settings to
CMAKE_OSX_DEPLOYMENT_TARGET:STRING=10.12
CMAKE_OSX_SYSROOT:STRING=macosx10.13
but this does not work. Same error.
Then I updated my Mac to MacOSX 10.13 High Sierra. This time cmake can correctly set
CMAKE_OSX_SYSROOT:PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk
but still generates the same error. Therefore I believe the problem comes from the application source code.
I googled how to install MacOSX10.12.sdk and find this post:SDKs.
The easiest way may be finding the old sdk from TimeMachine. But I just bought my Mac and it doesn't have the old version sdk. Therefore I simply duplicate and rename the sdk to try, and it works. I think putting the sym link of the real MacOSX10.12.sdk in the folder will be the best solution to this problem.
I updated to Xcode 5.0 and I can't seem to be able to include the GL/glew.h file. In previous Xcode version one had to set the base SDK to current OSX, but that option is no longer available (at least I can't find).
The file glew.h is in /usr/include/GL and I already set the header search paths to /usr/include, but it still doesn't work.
Can anyone help?
Thank you
Got it to work.
Find in the Project Build Settings > Search Paths > Always Search User Paths and set it to yes.
Also, I couldn't link with libGLEW so I had to go into the XCode.app and create a symbolic link to the the file.
Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/lib
It is definitely not a great solution but is a work-around for me.
Edit:
Here, I suppose that one is working with the Mac OSX 10.8 SKD. For other SDKS, the path should be another one.
In the terminal I created a link to my libGLEW.dylib (which was in /usr/lib) in this way
cd Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/lib
sudo ln -s /usr/lib/libGLEW.dylib libGLEW.dylib
Afterwards, back in XCode, in my project's "Build Settings" I set "Other Linker Flags" to -lGLEW
I am new to Xcode and Mac environment. I am using some dynamic and static libraries like boost, Clucene, etc. I have all the libraries under
MyApp.app/Contents/Resources
I want to set this path as the app's dyld_library_path. I tried editing XXX.plist file like
DYLD_LIBRARY_PATH /mypath/xxx
and setting the environment variable and argument in Xcode Nothing work.
but if I run a shell script like below without double clicking the app in my .dmg it works
#!/bin/bash
clear
cd /Volumes/xxx/myapp.app/Contents/MacOS
export DYLD_LIBRARY_PATH="/Volumes/xxx/myapp.app/Contents/Resources"
./myapp
I am sure this is not the proper way to do this. Is there proper way to set dyld_library_path every time I execute my app?
EDIT:
It also works if u mannualy copy all ur library to clients /usr/lib path... i guess this is also not a proper way to do it.
Setting DYLD_LIBRARY_PATH isn't the best way to solve this problem. It's working around the fact that you've misinformed dyld as to where to find your libraries.
If you run otool -L MyApp.app/Contents/MacOS/MyApp you'll see the paths to the libraries that MyApp wants to load. If any library isn't found at the specified path then dyld will look for the library in the locations specified by DYLD_FALLBACK_LIBRARY_PATH. Setting DYLD_LIBRARY_PATH causes dyld to look for the library in the given locations ahead of the path that the otool command above returned.
The best way to solve this problem is to have your application specify the correct location of the libraries to start with so that setting DYLD_LIBRARY_PATH is not necessary. To do this you need to do the following:
Set the library identifier of each of the libraries that you're bundling inside your application to an #rpath-relative value. You can do this using install_name_tool -id #rpath/libFoo.dylib libFoo.dylib.
Add a Copy Files build phase to copy the libraries in to your application wrapper. MyApp.app/Contents/Frameworks is a typical location. MyApp.app/Contents/Resources should be avoided since binaries aren't resources in the usual sense of the term.
Specify a run path search path when linking your application. This gives the linker a list of paths to use to resolve any #rpath variables that it encounters in any load commands. If you're copying the libraries to MyApp.app/Contents/Frameworks you'll want to specify a run path search path of #loader_path/../Frameworks. You can do this via the LD_RUNPATH_SEARCH_PATHS (Runpath Search Paths) configuration setting in Xcode on your application target.
After doing all this you should be able to re-run the otool command mentioned above and see that the paths to your library are using #rpath-relative paths. You should then be able to run otool -lV MyApp.app/Contents/MacOS/MyApp and see an LC_RPATH load command specified with a value of #loader_path/../Frameworks. Finally, you should be able to run your application and see that it finds the libraries within its Frameworks directory without having DYLD_LIBRARY_PATH set!
I'm getting the following error:
ld: library not found for -lGoogleAnalytics
clang: error: linker command failed with exit code 1 (use -v to see invokation)
I've spent some time googling but can't find how to fix this problem. I'm new to xcode and this is an existing project that I need to work on.
In my case, the project uses CocoaPods. And some files are missing from my project.
So I install it from CocoaPods: https://cocoapods.org/.
And if the project uses CocoaPods we've to be aware to always open the .xcworkspace folder instead of the .xcodeproj folder in the Xcode.
You need to set the "linker search paths" of the project (for both Debug and Release builds). If this library was in, say, a sibling directory to the project then you can set it like this:
$(PROJECT_DIR)/../GoogleAnalytics/lib
(you want to avoid using an absolute path, instead keep the library directory relative to the project).
All in all, the Xcode cannot find the position of library/header/framework, then you tell Xcode where they are.
set the path that Xcode use to find library/header/framework in Build Settings --> Library/Header/Framework Search Paths.
Say, now it cannot find -lGoogleAnalytics, so you add the directory where -lGoogleAnalytics is to the Library Search Paths.
In my case I had a project with lots of entries in "Build Settings > Other Linker Flags"
I needed to reduce it down to just
$(inherited)
-ObjC
Old settings:
Updated settings:
For me, I open the projectname.xcworkspace file and it all works.
If you have pods installed, make sure to open the workspace folder (white Xcode icon) not the project folder. This resolved the library not found for ... error. Very simple issue but I was stuck on this for a long time.
This worked for me:
Go to build setting -> Linking -> Other Linker Flags -> Remove all other than $(inherited)
Cd ios && pod update
If you are using Pods to include the GoogleAnalytics iOS SDK into your project, it's worth noting that since the 3.0 release your Other Linker Flags needs to include -lGoogleAnalyticsServices not the old -lGoogleAnalytics
If your library file is called libGoogleAnalytics.a you need to put -lGoogleAnalytics so make sure the .a file is named as you'd expect
None of the above worked for me, what did was making sure the Pod file platform :ios, '11.0' matched with the minimum deployment target in the XCODE setting
You can also try to lint with the --use-library option, as cocoapods lint libraries as framework by default since v0.36
The problem might be the following: SVN ignores .a files because of its global config, which means someone didn't commit the libGoogleAnalytics.a to SVN, because it didn't show up in SVN. So now you try to check out the project from SVN which now misses the libGoogleAnalytics.a (since it was ignored and was not committed). Of course the build fails.
You might want to change the global ignore config from SVN to stop ignoring *.a files.
Or just add the one missing libGoogleAnalytics.a file manually to your SVN working copy instead of changing SVNs global ignore config.
Then re-add libGoogleAnalytics.a to your XCode project and commit it to SVN.
In XCode 10.1, I had to set "Library Search Paths" to something like $(PROJECT_DIR)/.../path/to/your/library
For me it was a silly thing: my mac uploaded the file into iCloud, and that is why Xcode did not find it.
If you turn off the automatic upload, it wont happen again.
I've looked at a few related questions and cannot seem to find a solution for myself.
Basically I'm using the libmp3lame.dylib in my Xcode project. The install process for lame produced the .dylib and placed it in usr/local/lib and to get Xcode to build and run the project I changed the Library Search Paths to include the above folder. This works fine.
Now it's come to producing a release version and I want to include the .dylib in the bundle so that the user doesn't have to put up with an install phase or anything similar. I created a copy files phase of the target and this dumps the .dylib into the Frameworks folder in the contents of the bundle. However, running otool on the binary shows that instead of using the .dylib inside the bundle, the compiler has linked it to the usr/local/lib version (even if I delete that version).
Looking at the other results in the otool output I have other frameworks being linked to inside the bundle, just not the .dylib. Looking at the properties for both these frameworks and the .dylib in Xcode I can't see any differences other than file type.
My searching suggests I need to use rpath or similar, but I've no clue where to apply this in Xcode.
My workaround for this issue was to do the following in terminal (I've used Automator to, well, automate this):
install_name_tool -id #executable_path/../Frameworks/libmp3lame.0.0.0.dylib ~/path/to/lib/in/app/libmp3lame.0.0.0.dylib
install_name_tool -change /usr/local/lib/libmp3lame.0.dylib #executable_path/../Frameworks/libmp3lame.0.0.0.dylib ~/path/to/app/Contents/MacOS/AppName
Basically swapping the path to the library from the one in the usr local lib to the one included in the bundle.
My tip is to look at the build output, how does it actually run ld?