Is it possible to distribute a library that will work for any compiler the user wants to build/link with? (assuming it understands c++ standard). If so, could it .dlls/.so or would it have to be a header-only library?
Basically I'd like my library to be easily usable to people on windows using Visual Studio and people on linux using gcc, and other platforms too.
Related
A very simple C++ question that is more aimed at the compilers:
Suppose I create a static library (.lib) or a dynamic linked library (.dll) with the latest Microsoft Visual C++ compiler.
Can I also use such a library directly in GNU C++ compiler projects (within the same operating system) if the header files are available?
That's not compatible with each other, is it? (I'm thinking first of a different ABI etc.)
Many Thanks.
PS: I have an unknown 3rd party library (lib) available. Can I find out here which compiler was used to generate it?
I'm trying out the clang32 compiler coming with C++ builder 10.2. Builder don't yet have any good support for CMake, so a great number of 3rd party libraries are (very) hard to compile using it.
Anyone knowing if there is any binary compatibility between clang32 and Visual Studio compiler?
There are essentially three different levels of compatibility you need to worry about:
File formats for object code and debug data, which allow you to use clang to build part of your project and Visual C++ cl.exe to build a library and then link them together and debug both.
Ability to write code and structure data that conforms to a portable binary interface, so it can be called across a mix of compilers.
Binary compatibility of the C++ standard library, so that standard library objects can be shared across a mix of compilers.
I can definitely say that (2) is supported and (3) absolutely is not; you can't even share standard library objects between different patchlevels of the same compiler. For (1) I don't know. A common way to bypass the issues with (1) is to build a DLL using each compiler, so they dynamically interface but no static linking nor merging of debug data is necessary.
If your concern is about cmake though, I think your problem is not the compiler (clang is available for Linux and cmake supports it well -- you should find the make scripts are capable of configuring all the compiler options). Whether it can generate project files for C++Builder is a different story, but perhaps you should consider using a different IDE. There are many with clang support, even Microsoft's Visual Studio has some ability to use clang for the compile step, and it's getting better with each release.
I know that in Solaris 10 Sun now Oracle don't provide static version of C library i.e libC.a
but I check that same thing is not possible using Sun Studio either, I was under impression that C library are provided by Compiler just like Visual Studio provides C runtime libraries.
So is on Solaris C libray is provided by system only and there is no way to get static version of libC.a compatible on Solaris 10?
Thanks
Not sure you can find one. This is "by design" - while the stdlib API are stable, the internals change between releases of the OS, so they force everyone to link dynamically to avoid breakages.
Using dynamic version in theory keeps your executables portable across different Solaris releases (but it is not guaranteed).
If you really want to have a completely self-contained executable, you probably should use GCC with its own stdlib.
I noticed that both my compiler (MinGW) and the Windows 8 SDK come with the same libraries, save the naming conventions (i.e. win32.lib on the Windows 8 SDK is libwin32.a in the MinGW libraries).
Do all compilers come with libraries such as these?
Are these libraries for multiple operating systems?
What is the difference (if any) between the libraries that come with the Windows 8 SDK and those that come with the compiler?
There are two kinds of libraries:
Import libraries:
These libraries only list where to find references to variables/functions/etc., but they don't contain the code itself.
"Normal" libraries (which contain object files that contain machine code):
These libraries contain object files, which contain the actual machine code.
The libraries that ship with an operating system are generally import libraries.
The actual code, after all, is in the operating system itself; the import libraries merely tell you how to use the code provided in the operating system.
Why is this necessary? Because there is no way for a program to "discover" the libraries available on an operating system while it is running, so the program has to know what will be available when it is compiled.
Those that come with a compiler are generally code libraries; they contain code that the compiler requires (which varies depending on your particular compiler) in order to comple your program.
However, there is no single "standard format" for a library; Microsoft uses COFF, but *nix tools use ELF.
So when Microsoft ships the import libraries for a system, it only ships them in COFF format, which is great for the Visual C++ compiler -- but not so useful for other compilers.
This causes compiler vendors such as MinGW to be forced to create their own import libraries for the operating systems which they intended to target -- the purpose of these libraries is exactly the same as as those provided by the operating system vendor (such as Microsoft), but their format is different.
That's why you see seemingly similar libraries provided in multiple ways.
MinGW comes with its own set of SDK libraries for the simple reason that MinGW is intended to provide a freely available compiler implementation that can produce Windows programs, but the Windows SDK is not freely available in the sense that the MinGW developers want/need. Because of the license on the Microsoft Windows SDK, it is not something that can simply be distributed with the MinGW compiler. So a significant part of the MinGW development effort is a set of headers and libraries that provide the Windows SDK functionality without infringing on Microsoft's licensing terms.
A fair bit of the MinGW WinSDK is public domain (maybe even most or all of it). All of it is freely distributable open source.
There may also be compatibility issues with MinGW using MS object files and libraries, but I was surprised to find that MinGW can often link to object files and libraries produced by MS compilers (though I'm not sure if there are any guarantees that it is supported).
A related issue is that MinGW relies heavily on the msvcrt.dll C runtime DLL provided by Microsoft. But that DLL is not distributed by MinGW - it's a part of every Windows OS, so MinGW relies on it simply being present as a base OS facility.
I am creating a open-source C++ library using Visual Studio 2005. I would like to provide prebuilt libs along with the source code. Are these libs, built with VS2005, also going to work with newer versions of Visual Studio (esp VS Express Edition 2008)? Or do I need to provide separate libs per VS version?
Not normally, no. Libraries built with the VS tools are linked into the 'Microsoft C Runtime' (called MSVCRT followed by a version number) which provides C and C++ standard library functions, and if you attempt to run a program that requires two different versions of this runtime then errors will occur.
On top of this, different compiler versions churn out different compiled code and the code from one compiler version frequently isn't compatible with another apart from in the most trivial cases (and if they churned out the same code then there would be no point having different versions :))
If you are distributing static libraries, you may be able to distribute version-independent libraries, depending on exactly what you are doing. If you are only making calls to the OS, then you may be OK. C RTL functions, maybe. But if you use any C++ Standard Library functions, classes, or templates, then probably not.
If distributing DLLs, you will need separate libraries for each VS version. Sometimes you even need separate libraries for various service-pack levels. And as mentioned by VolkerK, users of your library will have to use compatible compiler and linker settings. And even if you do everything right, users may need to link with other libraries that are somehow incompatible with yours.
Due to these issues, instead of spending time trying to build all these libraries for your users, I'd spend the time making them as easy to build as possible, so that users can can build them on their own with minimal fuss.
Generally it's not possible to link against libraries built with different compilers, different versions of the same compiler, and even different settings of the same compiler version and get a working application. (Although it might work for specific subsets of the language and std library.) There is no standard binary interface for C++ - not even one for some common platform as there are in C.
To achieve that, you either need to wrap your library in a C API or you will have to ship a binary for every compiler, compiler version, and compiler setting you want to support.
If your library project is a static library, then, you'll have to supply a build for every Visual Studio version that you want your users to be in. In the example you gave, that equates to providing both a VS2005 and a VS2008 library.
If your library project is a dynamic library, then, you evade the problems somewhat, but, it means that users will need to make sure that they use the 'Microsoft C Runtime' that's compatible with your build environment. You can eliminate that criteria should you statically link the 'Microsoft C Runtime' into your dynamic library.