Compiler related shared object problem

abalabanb commented 6 days ago

Since the release of the latest SDK new compiler versions were provided officially. When compiling with one of them dependency to one of the compiler standard shared objects (libstdc++, libgcc...) may be added to the resulting executable. This executable will then expect the same version of these shared objects to be present in the SOBJS assign. In an AmigaOS context where the official compiler version does not evolve for years this is not a problem. But now that several new versions have been released and most of the three existing applications were compiled with the previous official one the problems start due to binary incompatibility between each version of these shared objects,leading to strange and misunderstandable crashes when trying to run such old applications with updated SOBJS directory, or when trying to run new applications with outdated SOBJS directory.

The problem is bi-fold: 1) from one compiler version to another these standard shared objects may or may not be binary compatible (nothing can be done to this) and 2) these shared objects are not versioned.

On Linux there is not such problem because somehow they managed to have the binary to load the appropriate shared object at compiler version dependent path (eg. /usr/local/lib/gcc/x.y.z/).

What can be done to solve this is either

replicate the same thing as in Linux and have subdirectory in SOBJS for each compiler version with the standard shared objects. But this requires cooperation of the kernel team probably.
to have these shared objects versioned in their name with the compiler version eg. libstdc++. so for GCC x.y.z becomes libstdc++.so. x.y.z. The user would then have several libstdc++ living in its SOBJS. Ideally if the linker could manage this automatically this would be better as this would maintain compatibility with other platform on the command line options.

3246251196 commented 5 days ago

There was a discussions tab, but I cannot find it. I think we talked about this before and we just need to agree on a solution. Joerg definitely is of the opinion of simply using more uniqueness in SO file names.

abalabanb commented 5 days ago

Yes I think name uniqueness is quicker and easier to achieve. But please consider finding a solution to avoid requiring developers to specify the version number for these compiler SOs in their makefile.

3246251196 commented 4 days ago

AmigaLabs / adtools

Compiler related shared object problem #16