I have a CMake C++ dylib project that builds correctly in one MacOS X environment but fails in another. Environments are on the same machine, but under different users. I'm seeking help how to do I troubleshoot where the failure in the second one comes from.
What I managed to figure out is that in failing configuration CMake adds the following flags in link.txt (the commands used to link the executable)
-arch x86_64
-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk
-mmacosx-version-min=10.6
-L/usr/local/lib
The last one causes havoc as it makes ld pick up dependencies from /usr/local/lib instead of link directories I configured in CMake.
I would appreciate any insight what triggers generating the flags above and what is the best way to squelch them, especially -L/usr/local/lib?
Related
I'm trying to compile CMake using a non-default GCC installed in /usr/local/gcc530, on Solaris 2.11.
I have LD_LIBRARY_PATH=/usr/local/gcc530/lib/sparcv9
Bootstrap proceeds fine, bootstrapped cmake successfully compiles various object files, but when it tries to link the real cmake (and other executables), I get pages of "undefined reference" errors to various standard library functions, because, as running the link command manually with -Wl,-verbose shows, the linker links with /usr/lib/64/libstdc++.so of the system default, much older GCC.
This is because apparently CMake tries to find curses/ncurses libraries (even if I tell it BUILD_CursesDialog:BOOL=OFF), finds them in /usr/lib/64, and adds -L/usr/lib/64 to build/Source/CMakeFiles/cmake.dir/link.txt, which causes the linker to use libstdc++.so from there, and not my actual GCC's own.
I found a workaround: I can get the path to proper libraries from $CC -m64 -print-file-name=libstdc++.so then put it with -L into LDFLAGS when running ./configure, and all works well then.
Is there a less hacky way? It's really weird that I can't tell GCC to prioritize its own libraries.
Also, is there some way to have CMake explain where different parts of a resulting command line came from?
I have an OpenGL project which works/compiles fine in Windows.
I wanted to port the application to Mac OS.
I got the application up and running on Mac, but the text inside the project is not visible. So I decided to use a 3rd party library for text rendering in Mac, I came across FreeType, which has many advantages such as anti-aliasing and UNICODE support.
So, I downloaded the library on my Mac, './configure'd it, did 'make' and 'make install' as I would normally do.
Then in Xcode I set search paths for both include and library directories,
/usr/local/include and /usr/local/lib respectively. Then I added 'other linker flags' in Xcode, freetype-configure --libs gave me following flags- -L/usr/local/lib -lfreetype -lz -lbz2, I added them in Xcode.
Now, whenever I include a freetype header there is no problem, but when I call any method from the freetype library, it gives me following linker error.
After looking up on google I found out that I have to set the build targets accordingly, I did that, now my application builds for i386 x86 the issue still persist.
I also tried following flags while configuring freetype ./configure CC="gcc -arch i386" CXX="g++ -arch i386"
which did not help either.
I am relatively new to Mac OS X/Unix environment, I have previously got freetype working on windows with VS 2008. Any help would be greatly appreciated.
What:
It seems you have more than one libfreetype.dylib file in your library search paths.
/master_repository/......../lib contains one and /usr/local/lib contains another
-lfreetype is a convenient way of telling the linker to look for file named libfreetype.dylib in all the directories specified with -L flags. Because -L/master_repository... comes before -L/usr/local/lib in the linker argument list, the linker uses the first instance it finds and attempts linking to that one.
Fix:
Reorganising your -L flags so that -L/usr/local/lib comes before the other. Avoid this option if you can.
Removing the extra search path, leaving only the relevant one.
Specifying the library explicitly instead of relying on the convenient -l by replacing -lfreetype with a full path to a library: /usr/local/lib/libfreetype.dylib
I'm trying to get qmake to produce a makefile which does not include -arch i386 in CFLAGS/LFLAGS and so far I'm not succeeding. I tried the following:
CONFIG-=x86
QMAKE_CFLAGS-="-arch i386"
and a couple of other variations. The only one that does work is removing x86.prf from mkspecs/features/mac but I don't think it's a proper solution.
The current commandline looks approximately like this:
qmake -makefile -nocache CONFIG-=release CONFIG+=Debug CONFIG+=mac
CONFIG+=CMDMAKE CONFIG-=x86 CONFIG+=x64
QMAKE_MAKEFILE=makefile_mac_Debugx64 QMAKE_LFLAGS="<...>"
QMAKE_CXXFLAGS="<..>" QMAKE_CFLAGS="<...>" QTVER=4.8.4 project.pro
I believe that qmake uses the compiler available in the PATH. If you want to use x86_64 compiler, alter PATH (and possibly INCLUDE, LIB and LIBPATH) environment variables for x86_64 compiler to be available, and then run qmake.
Tentative solution (need to verify a few things to confirm it, but seems to work):
1) make a separate build of Qt for x64 only, i.e.:
./configure -platform macx-g++42 -arch x64 -debug-and-release <...>
2) use qmake from that build to generate x64 makefiles.
It apparently still needs CONFIG-=x86 but that looks to be enough to prevent stray -arch i386 in the generated makefiles.
I am looking at the official documentation on the Apple site, and I see that there is a quickstart about how to use OpenCL on Xcode.
Maybe it is just me, but I had no luck building the code that is mentioned on the "hello world OCL" section.
I've started Xcode and created an empty project; created a main.c and a .cl kernel file, pasting what is on the Apple developer site, and I am not able to get anything to build, even after adding a target.
The AD site does not have a project to download, so I have no clue about the cause of the failure (it may be me most likely, or the site assume steps and does not mention them).
I've also tried the sample project from macresearch.org, but they are quite ancient, and the test project in the 3rd lesson is not running at all.
Now, I am pretty sure that others are using Xcode to run OCL code, but I cannot find any single page (except the aforementioned macresearch.org) that gives a clear setup about how to run an Xcode project with OCL. Is there anyone aware of a tutorial that shows how to work with OCL and Xcode?
I have purchased 3 books on OCL (Gaster's Heterogeneous computing with OpenCL, Scarpino's OpenCL in action and Munshi's OpenCL programming guide), and neither mention how to set up Xcode, while they go in detail for the visual studio setup and even for the eclipse setup.
On the side; is there any application that is able to validate kernel code before running it in the OCL application?
Thanks in advance for any suggestion that you may have.
Short answer: https://developer.apple.com/library/mac/#documentation/Performance/Conceptual/OpenCL_MacProgGuide/XCodeHelloWorld/XCodeHelloWorld.html
Long answer for command liners:
With a recent Xcode (and Lion or higher), you don't even need to call clCreateProgramWithSource, just write your kernel and call it from your app, there are some additional compiling steps needed though.
I'm taking the OpenCL Hello World example from Apple here using default compiler flags (see https://developer.apple.com/library/mac/#documentation/Performance/Conceptual/OpenCL_MacProgGuide/ExampleHelloWorld/Example_HelloWorld.html) and showing the steps Xcode would do in the background.
To get you started, do a:
/System/Library/Frameworks/OpenCL.framework/Libraries/openclc -x cl -cl-std=CL1.1 -cl-auto-vectorize-enable -emit-gcl mykernel.cl
This will create 2 files, mykernel.cl.h and mykernel.cl.c (and mykernel.cl.c does all the magic of loading your kernel into the app). Next you'll need to compile the kernel:
/System/Library/Frameworks/OpenCL.framework/Libraries/openclc -x cl -cl-std=CL1.1 -Os -triple i386-applecl-darwin -emit-llvm-bc -o mykernel.cl.i386.bc mykernel.cl
/System/Library/Frameworks/OpenCL.framework/Libraries/openclc -x cl -cl-std=CL1.1 -Os -triple x86_64-applecl-darwin -emit-llvm-bc -o mykernel.cl.x86_64.bc mykernel.cl
/System/Library/Frameworks/OpenCL.framework/Libraries/openclc -x cl -cl-std=CL1.1 -Os -triple gpu_32-applecl-darwin -emit-llvm-bc -o mykernel.cl.gpu_32.bc mykernel.cl
And last but not least, build the app itself:
clang -c -Os -Wall -arch x86_64 -o mykernel.cl.o mykernel.cl.c
clang -c -Os -Wall -arch x86_64 -o square.o square.c
clang -framework OpenCL -o square mykernel.cl.o square.o
And that's it. You won't see any clCreateProgramWithBinary or clCreateProgramWithSource in Apple's sample code. Everything is done via mykernel.cl.c generated by openclc.
So seems that I was able to partially resolve the issue in this way:
Create an empty project, create a main.c file and a kernel file
create a target as console application
in the build settings, add the OpenCL framework (you will see it appearing on the file browser in the left pane, if it will be added correctly).
specify the location where the kernel file is located, hardcoding the path (it is not enough to just say "my kernel.cl"; Xcode for some reasons don't get that the cl file is in the same dir as the main, so you gotta specify the path when loading the kernel file)
I was successful using these steps, while using the example code on the Apple developer site.
I am pretty sure that there are other ways to do this, but at least this may help whom, like me, had no clue about how to start.
To answer the second part of your question, on Mountain Lion you can run the OpenCL compiler on foo.cl like this:
/System/Library/Frameworks/OpenCL.framework/Libraries/openclc \
-c -Wall -emit-llvm -arch gpu_32 -o foo.bc foo.cl
It will compile foo.cl to LLVM bit-code foo.bc. This binary file can be used with clCreateProgramWithBinary, which is faster than clCreateProgramWithSource. Valid values for -arch are i386 x86_64 gpu_32.
The issue I'm having is that gcc (and family) don't appear to be properly setup. I have a 10.7.4 machine that I just installed Xcode on (from the app store). I've done no prior development on this machine.
Working w/in Xcode seems to work fine. I can build and compile no problem. However, trying to execute gcc command line fails.
First, I gcc wasn't on my path ... no big deal. I located it and ran as:
/Applications/Xcode.app/Contents/Developer/usr/bin/gcc -dynamiclib -fno-common -o s.dylib s.c
(I'm working on a lib w/some functions...). Anyways, it fails.
s.c:1:19: error: stdio.h: No such file or directory
s.c:2:20: error: stdlib.h: No such file or directory
s.c:3:20: error: string.h: No such file or directory
Surprise! hah, well I searched my machine for stdio.h and I can't find it anywhere. Since I've been out of the OSX game for a bit, I'm assuming I'm missing something -
Basically I want to be able to continue using Xcode but I want to be able to build C/C++/etc on the command line with all the dependencies (.h) in the correct place.
Any thoughts?
There are two main ways to run the compiler from the command line: the Command Line Tools package, and xcrun.
xcrun is particularly good if you just need this occasionally. Just stick "xcrun" at the start, like you'd do with sudo:
xcrun gcc -dynamiclib -fno-common -o s.dylib s.c
This will find the correct version of gcc and set the needed directories, etc. You can specify a specific SDK with --sdk.
If you do this a lot, download and install the Command Line Tools package (Xcode>Open Developer Tool>More Tools...; it also may be available in Preferences>Downloads). This installs a full copy of everything in /usr.
Probably xcrun is not enough if you are using 10.8.
Looking in to the clang documentation I found that you need to include the system root because you do not have your libraries in the standard place but inside Xcode.
using:
xcrun gcc -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk
or:
xcrun clang -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk