(I am new at pretty much everything that I will discuss here... apologies if the question is very basic) - I used Xcode to write some C++ code using OpenCV (dynamic libraries). The algorithm runs smoothly and I created an executable file that also works. However, it only works in my computer.
I understand that I need to use static libraries instead of dynamic libraries. I have done some research and found how to do this here: http://www.shiffman.net/2011/01/23/how-to-build-opencv-static-libraries-mac-os-x/ and here: http://www.randomsequence.com/articles/opencv-snow-leopard/.
I have followed the steps and, although I had to make a couple of changes, I was able to build ".a" files such as "libopencv_highgui.a".
My code, however, doesn't work anymore when I replace the libraries. I get 200+ errors. This is one of them:
Undefined symbols for architecture x86_64:
"_gzputs", referenced from:
__ZL7icvPutsP13CvFileStoragePKc in libopencv_core.a(persistence.o)
I have searched for this question here but this is the closest I could find: Linking OpenCV libraries in Xcode (not exactly the same question).
Thanks everyone!
You need .a files from $OPENCV_BUILD_PATH/3rdparty/lib/.
The _gzputs from your question belongs to libzlib.a
To link with OpenCV static libraries you also need to add all OpenCV's dependencies to you application. The most of these dependencies comes from the opencv_highui module and the list of dependencies is dependent from your build configuration so I can't tell you the full list. But you can find it yourself: open the CMakeCache.txt from your OpenCV build directory with any text editor and search for opencv_highgui_LIB_DEPENDS line. You need all items from that line except the word general.
Related
Recently I ran into a CMake problem that can be found in this thread:
Cmake on OSX Yosemite 10.10.3 - GLEW: package 'gl' not found
Eventually it got solved, maybe partly due to my inexperience in XCode and CMake. (I mainly used visual studio to compile projects in the past.)
After the alteration in the linked thread I got warning about my GLEW libs in CMake
(Is this something I should be worried about or is it not important?):
MACOSX_RPATH is not specified for the following targets:
GLEW_MX_shared
GLEW_shared
I simply ignored it and tried to compile my project in XCode with the ALL_BUILD target selected. In the sparky target it said the include files in main could not be found so I added the .h files into the inc folder of my project.
When I compiled again the compiler started complaining again
(I don't know what this error means and how I can fix it.):
ld: library not found for -llib
Googled it for the entire day now and I can't find anything to solve this issue.
It's so frustrating working with XCode as an IDE but I really want to learn more about different platforms and their most popular IDE's so I can make multi platform applications from the start instead of porting it afterwards.
And if it matters I am using OSX Yosemite 10.10.3.
To make my issue easier to understand, I've put a zip of my project on my dropbox.
https://www.dropbox.com/s/xnrh90kuih9ia5a/SPARKY%202.zip?dl=0
Feel free to ask questions if I explained things to briefly and again, thanks to everyone who contributes here. I really learned allot after discovering these forums.
EDIT: Alright I booted up my windows machine, generated a visual studio environment and tried to build it on there. Seems that the same problem also happens here. I looked at the linker attributes/flags and saw a lib.lib file added to the linking process which doesn't look right at all.
When removing the file, the error disappeared and many others arrived! (Which are simply solved by linking the appropriate libs so I wont handle those here.)
I misunderstood the error on my mac and thought it was referring to a random library which I needed to hunt down but actually it's a inconsistency in one of my CMake files.
EDIT2: Now I only have to find out where the lib.lib comes from and how I can ditch the flags from the project so I can generate my environment and build right away!
So moral of the story. Sometimes the solution is right in front of you and still ends up more like looking for a needle in a haystack.
I removed the following from my root CMakeLists.txt file and the random lib.lib library was gone from my generated projects
SET( PROJ_LIBRARIES "lib" )
I thought this added a folder containing libraries but actually what it did was adding another flag for a specific library because this variable was being fed to:
TARGET_LINK_LIBRARIES( ${PROJ_NAME} ${PROJ_LIBRARIES} ${OPENGL_LIBRARIES} ${GLEW_LIBRARIES} )
Much research here and in-depth exploration via Google links, to no avail.
I've made a simple, one function, static C library with OSX Xcode (5) which I'm trying to link into a Lazarus app, basically to port the Xcode function from Xcode to Lazarus.
Xcode builds the static library alright, and I have what seems to be the proper linkage code in the Lazarus app, as follows:
type
byteptr = ^byte;
const
libname = 'libLORaudio.a';
function LORaudioPlay (fd : longint; audio : byteptr): Integer;
cdecl; external libname;
r := LORaudioPlay(e, z);
All of that compiles just fine, but the build fails with the following messages:
Id: symbol(s) not found for architecture i386
Id: Warning: ignoring file libLORaudio.a, file was built for archive which is not the architecture being linked (i386): libLORaudio.a
(and it goes on to say the function is undefined, of course, since it ignored the library that supplies it.)
My problem could be solved in either of two ways, neither of which have I found sufficient information on, online nor within Xcode or Lazarus.
One solution would be to get Xcode to produce the static library with the architecture expected by Lazarus. I have tried the various options for setting the build architectures in Xcode mentioned in other answers here to similar questions, but it seems I haven't done them correctly because none of them worked for me.
The other solution would be to get Lazarus to accept the architecture produced by Xcode. The Laz.y documentation is not helpful in this regard.
Any suggestions I could try? Thanks so very much for your consideration.
So eventually, I scrounged around with Finder and found where (see below) I had built both the x86_64 and the i386 object files in separate attempts to solve the problem. This was done by changing the build settings for Architectures to 'i386'. Subsequent re-builds for 'x86_64' didn't remove the i386 object info from earlier.
Then I copied the i386 object file into the folder containing the Lazarus project (it was necessary to make the copy with the alt-option dragging method, as copy then paste didn't work).
There, I ran ar on it in Terminal, as: 'ar -r -s libname.a name.o' to build the static lib from the object.
Lazarus now handles the library as desired. (This of course, revealed some other buggy situations to be dealt with, but hey, progress happens.)
Xcode had put both versions of the object in a folder. Find these products from Xcode by right-clicking on the product mentioned in the project navigator and choose 'show in finder'. You can do this for whichever architecture you currently have; both lead to the same build folders. From there work your way back up thru the containing folders until you spot Build. Open that and work your way forward among the contained folders until you get to Objects-normal. In there you'll find folders for i386 and x86_64. Each of those folders contains the corresponding object file as name.o among other product related files.
I'm trying to write a simple game engine for iOS in Objective C and C++ using Xcode.
I've made a game project and a game engine project. The latter is added to the former as a subproject. The engine is also added as a target dependency and as a binary to be linked in the game project.
My engine uses CADisplayLink so I add QuartzCore.framework in the engine project's "Link binary with libraries list" (found in Build phases).
Now, when I try to build my game project (the project with the subproject), I get this error:
Undefined symbols for architecture i386: "_OBJC_CLASS_$_CADisplayLink", referenced from: objc-class-ref in libVoya-iOS.a
This error only happens when building from the game project - doing it from the engine project works fine. If I add QuartzCore.framework to the game project building works fine.
Can it really be true I have to specifically require frameworks that one of my target dependencies already have required? In this case: My engine (sub project) already links QuartzCore - is it really necessary to also do this in the projects using this engine? It feels like double work for no reason.
Or perhaps I've just completely misunderstood something? :)
Add QuartzCore framework to fix this issue.
I've now found the answer to my question and I'd like to share it.
Static libraries are nothing more than a grouping of the compiled versions of the library's source files. They do not include any libraries they themselves might depend on.
Fusing all dependencies together happens only when you build the actual executable in the very end. For this reason, your application should indeed link against your dependencies' dependencies.
As for the example in my question, that means that my game should link QuartzCore while my game engine should not (even though it is my GameEngine who is using it).
Learn more here:
Duplicate symbol: Include static lib A in static lib B, also include lib A and B in XCode Project
Linking static libraries, that share another static library
I believe this is because you're using a target dependency instead of linking against a precompiled library.
I added a static Library and its header file to my OSX project and added them to Link Binary With Libraries under Build Phases.
Xcode gives me the following warning
ignoring file /Users/sd1212/Desktop/OpenGLPlugin/libClientLib.a, file was built for archive which is not the architecture being linked (x86_64)
and wont let me call any of the library methods. I thought I had an architecture problem, so I looked online... Maybe the instructions weren't clear or something, but I think that I already have the x86_64 architecture added, and I changed "Build Active Architecture only" to "No."
Here is a screen shot of the project's architecture settings
Please help! Thanks in advance
Look at the project that builds the static library, as well as the project that links to it, and make sure they both build the right architecture. Consider not only the Valid Architectures line, which you highlighted in your screen shot, but also the Architectures setting. The ones that get built are the ones in both lines.
How to build a .bundle from source code?
This might sound like a simple problem but it has been hurdling me for a week...
Here is my problem:
I have a bunch of .c and .h files that are organized in a folder and its sub folders. The source code was written and compiled with gcc make and tested by many other make tools. The source code has some utilities and command line tools and it has more code that serve as library for those utilities and tools. It is the files that serve as libraries that I want to reuse. (By library I don't mean static library or something, I just mean that some .c and .h files in certain subfolders provide functions that can be called by some other .c files. I want to be able to call those functions, too)
Yet my problem is more complex than that: I need to build those .c and .h into a bundle to reuse it. I am not writing my application in C; I am developing in Unity and Unity can only take in .bundle files on Mac OS.
Here is my goal:
Organize the source code folder in a proper way so that I can build them into a bundle in Xcode 4.
Here is where I got stuck:
When building the project I got the following error:
Duplicate symbol _main in
/Users/zeningqu/Library/Developer/Xcode/DerivedData/ccn-cfygrtkrshubpofnfxalwimtyniq/Build/Intermediates/ccn.build/Debug/ccn.build/Objects-normal/i386/ccndsmoketest.o
and
/Users/zeningqu/Library/Developer/Xcode/DerivedData/ccn-cfygrtkrshubpofnfxalwimtyniq/Build/Intermediates/ccn.build/Debug/ccn.build/Objects-normal/i386/ccnd_main.o
for architecture i386
I can relate to this error because I can find lots of main entries in the source code. Most of them are test utilities.
Here is what I tried:
I tried removing all those utility .c files but with no luck. The error is still there. I delete and delete until some files cannot find the definition of the function they are calling. So I had to stop there.
Though I wasn't able to build a bundle I was able to build a C/C++ static library (with an .a extension). After I got the .a file I tried to put it into another Xcode project and tried to build it into a bundle. I could build a bundle in that way, but then I had problem accessing the content of the bundle. How do I call functions defined in a .a static library if that library is hidden in a bundle? I read about Apple's documentation which says:
Note: Some Xcode targets (such as shell tools and static libraries) do
not result in the creation of a bundle or package. This is normal and
there is no need to create bundles specifically for these target
types. The resulting binaries generated for those targets are intended
to be used as is.
(quoted from: https://developer.apple.com/library/mac/#documentation/CoreFoundation/Conceptual/CFBundles/AboutBundles/AboutBundles.html#//apple_ref/doc/uid/10000123i-CH100-SW1)
Here is what I thought about:
I thought about replacing all main with something like main_sth. But the source code was not written by me so I didn't want to modify it. (It just doesn't feel like a proper way of doing things to me...)
I learnt that Xcode has gcc compiler built in. So I guess if gcc can make it, so can Xcode? It's just a wild guess - I am not familiar with Xcode and gcc.
Here is a summary of my questions:
Is there a way to properly organize a pile of code previously compiled and made by gcc make so that they can be built into an Xcode bundle?
Is it meaningful to put a .a library in an Xcode project and build it into a bundle? If it is meaningful, how do I call functions defined in .a after it is built into a bundle?
Is it proper to just replace all main() entries with something else?
Alright I think I have figured out at least one solution to the problem.
The duplicate main error was caused by a bunch of main entries in my source code. When the code was compiled by gcc make, I guess the author defined a sort of compilation order so that duplicate mains won't be an issue. (If you know how to do this, please let me know. I barely know make tools.) But when I just add the entire source code folder into my Xcode project, of course Xcode would complain during linking...
As I was unwilling to modify the source code (because the source code library is not developed by me), I decided to use another strategy to walk around this problem.
If your duplicate main error was reported from your own code, you can stop reading here. But if you are like me, with a bunch of gcc compiled source code and badly need a bundle yet don't know what to do, I may be able to help.
Okay here is what I did:
I set up an empty workspace.
I built a C/C++ static library project.
Import my entire source code folder into the static library project.
Set some header search path for the static library project.
Build the static library project. (Now I have a .a library which I could link against)
I set up another project, with a bundle target.
At the bundle project -> Build Phases -> Link Binary with Libraries, add the .a library that I just built.
At the bundle project -> edit scheme -> Build, add the static library project to the scheme and move it up the list so that it is built prior to my bundle project.
Then add .h files of my library project to my bundle project as references.
After that, add a .c file in my bundle project that basically functions as a wrapper. I picked a function that I want to call in Unity, wrote a wrapper function in the new .c file, and was able to build the bundle.
After several trial and error, I was able to import the bundle into Unity and was able to call the test function from Unity.
I was really excited about this! Though it's not completed yet I think this gives me hope and I am confident I can use the source code now! And the best thing about this solution is that I don't have to modify the library code developed by others. Whenever they update their code, I just update my .a library and that's it!
Though I have listed 11 steps I still feel that there are lots of details that I missed. So here are my references:
I followed this tutorial to build my source code into a static library: http://www.ccnx.org/?post_type=incsub_wiki&p=1315
I followed this blog to link static library against my bundle code and twist build phases and search headers: http://blog.carbonfive.com/2011/04/04/using-open-source-static-libraries-in-xcode-4/
I followed this doc to import my bundle to Unity3D Pro as a plugin: http://unity3d.com/support/documentation/Manual/Plugins.html
I strongly recommend the second reference because that's what solved my problem!
Though the problem is almost solved there are still a few things that I haven't figured out:
I don't know if a wrapper function is at all necessary. I will try this out tomorrow and come back to update.
-- I am coming back to update: the wrapper function is NOT necessary. Just make sure you have all the headers in your bundle project and you will be able to use all the data structures and call functions defined in your headers.
I haven't used NSBundle class though I read a few docs about it. Previously I was thinking about using that class to access my .a library encapsulated in my bundle, but as I found the solution I wrote above, I didn't try the class out.
Lastly, if you have better solution, please don't hesitate to let me know!
I tried to follow the steps in the accepted answer, but had no luck. In the end, I realised step 10 needed to be modified slightly:
Create a dummy.c under (.bundle) project and the dummy.c can just be totally empty.
Remove the setting for the library you want to link inside Link Binary With Libraries
Instead use -Wl,-force_load,$(CONFIGURATION_BUILD_DIR)/libYourLib.a or -all_load to Other Linker Flags
PS: And also can use sub-project instead of workspace. and use Target Dependencies instead of Edit Scheme to achieve the same effect.