Unable to launch 1.8.1 on Linux Mint 20

Ian Cornwall 2021-2-6 6034

I was able to run 1.8 beta just fine. When I try to run 1.8.1 I get /usr/lib/x86_64-linux-gnu/libQt5Core.so.5: version `Qt_5.15' not found (required by ./CHITUBOX)

New Post (36)
  • Guest 2021-2-6
    Quote 2Floor
    I can confirm this. 1.8.1. simply doesn't launch on Linux Mint.

    Kernel: 5.4.0-65-generic x86_64 bits: 64 compiler: gcc v: 9.3.0 Desktop: Cinnamon 4.8.6 
               wm: muffin dm: LightDM Distro: Linux Mint 20.1 Ulyssa base: Ubuntu 20.04 focal
    Graphics:  Device-1: AMD Vega 10 XL/XT [Radeon RX Vega 56/64] driver: amdgpu v: kernel 
               bus ID: 22:00.0 chip ID: 1002:687f 
               Display: x11 server: X.Org 1.20.9 driver: amdgpu,ati unloaded: fbdev,modesetting,vesa 
               resolution: 2560x1440~75Hz 
               OpenGL: renderer: Radeon RX Vega (VEGA10 DRM 3.35.0 5.4.0-65-generic LLVM 11.0.0) 
               v: 4.6 Mesa 20.2.6 direct render: Yes 
  • Alex Burkoff 2021-2-6
    Quote 3Floor
    Same problem on Ubuntu 20.04.2 LTS. Qt available from the official repos is 5.12, so naturally Chitubox won't run.
  • Guest 2021-2-6
    Quote 4Floor
    Same problem on openSUSE Leap 15.2. Qt available from the official repos is 5.12 to. 

    #####NUX:/opt/CHITUBOX V1.8.1> ./CHITUBOX
    ./CHITUBOX: /usr/lib64/libQt5Core.so.5: version `Qt_5.15' not found (required by ./CHITUBOX)
  • Guest 2021-2-6
    Quote 5Floor
    Same here. I got a little further by copying the libQt5Core.so.5 file from the ChiTuBox into /lib/x86_64-linux-gnu. Then it threw: "CHITUBOX: error while loading shared libraries: libicui18n.so.56: cannot open shared object file: No such file or directory"
    This is on Ubuntu 20.10.
  • Alex Burkoff 2021-2-7
    Quote 6Floor
    Oh, I actually didn't realize correct Qt libraries were included in the lib directory... this works then :

    ~/Downloads/CHITUBOX V1.8.1$ sudo ldconfig "`pwd`"/lib
  • Cliff Knight 2021-2-7
    Quote 7Floor
    Same here--i also copied libQt5Core.so.5 file from the ChiTuBox into /lib/x86_64-linux-gnu and on next attempt got the error "CHITUBOX: error while loading shared libraries: libicui18n.so.56: cannot open shared object file: No such file or directory".

    Linux Mint 20.1 Mate-1.8.0 beta runs great...

    Any solution yet?
  • Alex Burkoff 2021-2-7
    Quote 8Floor
    Cliff Knight Same here--i also copied libQt5Core.so.5 file from the ChiTuBox into /lib/x86_64-linux-gnu and on ne ...
    The solution is above - you either manually add Chitubox lib directory to the linker cache using ldconfig, or you do something like this :

    ~/Downloads/CHITUBOX V1.8.1$ echo "`pwd`/lib" >> chitubox.conf
    ~/Downloads/CHITUBOX V1.8.1$ sudo mv chitubox.conf /etc/ld.so.conf.d/

    you can verify linker can see the libraries like this :

    user@user-pc:~/Downloads/CHITUBOX V1.8.1$ ldconfig -p|grep CHITU
            libicuuc.so.56 (libc6,x86-64) => /home/user/Downloads/CHITUBOX V1.8.1/lib/libicuuc.so.56
            libicui18n.so.56 (libc6,x86-64) => /home/user/Downloads/CHITUBOX V1.8.1/lib/libicui18n.so.56
            libicudata.so.56 (libc6,x86-64) => /home/user/Downloads/CHITUBOX V1.8.1/lib/libicudata.so.56
            libQt53DRender.so.5 (libc6,x86-64) => /home/user/Downloads/CHITUBOX V1.8.1/lib/libQt53DRender.so.5
            libQt53DQuickRender.so.5 (libc6,x86-64) => /home/user/Downloads/CHITUBOX V1.8.1/lib/libQt53DQuickRender.so.5
            libQt53DQuickInput.so.5 (libc6,x86-64) => /home/user/Downloads/CHITUBOX V1.8.1/lib/libQt53DQuickInput.so.5
            libQt53DQuickExtras.so.5 (libc6,x86-64) => /home/user/Downloads/CHITUBOX V1.8.1/lib/libQt53DQuickExtras.so.5
            libQt53DQuick.so.5 (libc6,x86-64) => /home/user/Downloads/CHITUBOX V1.8.1/lib/libQt53DQuick.so.5
  • Guest 2021-2-7
    Quote 9Floor
    Same problem on Ubuntu 20.04 LTS
  • 2021-2-10
    Quote 10Floor
    The Fix will not work under Ubuntu 20.04 nor 20.10
    Now i get:
    ./CHITUBOX: /lib/x86_64-linux-gnu/libQt5Core.so.5: version `Qt_5.15' not found (required by ./CHITUBOX)
    ./CHITUBOX: /lib/x86_64-linux-gnu/libQt5Core.so.5: version `Qt_5.15' not found (required by /home/chris/CHITUBOX V1.8.1/lib/libQt5Svg.so.5)
    ./CHITUBOX: /lib/x86_64-linux-gnu/libQt5Core.so.5: version `Qt_5.15' not found (required by /home/chris/CHITUBOX V1.8.1/lib/libQt5Widgets.so.5)
    ./CHITUBOX: /lib/x86_64-linux-gnu/libQt5Core.so.5: version `Qt_5.15' not found (required by /home/chris/CHITUBOX V1.8.1/lib/libQt5Quick.so.5)
    ./CHITUBOX: /lib/x86_64-linux-gnu/libQt5Core.so.5: version `Qt_5.15' not found (required by /home/chris/CHITUBOX V1.8.1/lib/libQt5X11Extras.so.5)
    ./CHITUBOX: /lib/x86_64-linux-gnu/libQt5Core.so.5: version `Qt_5.15' not found (required by /home/chris/CHITUBOX V1.8.1/lib/libQt5Gui.so.5)
    ./CHITUBOX: /lib/x86_64-linux-gnu/libQt5Core.so.5: version `Qt_5.15' not found (required by /home/chris/CHITUBOX V1.8.1/lib/libQt5Qml.so.5)
    ./CHITUBOX: /lib/x86_64-linux-gnu/libQt5Core.so.5: version `Qt_5.15' not found (required by /home/chris/CHITUBOX V1.8.1/lib/libQt5Network.so.5)
    ./CHITUBOX: /lib/x86_64-linux-gnu/libQt5Core.so.5: version `Qt_5.15' not found (required by /home/chris/CHITUBOX V1.8.1/lib/libQt5Xml.so.5)
    ./CHITUBOX: /lib/x86_64-linux-gnu/libQt5Core.so.5: version `Qt_5.15' not found (required by /home/chris/CHITUBOX V1.8.1/lib/libQt5QmlModels.so.5)
  • 2021-2-10
    Quote 11Floor

    I get the same problem with linux mint 20.

    ./CHITUBOX: /lib/x86_64-linux-gnu/libQt5Core.so.5: version `Qt_5.15' not foun...

  • Cliff Knight 2021-2-10
    Quote 12Floor
    Alex Burkoff The solution is above - you either manually add Chitubox lib directory to the linker cache using ldc ...

    Me too, with MInt 20.1.
    ~/Downloads/CHITUBOX V1.8.1$ echo "`pwd`/lib" >> chitubox.conf
    ~/Downloads/CHITUBOX V1.8.1$ sudo mv chitubox.conf /etc/ld.so.conf.d/

    This "solution" broke FreeCAD, the pulse audio equalizer, and who knows what else--thank goodness for Time Machine...

    QT seems to be PITA--I searched for libQt5* and found from 4 to 5 copies of each QT library scattered all over my system. It seems a "version" Hell...

  • Cliff Knight 2021-2-11
    Quote 13Floor

    Further toying around found that it was the ldconfig "`pwd`"/lib command that broke FreeCAD (a hard install, not the .appimage) and the PA Equalizer.

    Searching by modified dat/time for what the ldconfig... command had alterd I found that removing the CHITUBOX /lib path from /etc/ld.so.conf.d/x86_64-linux-gnu.conf and rebullding /etc/ld.so.cache with ldconfig corrected the problem--FreeCAD and the Equalizer lauched proprly again.

    Is there a proper solution?

  • Alex Burkoff 2021-2-11
    Quote 14Floor
    Well, folks... I apologize for the issues you were having with my proposed fix. Unfortunately there is no good way to have to have multiple versions of the same library on Linux when the applications are linking against the major version. That's just how dynamic loading works - if FreeCAD wants Qt_5, and Qt_5.15 pops up sooner in the linker cache, that's what it's going to get. To my knowledge there is no way to force ld consider some library path for the current session only.

    It Chitubox can be compiled for Qt5.12, then that will be the proper solution for now. If they're already relying on features in Qt5.15 and can't be backported, then we're out of luck until the major distros will catch up to that version.
  • Cliff Knight 2021-2-11
    Quote 15Floor

    Alex, thank you for your original post--it pointed me in the right direction to find the issue I reported above. Like you I have found no way to force the libraries to be used by a specific application. Much as I dislike Windows¹, in same all you have to do is place the desired .dll in the same folder as the ap in question--doesn't work in Linux--I tried.

    QT has to get part of this blame--their lack of a structured naming convention sucks, using the same filename for noncompatible versions of a library (in the absence of any other differentiating mechanism) is assine--at times QTs developers seem like a bunch of rank amateurs. 

    For now I just won't use CHITUBOX v1.8.1. I had planned on being first in line for CHITUBOX Pro, however if their response to this issue continues to be null I will rethink that...
    ¹ - In fact I'm all done with MS anything due to Gate's wacked out politics and demented visions for the future of civilization.

  • Guest 2021-2-11
    Quote 16Floor

    The proper way to do it, without messing with the OS linker is to use the LD_LIBRARY_PATH environment variable:

    cd ChiTuBoxV1.8.1 (or wherever you un-tar'd the app)
    export LD_LIBRARY_PATH=`pwd`/lib:$LD_LIBRARY_PATH

    Works for me on Ubuntu 20.04.2

  • Alex Burkoff 2021-2-11
    Quote 17Floor

    Well, render me surprised. I thought LD_LIBRARY_PATH was only for compile-time linking. Good catch, Guest! :)

    Note that if you're really trying to preserve the contents of the variable when exporting the new value, you need the $ there :

    export LD_LIBRARY_PATH=`pwd`/lib:$LD_LIBRARY_PATH

    it will typically be empty though, nothing to preserve. 

  • Guest 2021-2-12
    Quote 18Floor
    Oops... Thanks for catching the missing $ :-)
  • Cliff Knight 2021-2-12
    Quote 19Floor

    Curious thing here (MInt 20.1 Mate). Adding the LD_LIBRARY_PATH environment variable allows CB 1.8.1 to load from a command line, however if I place that same command string (~/Applications/CHITUBOX-V1.8.1/AppRun in my case)  in a desktop application launcher it does not load?  I modified the launcher I had been using for 1.8.0 beta, only change being the command line.

    Any thoughts/

  • Alex Burkoff 2021-2-12
    Quote 20Floor
    Cliff Knight Curious thing here (MInt 20.1 Mate). Adding the LD_LIBRARY_PATH environment variable allows CB 1.8.1 ...
    I suspect the problem is that your current working directory, the thing that's captured by the `pwd` is not the same as where the Chitubox is launched from. Typically when setting up a launcher you can specify the working directory. Alternatively just specify the path to the library directory, and you technically don't even need to use the export. May look like this :

    LD_LIBRARY_PATH=~/Applications/CHITUBOX-V1.8.1/lib ~/Applications/CHITUBOX-V1.8.1/AppRun

    note the space between the first and second parts
  • Cliff Knight 2021-2-13
    Quote 21Floor

    Alex, please bear with me here, at one time I (of necessity) knew Windows inside and out--however since retiring I have almost consciously avoided programming. and have never gotten that deeply into LInux.
    I had assumed this:

    LD_LIBRARY_PATH=~/Applications/CHITUBOX-V1.8.1/lib ~/Applications/CHITUBOX-V1.8.1/AppRun

    was to be used with the export command, however attempting to do so  (on Mint 20.1) throws an error:

    knightci@Paladin-NM01:~$ export LD_LIBRARY_PATH=~/Applications/CHITUBOX-V1.8.1/lib ~/Applications/CHITUBOX-V1.8.1/AppRun
    bash: export: `/home/knightci/Applications/CHITUBOX-V1.8.1/AppRun': not a valid identifier

    The "space" is there, though masked a bit by the proportional font.

    Update, in examining other environment variables I found the colon (":") used as a delimiter, so I tried:

    export LD_LIBRARY_PATH=~/Applications/CHITUBOX-V1.8.1/lib:~/Applications/CHITUBOX-V1.8.1/AppRun (colon delimiter)

    and got two path LD_LIBRARY_PATH variable loaded, but still no joy with launching CB from a destop launcher--works great from the commandline still...

    What am I missing?


    Also, what is the real fix for this? I assume it is that CHITUBOX needs to recompile the app with added or different directives or the like?

  • Alex Burkoff 2021-2-13
    Quote 22Floor
    Cliff Knight Alex, please bear with me here, at one time I (of necessity) knew Windows inside and out--however si ...
    export is a command, so it needs to be separated by a semicolon :

    export LD_LIBRARY_PATH=~/Applications/CHITUBOX-V1.8.1/lib; ~/Applications/CHITUBOX-V1.8.1/AppRun

    so that effectively executes two commands from a single command string. This, on the other hand is a single command :

    LD_LIBRARY_PATH=~/Applications/CHITUBOX-V1.8.1/lib ~/Applications/CHITUBOX-V1.8.1/AppRun

    it just uses a special syntax to set an environment variable prior to execution. Whether to use one or the other depends on the context - some places just don't allow for multiple commands executed like that. 

    Also colon is used for separating values within an environment variable that is a list. Not really relevant here.
  • Cliff Knight 2021-2-13
    Quote 23Floor

    Thank you,

    Unfortunately it still remains that executing  ~/Applications/CHITUBOX-V1.8.1/AppRun from a terminal session will launch CB v1.8.1; but the same specified as the "command" for a desktop launcher will not:

    I have devised a very kludgy solution to launching CB v1.8.1. I use AutoKey for keyboard macros, so I added a  macro for <ctrl>+<shift>+<c> that spits out the command text to launch CB v1.8.1--"~/Applications/CHITUBOX-V1.8.1/AppRun"

    Now to launch it I open a terminal session w/ <ctrl>+<alt>=<t>  and then press <ctrl>+<shift>+<c> and voila' there we have CB v1.8.1 up and running.

    Last evening I sent CHITUBOX support a WTF email message re: LInux and v1.8.1; it will be interest to see what happens. My decision to buy CB Pro if it ever is released will hinge on their response to this issue...

  • Alex Burkoff 2021-2-13
    Quote 24Floor
    well, the only other suggestion I have is to isolate it into a script. Create a file (call it chitubox.sh) that looks like this :


    CB_DIR=/home/user/Downloads/CHITUBOX\ V1.8.1 # adjust this path to match yours

    export LD_LIBRARY_PATH=$CB_DIR/lib


    then make it executable :

    chmod +x chitubox.sh

    you should be able to run it then from the terminal as ./chitubox.sh or use it form a launcher

  • Cliff Knight 2021-2-13
    Quote 25Floor

    Thank you Alex, works a charm...

  • Cliff Knight 2021-2-13
    Quote 26Floor

    I got it to work also with my FreeCAD macro that saves the current object to a .stl file and then opens same with Chitubox. The only change I had to make was to alter the script to pass the .stl file supplied as an argument when calling the script:



    export LD_LIBRARY_PATH=$CB_DIR/lib

    # launch chitubox with $1 passed argument (a .stl FQFN)
    "$CB_DIR"/AppRun $1

    All is well... Once again thank you Alex!

  • Cliff Knight 2021-2-14
    Quote 27Floor

    FWIW here's the reply I got from Chitubox support:



    If the terminal does not work, try adding a few commands: export LD_LIVRARY_PATH=lib export QML2_IMPORT_PATH=qml

    Thanks & regards
    Facebook:谢信福(Xinfu XieFaceBook Group : ChiTu Software and Controller"


    I have not implemented the QML2_IMPORT_PATH variable yet as currently "it ain't broke"--making me disinclined to continue trying to fix it.

    Thing is, the root problem HAS to be something they did in packaging the application for deployment. V1.8.0 beta loads perrfecly with no extra-curricular activities required...

  • Guest 2021-2-18
    Quote 28Floor
    Guest The&nbsp;proper&nbsp;way&nbsp;to&nbsp;do&nbsp;it,&nbsp;without&nbsp;mess ...

    Guest, you saved my day. Thanks to you all!!!

    It's the a shame the answer didn't come from "Chitubox"

  • Cliff Knight 2021-2-19
    Quote 29Floor

    Now that it (CB v1.8.1) will load I have found consistent bugs with bad .stl file creation; some have borne no resemblance to the original model. A telltale is if the file size is obviously too small, I had one instance that dellvered a 3.6 MB .stl I knew should be > 33 MB. Also I just had it crash three times in a row while re-slicing that file and attempting to save same.

    Additionally I've had ongoing problems with mucking about with the environment variables and run-time linker files causing other apps to not load (Free-CAD most annoyingly).

    So--I'm all done with it (CB v1.8.1) and going back to beta 1.8.0--maybe Chitubox can straighten this out...

  • cbd 2021-2-19
    Quote 30Floor
    Cliff Knight FWIW here&#39;s the reply I got from Chitubox support:========================================== ...
    These are two orders and need to be kept separate.