2

I have an embedded application that has been written for gcc 3.2.31, and I want to link a library, written by myself, and compiled using g++ 7.2.0.

I have already built and link a test library with almost no code, but now that I am trying something more relevant, I face some issues regarding undefined symbols. Currently, I have the following kind of errors:

undefined reference to __assert_func

I do not get this error if I compile using g++ 3.2.3.

I want to use g++ 7.2.0 to have access to the new C++14 (maybe C++17) features and some new parts of the standard library (std::chrono::duration, etc.).

Is there a way to make this work?

I can fix the above issue by defining my own __assert_func:

extern "C" void __assert(const char *, int, const char *);

extern "C" void __assert_func(
    const char *file, int line, const char *, const char *e) {
    __assert(file, line, e);
}

...but I was wondering if there is a simpler way? In particular, there may be other name changes and I do not want to have to modify these everytime...

I assume I will not use new features that would require code that is not in the old gcc version (e.g., std::thread or std::chrono::system_clock).


Related:


1 The application and the library are built using the sparc-rtems gcc toolchains, and some third party tools such as JamaicaVM. I cannot simply change the toolchain used to build the main application because there are many incompatibilities with the new compiler toolchain...

Holt
  • 36,600
  • 7
  • 92
  • 139
  • @VTT It's my code that contains such symbol. I have some `assert` in my code (currently for debugging purpose), and in the recent gcc versions, the `assert` macro calls `__assert_func`, while in old version it simply calls `__assert` and there are no `__assert_func` does not exist in the old libc. – Holt Aug 08 '18 at 08:53
  • Actually after rereading your question I've realized that you want to squeeze static libraries build with newer toolchain into old toolchain. I doubt that this is going to work. You may check [gcc ABI policies](https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html). But even if no linker errors occurs it would probably not going to work correctly. – user7860670 Aug 08 '18 at 09:01
  • @VTT The current (dirty) fix actually works, it just boils down to finding the right symbols... I was just hoping there would an somehow simple way to tell gcc to build for old libraries, or maybe a list of changes between the two (even if these are years appart... ). – Holt Aug 08 '18 at 09:07
  • @VTT I would be interested to know what kind of problems could occur at runtime once the linker step succeed. That may change my approach on the actual problem. – Holt Aug 08 '18 at 09:09
  • 1
    Use older gcc to compile that code (along with library files supplied with older gcc version). There is a clear line in the link @VTT posted: `GCC 3.4.0: libstdc++.so.6.0.0 (Incompatible with previous)`. The only releable way would be to check gcc commits for changes. Or you can try linking both old and newer library with some objcopy renaming tricks. – KamilCuk Aug 08 '18 at 09:32
  • @KamilCuk I would not have asked this question if I wanted to compile with the old version. The old gcc version is 3.1.3 which does not even have `c++0x`... The line you mentioned is the link is about `libstdc++`. I know there might be incompatibility issues in the C++ ABI, like different mangling or different class layout, but the interface between the two code is C, not C++, and as mentioned, I can manage to not rely on any external C++ dependencies (e.g., `std::chrono` templates classes do not require any external dependencies). [...] – Holt Aug 10 '18 at 20:05
  • @KamilCuk [...] I've kept going with my current approach and by being careful with what I am using, I did not face any issue except `__assert_func`. As I commented to @VTT, I am simply wondering what kind of runtime problems I could run in under the assumptions I mention in my answer (interface between code is C, no external libstdc++ dependencies, etc.). – Holt Aug 10 '18 at 20:09

0 Answers0