Can I use shared libraries created by different versions of GCC and how?
I have undefined reference to errors while linking. But these names exist in the so libraries. I figured out that libs were built with older GCC version (2.8), I'm using current GCC version (4.7) and thus it seems that names are mangled differently:
Built by GCC 2.8.1:
setInfo__10SS7_HeaderUl
Built by GCC 4.7.2:
_ZN10SS7_Header7setInfoEm
and can't be resolved (right?).
Is there any way to use old shared libraries without rebuilding them? (Maybe I can recompile existing code using some backward compatibility flags, etc, to suit old libraries)
Is there any way to use old shared libraries without rebuilding them?
No: gcc-2.x and 3.x are not ABI-compatible.
If you somehow managed to fix the mangling, you'd just get a crash because the object layout is completely different. The mangling was changed precisely to save you the trouble of debugging runtime crashes that would be very hard to understand.
Related
I am building Go code that uses CGo heavily and this code must be compiled into a shared or static library (static is highly preferred). (code for reference)
It all works just fine on Linux and Mac, but on Windows it fails on linker stage either saying that all 4 modes (c-shared, shared, c-archive, archive) are not available or if invoke go tool link -shared manually complains about missing windows specific instructions.
My understanding is that all I need to build usable lib.a is to compile everything I will use into object files (*.o) and then put it through ar to produce usable static library.
Now the question is whether I can completely skip Go's linker and based on prepared .o files create .a manually?
How would I go about doing that if that is even possible?
Looks like gcc on windows is unable to automatically discover necessary shared libraries. The problem was caused by GCC and not by Go.
Although for compiling Go I had to use self-compiled master tip as current release (1.6.2) does not support shared/static libraries on windows/amd64.
Manually feeding gcc with each shared library (ntdll, winmm etc) in default location (C:\Windows\SysWOW64) has fixed the problem.
Given a GLIBCXX version of the stdc++ library (example GLIBCXX_3.4.17) given this version, where would one find documentation which specifies what features have been implemented?
Further is there a way to which given the SO NAME version will provide the this same document.
I am working on an embedded system which has an existing version of libstdc++; unfortunately the supplied cross compiler (g++) is at a greater version than what the stdc++ library on the target supports. Upgrading the stdc++ library on the target is not an option. Before I write a lot of code, to only find that it does not run on the target; I would like to know beforehand what is and is not supported.
I have found the GNU Documentation to be useful; however, I am hoping there is a document in which one can get what has been implemented given the symbol version and/or the SO NAME and I just have somehow missed it.
Thanks for any help in advance
given this version, where would one find documentation which specifies what features have been implemented?
You can map a GLIBCXX_A.B.C symbol version to a GCC release by checking
https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html
N.B. that won't be precise, because e.g. GCC 5.1 and GCC 5.2 both use GLIBCXX_3.4.21 in the shared library. To tell them apart check the __GLIBCXX__ macro defined by the libstdc++ headers, also documented on that page.
The manuals for libstdc++ releases are at
gcc.gnu.org/onlinedocs/gcc-[X.Y.Z]/libstdc++/manual/
e.g.
https://gcc.gnu.org/onlinedocs/gcc-5.3.0/libstdc++/manual/
Within that manual is a status table showing the implementation status for each standard, the table for C++11 support in GCC 5.3.0 is at
https://gcc.gnu.org/onlinedocs/gcc-5.3.0/libstdc++/manual/manual/status.html#status.iso.2011
Before I write a lot of code, to only find that it does not run on the target; I would like to know beforehand what is and is not supported.
It's not enough to simply avoid using features that aren't supported by the library on the target system. If you link with the cross-compiler then it will depend on the libstdc++.so from that cross-compiler, and will fail to run on the target system if it only has an older libstdc++.so
Upgrading the stdc++ library on the target is not an option.
Then you either need to link statically (creating large executables) or downgrade your cross-compiler to match the target. Or at least force it to use the headers and dynamic library from the same version as found on the target (by overriding the header and library search paths to point to copies of the older files), although that might not work, as the newer g++ might not be able to compile the older headers if they contain some invalid C++ that the older g++ didn't diagnose.
I'm using the latest github version from https://github.com/bulletphysics/bullet3
To generate the visual studio solution, I've used the 'vs2010.bat' located in bullet3/build3. This sets it up as static libraries however. If I change the configuration type to dynamic, the .dlls are generated properly, but no .lib-files.
I've also tried using CMake with "BUILD_SHARED_LIBS" enabled, but again, no .lib-files are generated.
What's the proper way of building bullet as shared libraries?
At the moment it is not possible using Visual Studio on Windows to generate import libs (.lib) when using shared libraries for Bullet. The reasons is that no symbols are explicitly exported. Shared libraries work fine using gcc or clang on Linux and Mac OSX. It would require quite a bit of work to instrument the code to fix this issue.
See also https://cmake.org/Wiki/BuildingWinDLL
When I need to build some third party library to be used in several of my projects under different version of MSVC, I usually build it for every MSVC version and for both Debug and Release configurations. That's what boost does, and that's what we have been done for our whole life in my team.
However, I still don't get, why couldn't I just build this library with like... whatever. All I need is function prototype and object code, right? Since I'm linking CRT statically, I have no external dependencies. But when I'm trying to link library built in Release under MSVC8 with my project in Debug under MSVC10 I have this annoying "already defined" linker errors which we all hate so much.
But why? Can I just "encapsulate" all this functions inside lib and do not export them so that my project will take only what it needs from the lib? Why can I have precompiled version of libpng and zlib which I can link in every project? Yes, they are not build using MSVC, I guess, but the still uses the same functions of CRT. So can anyone please explain in depth or share a link to some enlightened explanation of this issue?
Since I'm linking CRT statically, I have no external dependencies
Well, that's not true, you do have a dependency. On the static version of the CRT. Debug or Release, depending on your build settings. And it is an external dependency, the linker glues the CRT later, when the library gets linked. The code that uses the library also has a dependency on the CRT. And if the compile settings don't match then the linker barfs.
You isolate that dependency by building a DLL instead of a static link library. You must further ensure that the exported functions don't cause a CRT dependency. You can't return a C++ object from the standard C++ library and can't return a pointer to an object that needs to be released by the client code. Even passing structures is tricky since their packing is an implementation detail, but you usually get away with it. A good practical example is COM automation, it forces you into using a subset of types that are universal. Windows is rife with them and all these servers work with any version of the compiler or CRT. Even any language. This however comes at a cost, writing such a library isn't as simple or convenient as just throwing a bunch of code in a static lib.
I'm trying to compile boost and mongodb.
I want 64bit versions, shared libs and dynamic linking to the runtime.
Boost is compiled with link=shared, runtime-link=shared, threading=multi (and some others). The lib and dll files have names like: boost_*-vc90-mt-1_41.dll
Now mongodb has per default set: /MT (multithreaded static). The linker required boost libraries with libboost_*-vc90-mt-s-1_41.dll (notice the additional lib and -s). So I changed the option to /MD (multithreaded dll) and the -sdissapeared but the libstayed. I tried it with /DBOOST_THREAD_USE_DLL /DBOOST_ALL_DYN_LINK but it doesn't change. Does the linker still look for the static libs?
Please help :)
BOOST_ALL_DYN_LINK should have done the trick. Please make sure you rebuild your project from scratch, though.
If the problem still persist, I guess you need to tell what is hiding behind the asterisk -- maybe there's a bug with a specific library.