optional package for libraries are not hybrid-enabled

[pulkomandy]

installing optional package with libraries only installs them for the 'main' gcc. For example, on a gcc2 hybrid you don't get the gcc4 version of the lib.

With the current runtime loader behaviour, this means when running a gcc4 app, the gcc2 lib could be loaded.

Even worse, running a gcc2 app on a gcc4h install in this case leads to load of the lib, which itself depends on libsupc++. Loading this in a gcc2 image causes a lot of weird bugs in unrelated places.

I think this could be solved by renaming the gcc4 libs, for example using "4so" as a suffix instead of just so. This would help avoiding mixups, and allow to put the libs in the same directory. As a result, the optional packages for gcc4 can be installed in a gcc2 hybrid without creating problems.

On the other hand :

• The package manager may solve that in a better way ? (installing the libs at the right place somehow ?)
• There is some work needed on build of packages, for example sdl-config, allegro-config and other pkg-config files should look to setgcc setting and use the right lib path according to that.

[bonefish]

Replying to pulkomandy:

• The package manager may solve that in a better way ? (installing the libs at the right place somehow ?)

With package management there will simply be two gcc4 packages: one for a gcc4 Haiku, one for a gcc2 Haiku. As such this solution is not related to package management. It could be implemented already, but would require work on the build system, as well as building all the new packages -- which would have to be solved differently/have to be redone with package management. So it isn't a particularly good investment of time ATM.

• There is some work needed on build of packages, for example sdl-config, allegro-config and other pkg-config files should look to setgcc setting and use the right lib path according to that.

First of all, as you already said, the runtime loader should not allow mixing shared objects for the two gcc versions. It should simply ignore mismatching ones. The reason why it doesn't and why both paths are searched is historical. It was necessary once, since we built C only libraries only for one gcc and used them in all combinations. I think all packages are available for both gccs now, so the runtime loader could be adjusted accordingly.

We may also need to go further and use another library path variable for the alternative gcc (like LIBRARY_PATH_GCC4 on a gcc2h build). Further path related changes (to gcc, cmake, pkg-config) may be necessary as well.

Save for the runtime loader related ones I'd put off the changes until package management is ready.

[pulkomandy]

PM solves this issue by providing hybrid packages.