0

This may be a dumb question, but I am a novice in the compilation of a C or C++ project through the command line. I am currently trying to cross-compile some frameworks to run in an aarch64 device, which has a built-in gcc5.4.0. However, some of the libraries require at least gcc7.5.0. So my first question is:

  1. Can a framework that is compiled with gcc7.5.0 version can be used in an environment where gcc5.4.0 is present?

Moreover, some processes the I try to run on the device also requires gcc7.5.0. Therefore, my second question is that:

  1. Can an object file (.o, e.g. the output of the compiled .c / .cpp file) that is compiled with gcc7.5.0 run on a system with gcc5.4.0?

Lastly, some processes require the libraries compiled in gcc5.4.0 and gcc7.5.0 to be used together. Therefore, I have to link the .so files that are generated by both gcc5.4.0 and gcc7.5.0. Hence, my last question is:

  1. Can one create an executable by using libraries together that are compiled with different gcc versions?

Thanks.

Barış Batuhan Topal
  • 1
  • 2
  • I am unsure how compatible GCC 5.4.0 and GCC 7.5.0 are at the binary level. In prior projects using two different compilers (granted, which had incompatible C++ ABIs with one another), I had to make a COM-inspired C ABI firewall between the two C++ components, including marshaling and translating exceptions. I vowed in the future to never have to do that again. – Eljay Oct 04 '22 at 14:50
  • @Eljay many compilers will intentionally mangle names differently, among other things, so that they are not compatible, in order to avoid people accidentally relying on two compilers having the same ABI. – CoffeeTableEspresso Oct 04 '22 at 14:55

1 Answers1

0

For your first two questions: the presence or absence of a compiler in the system does not matter. I've run software on machines where no compiler was installed (it was compiled elsewhere). I've run software on machines where a bunch of compilers are installed, included multiple version of g++.

For your last question: the thing which matter when linking (either statically, at link time, or dynamically at execution time) libraries is called ABI. There are two aspects of the ABI: for the language itself, and for the standard libraries. For both, GCC maintains forward compatibility: using the latest compiler and standard library, you can link with object files compiled with older compiler (and for older standard library) since something like 3.4. In some more restricted cases (less well documented), you can even use the older compiler and standard library.

If you want to execute a program dynamically linked (which is usually the default with GCC) with a newer version of the standard library than the one on your system, you need to ensure it is found. That's a whole other subject, but here are two key words to help you find information for Unix (I know nothing about how Windows handle this, I presume but could be wrong that MacOS is a unix for this purpose): LD_LIBRARY_PATH and rpath.

Obviously meeting bugs is always a possibility and some care is needed in some cases. So here are some relevant links with the details.

AProgrammer
  • 51,233
  • 8
  • 91
  • 143