[SOLVED] Qt5.1/Qt5.2 + XCode 5.0.2 + Mac OS 10.9 (Mavericks) , Can't link to the libraries ( Undefined symbols for architecture x86_64 )
-
Hi and welcome to devnet,
It seems that your OpenCV was build in 32bit, you need a 64 bit version
-
First of all, thanks for the reply.
Today, I prepared a clean system + XCode (with command line tool) + Qt5.2 + OpenCV + CMake 2.8.12 only.
The same thing happened.
I do notice that in CMake-gui, there is a line
@Host: Darwin 13.0.0 i386 @I can't change it, even when I set arch=x86_64
And even I set arch=x86_64, the error of Qt is the same.I also noticed
When I check
@uname -p@I got
@i386@
When I check
@uname -m@I got
@x86_64@
May I ask one last question ?
If this error in Qt comes from 32bit/64bit build of the library,
Why I can compile and run under terminal but not in Qt ? -
This is not a Qt error. It's OpenCV that doesn't provide symbols for 64bit. Are you sur OpenCV is built either as universal or x86_64 ?
-
- I checked the arch of OpenCV lib at /usr/local/lib by the command
@file *.dylib@
All of them are
@libopencv_XXXX.dylib: Mach-O 64-bit dynamically linked shared library x86_64@- I have a good news, I think.
I opened the Makefile generated by Qt for the project
Here is few lines in the original Makefile@CFLAGS = -pipe -g -gdwarf-2 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk -mmacosx-version-min=10.6 -Wall -W -fPIE $(DEFINES)@
@CXXFLAGS = -pipe -g -gdwarf-2 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk -mmacosx-version-min=10.6 -Wall -W -fPIE $(DEFINES)@
@LFLAGS = -headerpad_max_install_names -Wl,-syslibroot,/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk -mmacosx-version-min=10.6@
I change -mmacosx-version-min=10.6 to -mmacosx-version-min=10.9
by adding this line to .pro
@QMAKE_MACOSX_DEPLOYMENT_TARGET = 10.9@
Then after a week struggle. The peace returns to the Universe.
( only 10.9 works, others don't work, actually, you can delete all the three flags, Qt can still build and run nicely)
I will make more check after I install all other libraries, and report the result.
Thanks for the advice of checking the arch of OpenCV, which direct me to check the Makefile.
- I checked the arch of OpenCV lib at /usr/local/lib by the command
-
Does it also fail for version-min 10.7 and 10.8 ?
Can you test with the latest snapshot ?
-
I didn't finish my own test of other libraries.
But to your question, the answer is
-
I download Qt5.2beta, OpenCV 2.4.7, XCode 5.02, and Mac OSX 10.9 less than a week ago. I think they are the last one so far.
-
If I set -mmacosx-version-min=10.7 or 10.8, the same error message shows up.
I even have to remove the broken main.o by clean action in Qt to let the correct 10.9 setting to generate new main.o. (I also compared the broken main.o and OK main.o by using nm tool. They are different. So I think the problem happens at compile time, before the link stage. )
I noticed that not only OpenCV but also Boost has the same problem.
I have to add the same setting for a pure Boost (No OpenCV) program.
However, the pre-build Intel TBB does not affect by this flag.So I
@file XXX.dylib@for OpenCV or Boost which make on my own computer, I got
@Mach-O 64-bit dynamically linked shared library x86_64@
for pre-build TBB
@libtbb.dylib: Mach-O universal binary with 2 architectures
libtbb.dylib (for architecture i386): Mach-O dynamically linked shared library i386
libtbb.dylib (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64@
as you can see, I guess if I set to 10.9, X86_64 version will be used (other setting, i386 will be used). That is why a TBB program has no error message on my computer.
-
-
The thing that I find strange is it complains about missing the x86_64 architecture, I would have expected it would complain that the i386 is missing from OpenCV
-
Yes, I agree that. I can't find a satisfied explanation for this.
(If you need me to try something to find out the answer, I will try.)By the way, I make a fresh Mac again and I found there is Qt5.2.0-rc1.
But nothing change.this time, I change ..../Qt5.2.0/5.2.0-rc1/clang_64/mkspecs/macx-clang/qmake.conf
@QMAKE_MACOSX_DEPLOYMENT_TARGET=10.6@to
@QMAKE_MACOSX_DEPLOYMENT_TARGET=10.9@so I don't need to set every project.
-
Opencv was probably compiled with a different standard library then Qt is setup to use.
Qt binary distribution compile with -stdlib=libstdc++ to be compatible with 10.6, Xcode 5 on 10.9 will select -stdlib=libc++ by default (for OS X 10.7 and better only).
So symbol using classes from the standard library (like std::string in this case) will not resolve correctly at link time.
This is why you're seeing this error. Look with which standard library opencv is built:otool -L opencv.dylib
You'll have to rebuild it with the right one or change Qt's mkspec to use the newer one.
-
Yes, you are right.
I check libopencv_XXX.dylib or libboost_XXX.dylib
@/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0)@the binary (hello world or OpenCV) build with
QMAKE_MACOSX_DEPLOYMENT_TARGET=10.9
@/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0)@the binary ( hello world ) build with QMAKE_MACOSX_DEPLOYMENT_TARGET=10.6
@/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 60.0.0)@ -
The solved method is good but not enough. QMAKE_MAC_SDK is still 10.8
This solved method make debug version success but release version error,like :
@Undefined symbols for architecture x86_64:
"___sincos_stret", referenced from:
"___sincosf_stret", referenced from:
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [trimeshview.app/Contents/MacOS/trimeshview] Error 1
14:30:06: The process "/usr/bin/make" exited with code 2.
Error while building/deploying project trianglemesh (kit: Desktop Qt 5.2.1 clang 64bit)
When executing step 'Make'
@SO, Further add:
@
macx:QMAKE_MAC_SDK=macosx10.9
@Every thing is OK!