Building programs with multiple versions of gcc installed

compton · 06-09-2020, 09:49 PM

I'm on Slackware64-14.2. I have found a new audio software to play with, called Geonkick. The new program requires =>gcc-7. I upgraded stock gcc-5.5.0 package to gcc-9.3.0. The new program has a standalone version and an lv2 plugin version for use in host software. Both the standalone and the plugin, which is a shared object(.so), build and run with gcc-9.3.0 installed. Then I downgraded gcc.9.3.0 back to gcc-5.5, and Geonkick wouldn't run anymore, neither the shared object, nor the standalone executable. They look in /usr/lib64 for GLIBCXX_3.4.26 not /usr/gcc93/lib64. I figured I need both versions of gcc installed. I modified gcclegacy494.SlackBuild from SBo to install gcc-9.3.0 as package gcc93-9.3.0 in /usr/gcc93 concurrently with stock gcc-5.5. In order to make Geonkick build with gcc-9.3.0 I exported these varables:

Code:

export CC=/usr/gcc93/bin/gcc-9.3.0
export CXX=/usr/gcc93/bin/g++-9.3.0

So as not to have to prepend geonkick with

Code:

LD_PRELOAD=/usr/gcc93/lib64/libstdc++.so.6.0.28

every time I use the program I added theses linker options to $SLKCFLAGS variable in the slackbuild.

Code:

-L/usr/gcc93/lib64 -Wl,-rpath=/usr/gcc93/lib64

...and

Code:

export LD_RUN_PATH=/usr/gcc93/lib64/

Now the standalone executable works normally, but when loading the plugin in an lv2 plugin host, geonkick still fails with:

Code:

/usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by /usr/lib64/lv2/geonkick.lv2/libgeonkick_lv2.so)

$ strings /usr/lib64/libstdc++.so | grep GLIBC

Code:

GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
GLIBCXX_3.4.9
GLIBCXX_3.4.10
GLIBCXX_3.4.11
GLIBCXX_3.4.12
GLIBCXX_3.4.13
GLIBCXX_3.4.14
GLIBCXX_3.4.15
GLIBCXX_3.4.16
GLIBCXX_3.4.17
GLIBCXX_3.4.18
GLIBCXX_3.4.19
GLIBCXX_3.4.20
GLIBCXX_3.4.21
GLIBC_2.3
GLIBC_2.2.5
GLIBC_2.14
GLIBC_2.18
GLIBC_2.17
GLIBC_2.3.2
GLIBCXX_DEBUG_MESSAGE_LENGTH

$ strings /usr/gcc93/lib64/libstdc++.so | grep GLIBC

Code:

GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
GLIBCXX_3.4.9
GLIBCXX_3.4.10
GLIBCXX_3.4.11
GLIBCXX_3.4.12
GLIBCXX_3.4.13
GLIBCXX_3.4.14
GLIBCXX_3.4.15
GLIBCXX_3.4.16
GLIBCXX_3.4.17
GLIBCXX_3.4.18
GLIBCXX_3.4.19
GLIBCXX_3.4.20
GLIBCXX_3.4.21
GLIBCXX_3.4.22
GLIBCXX_3.4.23
GLIBCXX_3.4.24
GLIBCXX_3.4.25
GLIBCXX_3.4.26
GLIBCXX_3.4.27
GLIBCXX_3.4.28
GLIBC_2.2.5
GLIBC_2.3
GLIBC_2.14
GLIBC_2.6
GLIBC_2.4
GLIBC_2.18
GLIBC_2.16
GLIBC_2.17
GLIBC_2.3.2
GLIBCXX_DEBUG_MESSAGE_LENGTH

$ ldd /usr/lib64/lv2/geonkick.lv2/libgeonkick_lv2.so |grep libstdc++.so

Code:

libstdc++.so.6 => /usr/gcc93/lib64/libstdc++.so.6 (0x00007fca354ff000)

Any feedback would be greatly appreciated.

business_kid · 06-10-2020, 04:30 AM

Programs come numbered program-x.y.z, where
z+1 indicates a bug fix in latest release.
y+1 = feature addition in latest release.
x+1 = compatibility break in latest release.

From my days over at LFS, the toolchain consists of: kernel headers; gcc; glibc, and you won't get far without binutils. For such differing versions of gcc, I'd be thinking of making /opt a directory you can chroot into, and do your crazy stuff with gcc-5.5.0 there. You can install retro duplicates there, build there, etc, safely out of the way of your base system. Stick /opt/lib(64) & /opt/usr/lib(64) on to the end of /etc/ld.so.conf, run ldconfig, and it should go. Even pkgtools accommodate a different root dir. And whoever thinks this is a bad idea will chime in shortly after I post this

moesasji · 06-10-2020, 08:58 AM

For situations like this I suggest you could look at guix on top of Slackware. Guix has this application packaged, which should make this relatively straight-forward. Note that although Guix takes a bit of getting used to it definitely helps installing bits of software that require newer compilers

mickski56 · 06-10-2020, 11:25 AM

@compton Don't know the solution but the problem is the plugin host is compiled with a different older compiler and c libraries.
recompiling the plugin host just seems to push the problem deeper into the system.
Any solutions would be welcomed, but I'm unsure there are any.

compton · 06-11-2020, 05:08 AM

Quote:

Originally Posted by mickski56

... the problem is the plugin host is compiled with a different older compiler and c libraries.

Thats what I was thinking.

Quote:

Originally Posted by mickski56

recompiling the plugin host just seems to push the problem deeper into the system.

But maybe not. Recompiling the host doesn't seem that bad, its not an official Slackware package. I guess I'd have to recompile all the other plugins though. I will consider that.

Quote:

Originally Posted by mickski56

For situations like this I suggest you could look at guix on top of Slackware.

That looks cool. I wanna try it out.
I've been considering upgrading to current as well.

Thanks for the reply's

mickski56 · 06-13-2020, 04:17 PM

Quote:

But maybe not. Recompiling the host doesn't seem that bad, its not an official Slackware package. I guess I'd have to recompile all the other plugins though. I will consider that.

What I was getting at is the host my now be compiled with the same compiler and libraries as the plugin but some of the libraries it links against will not be, so it still won't work. I've only tried this with retoarch mind you not an audio plugin and host ymmv.

business_kid · 06-14-2020, 04:49 AM

Drawing on my Jesuit education which, incidentally, I have mainly refuted & rejected), they did teach how to break the law with style.

If you compile plugins with static libs(?? I'm getting lost at this stage) They'll have their own libs included. They will be bigger, but the 'linked against' problems will disappear.

@OP: Personally, I think we've talked this around enough. Let's see you try something, see how it works out and we'll go forward from there.

DarrenDrapkin · 06-29-2020, 11:07 AM

As a contrast to all this assertion about what you need to do. I present my analysis of what may have happened here. The bulid process may be linking to the compiler itself, always a bad idea.

business_kid · 06-30-2020, 03:18 AM

Maybe we should wait until we see what the OP does, as I'm sure he has enough useful ideas. He's the one who wants to gain experience with a compiler that is at this stage, a subject of interest only to computer archaeologists & paleontologists.