I want to use the libcurl in my XCode project on Mac. But I find there three lib curl dynamic libraries.
Namely, they are libcurl.dylib / libcurl.3.dylib / libcurl.4.dylib.
I find there are a lot of other libraries on Mac which also have the multiple version, in the same way as libcurl.
So what's the difference with those versions library, and which one should I use?
Isn't each one a soft link to the more specific version? Example libXXX -> libXXX.2 -> libXXX.2.3. If you always want the latest libXXX then you link to libXXX. But if you need a specific version you link to that specific version.
As you update OS X or Xcode, these libraries and their soft links get updated but you don't need to change which library reference you have.
Run a terminal window and do ls -l /usr/lib for lots of examples of this.
Related
I know this question is not specific to crypto++. But I compiled crypto++ on a Mac OS X using Qt. After building I see 4 files with the dylib extention:
libcryptopp.1.0.0.dylib
libcryptopp.1.0.dylib
libcryptopp.1.dylib
libcryptopp.dylib
What is the difference between them? Which one is actually used to compile against my application?
The multiple files exist in case your application needs to link to a specific version of it. Of course, you have just one version of the library, so it doesn't seem helpful, but consider these on my system:
libnetsnmp.15.1.2.dylib
libnetsnmp.15.dylib
libnetsnmp.25.dylib
libnetsnmp.5.2.1.dylib
libnetsnmp.5.dylib
libnetsnmp.dylib
Only .25, .15.1.2 and .5.2.1 are actual files, the rest are symbolic links for either. In your case, they're probably all symlinks except 1.0.0, so you case use either.
If you look carefully, there's just one actual dylib (libcryptopp.1.0.0.dylib) and 3 links to that one. These give you the version info for the library.
If you want to link to a specific version you can specify that, else if you always expect your app to work with the latest version, you can point to libcryptopp.dylib.
We just wrapped up a game in SFML for Mac and submitted it to the Mac store. We are using SFML 2.0. We're using a standard SFML project in Xcode with the link script that copies over the required frameworks. The game works great on all computers from Mac OSX 10.6-10.9. Trouble is, when we submit to the App Store, we get an email back saying the following:
Malformed Framework - The framework bundle
(Shibashiba.app/Contents/Frameworks/freetype.framework) must contain a
symbolic link 'freetype' -> 'Versions/Current/freetype'. Refer to the
Anatomy of Framework Bundles for more information.
If I go into the Archived application, the freetype.framework folder is in Contents/Frameworks and it has a symbolic link that points to Versions/Current/freetype, so I'm at a loss as to what this error means. Could it be some kind of permissions error? Could the freetype distro included with 2.0 be messed up in some way? Any help would be appreciated. This is our last hurdle to shipping!
I think I figured it out! Basically, the compiled freetype.framework included with SFML is linked incorrectly.
If you look in the folder using Finder, the links look correct, but if you compare it to sndfile.framework, it is different. For example:
sndfile.framework
sndfile -> Versions/Current/sndfile
Versions
A
sndfile
Current -> A
versus
freetype.framework
freetype -> Versions/A/freetype
Versions
A
freetype
Current -> A
You can see above that freetype points DIRECTLY to the "A" version of freetype, whereas in the correct "Anatomy", it should point to Current, which in turn points to the current version.
I changed the symlink and Apple accepted the corrected binary:
cd /Library/Frameworks/freetype.framework
ln -fns Versions/Current/freetype freetype
I working with Firebreath 1.7, MacOSX 10.8.3, Xcode 4.6.3.
I want add boost::chrono as static library to my plugin.
After running prepmac.sh i have my_plugin bundle target. I choose my_plugin target in project/targets tab and don't see option "Link binary With Libraries".
How i can add boost::chrono library to my_plugin by another method?
Changing things manually there is not the correct way to do it; you should never change the project files without changing the cmake files, because eventually you'll need to rerun the prep script.
First of all, are you using system boost? boost::chrono is not part of the boost that firebreath includes, which is a subset of the boost features to keep size down for those who don't want to deal with it. If you are using part firebreath boost and part your own, you could have problems.
If you've configured system boost correctly, you should be able to just add this to the end of your PluginConfig.cmake file and rerun the prep script:
add_boost_library(chrono)
Barring that, you could also just do it using cmake directly, which would mean adding a target_link_libraries command to your CMakeLists.txt or Mac/projectDef.cmake file at the end, something like:
target_link_libraries(${PROJECT_NAME} boost_chrono)
(you'd need to find out for sure what the library name is; you might even need to use find_library to locate it).
I'm writing an application in which I want to use free image to load files. I am on MacOSX 10.8.2 and I am using the mac ports version of free image. I had it working, but when I tried putting it on another computer without the port, it wouldn't run because it didn't have the files. The macports version comes with a dylib, can I use that to run it without downloading the port? If I can how would I compile it with the project because I have tried linking it as a Binary Library, but I can't include the files. Any help would be appreciated, as I have bee at this for a few hours now.
Thanks
You can actually build the FreeImage library as a static library. Unfortunately, the downloadable source from the http://freeimage.sourceforge.net/download.html website uses makefiles that are expecting to use the older SDKs for Xcode3.
I actually updated the Makefile.osx to build with Xcode4 using the 10.7 SDK and posted the change to https://gist.github.com/AhiyaHiya/5105571
You should be able to run this make from Terminal.app and create your .dylib and .a files for your needs.
I can't stand XCode, but really love OpenFrameworks, and I know it works on Linux+Win32 so I don't see why it should be XCode dependent. If I need to have XCode installed that's fine, I just don't want to use it at all.
Xcode internally uses gcc/llvm. in fact from the command line you can cd into a directory that contains an openFrameworks project and just type xcodebuild. but this won't allow you to edit the project file and add new source code, etc.
the Linux makefiles could be adapted to work on OSX as well. they already contain a lot of the information necessary about finding the correct source files, library paths etc. however Linux allows us to install many more components as shared system libraries, while on OSX we link most of the libs statically, so a number of extra library paths would need to be added. probably the biggest gotcha is that everything has to be compiled 32 bit, which means passing -arch i386 everywhere, so you can't just install dependant libs using Homebrew or MacPorts. we are in the process of transitioning to 64 bit but there are still some QuickTime calls that require us to stick with 32 bit, mainly around accessing legacy video capture devices that a lot of us still use for computer vision.
like #cdelacroix points out, we only maintain Xcode project files on OSX. this is mainly due to the lack of a decent alternative. there is a version of Code::Blocks for OSX but it is not very well supported, has some issues with native gui rendering and tends to lag behind the other platforms. Xcode is also the easiest way to install a toolchain on OSX so for most users installing Xcode is necessary.
if you do get a makefile based build system working, and would be interested in maintaining it medium to long term, please consider contributing it to the GitHub repository, it would be gladly accepted.
As of March 2013, openFrameworks has official makefile support for compiling the library itself. However, at the time of this writing, the changes haven't yet been merged into the stable release. You'll need to clone the Git repository and switch to the development branch.
git clone https://github.com/openframeworks/openFrameworks
cd openFrameworks && git checkout develop
cd libs/openFrameworksCompiled/project
make
As far as I can tell, we still need to use the unofficial solutions for compiling apps against the library.
You need Xcode, or at least a set of compilers (more information is available here), but otherwise, no, you can edit/work with the code in whatever editor or environment you want.
Here's a link to a makefile which will compile an OpenFrameworks application on OsX:
https://gist.github.com/labe-me/1190981
Place the makefile in the apps' directory and run make. Tested on OsX 10.6, but haven't tried with addons yet.
As #mipadi said, there is no requirement to actually use Xcode, you can do pretty much everything you do in Xcode with make or cake or any of your build system of choice. All you have to do is find the right set of command line options to pass to the usual tools (compiler, linker, strip, etc.), and sometimes the easier way is to... look in the Xcode build window how it is doing stuff (expand the lines with the small button on the right of each line).
For example you can link with your framework of choice with ld -framework Framework -FPathToFramework foo.o or your dynamic library with ld -lLib -LPathToDylib foo.o. You might have to learn about #rpath, #loader_path and install_name_tool to ship a self-contained packaged application.
As for OpenFrameworks, the "requirement" for Xcode is that the authors decided to maintain only Xcode project files. I just looked at how they do it, they ship source code and Xcode project files that build static libraries, so it will be even more simple for you (although you will need to link the library dependencies by hand). You will have to choose between compiling everything from source in your build system (if you want more customization power without touching Xcode), or just produce the 2 static libraries (openFrameworks.a and openFrameworksDebug.a) with Xcode once, then use them in your build system (recommended until you really need continuous customization).