I am using SFML, and I am building an application in Code::Blocks and mingw32. I have have added the SFML libraries (sfml-whatever.a) to my project, and it runs nicely.
BUT iIrc, the static libraries get 'compiled' into the executable. If this is so, then why do I have to place all the SFML DLL's next to the executable for it to run anywhere outside of Code::Blocks? And if I were to somehow 'dynamically link' the DLL's from within Code::Blocks to my project, (I don't know how to do that), would I still have to ship my executable with all the .a files for it to run properly?
Thanks in advance, I am not quite familiar with libraries, static or dynamic. If it makes any difference, I am working on Ubuntu linux, and I am using mingw32 for cross-compiling.
With SFML you can link statically to their libraries as mentioned in the comments above. This way its all compiled into the executable and you won't need to ship it with the DLL's. How this is done depends on whether you are using SFML 1.6 or 2.0.
1.6 doesn't require any preprocessor definitions, but 2.0 requires you to build a solution/makefile using cmake for your compiler and then #define SFML_STATIC in your preprocessor definitions.
In this case, the static libraries simply contain the code that interfaces to the dynamic libraries, it's not the actual library code.
Related
I wrote a static library (compiled with TDM-gcc 4.8.1 in Windows 7 for x64) that has dependencies on other static libraries. Boost libraries (locale and system) to be specific.
Since I'm building a static library I assumed that the libraries I'm dependend on would automatically included in my final .a, especially since I'm using them in my code.
But when I'm trying to build an executable that statically links to my aforementioned library there are still undefined references to some boost parts, that are definitely used in my library.
Is there a way to fix that?
Any help is gladly appreciated. Thank you
Edit:
I haven't been careful enough, because I now know what causes the problem. I'm using codeblocks and all the necessary arguments for building the archive are declared in the project prooperties. But codeblocks doesn't even call the linker when building my library. Instead it calls ar.exe and passes all object files of my project. That way, no external library are ever included. So, I have too look for away to tell codeblocks to build the library in the right way..
Your executable needs to link against all the relevant libraries, including the ones it directly depends on, plus the ones it indirectly depends on. When you link a static library you typically do not embed other static libraries within it.
So I have this SFML 1.6 application that works well on Mac OS X Lion. Currently the way I have it is that the SFML frameworks are in /Library/Frameworks and it works well, however to install on other machines it requires admin privileges. So I want to do one of the following:
Be able to install the libraries in /User/idk/Library/Frameworks or similar
Package the libraries and the app into a Mac disk image and have it reference the libraries from there
Statically link the libraries
Now since the program is built using the Terminal with makefiles, I would prefer the solution to be in the Terminal rather than XCode, but if absolutely necessary then I guess I could somehow import the project to XCode.
So can anyone explain (precisely) how to do any of the three above, whichever is the easiest to do?
By the way I'm using the LLVM GCC 4.2 that ships with XCode 4.1 for the compilation.
EDIT:
How about someone tries the other two, aside from statically linking?
I solved it so... kind of a waste of bounty points... SUCKS FOR YOU! :P
I did something quite simple and was surprised no one else had suggested it:
I used install_name_tool to change the names and dependencies of the SFML dynamic libraries so that they can be placed in the same directory as the executable, or in a special folder, but that's relative to the executable's directory. So it requires no admin privileges, and I easily packaged it all into an application bundle.
You should probably statically link to SFML. To do this you will have to compile SFML as a static library. The easiest way to do this is probably to modify the Xcode project that comes with SFML ("SFML with Intel 64 bits.xcodeproj"). You need to change the Mach-O type of the libraries to Static Library.
I've uploaded the modified version of SFML with Intel 64 bits.xcodeproj that I use, you can get it here. (This project requires GCC4.2, and so only works with Xcode 3).
Statically linking to SFML is very similar to dynamically linking to it, just remember that you also need to link to Cocoa.framework, OpenGL.framework, and CoreFoundation.framework.
Also note that if you want to deploy to OSX 10.4 or earlier, you should statically link to libfreetype. The libfreetype that is supplied with the OS is in a different location in 10.4 and earlier, and this causes problems when it is dynamically linked.
Im helping on a c++ application. The application is very large and is spread out between different sub directories. It uses a script to auto generate qt .pro files for each project directory and uses qmake to then generate make files. Currently the libraries are being compiled in alphabetical order.. which is obviously causing linking errors when a library its trying to link isn't built yet.. Is there some kind of g++ flag i can set so it wont error out if a library its trying to link hasn't been built yet? or a way to make it build dependencies first through the qt .pro file?
NOTE:
This script works fine on ubuntu 10.10 because the statements to build the shared libraries didnt require that i use -l(libraryname) to link to my other libraries but ubuntu 11.10 does so it was giving me undefined reference errors when compiling on 11.10.
Have you looked into using Qt Creator as a build environment and IDE? I've personally never used it for development on Ubuntu, but I have used it on Windows with g++, and it works great there. And it appears its already available as a package in the repository.
Some of the advantages you get by using it are:
Qt Creator will (generally) manage the .pro files for you. (If you're like me, you can still add lots of extra stuff here, but it will automatically add .cpp, .h, and .ui files as they are added to the project.)
You can set up inter-project dependencies that will build projects in whatever order they need to link.
You can use its integration with gdb to step through and debug code, as well as jump to the code.
You get autocomplete on Qt signals and slots, as well as inline syntax highlighting and some error checking.
If you're doing GUIs, you can use the integrated designer to visually layout and design your forms.
Referring back to your actual question, I don't think it's possible for a flag to tell gcc to not error when a link fails simply because there is no way for the linker to lazily link libraries. If its linking to static libraries (.a), then it needs to be able to actually copy the implementation of that code into the executable/library. If its dynamically linking (.so), it still needs to verify that the required functions actually exist in the library. If it can't link it during the linkage step, when can it link?
As a bit of an afterthought, if there are cyclic dependencies in your compile process (A depends on B, B on C, and C on A), then you might need to have a fake version of a library get built first, which only has empty stubs for the implementation of each function, and the full definition for each class or object. Then, build everything else while linking to that, and at the end, build the real version of the fake library, and link it to all the other versions that were already linked. I think this would only work on dynamic linking, though.
You could use a subdirs project to have control over the build order (no matter whether the other dev wants it or not :) ).
E.g.
build_all.pro
TEMPLATE=subdirs
CONFIG+=ordered
SUBDIRS=lib2/lib2.pro lib1/lib1.pro app/app.pro
The lib1.pro, lib2.pro, ... are your generated pro files.
Then run qmake once for the build_all.pro and also run make in that directory. This will build lib2 before lib1 and then app.
I've compiled Boost and it works just fine. I would like to to copy specific .dll's and .libs into my project for deployment. The problem is I'm having a hard time finding which packages contain the libraries I need. I've looked around but haven't seen any documentation on what's actually inside the compiled libraries.
For instance, if I wanted to use boost:asio and boost::prt_vector in my project, which .dll/.libs should I copy over?
The entire library folder is over 1.2 GB so I'd rather not use the entire thing. I'm using Windows, vs2008.
Any ideas?
Are you deploying your application as an executable or as a project to be compiled by the user? If it is the former, you shouldn't need to send static libraries, as they're linked into your executable. If you build Boost libraries as dynamic libraries, you will need them of course.
But if you're deploying your app as something to be compiled, or if you have Boost DLLs, then as martiall said, you should use BCP.
You can use the bcp which is bundled in Boost
BCP Docs
I've tried searching A LOT for this with no luck (possibly because I'm not using the right technical terms). My issue is mainly to do with linking static libs, compiling and deploying. Before I get into details, my executables compile fine on my system; the main issue is how to deploy these as a working solution to others.
I've written a basic c++ image processing exe that uses OpenCV static libraries (I link these in VC++ using the Project>Properties>Linker> add additional dependencies, as standard). I compile by pointing to the right include files by setting the VC++ Options... basically, it all compiles fine. I now want to be able to deploy this on another PC. I understand I'll need the release version of the exe + static libs... is there anything else?
Some of the libs rely on using libjpeg and libpng; I don't think these are included as standard. Also, I've set the linker path to the static libs to be relative (e.g. resources/libs) so it's not system dependent so it knows where to find the libs. The basic OpenCV data strucs are working fine (e.g. CvPoint), but when I try to load an image using CvLoadImage, the application crashes. If I use standard ifstream fopen instead, I can open the file with no problems (but can't seem to get it into the IplImage OpenCV image strut - does anyone know how to do these? Probably to do with IplImage->imageData.).
Any help very much appreciated. Thanks!
Static libraries do not have to (and should not) be distributed with the application. Static libraries are built into the exe file by the linker.
The reason why OpenCV crashes is that it cannot find libpng/libjpeg dlls. OpenCV doesn't link them as static dependencies but uses LoadLibrary/dlopen APIs at runtime instead. If these calls fail, there's probably no nice recovery and the application crashes. Your problems should be fixed if you include the libpng/libjpeg libraries.
Also beware - some .lib files aren't truly static libraries but are just a thin layer that allows the linker to find the appropriate functions in a DLL and generate the dynamic linking code so that the programmer doesn't have to do that by hand. You will usually see that from the .lib file size that is pretty small and that your application cries that it cannot find a DLL entry point at the startup of the exe..