Libm.so.6 and 3D Printing with LycheeSlicer

Rocky Linux General
1

This might be a long story, so please bear with me.

I recently acquired an Anycubic Photon Mono 4K printer (as a Christmas present to myself). The printer itself is fine. The slicing software packaged with the machine is Windows-only, so I researched some Linux-compatible alternatives (LycheeSlicer and Chitubox). These were easy to install. LycheeSlicer was an AppImage, while Chitubox was a simple tar.gz file, both of which I copied to /opt. The LycheeSlicer error is shown in the attached PNG. Both packages require libm.so.6 from GLIBC_2.29. The version that ships with RL8 is from GLIBC_2.28.

The following posts

and

explain that GLIBC_2.29 (or higher) can’t be installed into /lib64 or it needs to be installed separately AWAY from /lib64. This was borne out by a brief email exchange with infrastructure@rockylinux.org.

OK. So, I downloaded and installed glibc-2.29 and glibc-2.36 (the current stable version) into separate directories under /opt. Again, this was pretty easy.

Now, I reckoned that, on the command line, the easiest way to run either LycheeSlicer or Chitubox would be with:

LD_LIBRARY_PATH=/opt/glibc-2.36/lib /opt/LycheeSlicer

Still no joy.

After some trial-and-error, I eventually got LycheeSlicer working in the most horrible and kludgy way. The solution was to change the libm.so.6 symlink under /lib64 to point to the newer version under /opt.



root@kuu# pwd
/lib64
root@kuu# ls -l libm.* libm-2*
-rwxr-xr-x. 1 root root 1599024 Sep 27 17:36 libm-2.28.so
-rw-r--r--. 1 root root     141 Sep 27 17:25 libm.so
lrwxrwxrwx. 1 root root      12 Jan  1 17:42 libm.so.6 -> libm-2.28.so
root@kuu#

root@kuu# rm libm.so.6
root@kuu# ln -s /opt/glibc-2.36/lib/libm.so.6 libm.so.6
root@kuu# ls -l libm.* libm-2*
-rwxr-xr-x. 1 root root 1599024 Sep 27 17:36 libm-2.28.so
-rw-r--r--. 1 root root     141 Sep 27 17:25 libm.so
lrwxrwxrwx. 1 root root      12 Jan  1 17:42 libm.so.6 -> /opt/glibc-2.36/lib/libm.so.6
root@kuu#

With these changes in place, LycheeSlicer worked. Cool! As a test, I reversed the symlink changes and LycheeSlicer crashed again. So it seems the only way to get LycheeSlicer working is to change the symlink for /lib64/libm.so.6 . This is a Bad Thing.

Other searches suggested using ldd on the executables:

97 colin@kuu> ldd /opt/CHITUBOX/CHITUBOX
/opt/CHITUBOX/CHITUBOX: /lib64/libm.so.6: version `GLIBC_2.29' not found (required by /opt/CHITUBOX/CHITUBOX)
	linux-vdso.so.1 (0x00007ffdc3347000)
	libQt5Svg.so.5 => /lib64/libQt5Svg.so.5 (0x00007f72219c7000)
	libQt5Widgets.so.5 => /lib64/libQt5Widgets.so.5 (0x00007f72210f1000)
	libQt5Quick.so.5 => /lib64/libQt5Quick.so.5 (0x00007f722095d000)
	libQt5X11Extras.so.5 => /lib64/libQt5X11Extras.so.5 (0x00007f7220758000)
	libQt5Gui.so.5 => /lib64/libQt5Gui.so.5 (0x00007f721ff5f000)
	libQt5Qml.so.5 => /lib64/libQt5Qml.so.5 (0x00007f721f8aa000)
	libQt5Network.so.5 => /lib64/libQt5Network.so.5 (0x00007f721f4de000)
	libQt5Xml.so.5 => /lib64/libQt5Xml.so.5 (0x00007f721f29a000)
	libQt5Core.so.5 => /lib64/libQt5Core.so.5 (0x00007f721eb07000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f721e8e7000)
	libX11.so.6 => /lib64/libX11.so.6 (0x00007f721e5a4000)
	libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f721e20f000)
	libm.so.6 => /lib64/libm.so.6 (0x00007f721de8d000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f721dc75000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f721d8af000)
	libGL.so.1 => /lib64/libGL.so.1 (0x00007f721d629000)
	libz.so.1 => /lib64/libz.so.1 (0x00007f721d411000)
	libQt5QmlModels.so.5 => /lib64/libQt5QmlModels.so.5 (0x00007f721d187000)
	libpng16.so.16 => /lib64/libpng16.so.16 (0x00007f721cf52000)
	libharfbuzz.so.0 => /lib64/libharfbuzz.so.0 (0x00007f721ccad000)
	librt.so.1 => /lib64/librt.so.1 (0x00007f721caa5000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007f721c8a1000)
	libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007f721c64c000)
	libssl.so.1.1 => /lib64/libssl.so.1.1 (0x00007f721c3b8000)
	libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007f721becf000)
	libsystemd.so.0 => /lib64/libsystemd.so.0 (0x00007f721bb84000)
	libicui18n.so.60 => /lib64/libicui18n.so.60 (0x00007f721b6c2000)
	libicuuc.so.60 => /lib64/libicuuc.so.60 (0x00007f721b2ff000)
	libicudata.so.60 => /lib64/libicudata.so.60 (0x00007f7219755000)
	libpcre2-16.so.0 => /lib64/libpcre2-16.so.0 (0x00007f72194dc000)
	libgthread-2.0.so.0 => /lib64/libgthread-2.0.so.0 (0x00007f72192da000)
	libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x00007f7218fc1000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f7221c23000)
	libxcb.so.1 => /lib64/libxcb.so.1 (0x00007f7218d98000)
	libGLX.so.0 => /lib64/libGLX.so.0 (0x00007f7218b66000)
	libXext.so.6 => /lib64/libXext.so.6 (0x00007f7218953000)
	libGLdispatch.so.0 => /lib64/libGLdispatch.so.0 (0x00007f721869d000)
	libfreetype.so.6 => /lib64/libfreetype.so.6 (0x00007f72183e1000)
	libgraphite2.so.3 => /lib64/libgraphite2.so.3 (0x00007f72181b5000)
	libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007f7217ecb000)
	libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f7217cb4000)
	libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f7217ab0000)
	libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007f721789f000)
	libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f721769b000)
	libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f7217483000)
	liblzma.so.5 => /lib64/liblzma.so.5 (0x00007f721725c000)
	liblz4.so.1 => /lib64/liblz4.so.1 (0x00007f721703f000)
	libcap.so.2 => /lib64/libcap.so.2 (0x00007f7216e37000)
	libmount.so.1 => /lib64/libmount.so.1 (0x00007f7216bdd000)
	libgcrypt.so.20 => /lib64/libgcrypt.so.20 (0x00007f72168bf000)
	libgnutls.so.30 => /lib64/libgnutls.so.30 (0x00007f72164ce000)
	libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f721625d000)
	libXau.so.6 => /lib64/libXau.so.6 (0x00007f7216059000)
	libbz2.so.1 => /lib64/libbz2.so.1 (0x00007f7215e48000)
	libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f7215c1d000)
	libblkid.so.1 => /lib64/libblkid.so.1 (0x00007f72159ca000)
	libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f72157c2000)
	libgpg-error.so.0 => /lib64/libgpg-error.so.0 (0x00007f72155a1000)
	libp11-kit.so.0 => /lib64/libp11-kit.so.0 (0x00007f7215277000)
	libidn2.so.0 => /lib64/libidn2.so.0 (0x00007f7215059000)
	libunistring.so.2 => /lib64/libunistring.so.2 (0x00007f7214cd8000)
	libtasn1.so.6 => /lib64/libtasn1.so.6 (0x00007f7214ac5000)
	libnettle.so.6 => /lib64/libnettle.so.6 (0x00007f721488b000)
	libhogweed.so.4 => /lib64/libhogweed.so.4 (0x00007f721465b000)
	libgmp.so.10 => /lib64/libgmp.so.10 (0x00007f72143c3000)
	libpcre2-8.so.0 => /lib64/libpcre2-8.so.0 (0x00007f721413f000)
	libffi.so.6 => /lib64/libffi.so.6 (0x00007f7213f36000)
98 colin@kuu> ldd /opt/LycheeSlicer-5.0.0.AppImage
	not a dynamic executable
99 colin@kuu> 
99 colin@kuu> LD_LIBRARY_PATH=/opt/glibc-2.36/lib /opt/CHITUBOX/CHITUBOX
Segmentation fault (core dumped)
100 colin@kuu>

The Chitubox output suggests /lib64/libm.so.6 is ‘hardwired’ into the executable and can’t be overridden with LD_LIBRARY_PATH. I admit I don’t understand the LycheeSlicer output.

I have a few questions, none of which are to do with the printing.

  1. Why didn’t /opt/LycheeSlicer pick up LD_LIBRARY_PATH on the command line and use that instead of /lib64 ? Have I missed some basic command line syntax that will enforce LD_LIBRARY_PATH ?
  2. What might be the consequences of leaving the /lib64/libm.so.6 symlink pointing to /opt/glibc-2.36/lib/libm.so.6 when using other software and/or running a “dnf update” command (which I do every quarter)?
  3. Should I be considering upgrading to RL9 instead?

I’m at a loss. I can continue with the kludgy workaround for now but would really like to find a more elegant solution.

Does the Community have any suggestions?

Best Regards,
Colin

2

Hi,

I’m curious, wouldn’t Rocky 9 be better as it has glibc 2.34?

1 Like
3

This is certainly an option for the mid-term but I’d prefer sticking with 8 for now.

4

Aren’t PATHs colon-separated lists? You show space.

What in that did fail?

Overall, the current hype are containers – an another attempt to package application with what it needs regardless of the OS platform. Can you put Chitubox into container that has “more suitable” set of libs?

1 Like
5

Some info on for example stackexchange suggest alternatives like:

LD_LIBRARY_PATH=/opt/glibc-2.36/lib
export LD_LIBRARY_PATH
/opt/LycheeSlicer

You could put that in a script and run the script that would set that each time you run it. The command you have should have run though, so no idea why it failed.

As per setting libm.so.6 permanently, you risk borking the rest of your entire system that relies on glibc-2.28. So I would definitely not do that.

1 Like
6

HPC clusters do use prominently environment-modules (or its alternative: Lmod) for creating environments, similarly to scldoes for Software Collections. Obviously, if there is only one executable that requires custom environment, then calling it via wrapper script “contains” the environment better.

The binary links to multiple libraries. They all use glibc, don’t they?
Libraries built with el8 version of glibc (libm-2.28.so).
Due to symlink some of them probably choke on the libm-2.36.so, like any system binary might.

Furthermore, glibc is loaded into memory early in boot and cannot be trivially reloaded. If you dnf up glibc, you have to reboot before the new version is used by all processes. I have no idea how/whether you can have two clearly different glibc in memory simultaneously.

1 Like
7

Yup, this is why I think to be honest, the best approach is to run the apps on a system that has the newer version of glibc, eg: Rocky 9. Attempting it on Rocky 8 is just going to be problematic and a headache, maybe doable, but is it really worth it considering the amount of time being spent?

8

But downloaded from where, and installed how?

9

I downloaded the glibc 2.29 and 2.36 files from Index of /gnu/glibc and installed them to /opt as described in the INSTALL files. Admittedly, I kinda skimmed the install notes so I may have missed something important. At its simplest, I used:

…/glibc-2.29/configure --prefix=/opt/glibc-2.29

Do you think I missed a particular option to the configure step?

10

The command line looks good, as close as it can be for a non-standard installation.

When they build the rpm, there’s a bit more to it, they split into main package and ‘devel’, and use %post scripts. You could pull apart the source repo for 2.28 and follow the pattern, but only do this on a test box. Messing with glibc is not a good idea. But as others have said, Rocky 9 may be the correct solution.

1 Like
11

Well, that was a busy day.

Long story short, I looked at containers under RL8 and hit a problem with the podman package. IBM’s RHEL documentation described how to uninstall podman but I didn’t want to touch it as it uninstalled other dependencies and I had no idea of how that would affect the rest of the system.

So, I bit the bullet and did a new install of RL9.

This time, the LycheeSlicer app worked out of the box, so I’m calling this a big win. At least the £300 worth of 3d printer won’t sit idle now!

The Chitubox app continues to fail, this time with a different error:

[colin@kuu binary]$ /opt/CHITUBOX/CHITUBOX
/opt/CHITUBOX/CHITUBOX: symbol lookup error: /opt/CHITUBOX/CHITUBOX: undefined symbol: _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE9_M_createERmm, version Qt_5
[colin@kuu binary]$

What the heck? Anyway, it turns out that this sort of problem has been happening with Chitubox for a few years (going back to version 1.8.1 on Archlinux in 2021 and later reappearing in version 1.9.0 on a Debian system).

So I think it’s time to log a call with Chitubox support and see if they can fix it.

I just want to say a big thanks to everyone who responded: @jlehtone, @iwalker and @gerry666uk. Is there a way of adding kudos points (or similar) to those who contributed?

Colin

1 Like
12

Kudos I guess can be given by liking the posts eg clicking the heart under each contributors post :blush:

That’s about the only way.

1 Like
13

It might need ‘ldd’ again, to check all dependencies. There’s a hint about Qt5 at the end of the error message, and it sounds like C++ is looking for part of std::string.
It could mean it was linked with a library, but that library is not being found.

14

@gerry666uk Thanks for that. I’ll remember it when I post to the Chitubox forums. For now, just getting the printer up-and-running is a win.

15

Not quite. If dynamic linker cannot find library, then the error is different and mentions name of library file.

This one is “undefined symbol”. Linker has found all the files that it is supposed to find, but none of them has that symbol.

Let say that when program was built, symbol X was found and linked from “libm.so”.
When program runs, the “libm.so.N” of the system is loaded, but it does not have X.
That generates the “undefined symbol” and the issue is that the two systems both nominally
have “libm.so.N”, but they do differ; they have been built with different options (or other changes).

Other detail is Qt5. When 8.7 and 9.1 were released, their Qt5 did differ from Qt5 in 8.6 and 9.0.
As result all the Qt5-based applications had to be rebuilt. (KDE was prominent example.)
If the pre-built Chitubox was built with the previous Qt5-libs …

1 Like
16

OK, maybe I misunderstood that part, I assumed it was source code that was then built, but if it was a binary…

17

For what it is worth, I assumed that problem description would have been different if source build would have issue on feature that the system libm version does not have.

18

I finally found a solution, so I thought I should post it here in case someone Googles for it in future. They might find it useful.

This project started with Rocky Linux 8.

At the start of this thread I noted that both the LycheeSlicer and Chitubox 3D slicing applications crashed, reporting that they needed /lib64/libm.so.6 built with GLIBC_2.29 or higher. I tried installing 2.29 and 2.36 (the current stable release) into /opt and setting LD_LIBRARY_PATH as follows:

31 colin@kuu> LD_LIBRARY_PATH=/opt/glibc-2.29 /opt/CHITUBOX/CHITUBOX &
[1] 388041
32 colin@kuu> /opt/CHITUBOX/CHITUBOX: /lib64/libm.so.6: version `GLIBC_2.29' not found (required by /opt/CHITUBOX/CHITUBOX)

[1]+  Exit 1                  LD_LIBRARY_PATH=/opt/glibc-2.29 /opt/CHITUBOX/CHITUBOX
32 colin@kuu>

The kludge was to point the symbolic links from /lib64/libm.so.6 to the relevant /opt directory:

255 root@kuu# ls -l libm.* libm-2*
-rwxr-xr-x. 1 root root 1599024 Sep 27 17:36 libm-2.28.so
-rw-r--r--. 1 root root     141 Sep 27 17:25 libm.so
lrwxrwxrwx. 1 root root      29 Jan  1 16:48 libm.so.6 -> /opt/glibc-2.36/lib/libm.so.6
256 root@kuu#

Obviously, this was not a good solution.

Answers posted in this thread suggested upgrading to RL9, which has glibc-2.34, so I did.

After this, the LycheeSlicer application worked out-of-the-box and all was good, so I thought I would stick with that. However, LycheeSlicer doesn’t run on my backup laptop (a simple case of age, not enough memory and GPU power). So I had to look at Chitubox again.

This command fails:

3 colin@kuu> /opt/CHITUBOX/CHITUBOX
/opt/CHITUBOX/CHITUBOX: symbol lookup error: /opt/CHITUBOX/CHITUBOX: undefined symbol: _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE9_M_createERmm, version Qt_5
4 colin@kuu>

But this one works:

4 colin@kuu> cd /opt/CHITUBOX
5 colin@kuu> ls
AppRun  CHITUBOX  CHITUBOX_V1.9.4.tar.gz  lib  plugins  qml  qt.conf  resource  translations
6 colin@kuu> ./CHITUBOX
main 555
resource path: "/opt/CHITUBOX/resource"
applicationDirPath(): "/opt/CHITUBOX"
currentPath(): "/opt/CHITUBOX"
<truncated>
save to file: "/home/colin/.config/ChiTuBox/global.cfg"
save to file: "/home/colin/.config/ChiTuBox/machine/1.cfg"
save to file: "/home/colin/.config/ChiTuBox/machineBackup/1.cfg"

This method also works on my backup machine and via the KDE Application Launcher pointing to a little script:

8 colin@kuu> cat ~/bin/run_chitubox 
#!/usr/bin/bash
cd /opt/CHITUBOX
./CHITUBOX
9 colin@kuu>

Now, I can’t explain why running Chitubox with the absolute path fails and the relative path in a local directory works.

In conclusion, many thanks to all who contributed to this discussion and the eventual solution.

Best Regards,
Colin