How to Edit and Re-Build the Gcc Libstdc++ C++ Standard Library Source

How to edit and re-build the GCC libstdc++ C++ standard library source?

Yes, you have to build the whole of GCC, but once you've done that you only need to rebuild the libstdc++ part.

Building GCC is described at http://gcc.gnu.org/wiki/InstallingGCC

The libstdc++ sources are in the libstdc++-v3 directory. The parallel algorithms are in libstdc++-v3/include/parallel, they are templates so all the code is in headers. The small amount of non-header code is in libstdc++-v3/src/c++98/parallel-settings.cc

After configuring and building the whole of GCC as normal, you can rebuild libstdc++ by running make in the $TARGET/libstdc++-v3 directory (where $TARGET is something like x86_64-pc-linux-gnu).

By default the makefiles don't have proper dependencies that cause objects to be rebuilt after headers change, so you might need to do make clean then make again to get your changes to be picked up.

How to compile my own glibc C standard library from source and use it?

The Makefile is going to exist in your build-glibc directory if the configure script finishes successfully.

If everything seems to have gone smoothly during configure and still no Makefile, then you probably missed an idiosyncrasy:

While doing a configure for glibc, it is expected that you normally provide an alternative --prefix, because installing to the default location (/usr/local) can potentially cripple the system. If you don't provide one, then you need to switch on --disable-sanity-checks.

If this is not the case either, look for a config.log file, and read its contents.

How to build an application that requires both libstdc++.so.5 and libstdc++.so.6?

You may try to build a wrapper library around your 3rd party library: use the static version of that library + link it with the static standard library (-static-libgcc - make sure you pick up a proper version via -L). The important thing to do is to close this wrapper library properly, i.e only symbols from the original 3rd party library should be exported, everything else should be hidden. This way you wrapper library will expose all needed symbols for your application and encapsulate standard stuff inside. Note it is not guaranteed to work especially if some memory operations are shared between your code and 3rd party code (e.g. you allocate memory in your code and deallocate in 3rd party)... in such case the only option can be to keep this 3rd party lib in a different process space.

I don't think the dynamic option mentioned above would work because you will get exactly same problem - just later.

In general it is better not to mix binaries with different run-times in the same process space. It is almost always a recipe for disaster.

Producing a library with a recent gcc and consuming it with an older gcc - Why are there issues despite the same C++ version?

Does it mean that in general, it is necessary but not sufficient for the
producer and the consumer of a library to use the same C++ version (and the > same ABI) ?

Correct. Backwards/forwards compatibility is not defined just by the C++ language version used when compiling source code. Backwards/forwards compatibility is a complicated topic of its own. But I'll just give a simple contrived, example that illustrates some underlying concepts.

Let's simplify what a std::string is. It's basically a pointer, and the number of characters in the string:

namespace std {

class string {
char *chars;
size_t nchars;
public:
// Constructors and other methods.
};
}

The real std::string is somewhat more complicated (and would use symbol names that are reserved for C++ implementations, but that's immaterial). This is just a simplified illustration. std::string existed even before C++11. So, things roll along, over the years, and your C++ compiler has been updated to C++20. For whatever reason its C++ library decided to change this class slightly:

namespace std {

class string {
size_t nchars;
char *chars;
public:
// Constructors and other methods.
};
}

At this point you can choose to instruct your new C++ compiler to compile only at the C++11 language revision. This will allow only C++11 language features. However the resulting binary code still will not be binary-compatible with code that was built by an older version of the C++ compiler, which was compiled with an incompatible class layout.

In general: in order for C++ code built by a new compiler to be binary compatible with code built by an older compiler, an explicit compilation/configuration option would be needed. It's certainly possible that this is this might be the option that specifies the general C++ language version, but just doing that is not generally sufficient. All that does is instruct the compiler which language version to use for compiling the C++ code. Newer language versions obsolete/deprecate features from earlier versions, and the purpose of the language option is to allow source code written for an earlier version of the C++ standard to be compiled, by the current C++ compiler. This is not the same thing as backwards/forwards compatibility.

Error building gcc 4.8.3 from source: libstdc++.so.6: version `CXXABI_1.3.8' not found (required by /usr/lib/x86_64-linux-gnu/libicuuc.so.55)

So, this problem occurs when a library that has been built with a newer compiler is linked with an older version of C++ library - or sometimes when a newer headerfile is used to compile something that then links to an older C++ library.

It is also possible come up with a similar problem when moving binary files from one system to another, if the shared libraries installed on the "new system" are older than the ones on which the code was built.

There are typically three plausible solutions:
1. Recompile the offending library with an older compiler.
2. Install a newever version of the C++ library.
3. Rebuild the C++ library from sources (with a new enough compiler).



Related Topics



Leave a reply



Submit