I have a large iOS project in Objective-c that also has a large number of C++ classes in a 6 subfolders. If I have all of the C++ source code in the iOS project and compile from the source files, everything compiles and works just fine. All good so far.
I wanted to move all of this C++ code to a static library, so I created a new project and a wrapper for my classes and compiled it as a Static Library based on the numerous sets of instructions on SO. It compiles without any errors and created the .a output file with the appropriate header.
When I include this Static Library into my project I get 11 errors related to:
Undefined symbols for architecture arm64:
"Configuration::Configuration()", referenced from:
___cxx_global_var_init in libMInterfaceLib.a(M-
3fdac31d875d4f01157909522738d4c95b3c465d55314d375878e8f2faec0803.o)
"Type::GetSizes(int, int, int&, int&, int&)", referenced from:
CM::BitSizes() in libMInterfaceLib.a(M-
3fdac31d875d4f01157909522738d4c95b3c465d55314d375878e8f2faec0803.o)
When I use the lipo info command I get confirmation that my Static Library is architecture: arm64
$lipo -info libMInterfaceLib.a
Non-fat file: libMInterfaceLib.a is architecture: arm64
Which makes sense because I'm building the Static Library for a device and including it in a device build. I'm not using a Simulator for this project because it needs a live camera so I only need one Architecture which is arm64.
If I create a Static Library from the same code for the Linux version of the application it works just fine, so I know the basic code, headers and file structure is good. That Static Library says it is architecture x86_64 according to lipo -info which make sense.
$lipo -info libMInterfaceLib-OSx.a
Non-fat file: libMInterfaceLib-OSx.a is architecture: x86_64
The other thing I see is that the .a file built by XCode as a Static Library is 732KB, but the file built by eclipse for Linux from exactly the same source files is 2.2MB. Why would they be so different? All of the source code that is supposed to be included is 1.6MB.
I get the feeling that the problem is not that the Static Library is the wrong Architecture, but that it is not including all of the C++ files that are in the subfolders of the project. The other issue I see is that if I misconfigure the Static Library XCode Project to compile as an executable, I get exactly the same set of errors as I get when I include the Static Library into the device project, but I don't quite know what to make of that other than its not compiling all of the files. Its also super fast to compile which leads me to believe again that its not building everything into the Static Library that it should. Remember, when this C++ source code is added and compiled as part of the main project it all works fine.
Does anyone know how to ensure that XCode will include all of the files in the subfolder and classes that are associated with them? Is there a special linker setting that I need to be using in XCode to get it to link all of the C++ files that are part of the Static Library project?
Anyone know where I'm going wrong here?
Any help and guidance is greatly appreciated.
OK, So after a bunch of messing around I realized that just including the folders into the Static Library project didnt work. I had to create individual Groups for each folder and then import all of the files into those Groups as files in the folders. As there were multiple levels of files this was a pain in the arse but the final blurry eyed late night clue was that the folders in XCode were Blue and not Yellow. That was the only indication that they werent all included. There we no compilation errors in the Static Library project, it was only when trying to use that Static Library in another project that any errors showed up. I've been caught by the same thing before and should have recognized that when folders are Blue in XCode, it hasnt imported your files even though they show up inside and appear to build. C++ Static Libraries in XCode do work and its simple once you have all the files included in the Static Library project.
Related
Good evening,
I have been working on a C++ project from someone of my University which I had to improve for my Bachelor thesis. It basically uses the library libjpeg to do some computation resulting in a steganographic process in order to embed a message into a given image.
Now that the C++ code works smoothly, I'd like to create a little iOS app allowing the user to encrypt whatever message he'd like into an image of his choice. So I created an xCode project following this procedure: using c++ in an iOS app
I also found the following file: libjpeg for iOS which allowed me to compile libjpeg for iOS. Since I'm not so sure how to use the framework freshly created and couldn't find anything sufficiently convincing on the internet, I put all the files (.c and .h) of the libjpeg library into my "include" folder where I have my own .hpp.
xCode only throws me the following error:
xCode error
From what I could gather on several posts, I have to modify the build options of my xCode project to link manually the library, so I tried the following:
Other linking flags
Library search path
This wasn't enough to do the trick and I'm still struggling with the same error xCode throws at me. Any help would be very appreciated on how to proceed!
Thanks a lot,
Theo.
Do not add the .c files to your project, add the libjpeg.a file produced by your build to your project. Add the .h files as you are already doing, or edit the project settings to include their containing folder in the search path.
HTH
I have built a simple graphical engine with .obj mesh loader using OpenGL. Now I want to add some textures to my meshes. I intend to use .dds files to store them. I chose SOIL library for loading, due to its simplicity.
So far, I've only used dynamic dll linking for my externals(SFML, Glew, OpenGL32). SOIL, on the other hand, is a static lib. I've seen static libs built within project solution, which apparently adds em to .exe and eliminates the need to add dlls. I also read that there's another way to link static lib by adding reference in the Linker (I'm using VC++ 2012 as my DevEnv). However, after hours of searching I failed to find a suitable tutorial on how to accomplish this.
I renamed "src" directory in SOIL distribution to "include" (just to be consistent) and added it to Additional Include Directories, added the path to the lib directory to the Linker (where libSOIL.a file was stored) and added libSOIL.a to Additional Dependencies. It gave me lnk2019 err with SOIL_load_OGL_texture. I renamed libSOIL.a to SOIL.lib adjusting it in the linker as well - same err persisted. I proceeded to compile provided VS projects and built SOIL.lib in "VS9" and "VS8" project folders. Linking either was a failure.
In my final moment of desperation, I used extern "C", thinking SOIL is a C lib. That was totally stupid :) I went on to read that people use g++ to link their static libs, which I have no idea how to use.
Could someone, please, provide a simple step-by-step algorithm on how to link a static lib like SOIL to a VS2012 c++ project. If you have time, a video on the subject would be absolutely awesome!
Thanks heaps for any help!
P.S. If one of my attempts seems reasonably correct to you, can lnk2019 err pop up due to me compiling in (x64)?
Using netbeans 7.2 and the most recent version of MinGW (using installer) I can't use the libnoise library. I am properly including the header files, the auto completion confirms this, however the library is simply not working. There is a .lib file and a .dll. I have tried every possible combination of adding them under project > properties > Build > Linker as well as putting the .dll in the base project directory. Despite all this I am still getting undefined reference errors whenever I try and run the code. Does anyone know what to do?
I know that it is possible to link import library files (*.lib) with MinGW, but I still suggest to recompile libnoise.
With the current Makefile, this is not very easy and may break. Thus I've written a CMake script, which doesn't only work on Windows, but should work on all CMake supported platforms. In addition to this, I've cleaned up the directory structure. The code itself hasn't been touched and when you build a library it should essentially be the same as the current one.
libnoise on GitHub
After you've built your shared library, you'll have a libnoise.dll.a and libnoise.dll file. You then add libnoise.dll.a to the linking settings and put the DLL itself next to the binary, or in the working directory.
You have to link the lib file (= adding it to linker libraries) and put the dll to
<project root>/dist/<...>/
(where your exe is put to). There's no need to add the dll to linker too.
Can you please post the error message you get?
I am in the process of porting my c++ engine to mac, and so I used premake to generate an xcode project, which it does fine.
Box2D is built into the engine and one of its files "b2Broadphase.h" is including algorithm from the c++ standard library.
This is giving these errors: ::clock_t has not been declared and so on for all the using commands in the ctime file.
I cannot figure this out because when using premake to build a make file it runs fine and build a perfect library on OSX. Its only Xcode giving these errors.
My guess is that Xcode has not been configured to include the implementation files (.m or .cpp) or it has not been configured to link against a library which you are using. In general, you need to do two things: 1. include the headers 2. link against the libraries with the actual executable objects.
In Xcode, you do this by selecting the project (top-most item) in the file-browser panel on the left, and there is a section in the main area to choose which libraries to link to. You must specifically tell it to link against whichever libs you are using, even if you have imported their headers.
For .cpp or .m implementation files, you need to tell it to include that file in the target for compilation. This can be done either in the build settings (similar place to the lib inclusion) or else when you have a file selected, the inspector panel on the right has a little area for you to choose which targets to include the file in. (you only need to "include" implementation files like this, not .h files)
I'm trying to use TinyXml++ in my project, and I have tested it successfully in a small program before. I recently decided to use it to read a configuration file in my current project and though the code compiled, I got a ton of linker errors (unresolved external symbols mostly). I read in some forum thread, describing a similar problem, that I had to use the same runtime library as TinyXml++ was compiled with. I opened the accompanying Visual C++ 2008 project and saw it was using Multi-threaded Debug (/MTd).
I have now tested all runtime libraries with and without #define TINYXML_USE_TICPP before I include "ticpp.h". I've gotten from 9 to 80 linker errors (which I why I initially didn't want to post them all, but I will if you want to see them).
I have copied the static library ticppd.lib (found in the download folder) to my project's directory and linked it under Linker->Input->Addtional Dependencies. I have included a directory path to the TinyXml++ source under C/C++->General->Addtional Include Directories. What am I doing wrong? :(
TinyXML is a library with the full source code available; you should not need to include a .lib. You could separate TinyXML into a separate project and mark your project as depending on it, which will allow you to compile both projects with consistent settings for threading and debugging, but the easiest way to get it working should be to just add the TinyXML .cpp and .h files (just not the test one) to your project and compile.