I am in the need to link against a library (written in Qt by myself). Of course this would generate (regardless of the extern "C" and name mangling stuff) a lot of errors during linking because of the C++ dependencies (stdc++ and Qt).
So I have got an idea, but I'm not sure, if I am missing something or if the approach is a realistic solution at all:
Searching some hints on this topic, I have found an article about building static Qt. Without reading all of it in detail I think the solution could be to compile Qt statically and then link my application against this static version of Qt. In my opinion this should lead to a successful build because of the following reasons:
Building my Qt library with the static Qt Library (again as static lib) would resolve all dependencies because they are all in the static lib archive.
Because of the extern "C"d interface functions, that will be accessed by the c application the C compiler (and linker) will also see all dependencies resolved and here is no problem either.
Now before trying the exhausting steps to build Qt statically, I would like to know, whether this approach could solve the problem.
EDIT 1:
The alternative solution would be to implement a server-client architecture on top of both the Qt- and the C-part of the application and let them communicate in that way with each other.
EDIT 2:
The probably best solution is neither of the both mentioned. Instead I just wrote a dynamically linked boundary (as suggested by Laszlo Papp and dsu) and everything works fine.
Now before trying the exhausting steps to build Qt statically, I would like to know, whether this approach could solve the problem.
Based on the comments where you mention that becoming a commercial client of Digia is a problem, I would say no.
Static linking cannot happen with proprietary software, and based on your comment, your project is not open sourceable.
That being said, you seem to have your own wrapper anyway, and Qt keeps binary compatibility for a given major version the lifecycle of which is usually several years, so I would personally go for dynamic linking and some kind of binding.
Related
It's a bit annoying.
I have a project that is entirely dynamically linked, but I want to use a library that seems to be only designed to be statically linked, using the /MT flags, Is it possible to build a separate dll to link to the static libs and then link to that In my project?
I apologise for the rushed explanation, I'm quite tired.
The library in question is the bullet physics library.
Edit:
Well, with more googling, it appears that there can be a /MD/MDd compiled version, though I'm not sure where It's located.
Edit(for anyone interested):
According to this page: http://www.bulletphysics.org/Bullet/phpBB3/viewtopic.php?f=9&t=3846
"If your entire engine is compiled with the /MD flag then you would use the 'release DLL' version of bullet. You should not mix libraries compiled with /MD with ones compiled with /MT. That's the main difference. There is no "separate DLL (.dll)" files for bullet."
Edit: And If I build it using the MSVC Runtime library, then it fails.
In short, I have no idea what to do.
He's what I'm doing:
Building the whole library in cmake, using the Visual studio 12, 2013 compiler.
Then building the project built by cmake, to build all the required projects.
This is the supplied instructions. Here
Last Edit:Thank you all so much for you help! I managed to build it in the end
Sorry for any spelling mistakes, I was quite tired at the time :3
Short answer, yes.
Although you could just have the dynamic libraries link to it, there are scenarios where this may cause serious problems, depending on how the library was written (state information, etc.).
Although it's more work, a wrapper DLL is probably the safest course of action. However, this is offset by the fact that you only need to wrap the functions actually called from the various components of your application, not the entire API provided by the library. Also, you'll need to have some kind of slight rename to the functions you actually wrap, to prevent ambiguity.
On edit:
Just took a look at the bullet physics library, as I was not personally familiar with it and was curious about your options after I initially answered. If they're that explicit about not supporting dynamic builds for the library, I think wrapping whatever functions you actually use would definitely be safest. That sucks. I hope it's not too large of a cross-section.
I have a question related to embedding one library in another.
I have a code that is pure C and my users rely on that, they don't want to depend on C++ libraries. However, the need arose to embed a 3rd party library (ICU) into mine. None of the ICU functions would be exported, they would only be used internally in my library. Unfortunately ICU is a C++ library, though it does have a C wrapper. ICU does not use exceptions, but it does use RTTI (abstract base classes).
The question is how could I create my static library so that
ICU is embedded in my library (all references to ICU functions are resolved within my library)
all references to libstdc++ are also resolved and the necessary code is embedded into my library
if a user does not even have libstdc++ installed on their system things work just fine
if a user does happen to use my library within a C++ project then there are no conflicts with whatever libstdc++ (presumably the system libstdc++) he uses.
Is this possible at all? The targeted platforms are pretty much everything: windows (there my library is dynamic), and all sort of unix versions (linux, solaris, aix, hpux - here my library needs to be static).
gcc-4.5 and later does have --static-libstdc++, but as far as I understand it is only for creating shared libs or executables, and not static libs.
Thanks for any help!
The solution to this problem is pretty simple, but may not fall inside the parameters you have set.
The simple rules are:
You can dynamically link a C++ library to a C caller, but you have to wrap the library inside an extern C layer. You design the extern C API and implement it using C++ internals, which are forever hidden from view. [You can also use COM or .NET to do this on Windows.]
You cannot statically link a C++ library to a C caller. The libraries are different and the calling sequences/linker symbols are different. [You often can't even statically link between different versions of the same compiler, and almost never between different compilers.]
In other words, the solution is simple: use dynamic linking. If that's not the right answer, then I don't think there is one.
Just to make things interesting, you can even implement your own plug-in architecture. That's just another name for dynamic linking, but you get to choose the API.
Just to be clear, the only viable portable option I can see is that you link ICU inside its own dynamic library (DLL or SO). Its symbols, C++ libs, RTTI and exceptions all stay inside that. Your static lib links to the ICU dynamic lib by extern C. That's exactly how much of Windows is built: C++ inside DLL, extern C.
You can debug across the boundary, but you cannot export type information. If you need to do that, you will have to use a different API, such as .NET or COM.
I don't know if this will work, but let me at least suggest that you try it!
The excellent LLVM project (origin of clang compiler) has many front-ends and back-ends for different languages, such as C++ and C. And according to this S.O. question it should be possible for LLVM to compile C++ into C which in turn can be compiled as normal.
I imagine this route is a bumpy one, but if it works, it might solve your problem without the need to link dynamically. It all depends on if ICU will compile with LLVM C++.
If you do decide to give it a go, please let us know how you fare!
I need some help with wrapping C++ libraries in XCode.
What I want to achieve is to create new library in XCode, import C++ library (I have .a and .h files), wrap it to Obj-C so I can import that library to MonoTouch.
The reason why I do it round way is that when I try to import C++ lib into MonoTouch, because of name mangling I keep getting WrongEntryPoint exceptions. Correct me if I'm wrong but there is no way for me to find out mangled names, which depends on compiler.
Thank you in advance
Correct me if I'm wrong but there is no way for me to find out mangled names, which depends on compiler.
Technically you could. Many compilers share the same mangling syntax, maybe the most useful and long-lasting gift from Itanium ;-)
However it will bring it's own pain (e.g. non-primitive types, other compilers) and maintenance issues as you update your C++ code.
You'll better served by:
writing an ObjectiveC wrapper and use MonoTouch's btouch tool to generated bindings;
writing a C wrapper and using .NET p/invoke to call your code;
The choice it yours but if you think about reusing the C++/C# code elsewhere (e.g. Mono for Android) then using C and p/invoke will be reusable.
I would definitely recommend going the route of wrapping the library in an Obj-C library and using btouch to import the library into MonoTouch. I have recently done this for a C++ library that implemented a Sybase database engine. If you look at my questions you will find quite a few pertaining to wrapping C++ libraries as I posted a few times regarding issues I encountered.
Specifically, you can look at these questions:
Linking to a C++ native library in MonoTouch
Wrapping a C++ library in Objective-C is not hiding the C++ symbols
Application with static library runs on simulator but not on actual device
Undefined symbols when linking PhoneGap static library in MonoTouch
Linker options 'Link all assemblies" and "Link SDK assemblies only" causes undefined symbols in 3rd party static library
I would also recommend, if you are going to go the route of an Obj-C wrapper, that you get btouch to output code and include that in your project rather than including a dll from btouch. From my experience, the code worked more reliably than the dll, although the issues with the dll may have been resolved by now. But take a look at this question regarding the btouch issue:
Exception System.InvalidCastException when calling a method bound with btouch that returns an object. MonoTouch bug?
If you have specific questions/problems in building the Obj-C wrapper then ask them here and post some code and I am sure that I or other members of the community would be able to help you with it.
Bruce, as you assumed, I have problems with wrapping C++ code. After hours and hours of reading and trying, I couldn't wrap the C++ code.
Anyway, I managed to create a simple Obj-C library made of some dummy class, and then import it into another library. That worked fine. However, following same pattern, I included C++ .a file along with .h file (I'm not sure whether .h is mandatory because we can link header files in build options, right??) and when I compiled it, it went fine, the build succeeded, but XCode didn't produce new .a library.
I added linker flags: -ObjC -lNameOfLib
Does C++ Standard Library Type in Build - Linking has to be Static? And Symbols Hidden By Default as well?
It would be great if we could write step-by-step tut, since there are tons of various instructions, but I haven't been able to push it through the end.
I'm confused a bit..
Thank you guys...
What are the use cases of using static libraries in C++? I have seen that people create DLLs instead or some that use static libraries only. Whats your recommendation?
I'm a big fan of static libraries pretty much everywhere. The one big thing that DLLs get you that static libs cannot do is the ability to dynamically load and unload library functionality. So if your application is going to support some sort of hot swapping plugins, you need to use dynamic libs. Otherwise you can probably use static libs.
Static libs open the door to a lot of optimizations that you can't do with dynamic libs because they are performed at link-time. In the microsoft world Link Time Code Generation (LTCG) give you the ability to do whole program optimization and dead code stripping through not only your application, but also your libraries (in gcc this is called Link Time Optimization [LTO])
Additionally static libs tend to make your program easier to distribute because you aren't forced to pass around a lot of library files, and you can completely avoid DLL-hell if you ever were to version your library.
You should use shared libraries (DLL) if you have a significant functionality that needs to be shared between applications; AND this functionality may be improved independant of all the application and updates shipped seprately.
The 'AND' part is the hardest to fulfill: usually you ship your application with any new functionality added and never update the library without updating the application at the same time (I am not saying that never happens) but usually the two ship in lockstep.
Otherwise it is easier to just build normal libs and ship the application.
An Example of a good (I use the term loosely for example purposes) is DirectX. When a new version of DirectX is shipped (and the interface has not changed) you just need to update the DLL and all apllications that use DirectX get the benifit of the new version of the library. In reality it is not quite that simple but you get the idea.
In general, although there are always exceptions to the rule, I would say:
Advantages of DLLs
Less physical memory usage when running multiple instances of an application. (Copy on write optimisation of memory usage.)
Faster link times.
Smaller executables.
Better modularity.
Advantages of static libraries
Less virtual memory usage (and probably less physical memory usage) when running a single instance of an application.
Performance. Approximately 10% (more or less) improvement over DLLs, depending on your application.
Reliability. You tested your application against a specific version (or specific versions) of a library. An upgrade to a DLL could potentially break your application.
There is the advantage of not having to recompile your entire program if you make a change to a dynamically linked library. #Chris makes a good point about dll-hell but if it s a minor bug fix that doesn't affect the API, this can save you the recompilation.
There is a SO post that talks about Windows not being able to apply updates to your program if you statically link their libraries (link to come). Although i think you are more talking about statically linking your own modules.
Use static version of your libraries where you can. Use dynamic libraries where you need to (license, availability or plugin system).
I use static libraries to implement UML's "package" concept. All modules belonging to a package gets put into their own subdirectory, and I create an IDE subproject or makefile for that directory which builds a static library *.a file. Modern IDEs make it possible to work with your top-level package along with sub-packages within the same "workspace".
If a package (or a group of packages) can be deployed separately from the main executable, then I compile it into a shared library (*.so or *.dll) instead and consider it a "component" in UML jargon.
Well a Static DLL would be for holding huge libraries and also for using Multi-Os coode as i like to call it so it's able to be ran on Linux , Windows ...
I recently had to program C++ under Windows for an University project, and I'm pretty confused about static and dynamic libraries system, what the compiler needs, what the linker needs, how to build a library ... is there any good document about this out there? I'm pretty confused about the *nix library system as well (so, dylibs, the ar tool, how to compile them ...), can you point a review document about the current library techniques on the various architectures?
Note: due to my poor knowledge this message could contain wrong concepts, feel free to edit it.
Thank you
Feel free to add more reference, I will add them to the summary.
References
Since most of you posted *nix or Windows specific references I will summarize here the best ones, I will mark as accepted answer the Wikipedia one, because is a good start point (and has references inside too) to get introduced to this stuff.
Program Library Howto (Unix)
Dynamic-Link Libraries (from MSDN) (Windows)
DLL Information (StackOverflow) (Windows)
Programming in C (Unix)
An Overview of Compiling and Linking (Windows)
Start with Wikipedia - plenty of information there, and lots of links to other useful resources.
P.S. But perhaps it would be better to just ask a specific question about the problem you're currently having. Learning how to solve it may go a long way to teaching you the general concepts.
You can find some background information from this article here. It gives you the basic background. I'm trying to locate something with diagrams. This should be a good place to get started.
The fundamental differences between a static library and a DLL is that with the static library the code is compiled into your final executable whereas a dynamic link library involves linking in a "stub" library (into your application) which contains mappings to functions in a separate file (.dll).
Here's an MSDN entry on creating a static Win32 Library which might also help you.
..another link to MSDN for creating a Dynamic Link Library..
Just found this site which covers definitions of basically all the aspect you've quoted.
There is always MSDN for windows related stuff:
Head page for dlls ->
http://msdn.microsoft.com/en-us/library/ms682589
For Unix my favorite reference manual:
Programming in C, UNIX System Calls and Subroutines using C ->
http://www.cs.cf.ac.uk/Dave/C/
RM
See if these are useful:
Static and dynamic libraries
Program Library HOWTO