Works here with tb87-TDF/2023-01-11_04.03.16/LibreOfficeDev_7.6.0.0.alpha0_Linux_x86-64_deb.tar.gz and qt5-base 5.15.8+kde+r162-1 on Arch Linux.

On pc Debian x86-64 with master sources updated today + brand new LO profile + kf5 rendering, I don't reproduce this.

Pierre: on which distrib are you? FYI, rpm/deb files are more for distrib maintainers since dependencies must be taken into account.
You can try this:
- launch a terminal/console
- type:
export SAL_USE_VCLPLUGIN=gen
- scalc &

(In reply to Julien Nabet from comment #2)
> On pc Debian x86-64 with master sources updated today + brand new LO profile
> + kf5 rendering, I don't reproduce this.
> 
> Pierre: on which distrib are you? 

Operating System: Mageia 9
KDE Plasma Version: 5.26.5
KDE Frameworks Version: 5.101.0
Qt Version: 5.15.7
Kernel Version: 6.1.4-server-1.mga9 (64-bit)
Graphics Platform: X11
Processors: 20 × 12th Gen Intel® Core™ i7-12700K
Memory: 125.5 GiB of RAM
Graphics Processor: AMD Radeon RX 6600 XT
Manufacturer: Dell Inc.
Product Name: XPS 8950


> FYI, rpm/deb files are more for distrib
> maintainers since dependencies must be taken into account.

Other than a few fixed bugs; the daily builds have been working here for months. Doing what I can to help test...

> You can try this:
> - launch a terminal/console
> - type:
> export SAL_USE_VCLPLUGIN=gen
> - scalc &

Splash and quits; no error message with this var.  Just installed today's build; same...

Let me know if an strace, or other would help...

Thank you for your feedback, no idea here so uncc myself.

(In reply to Pierre Fortin from comment #0)
> $ warn:sal.osl:2095766:2095766:sal/osl/unx/module.cxx:152:
> dlopen(/home/pfortin/libreoffice/opt/libreofficedev7.6/program/
> libvclplug_kf5lo.so, 257): /lib64/libQt5Core.so.5: undefined symbol:
> u_strToLower
> warn:sal.osl:2095766:2095766:sal/osl/unx/module.cxx:152:
> dlopen(/home/pfortin/libreoffice/opt/libreofficedev7.6/program/
> libvclplug_gtk3_kde5lo.so, 257): /lib64/libQt5Core.so.5: undefined symbol:
> u_strToLower

u_strToLower should be from the ICU library ( https://unicode-org.github.io/icu-docs/apidoc/dev/icu4c/ustring_8h.html#a1b516af424a82c73421754e63306b4b6 ).

I'm wondering whether this is any mismatch of what the system Qt was compiled against and what is there now, rather than a LO issue.

> May be due to recent update:

Was there any recent update of ICU on your system as well, or just Qt?

Some commands you might check: What do these commands output for you? (You'll have to adapt paths to where the libraries are on Mageia). Following what I see on Debian testing):


$ nm -gD /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 | grep u_str
                 U u_strToLower_72
                 U u_strToUpper_72

$ ldd /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 | grep icu
        libicui18n.so.72 => /lib/x86_64-linux-gnu/libicui18n.so.72 (0x00007f6ef1e00000)
        libicuuc.so.72 => /lib/x86_64-linux-gnu/libicuuc.so.72 (0x00007f6ef1c02000)
        libicudata.so.72 => /lib/x86_64-linux-gnu/libicudata.so.72 (0x00007f6eef600000)


$ nm -gD /lib/x86_64-linux-gnu/libicuuc.so.72 | grep -i u_strToLower
0000000000143330 T u_strToLower_72

(In reply to Pierre Fortin from comment #3)
> Operating System: Mageia 9

Is that a stable Mageia release or (as a quick look on the Mageia website suggests) some alpha/pre-release?


> > You can try this:
> > - launch a terminal/console
> > - type:
> > export SAL_USE_VCLPLUGIN=gen
> > - scalc &
> 
> Splash and quits; no error message with this var.  Just installed today's
> build; same...

Does this still happen after deleting your LO profile or when you start in safe mode?
Does it also happen when you start 'soffice --writer' or just 'soffice' instead of 'scalc'?


Does the LibreOffice installed via Mageia packages work, in particular the kf5 VCL plugin (i.e. the one that says "VCL: kf5 (...)" in "Help" -> "About LibreOffice"? (Don't know whether Mageia provides that as a package.)

(In reply to Michael Weghorn from comment #5)

> Was there any recent update of ICU on your system as well, or just Qt?

Looks like ICU also:
$ rpm -qa --last | grep icu
lib64icu-devel-72.1-1.mga9.x86_64             Sun 08 Jan 2023 08:08:18 AM EST
lib64icu72-72.1-1.mga9.x86_64                 Sun 08 Jan 2023 08:05:05 AM EST
icu72-data-72.1-1.mga9.noarch                 Sun 08 Jan 2023 08:05:05 AM EST
### The following are still in the system
lib64icu71-71.1-2.mga9.x86_64                 Mon 20 Jun 2022 09:15:09 AM EDT
icu71-data-71.1-2.mga9.noarch                 Mon 20 Jun 2022 09:15:09 AM EDT
lib64basicusageenvironment1-2021.06.25-3.mga9.x86_64 Thu 24 Mar 2022 11:54:19 AM EDT
lib64icu69-69.1-2.mga9.x86_64                 Thu 24 Mar 2022 11:48:03 AM EDT
icu69-data-69.1-2.mga9.noarch                 Thu 24 Mar 2022 11:48:03 AM EDT



> Some commands you might check: What do these commands output for you?
> (You'll have to adapt paths to where the libraries are on Mageia). Following
> what I see on Debian testing):
> 
> 
> $ nm -gD /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 | grep u_str
>                  U u_strToLower_72
>                  U u_strToUpper_72

$ nm -gD /lib64/libQt5Core.so.5 | grep u_str
                 U u_strToLower
                 U u_strToUpper
 
> $ ldd /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 | grep icu
>         libicui18n.so.72 => /lib/x86_64-linux-gnu/libicui18n.so.72
> (0x00007f6ef1e00000)
>         libicuuc.so.72 => /lib/x86_64-linux-gnu/libicuuc.so.72
> (0x00007f6ef1c02000)
>         libicudata.so.72 => /lib/x86_64-linux-gnu/libicudata.so.72
> (0x00007f6eef600000)

$ ldd /lib64/libQt5Core.so.5 | grep icu
        libicui18n.so.72 => /lib64/libicui18n.so.72 (0x00007fae2be00000)
        libicuuc.so.72 => /lib64/libicuuc.so.72 (0x00007fae2bc0a000)
        libicudata.so.72 => /lib64/libicudata.so.72 (0x00007fae2c133000)


> $ nm -gD /lib/x86_64-linux-gnu/libicuuc.so.72 | grep -i u_strToLower
> 0000000000143330 T u_strToLower_72

$ nm -gD /lib64/libicuuc.so.72 | grep -i u_strToLower
000000000013b0c0 T u_strToLower

> (In reply to Pierre Fortin from comment #3)
> > Operating System: Mageia 9
> 
> Is that a stable Mageia release or (as a quick look on the Mageia website
> suggests) some alpha/pre-release?

Other than LOTS of updates; I've been using it as my primary OS since Feb/22 when I acquired the machine. On the whole, I have no problem with alpha/beta software; support tends to be better than with released software...  :)


> > > You can try this:
> > > - launch a terminal/console
> > > - type:
> > > export SAL_USE_VCLPLUGIN=gen
> > > - scalc &
> > 
> > Splash and quits; no error message with this var.  Just installed today's
> > build; same...

For completeness:
$ scalc --safe-mode
warn:sal.osl:377911:377911:sal/osl/unx/module.cxx:152: dlopen(/home/pfortin/libreoffice/opt/libreofficedev7.6/program/libvclplug_kf5lo.so, 257): /lib64/libQt5Core.so.5: undefined symbol: u_strToLower
warn:sal.osl:377911:377911:sal/osl/unx/module.cxx:152: dlopen(/home/pfortin/libreoffice/opt/libreofficedev7.6/program/libvclplug_gtk3_kde5lo.so, 257): /lib64/libQt5Core.so.5: undefined symbol: u_strToLower
warn:desktop.app:377911:377911:unotools/source/ucbhelper/localfilehelper.cxx:87: error removing directory file:///home/pfortin/libreoffice/opt/libreofficedev7.6/program/../../UserInstallation/user/extensions

The last line is new.  
$ ll libreoffice/opt/UserInstallation/user/
total 16
drwxr-xr-x  2 pfortin pfortin 4096 Jan 11 14:58 config/
drwxr-xr-x  2 pfortin pfortin 4096 Jan 11 14:58 extensions/
-rw-------  1 pfortin pfortin  329 Jan 11 14:58 registrymodifications.xcu
drwxr-xr-x 13 pfortin pfortin 4096 Jan 11 14:57 SafeMode/
$ ll libreoffice/opt/UserInstallation/user/extensions/
total 4
-rw-r--r-- 1 pfortin pfortin 40 Jan 11 14:58 buildid


> Does this still happen after deleting your LO profile or when you start in
> safe mode?
Safe mode: see above.

$ mv libreoffice/opt/UserInstallation/user libreoffice/opt/UserInstallation/user.off

No change.


> Does it also happen when you start 'soffice --writer' or just 'soffice'
> instead of 'scalc'?

Interesting:  'soffice --writer' & 'soffice --calc' both start up.
'scalc' and 'swriter' fail as originally reported...

> Does the LibreOffice installed via Mageia packages work, in particular the
> kf5 VCL plugin (i.e. the one that says "VCL: kf5 (...)" in "Help" -> "About
> LibreOffice"? (Don't know whether Mageia provides that as a package.)
Never saw VCL (whatever that is)...  Here's the version info:
Version: 7.4.3.2
Build ID: 40(Build:2)
CPU threads: 20; OS: Linux 6.1; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded Jumbo

And for 7.6:
Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 28ff4647e9dac8eebe3a169e828bacc8dc78e363
CPU threads: 20; OS: Linux 6.1; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded


Argh...  this may be an invalid bug report...  When I thought both 7.4.3.2 and 7.6.0.0 were shutdown, I got this:

$ ps aux | grep office
pfortin  1814092  0.0  0.0 164560  5684 pts/16   Sl   Jan10   0:00 /home/pfortin/libreoffice/opt/libreofficedev7.6/program/oosplash --calc
pfortin  1814127  0.1  1.2 38046616 1708112 pts/16 Sl Jan10   3:01 /home/pfortin/libreoffice/opt/libreofficedev7.6/program/soffice.bin --calc --splash-pipe=5

Somehow, these windows were nowhere to be found.  I did find the konsole from where they were started and fg + Ctrl+C got rid of them. Now scalc and swriter start just fine.

Hmm...   I can do 'scalc &' multiple times and get a new instance each time.  Somehow, I thought all previous instances were closed (no calc windows or taskbar icons); these appear to have been causing this issue.  Now that I can start multiple instances; I don't get how the instances without windows caused this...  Closing as INVALID vs UNCONFIRMED -- unless there's something here you feel needs a second look...  Sorry for the noise that still leaves me puzzled...  no idea how 2 windows got disowned or ?

(In reply to Pierre Fortin from comment #6)
> Other than LOTS of updates; I've been using it as my primary OS since Feb/22
> when I acquired the machine. On the whole, I have no problem with alpha/beta
> software; support tends to be better than with released software...  :)

Similar here with Debian testing. :) Usually there are smooth transitions when a library that is used by all kinds of other software is updated: all things depending on that are automatically rebuilt and updated at the same time, but I've rarely seen cases where that wasn't the case - which is why I was asking.

> Argh...  this may be an invalid bug report...  When I thought both 7.4.3.2
> and 7.6.0.0 were shutdown, I got this:
> 
> [...]
> 
> Somehow, these windows were nowhere to be found.  I did find the konsole
> from where they were started and fg + Ctrl+C got rid of them. Now scalc and
> swriter start just fine.

Thanks for all additional testing and the update here. Great to hear it's working now.