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 

Same problem on Ubuntu 20.04.2 LTS. Qt available from the official repos is 5.12, so naturally Chitubox won't run.

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)

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.

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
./CHITUBOX

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?

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

Same problem on Ubuntu 20.04 LTS

Hallo
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)

I get the same problem with linux mint 20.

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

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...

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?

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.

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.

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
./CHITUBOX

Works for me on Ubuntu 20.04.2

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. 

Oops... Thanks for catching the missing $ :-)

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/

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

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?

TIA

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?

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.

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...

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 :

#!/bin/bash

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

export LD_LIBRARY_PATH=$CB_DIR/lib

"$CB_DIR"/AppRun

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

BINGO!
Thank you Alex, works a charm...
-cliff-

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:

======================================
#!/bin/bash

CB_DIR=/home/knightci/Applications/CHITUBOX-V1.8.1

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!

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

========================================================================

"hello，

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

Thanks & regards
------------------------
创必得科技/谢信福
Tel:0755-23103569
手机：15112318095
Facebook：谢信福（Xinfu Xie）FaceBook 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 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"

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...

Cliff Knight FWIW here&#39;s the reply I got from Chitubox support:========================================== ...

These are two orders and need to be kept separate.