Pi OS 64 Bit 5/27/2021 release and libstdc++

[DaveXanatos]

Installing some TTS voices (Cepstral) that work on the previous release of the 64 bit OS from 5/2020, but not on the 5/2021 release. When installation script is run, the following error is generated:

/opt/swift/bin/swift.bin: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory

Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 libstdc++-8-doc : Conflicts: libstdc++-7-doc but 7.4.0-6 is to be installed
 libstdc++6-8-dbg : Conflicts: libstdc++6-7-dbg but 7.4.0-6 is to be installed
                    Conflicts: libstdc++6-7-dbg:armhf but 7.4.0-6 is to be installed
 libstdc++6-8-dbg:armhf : Conflicts: libstdc++6-7-dbg but 7.4.0-6 is to be installed
                          Conflicts: libstdc++6-7-dbg:armhf but 7.4.0-6 is to be installed
E: Unable to correct problems, you have held broken packages.

Yet, when I run

pi@LangDev:~/Desktop/HOSTCORE/_CEPSTRAL_VOICES/Allison $ /sbin/ldconfig -p | grep stdc++
    libstdc++.so.6 (libc6,AArch64) => /lib/aarch64-linux-gnu/libstdc++.so.6

It shows it's installed.

I have also done the usual apt-get update --fix-missing and subsequent install -f, nothing indicates it's anything but perfect.

Is this because, as stated in the error message, that this is still a developmental version and some stuff may not be where it needs to be yet? Or does this error suggest something else? Thanks for any help!

------- UPDATE 6/6/2021 -------

This is on a brand-new fresh download from the repository. The only things that were done after the built-in setups run (that set locality, wifi, etc) was to enable SSH & VNC, and I set the IP to static.

To be sure, I wiped the card and redid a fresh burn of the newest 64 bit os, as described above, and when I attempted again to install the voices, I received the same error. So, being circumspect, I wiped and flashed the 5/2020 release onto the card, performed the same steps as described above, and successfully installed and tested the voices.

Something changed between 5/2020 and 5/2021 that affects things in a way that keeps them from seeing that I do have libstdc++.so.6 in place. Apparently, anyway.

I was asked also to run "apt policy" on the forum at raspberrypi.org, here is that output:

pi@raspberrypi:~ $ apt policy Package files: 100 /var/lib/dpkg/status release a=now 500 http://archive.raspberrypi.org/debian buster/main armhf Packages release o=Raspberry Pi Foundation,a=testing,n=buster,l=Raspberry Pi Foundation,c=main,b=armhf origin archive.raspberrypi.org 500 http://archive.raspberrypi.org/debian buster/main arm64 Packages release o=Raspberry Pi Foundation,a=testing,n=buster,l=Raspberry Pi Foundation,c=main,b=arm64 origin archive.raspberrypi.org 500 http://deb.debian.org/debian buster-updates/main armhf Packages release o=Debian,a=stable-updates,n=buster-updates,l=Debian,c=main,b=armhf origin deb.debian.org 500 http://deb.debian.org/debian buster-updates/main arm64 Packages release o=Debian,a=stable-updates,n=buster-updates,l=Debian,c=main,b=arm64 origin deb.debian.org 500 http://deb.debian.org/debian-security buster/updates/main armhf Packages release v=10,o=Debian,a=stable,n=buster,l=Debian-Security,c=main,b=armhf origin deb.debian.org 500 http://deb.debian.org/debian-security buster/updates/main arm64 Packages release v=10,o=Debian,a=stable,n=buster,l=Debian-Security,c=main,b=arm64 origin deb.debian.org 500 http://deb.debian.org/debian buster/non-free armhf Packages release v=10.9,o=Debian,a=stable,n=buster,l=Debian,c=non-free,b=armhf origin deb.debian.org 500 http://deb.debian.org/debian buster/non-free arm64 Packages release v=10.9,o=Debian,a=stable,n=buster,l=Debian,c=non-free,b=arm64 origin deb.debian.org 500 http://deb.debian.org/debian buster/contrib armhf Packages release v=10.9,o=Debian,a=stable,n=buster,l=Debian,c=contrib,b=armhf origin deb.debian.org 500 http://deb.debian.org/debian buster/contrib arm64 Packages release v=10.9,o=Debian,a=stable,n=buster,l=Debian,c=contrib,b=arm64 origin deb.debian.org 500 http://deb.debian.org/debian buster/main armhf Packages release v=10.9,o=Debian,a=stable,n=buster,l=Debian,c=main,b=armhf origin deb.debian.org 500 http://deb.debian.org/debian buster/main arm64 Packages release v=10.9,o=Debian,a=stable,n=buster,l=Debian,c=main,b=arm64 origin deb.debian.org Pinned packages: pi@raspberrypi:~ $

[DaveXanatos]

Side by side comparison of installs, in case it's useful:

https://xanatos.com/image/CepstralInstalls_OS64_Version_Good-Bad.jpg

[lurch]

I did a bit of googling and found https://www.cepstral.com/en/personal/download/?os=linux&refpage=linux which lists "Linux 32 Bit", "Linux 64 Bit" & "Linux ARM chipset". So the Linux-ARM version is probably 32-bit ARM only, and the

/opt/swift/bin/swift.bin: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory

message probably indicates that /opt/swift/bin/swift.bin is in fact a 32-bit armhf program, and can't find the 32-bit armhf libstdc++.so.6 as you only have the 64-bit arm64 version installed? :man_shrugging: (or I may be barking up the wrong tree entirely!)

What does file /opt/swift/bin/swift.bin say?

[DaveXanatos]

Cepstral has been working on the 64 bit OS release 5/28/2020. It's only on the new release 5/28/2021 that it fails.

On the older 5/2020 version:

pi@raspberrypi:~ $ file /opt/swift/bin/swift.bin
/opt/swift/bin/swift.bin: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.26, BuildID[sha1]=cafd7c6a69acff7788af4a19e70e6d811ee5c9c6, with debug_info, not stripped

On the new 5/28/2021 release:

pi@visionCORE:~ $ file /opt/swift/bin/swift.bin
/opt/swift/bin/swift.bin: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.26, BuildID[sha1]=cafd7c6a69acff7788af4a19e70e6d811ee5c9c6, with debug_info, not stripped

So I guess no difference between them on that count.

[lurch]

Ah, so my hunch was correct and Cepstral is 32-bit ARM only :slightly_smiling_face: Maybe the difference between the May2020 and the May2021 releases of the 64-bit beta Pi OS, is that the May2020 release included the 32-bit armhf libstdc++ by default, but the May2021 release doesn't? :man_shrugging: But this is pretty much where my knowledge runs out, so I'll let @XECDesign provide any further help :wink:

P.S. Might be worth asking Cepstral if they'd be willing to build 64-bit ARM versions?

[DaveXanatos]

Ah, so my hunch was correct and Cepstral is 32-bit ARM only 🙂 Maybe the difference between the May2020 and the May2021 releases of the 64-bit beta Pi OS, is that the May2020 release included the 32-bit armhf libstdc++ by default, but the May2021 release doesn't? 🤷‍♂️ But this is pretty much where my knowledge runs out, so I'll let @XECDesign provide any further help 😉

P.S. Might be worth asking Cepstral if they'd be willing to build 64-bit ARM versions?

So if this is the case, how would one go about installing the 32-bit armhf libstdc++ manually so it would run beside the 64-bit version?

I have to believe that the Raspberry Pi Foundation is not aiming to remove compatibility with 32 bit applications - not every application has been built specifically with 64-bit OSes in mind. 5/28 was only 10 days ago. I suspect there are more 32-bit applications that will pop up over time calling for, and not finding, their 32-bit libraries if they are being removed from the 64-bit OS... Raspberry Pi has always been good about backwards compatibility... I'm guessing that if our conjecture here is correct, that they will re-include the 32-bit libraries.

[DaveXanatos]

I'm also going to try the other two releases that came between the 5/28/2020 and 5/28/2021 releases. Downloading raspios_arm64-2021-04-09 now... This way we can see which point the change came in at.

[rag2]

Dave, others,

there is a compatibility mode built in to Linux that allows for mixed 32 & 64 bit packages to be supported.

From my notes on this, consider the reference to WXtoImg to be a worked example:

  32 bit compatibility

It is possible to run *32 bit armhf binaries, such as WXtoI*mg^1 <#sdfootnote1sym>:

Debian's multiarchsystem^2 <#sdfootnote2sym> provides asolution^3 <#sdfootnote3sym> by allowing an armhf capability to be added, as an additional supported architecture.

sudo dpkg --add-architecture armhf

To resolve an error around any package, usually a library package, requires installing the armhfversion of that package, denoted by an :armhfsuffix. If libX11.so.6, for example, is required:

sudo apt install libx11-6:armhf

WXtoImg, for example, requires2 further armhf libraries:

sudo apt-get install libxft2:armhf sudo apt-get install libasound2:armhf

1 <#sdfootnote1anc>This program is commercialware→abandonware→freeware, with no source available. See https://wxtoimgrestored.xyz/beta/ https://wxtoimgrestored.xyz/beta/.

2 <#sdfootnote2anc>See https://wiki.debian.org/Multiarch/HOWTO https://wiki.debian.org/Multiarch/HOWTO.

3 <#sdfootnote3anc>Adapted from a description at https://github.com/raspberrypi/Raspberry-Pi-OS-64bit/issues/62#issuecomment-647459572 https://github.com/raspberrypi/Raspberry-Pi-OS-64bit/issues/62#issuecomment-647459572.

HTH,

Robin

On 06/06/2021 18:17, Dave Xanatos wrote:

So if this is the case, how would one go about installing the 32-bit armhf libstdc++ manually so it would run beside the 64-bit version?

[DaveXanatos]

Dave, others, there is a compatibility mode built in to Linux that allows for mixed 32 & 64 bit packages to be supported. ...

sudo dpkg --add-architecture armhf To resolve an error around any package, usually a library package, requires installing the armhfversion of that package, denoted by an :armhfsuffix....

HTH, Robin

Thanks, this looks interesting - also see my next post regarding the findings from the .info files for each release of the OS in question.

[DaveXanatos]

------- UPDATE -------

Note the following from the .info files for each release. They are identical:

From 2020-05-27-raspios-buster-arm64.info:

ii libstdc++-8-dev:arm64 8.3.0-6 arm64 GNU Standard C++ Library v3 (development files) ii libstdc++6:arm64 8.3.0-6 arm64 GNU Standard C++ Library v3

From 2021-05-07-raspios-buster-arm64.info:

ii libstdc++-8-dev:arm64 8.3.0-6 arm64 GNU Standard C++ Library v3 (development files) ii libstdc++6:arm64 8.3.0-6 arm64 GNU Standard C++ Library v3

So if the 5/27/2020 version AND the 5/7/2021 version both show the exact same components, should they not operate the same?

[lurch]

They are identical: ii libstdc++6:arm64 8.3.0-6 arm64 GNU Standard C++ Library v3

...but that's the arm64 (64-bit) version of the libstdc++6 package, and the problem you're having is with the armhf (32-bit) version of the libstdc++6 package (since you're trying to run a 32-bit binary).

I wonder if the error-output in your first message indicates "something" is wrong with the dependency-info for the 32-bit libstdc++6:armhf package? :man_shrugging:

[DaveXanatos]

They are identical: ii libstdc++6:arm64 8.3.0-6 arm64 GNU Standard C++ Library v3

...but that's the arm64 (64-bit) version of the libstdc++6 package, and the problem you're having is with the armhf (32-bit) version of the libstdc++6 package (since you're trying to run a 32-bit binary).

I wonder if the error-output in your first message indicates "something" is wrong with the dependency-info for the 32-bit libstdc++6:armhf package? 🤷‍♂️

Yep... I'm in over my head for now, but you see my conundrum. Both the working 64 bit OS, and the non-working one, both use the same 64-bit version of the libstdc++6 package. And my 32 bit application works on one but not the other. You'd think it would either work on both, or neither.

I just finished trying the April 2021 release, also a no go. I'm flashing over the August 2020 version now, that should be done in a few minutes and I can see if that one allows the install or not. At least I can narrow it down to between which two releases the change happened, maybe that will help someone recognize the issue.

[DaveXanatos]

And.... that's a wrap. The 8/2020 version also fails install of the voices for the libstdc++.so.6 issue.

So - the 5/27/2020 release of the 64-bit OS works fine, the next and all subsequent ones do not, when installing (at least one) 32-bit application that calls for the libstdc++ library.

So now I am trying #rag2's "sudo dpkg --add-architecture armhf"...

AND.... !!! WE HAVE A WINNER !!! WooHoo!!!

Sequence:

sudo dpkg --add-architecture armhf
sudo apt install libstdc++6-8-dbg:armhf
sudo apt install libstdc++:armhf

Ran install, install reported success.

So now I have a functional workaround, my next question is, did Raspberry Pi OS programmers intentionally leave out armhf/32-bit support, or should that have been left in for backwards compatibility? I can't imagine they'd want to kill backwards compatibility with 32-bit applications? Especially operationally critical ones that people have paid for - like me licensing five of Cepstral's voices... I hope they return armhf support in a future release.

Thanks for your help, and thanks #rev2!!!

[rag2]

Dave,

for the sake of clarity, armhf (32 bit) support is built in to Pi OS (and 64 bit ARM Debian, on which Pi OS is based). Otherwise the problem could not have been resolved. However, armhf support is apparently not enabled by default. Presumably it had been enabled on earlier releases of Pi OS 64 bit (still a beta OS).

The same issues of 32 bit support from a 64 bit OS also arises in the x86/x86-64 world. There are similar tensions between a "clean" 64 bit only OS, and a pragmatic need to support 32 bit only software, for one reason or another.

Glad to have helped, and thanks for the shout, even if I seem to have become a Rev. Not sure that a dog collar would suit me, though!

Robin

On 07/06/2021 00:56, Dave Xanatos wrote:

So now I have a functional workaround, my next question is, did Raspberry Pi OD programmers intentionally leave out armhf/32-bit support, or should that have been left in for backwards compatibility? I can't imagine they'd want to kill backwards compatibility with 32-bit applications? Especially operationally critical ones that people have paid for - like me licensing five of Cepstral's voices... I hope they return armhf support in a future release.

Thanks for your help, and thanks #rev2!!!

[DaveXanatos]

Dave, for the sake of clarity, armhf (32 bit) support is built in to Pi OS (and 64 bit ARM Debian, on which Pi OS is based). Otherwise the problem could not have been resolved. However, armhf support is apparently not enabled by default. Presumably it had been enabled on earlier releases of Pi OS 64 bit (still a beta OS). The same issues of 32 bit support from a 64 bit OS also arises in the x86/x86-64 world. There are similar tensions between a "clean" 64 bit only OS, and a pragmatic need to support 32 bit only software, for one reason or another. Glad to have helped, and thanks for the shout, even if I seem to have become a Rev. Not sure that a dog collar would suit me, though! Robin

LOL I have no idea how #rag2 became #rev2, but it is probably an indication of how crosseyed I was after working on code & packages for the whole weekend! :) Thanks again! Dave