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.
Related
I'm trying to implement this tutorial with the addition that I want to include the json11 C++ library.
I followed the same process for both, downloaded the repo from:
https://github.com/libmx3/mx3, added them to the /deps/ folder of my project, and ran GYP to generate the .xcodeproj files for both.
Then I create a C++ project, add both the projects into the workspace, and add the libraries under Build Phases->Link binaries with libraries.
When I hit run the build fails with ld: library not found for -ljson11
I have tried regenerating them and adding them into the main xcodeproj. and into the Target Dependencies.
I have double-checked the library projects and they are identical. I have also added the folders where the .a files are compiled in Library Search paths but none of this makes a difference. If I remove the json11 dependency the project compiles, but I can't understand why the sqlite3 is found and throws no errors but the identical json11 project won't work.
I can see the .a files in the Debug-build folder and there are no errors if I build them separately.
Heres the full build log
Ld /Users/myuser/Library/Developer/Xcode/DerivedData/DjinniTest-eqaqzcfyskdxupbqpdngkdmoidtq/Build/Products/Debug/DjinniTest normal x86_64
cd /Users/myuser/Documents/Dev/djinni_test/cpp_project
export MACOSX_DEPLOYMENT_TARGET=10.11
/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.11.sdk
-L/Users/myuser/Library/Developer/Xcode/DerivedData/DjinniTest-eqaqzcfyskdxupbqpdngkdmoidtq/Build/Products/Debug
-L/Users/myuser/Library/Developer/Xcode/DerivedData/DjinniTest-eqaqzcfyskdxupbqpdngkdmoidtq/Build/Products/Debug/..
-F/Users/myuser/Library/Developer/Xcode/DerivedData/DjinniTest-eqaqzcfyskdxupbqpdngkdmoidtq/Build/Products/Debug
-filelist /Users/myuser/Library/Developer/Xcode/DerivedData/DjinniTest-eqaqzcfyskdxupbqpdngkdmoidtq/Build/Intermediates/DjinniTest.build/Debug/DjinniTest.build/Objects-normal/x86_64/DjinniTest.LinkFileList
-mmacosx-version-min=10.11
-stdlib=libc++
-ljson11
-lsqlite3
-Xlinker
-dependency_info
-Xlinker /Users/myuser/Library/Developer/Xcode/DerivedData/DjinniTest-eqaqzcfyskdxupbqpdngkdmoidtq/Build/Intermediates/DjinniTest.build/Debug/DjinniTest.build/Objects-normal/x86_64/DjinniTest_dependency_info.dat
-o /Users/myuser/Library/Developer/Xcode/DerivedData/DjinniTest-eqaqzcfyskdxupbqpdngkdmoidtq/Build/Products/Debug/DjinniTest
ld: library not found for
-ljson11
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Edit: even if I add the compiled files into the project so that they turn black, it still complains that the ljson11 library is not found. Maybe there's something wrong with the way the library is compiled?
Both the libraries gave warning that "macosx" was not found in the supported platforms. When I added it into the json11 project settings, the build compiled and both the warnings disappeared.
SQlite3 still only has iOS(iphone,iphonesimulator) but it compiles fine. I wonder what the difference is.
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 have build the poco library in solaris. My system configuration is SunOS solaris2 5.10 Generic_144488-07 sun4v sparc SUNW,SPARC-Enterprise-T1000. When I tried to run the sample which was provided along with the sample I am able to build and run the sample application. But when I wrote a seperate program and tried to link with poco library, I am getting the following error
ld: fatal: file /74bkp/ramesh/poco-1.4.7p1/lib/SunOS/sun4v/libPocoXML.so: wrong ELF class: ELFCLASS32
ld: fatal: file /74bkp/ramesh/poco-1.4.7p1/lib/SunOS/sun4v/libPocoFoundation.so: wrong ELF class: ELFCLASS32
I use the following command to compile the source
g++ -I/74bkp/ramesh/poco-1.4.7p1/XML/include -I/74bkp/ramesh/poco-1.4.7p1/Foundation/include -L/74bkp/ramesh/poco-1.4.7p1/lib/SunOS/sun4v DOMParser.cpp -lPocoXML -lPocoFoundation -m64
Can some one please give a clue. I could not move further.
regards,
Sam Mouli
You have built 32-bit binaries of Poco, therefore you cannot link them to 64-bit binaries.
Remove the -m64 option from the compiler call and optionally add -m32, then it should work. Alternatively, build 64-bit binaries of Poco and link to them.
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.
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....