I have compiled opencv on snow leopard and it says it compiled correctly, however when I try to compile my sample program against it, I get output like:
g++ -o tm_scons template.o -L/opencv/opencv/build/lib -lcxcore -lcv -lcvaux -lhighgui -lml
ld: warning: in /opencv/opencv/build/lib/libcxcore.dylib, file is not of required architecture
ld: warning: in /opencv/opencv/build/lib/libcv.dylib, file is not of required architecture
ld: warning: in /opencv/opencv/build/lib/libcvaux.dylib, file is not of required architecture
ld: warning: in /opencv/opencv/build/lib/libhighgui.dylib, file is not of required architecture
ld: warning: in /opencv/opencv/build/lib/libml.dylib, file is not of required architecture
Is this likely a problem with my compilation of OpenCV or of my app that is using it?
Compiling correctly does not mean compiling for whatever architecture you're trying to compile now. Most likely the library is compiled as 32-bit and you're compiling as 64-bit or vice-versa.
Most likely your program is compiled 64-bit (the default behavior on SnowLeopard) and the library is compiled 32-bit. Try adding the -m32 or -arch i386 flag to the compiler when you build your program and see if the link works.
As it turns out the magic was using -m32 and switching to the /usr/bin/g++-4.0 compiler.
Ugh....
Related
Here's a bit of background before I dive into the question. My ultimate goal is to compile the source of a c++ static library for the architectures arm64, armv7, armv7s, i386, and x86_64, and then package the libraries into a fat library so that I can use them during iOS development. This will enable me to use the simulator and a device with the same library.
Here's my issue. I'm trying to test the i386 version of the library, on it's own, using the iPhone 5 simulator. I compiled the static library for i386 as follows:
./configure --enable-utf8-only --disable-shared --host=i386-apple-darwin LDFLAGS="-L." CC="/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang" CXX="/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++"
then
make CXXFLAGS="-arch i386 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator10.3.sdk" CCFLAGS="-arch i386 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator10.3.sdk"
This resulted in my static library, libtest.a. I then ran the follow to verify the libraries architecture
jamespc:Desktop $ lipo -info libtest.a
input file libtest.a is not a fat file
Non-fat file: libtest.a is architecture: i386
Everything seemed to look good so far. Next I added the library to my Xcode project and tried to build the project. When building the project I get the following warning and error.
ld: warning: ignoring file
/Users/cleandev/Library/Developer/Xcode/DerivedData/MyProject-hjtfdovfmdsubkejojqknkmqkzps/Build/Products/Debug-iphonesimulator/libtest.a,
file was built for archive which is not the architecture being linked (i386):
/Users/cleandev/Library/Developer/Xcode/DerivedData/MyProject-hjtfdovfmdsubkejojqknkmqkzps/Build/Products/Debug-iphonesimulator/libtest.a
Undefined symbols for architecture i386:
...
ld: symbol(s) not found for architecture i386
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Perplexed by error I ran lipo on my static lib again, this time using the path listed in the warning, in the derived data folder.
jamespc:Debug-iphonesimulator $ lipo -info libtest.a
input file libtest.a is not a fat file
Non-fat file: libtest.a is architecture: x86_64
I'm confused as to why the library appears to have a different architecture associated with it when I take a look at it in the derived data.
Is the way I'm compiling the static library wrong?
Is there something I might be doing wrong in my Xcode build settings?
Thank you for taking the time to read my question
I guess the framework was not compiled for the iOS Simulator's architecture, which is i386. Xcode only compiles a framework for the target architecture.
Please follow this tutorial: http://www.raywenderlich.com/65964/create-a-framework-for-ios
It may help.
I wanted to use a Dynamic shared library ".so" file using ld command on Mac OS X.
I'm able to compile without errors and create the file using
ld -dynamic -dylib -arch x86_64 -macosx_version_min 10.10.0 -o libpacket.so obj/SpectrumClient.o obj/socket.o obj/packetCounters.o -lSystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.1.0/lib/darwin/libclang_rt.osx.a
To check the file generated is for OS X..
~ vamsi$ file libpacket.so
libpacket.so: Mach-O 64-bit dynamically linked shared library x86_64
To allow ld to search for this I move the .so file to
/usr/lib
(I get error "ld: library not found for -lpacket" when I don't do so.)
To check if this works I run the command
ld -lpacket -v
I get the following error:
#(#)PROGRAM:ld PROJECT:ld64-242
configured to support archs: i386 x86_64 x86_64h armv6 armv7 armv7s armv7m armv7k arm64
Library search paths:
/usr/lib
/usr/local/lib
Framework search paths:
/Library/Frameworks/
/System/Library/Frameworks/
ld: warning: -arch not specified
ld: warning: -macosx_version_min not specified, assuming 10.6
Undefined symbols for architecture x86_64:
"start", referenced from:
implicit entry/start for main executable
ld: symbol(s) not found for inferred architecture x86_64
I'm running on updated OS X (10.10.5)
Even though I'm specifying the architecture and Minimum OS X version why am I getting the error?
I know I don't have start function in this .so file, but when I link this in other the functions are not linked.
Can someone point out the mistake I'm doing?
Thank you.
ld interprets your command ld -lpacket as a request to link a complete program executable from the object files in the specified library. That would make most sense if packet referred to a static library.
In any case, your library isn't sufficient to build a complete executable. The linker is implicitly looking for a start routine and not finding it. The start routine would not normally be in your code, it would be in the C runtime library. When you use the compiler to drive the link step, the compiler specifies the C runtime library, which provides start. However, the C runtime library then has a dependency on your code providing a _main symbol, so that just moves the problem one step along.
In short, ld -lpacket is not a sensible link command. You can't link just a dynamic library. What is it being linked to? What did you expect that command to accomplish?
The other stuff about -arch and -macosx_version_min not being specified is about this link command. The fact that you specified them when building the library is irrelevant. For this invocation of the linker, you're forcing the linker to guess what you intend, so it's telling you what it guessed.
I found out the issue with why the project wasn't able to link the .so file.
While compiling ".so" file, have additional config
-DTARGET_OS_MAC
Now I don't get the error "Can't find the method..." while linking the .so file to the other project.
#KenThomases.. You were right about "ld -lpacket -v" command not giving any useful information. Thank you!
I'm having a compilation issue which I'm unable to solve. I'm developing a cross platform C++ project coding on both Mac Os X 10.8 and Windows. The code compiles and run fine on Windows and on Mac Os X Leopard as well.
Since Apple pushes the developers to stick to the latest platform for various reasons I'm forced to develop on Mountain Lion and I'm trying to get the project to work again.
I compiled correctly all the libraries I needed (wxWidgets, etc) and I imported the project in the latest version of Eclipse. When I try to build the project it tries to compile the firts .cpp file and at the end it (why?) tries to invoke the linker resulting on a series of missing symbols for my own defined classes. None of the other .cpp files is being compiled, so it's pretty understendable why the whole process is failing.
I also tried to invoke make from CLI, with the same result. I went into the makefile and everything seems correct. It looks like a very newbie issue, I feel I'm missing something huge here.
I'm pasting below the output of the compiler, just in case some compiling guru step in. Please feel free to ask for more details.
Compiler output
Pastebin Link: Compiler output
I used PB since the output is quite large.
The relevant section are the invocation of as and collect2 soon after the compiling phase of the very first .cpp file. The missing symbols are defined in other .cpp files in the same dir.
/usr/llvm-gcc-4.2/bin/../libexec/gcc/i686-apple-darwin11/4.2.1/as -arch x86_64 -force_cpusubtype_ALL -o /var/folders/br/h6ln_j014ll56zwc8x6xjmk80000gn/T//ccSUmHal.o /var/folders/br/h6ln_j014ll56zwc8x6xjmk80000gn/T//ccn8ex81.s
/usr/llvm-gcc-4.2/bin/../libexec/gcc/i686-apple-darwin11/4.2.1/collect2 -dynamic -arch x86_64 -macosx_version_min 10.8.3 -weak_reference_mismatches non-weak -o Calcoli.o -lcrt1.10.6.o -L/usr/llvm-gcc-4.2/bin/../lib/gcc/i686-apple-darwin11/4.2.1/x86_64 -L/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2/lib/gcc/i686-apple-darwin11/4.2.1/x86_64 -L/usr/llvm-gcc-4.2/bin/../lib/gcc/i686-apple-darwin11/4.2.1 -L/usr/llvm-gcc-4.2/bin/../lib/gcc -L/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2/lib/gcc/i686-apple-darwin11/4.2.1 -L/usr/llvm-gcc-4.2/bin/../lib/gcc/i686-apple-darwin11/4.2.1/../../.. -L/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2/lib/gcc/i686-apple-darwin11/4.2.1/../../.. /var/folders/br/h6ln_j014ll56zwc8x6xjmk80000gn/T//ccSUmHal.o -lstdc++ -lSystem -lgcc -lSystem
The compiler output ends with the "classic" undefined symbol issue. All emphasized text*emphasized text*emphasized text
Undefined symbols for architecture x86_64:
"typeinfo for TipoPuntoCalc", referenced from:
Calcoli::setPuntoS(GTGraphicObject*) in ccSUmHal.o
"typeinfo for TipoPali", referenced from:
Calcoli::setPaloS(GTGraphicObject*) in ccSUmHal.o
"typeinfo for TipoRett", referenced from:
Calcoli::setFondazioneS(GTGraphicObject*) in ccSUmHal.o
"_main", referenced from:
start in crt1.10.6.o
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status
make: *** [Calcoli.o] Error 1
This shouldn't be an architecture related issue, since specifing i386 as target has the same result (symbol(s) not found for architecture i386).
Thank you,
Evelina
Go to your target's "Build Phases" section and verify that all the files you need to compile and link are actually included in the proper sections.
It sounds as if the compiler is not being told to include some things you need.
So I've spent the last 20 hours trying to get boost working under OS X 10.8, and I have finally gotten it to compile without errors, but when I try to compile a test case that uses Boost.test, I'm back again in a world of hurt.
I should mention, the reason I compile boost myself instead of using the binary available, is because I want to use c++11 and libc++.
When I compiled boost, I called b2 like this:
./b2 toolset=clang cxxflags="-std=c++11 -stdlib=libc++" linkflags="-std=c++11 -stdlib=libc++" link=static
and it compiles all file. Then I have this piece of code
#define BOOST_TEST_DYN_LINK
#define BOOST_TEST_MODULE Addition
#include <boost/test/unit_test.hpp>
int addition(int i, int j)
{
return i + j;
}
BOOST_AUTO_TEST_CASE(universeInOrder)
{
BOOST_CHECK(addition(2, 2) == 4);
}
which I
try to compile with
clang++ -std=c++11 -stdlib=libc++ -g -Wall -v -I/Users/cb/Downloads/boost_1_51_0 tests/arithmetic.cpp -o tests/arithmetic /Users/cb/Downloads/boost_1_51_0/stage/lib/libboost_unit_test_framework.a`
And it fails miserably, giving me this error:
"/usr/bin/ld" -demangle -dynamic -arch x86_64 -macosx_version_min 10.8.0 -o tests/arithmetic /var/folders/pg/4wcxn1j12c3188vqrv0x4w9r0000gn/T/arithmetic-UFmO1B.o /Users/cb/Downloads/boost_1_51_0/stage/lib/libboost_unit_test_framework.a -lc++ -lSystem /usr/bin/../lib/clang/4.0/lib/darwin/libclang_rt.osx.a
Undefined symbols for architecture x86_64:
"boost::unit_test::unit_test_main(bool (*)(), int, char**)", referenced from:
_main in arithmetic-UFmO1B.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
At first, I figured it was because boost was not compiled for 64bit so I tried telling b2 to do that specifically, but it made no difference, and I also think that it compiles for 64bit by default on OS X.
Any ideas as to why it is failing and how I get it working?
It looks like bad compilation of the test. You requested
#define BOOST_TEST_DYN_LINK
but than you are linking the static version of boost.test
/Users/cb/Downloads/boost_1_51_0/stage/lib/libboost_unit_test_framework.a
and IIRC there is a difference between the static and dynamic versions of this library. So either link the dynamic version of the library (the one with .so extension), or remove that define.
I've been trying to get SFML working for a while now and I've been trying to get it working using GCC. I'm on OS X by the way. I followed the standard Linux instructions and using the Linux 64-bit download however when it comes to compiling...
g++ -o testing main.cpp -lsfml-system
This happens:
main.cpp: In function ‘int main()’:
main.cpp:7: error: ‘class sf::Clock’ has no member named ‘GetElapsedTime’
main.cpp:9: error: ‘class sf::Clock’ has no member named ‘GetElapsedTime’
main.cpp:10: error: ‘Sleep’ is not a member of ‘sf’
So I thought it could be due to not using includes, so I changed my gcc compile command to:
g++ -o testing main.cpp -I ~/SFML-1.6/include/ -lsfml-system
and now I'm getting this error:
ld: warning: ignoring file /usr/local/lib/libsfml-system.so, file was built for unsupported file format which is not the architecture being linked (x86_64)
Undefined symbols for architecture x86_64:
"sf::Clock::Clock()", referenced from:
_main in ccZEiB7b.o
"sf::Clock::GetElapsedTime() const", referenced from:
_main in ccZEiB7b.o
"sf::Sleep(float)", referenced from:
_main in ccZEiB7b.o
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status**
And I have no idea what to do to fix it.
Short answer
Add the -arch i386 (on mac) or -m32 (on linux) flag
Long answer
Your sfml-system library was built in 32 bits whereas you are trying to compile your program in 64 bits. So your program cannot link to the library.
Recompile SFML in 64 bits if possible and you should be able to compile your program in 64 bits.
SFML expects you to use frameworks on OS X. Open the SFML folder and copy all the folders under lib64 to /Library/Frameworks (that is, copy SFML.framework, sfml-system.framework, etc. to /Library/Frameworks).
Once you've installed the frameworks, you can use them by passing the -framework command to g++ like so:
g++ -o testing main.cpp -framework SFML -framework sfml-system