Error: Can't figure out how to solve this.

[flixtor]

I get this error when ever I try to convert anything at all with qsvencc.

"usr/local/bin/qsvencc: /tmp/_MEIjlcVd7/libstdc++.so.6: version `CXXABI_1.3.15' not found (required by /usr/local/bin/qsvencc)"

And I have tryed to google it, reinstalled, updated etc, everything, also made sure to have the LD_LIBRARY_PATH set.

$ export LD_LIBRARY_PATH=/usr/local/lib64:${LD_LIBRARY_PATH})

And verifyed via: $ echo $LD_LIBRARY_PATH /usr/local/lib64:

I have made vainfo, clinfo, also qvencc --check-hw, qvencc --check-lib etc, I have done ANYTHING possible, still, I can't get it to work.

It happens after update, but I can't figure out which one, that caused this problem.

I am running on: CachyOS (Arch Linux), and have, for the last year, self compiled the qvencc without any problems so far.

I do have the log from the ./configure commands also, and can of course made one from the "make" also, and both of them shows no errors at all.

$ qsvencc --check-environment

QSVEncC (x64) 7.64 (r3360) by rigaya, May 12 2024 08:57:04 (gcc 11.4.0/Linux) Intel Media SDK API v2.09 reader: raw, avs, vpy, avsw, avhw vpp: resize, deinterlace, denoise, detail-enhance, image-stab, delego, sub Environment Info OS : CachyOS (6.9.1-2-cachyos-lto) x64 CPU: AMD Ryzen 9 5900X 12-Core Processor (12C/24T) RAM: Used 63029 MB, Total 64199 MB GPU: Intel Graphics / Driver:

$ qsvencc --check-lib

QSVEncC (x64) 7.64 (r3360) by rigaya, May 12 2024 08:57:04 (gcc 11.4.0/Linux) Intel Media SDK API v2.09 reader: raw, avs, vpy, avsw, avhw vpp: resize, deinterlace, denoise, detail-enhance, image-stab, delego, sub libmfxhw64.dll : v2.11

$ qsvencc --check-hw

Success: QuickSyncVideo (hw encoding) available Supported Encode Codecs for device auto: H.264/AVC FF H.265/HEVC FF VP9 FF AV1 FF

$ vainfo

Trying display: wayland Trying display: x11 vainfo: VA-API version: 1.21 (libva 2.21.0) vainfo: Driver version: Intel iHD driver for Intel(R) Gen Graphics - 24.2.3 (dd0084f) vainfo: Supported profile and entrypoints deleted rest of the information showed

$ qsvencc --check-clinfo

OpenCL platform #0 [0x0x5e8575cf3c40] Intel(R) OpenCL Graphics Intel(R) Corporation OpenCL 3.0 [FULL_PROFILE] deleted rest of the information showed

Is there anyone out there, that might be able to help me?

IMPORTANT information about me: I am autistic, and do have communications problems and not always can tell what I really want, please have this in your mind, before you judge me.

[rigaya]

According to gcc manual, CXXABI_1.3.15 is supported from gcc 14.1.0.

I think there is some dependency(.so) includes binary built by gcc 14.1.0 or later.

You can check which libstdc++.so is currently used on runtime by ldd.

For example, on my Ubuntu 22.04 system, it shows like below.

$ ldd qsvencc | grep libstdc++
        libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f30c7936000)
$ strings /lib/x86_64-linux-gnu/libstdc++.so.6 | grep CXXABI_
CXXABI_1.3
CXXABI_1.3.1
CXXABI_1.3.2
CXXABI_1.3.3
CXXABI_1.3.4
CXXABI_1.3.5
CXXABI_1.3.6
CXXABI_1.3.7
CXXABI_1.3.8
CXXABI_1.3.9
CXXABI_1.3.10
CXXABI_1.3.11
CXXABI_1.3.12
CXXABI_1.3.13
CXXABI_1.3.14
CXXABI_TM_1
CXXABI_FLOAT128

I'm not sure how you can update libstdc++.so.6 in CachyOS, but you'll need to update libstdc++.so.6 to the one which includes CXXABI_1.3.15, or rebuild qsvencc including the dependencies with the current compiler.

[flixtor]

Hi, and really many thanks for reaching out to me. I have even made a total fresh installation of another arch Linux, and ... same results.

I might have to try out Ubuntu, even I really don't want.

Here is my info:

$ ldd qsvencc | grep libstdc++ libstdc++.so.6 => /usr/local/lib64/libstdc++.so.6 (0x000073d34d400000)

$ strings /usr/lib64/libstdc++.so.6 | grep '^CXXABI_' CXXABI_1.3 CXXABI_1.3.1 CXXABI_1.3.2 CXXABI_1.3.3 CXXABI_1.3.4 CXXABI_1.3.5 CXXABI_1.3.6 CXXABI_1.3.7 CXXABI_1.3.8 CXXABI_1.3.9 CXXABI_1.3.10 CXXABI_1.3.11 CXXABI_1.3.12 CXXABI_1.3.13 CXXABI_1.3.14 CXXABI_1.3.15 CXXABI_TM_1 CXXABI_FLOAT128 CXXABI_1.3 CXXABI_1.3.15 CXXABI_1.3.11 CXXABI_1.3.2 CXXABI_1.3.6 CXXABI_FLOAT128 CXXABI_1.3.12 CXXABI_1.3.9 CXXABI_1.3.1 CXXABI_1.3.5 CXXABI_1.3.8 CXXABI_1.3.13 CXXABI_1.3.4 CXXABI_TM_1 CXXABI_1.3.7 CXXABI_1.3.14 CXXABI_1.3.10 CXXABI_1.3.3

$ gcc -v COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/14.1.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../configure --enable-checking=release --enable-languages=c,c++ --disable-multilib Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.1.0 (GCC)

I am newbie into compile and make this kind of install. Being on Winblows away to many years :-(

[rigaya]

I'm finding it difficult to find the cause of your system, but I think you can check the followings.

1. Are you using self built gcc for compile? Most of the time, it will be easier to use system default gcc/g++ for compiling.

2. In your system, qsvencc is using "/usr/local/lib64/libstdc++.so.6", but you are checking "/usr/lib64/libstdc++.so.6" with strings command. Is this the same file? If not, please have a check with "/usr/local/lib64/libstdc++.so.6".

3. You might also need to check the /tmp/ directory libstdc++.so.6 ("/tmp/_MEIjlcVd7/libstdc++.so.6" according to your error message) with strings command. (I'm actually not aware why it is going looking into /tmp/ directory libstdc++.so.6)

[flixtor]

Hi again.

Answers for your nr. 1/2/3 1: I did a test with a git version of gcc 2: the /urs/local/lib was a test install and I have changed to usr/lib64, and it's give me 100% the same error 3: the temp is only "active" when I use qsvencc via FastFlix. As soon FastFlix is closed, the temp/_ME(change all the time)

I am about to make a backup of my system. Then I will make a total new install, on a total new NVMe Going to test Fedora

(I don't want to use Ubuntu to their doing to their policy with snap etc...)

[rigaya]

3: the temp is only "active" when I use qsvencc via FastFlix. As soon FastFlix is closed, the temp/_ME(change all the time)

Does running directly qsvencc from the command line create the directory and cause the issue? I'm actually confused as the results from ldd and "strings /usr/lib64/libstdc++.so.6" seems to be fine.

[flixtor]

I think I might be a step closer to solve this very odd behavior.

When I test the libstdc++.s0.6 in usr/lib64, the CXXABI_1.3.15 are within.

When I run the qsvencc, and then it's use the /tmp/_M(whatever) then the included libstdc++.s0.6 do NOT contain that CXXABI_1.3.15 but max version are CXXAI_1.3.14

I did compare the size of both libstdc++ and the one in the tmp is bigger!

libstdc++.so.6 from /usr/lib64 = 20.939.064 libstdc++.so.6 from /tmp/M_* = 24.111.864

So when I compile the qvencc, it somehow gets another libstdc++, but I can't find it in my system BEFORE the compiled (I mean the version without GXXAI_1.3.15)

If I run the qvencc in stand-Alone mode (via terminal) it does convert without problems, and do NOT make any temp files as I can see. Well not in /tmp so was not able to locate where the possible temp files goes to check the libstdc++...

All this trouble started after an update, but can't trace back to what went wrong. I got 2 PC running, and BOTH are hit with the same weird errors, and no ... the FastFlix is still the same, only thing that MIGHT have changed, is the python need is v3.11 for the FastFlix, but 3.12 is installed.

Can be that is the problem??? I can't manually compile a new FastFlix, since it do require v3.11, but I got 3.12. I don't have that kind of knowledge at all :-/

IF I could make a GUI for qvencc, where I could add lots of files at once, I would do it! But I simply don't have any knowledge into programming, and doing to my autism I do have give up on that for MANY years ago!

Sadly there is no other choice as I am aware of, that is using qvencc on Linux, on Winblows you can use FastFlix without problems, and StaxRip also. StaxRip is winblows only, so no help there.

Link to FastFlix here on GitHub: https://github.com/cdgriffith/FastFlix

[rigaya]

I see, if you have compiled qsvencc using gcc 14.1.0, then it should be linked with libstdc++.so.6 with the version which includes CXXABI_1.3.15. So there is no problem when running qvencc via terminal but somehow /tmp/_Mxxxx libstdc++.so.6 is created when running from FastFlix.

I'm not sure what is going on there, and I can do nothing about that.

However, we might be able to avoid this by following method, forcing qsvencc to use /usr/lib64/libstdc++.so.6 by wrapper script using LD_PRELOAD.

1. Rename qsvencc binary to any name ("qsvencc.bin" here as example)
   here suppose qsvencc is installed in /usr/local/bin/qsvencc

   sudo mv /usr/local/bin/qsvencc /usr/local/bin/qsvencc.bin

2. Create wrapper script /usr/local/bin/qsvencc which should be following. The script will set LD_PRELOAD and then run the actual qsvencc binary. LD_PRELOAD will force the libstdc++.so.6 to be used.

   #!/bin/sh
   
   QSVENCC_BIN=$(dirname "$0")/qsvencc.bin
   
   export LD_PRELOAD=/usr/lib64/libstdc++.so.6
   "$QSVENCC_BIN" $@ < /dev/stdin

3. Add exec permission to script /usr/local/bin/qsvencc

   sudo chmod u+x /usr/local/bin/qsvencc

I'm not sure if this works fine, but I think it's worth a try.

[flixtor]

Hello again, Sir rigaya!

I have managed to find out the reason WHY I got all this weird issue!

onevpl-intel-gpu are being replaced by vpl-gpu-rt

As soon the vpl-gpu-rt are used, I got those CXXABI_1.3.15 errors. No matter if I even made a new compile or not. It doesn't matter. So I guess, you too will have these issue, but now you know how-to fix it.

(I did install Ubuntu, but oh-my-god! I really don't understand why people are using that, so much work to install drivers and apps, it took me 10–12 hours of work, on arch, it takes me max 20 min with same configuration!)

PS: I did test your script above, but it gave me another errors, so I gave up on that.

[flixtor]

Grrrr ... Sorry .. but .. No .. Still got errors, but on other apps instead.

I do found this information:

https://gcc.gnu.org/onlinedocs/libstdc++/faq.html#faq.how_to_install

`` If you already have an older version of libstdc++ installed then the error might look like one of the following instead:

./a.out: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.20' not found
./a.out: /usr/lib/libstdc++.so.6: version `CXXABI_1.3.8' not found

This means the linker found /usr/lib/libstdc++.so.6 but that library belongs to an older version of GCC than was used to compile and link the program a.out (or some part of it). The program depends on code defined in the newer libstdc++ that belongs to the newer version of GCC, so the linker must be told how to find the newer libstdc++ shared library.

The simplest way to fix this is to use the LD_LIBRARY_PATH environment variable, which is a colon-separated list of directories in which the linker will search for shared libraries:

export LD_LIBRARY_PATH=${prefix}/lib:$LD_LIBRARY_PATH``

I do have that path allready...., could be I have mispell some of the words.

Going to have another look on that, are totally brain-busted now, going to relax for some days. (It's typical for us that got autism, it's called burnout, or brain-burnout)

[flixtor]

Short status report and just close this topic:

I have given up upon this error, and moved forward. The solution for me was simply to install Distrobox, and run your great app together with FastFlix, and anything works again :)

Many thank you for trying to help me.

With best regard

Dr. Pain, Europa

[rigaya]

Thank you for the status report, glad to hear that anyway you've been able to run fine. I'll have the issue closed.