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.
Related
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.
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 know that if I link my c++ program to a dynamic library (DLL) that was built with a different version of Visual Studio, it won't work because of the binary compatibility issue.
(I have experienced this with Boost library and VS 2005 and 2008)
But my question is: is this true for all versions of MSVS? Does this apply to static libraries(LIB) as well? Is this an issue with GCC & Linux as well? and finally how about linking in VS to a DLL built with MinGW?
By the way aside from cross-platform or cross-compiler, why can't two version of the same compiler(VS) be compatibile?
Hi. I know that if I link my c++ program to a dynamic library (DLL) that was built with a different version of Visual Studio, it won't work because of the binary compatibility issue. (I have experienced this with Boost library and VS 2005 and 2008)
I do not remember ever seeing MS changing the ABI, so technically different versions of the compiler will produce the same output (given the same flags (see below)).
Therefore I don't think this is not incompatibilities in Dev Studio but changes in Boost.
Different versions of boost are not backwards compatible (in binary, source they are backward compatible).
But my question is: is this true for all versions of MSVS?
I don't believe there is a problem. Now if you use different flags you can make the object files incompatible. This is why debug/release binaries are built into separate directories and linked against different versions of the standard run-time.
Does this apply to static libraries(LIB) as well?
You must link against the correct static library. But once the static library is in your code it is stuck there all resolved names will not be re-resolved at a later date.
Is this an issue with GCC & Linux as well?
Yes. GCC has broken backwards compatability in the ABI a couple of times (several on purpose (some by mistake)). This is not a real issue as on Linux code is usually distributed as source and you compile it on your platform and it will work.
and finally how about linking in VS to a DLL built with MinGW?
Sorry I don't know.
By the way aside from cross-platform or cross-compiler, why can't two version of the same compiler(VS) be compatibile?
Well fully optimized code objects may be compressed more thus alignment is different. Other compiler flags may affect the way code is generated that is incompatible with other binary objects (changing the way functions are called (all parameters on the stack or some parameters in registers)). Technically only objects compiled with exactly the same flags should be linked together (technically it is a bit looser than that as a lot of flags don't affect the binary compatibility).
Note some libraries are released with multiple versions of the same library that are compiled in different ways. You usually distinguish the library by the extension on the end. At my last job we used the following convention.
libASR.dll // A Sincgle threaded Relase version lib
libASD.dll // A Single threaded Debug version
libAMR.dll // A Multi threaded Release version
libAMD.dll // A Multi threaded Debug version
If properly built, DLLs should be programming-language and version neutral. You can link to DLLs built with VB, C, C++, etc.
You can use dependency walker to examine the exported functions in the dll.
To answer part of your question, GCC/Linux does not have this problem. At least, not as often. libstdc++ and glibc are the standard C++/C libraries on GNU systems, and the authors of those libraries go to efforts to avoid breaking compatibility. glibc is pretty much always backward compatible, but libstdc++ has broken ABI several times in the past and probably will again in the future.
It is very difficult to write stable ABIs in C++ compared to C, because the automatic features in C++ take away some of the control you need to maintain an ABI. Especially once you get into templates and inline functions, where some of the code gets embedded in your application rather than staying contained in the shared library. That means that the object's structure can't ever change without requiring a recompilation of the application.
In practice, it isn't a huge deal on Windows. It would be fantastic if Microsoft just made the MSI installer know how to grab Microsoft-provided DLLs from Windows Update when an app is installed that needs them, but simply adding the redistributable to an InnoSetup-generated installer works well enough.
I have libraries which are build using VC++. I want to use the same libraries in a program and build in cygwin gcc compiler. Is this scenario will work?
Since C++ doesn't have a standardized ABI, and since Visual C++ and g++ in particular almost certainly have different ABIs, I don't think you can do this. Your only real option is to restrict yourself to C, not C++.
Edit: If all of the libraries that you're using are straight C (extern "C", in C++ terms), then you ought to be able to share libraries between compilers. (Otherwise, your Cygwin and MinGW apps couldn't call the Windows API.) You'll need to be careful to match up calling conventions. For example, the Windows API uses __stdcall instead of the standard C calling convention. You can tell GCC which calling convention to use with function attributes. Google, and your library's header files, should have more information on what calling convention to use.
Probably not
There is mingw a port of GCC (and lots of gnu tools) to windows which uses standard windows libs - it's pretty much a drop in replacement for cygwin and should be easier to link to gcc.
Greetings,
I am facing a complicated situation about using a static library under windows.
The static library is build by a specific version of mingw which is bundled with Eiffel studio. Since Eiffel studio uses mingw to create its output as a static lib, I have no control over this configuration.
If I try to use this static library with Eclipse CDT which is using a more recent version of mingw, then I can't compile my project. This is because I have to provide -l options to various libraries like winsock, and it appears due to difference between versions of compilers generating static library and my code, this does not work.
If I force Eclipse to use the same mingw directory that comes with Eiffel studio, the one that compiled the static lib, then I can compile my code (there are some other issues here though)
I do not want to constrain my c++ development just because a static library is build with a particular version of mingw.
So how can I use this static library from my own mingw version? This is windows xp btw..
Best Regards
Seref
Though I don't have a lot of information here is what I would do:
Try to compile with the newer version of mingw and see if you can make it work. Errors are very important in this case (you should check also the mingw manual/mailing lists/forums for finding about the compatibility between mingw versions
Separate the library from the program and wrap all its functionality - to avoid different incompatible compilation flags (you could create a different library - even a DLL and call your new functions (wrappers for some library functions)
Decide what part of the project is mandatory - the part with the library or the rest of the code
If the library is mandatory I would compile the code with that version of mingw
Else I would try to find an equivalent for that library or eliminate it
Others option may be available but this is what I would do (in this order)