[SOLVED] New LLVM kills Libreoffice-7.5.2

3rensho · 04-01-2023, 08:56 AM

Quote:

Originally Posted by ppr:kut

The output of this should tell me all I need to know

Code:

ls /etc/OpenCL/vendors/

Here ya goes -

Code:

ls -l /etc/OpenCL/vendors/ls -l /etc/OpenCL/vendors/
total 12
-rw-r--r-- 1 root root 19 Mar 31 19:25 mesa.icd
-r--r--r-- 1 root root 22 Apr  1 04:06 nvidia.icd
-rw-r--r-- 1 root root 22 Mar 31 19:25 rusticl.icd

Petri Kaukasoina · 04-01-2023, 09:12 AM

In libreoffice, I went Tools - Options - LibreOffice - OpenCL. Then clicked the box "Allow use of OpenCL". After that I get the same error:

Code:

: CommandLine Error: Option 'use-dbg-addr' registered more than once!
LLVM ERROR: inconsistency in registered CommandLine options
Unspecified Application Error

(No nvidia here.)

chrisretusn · 04-01-2023, 11:43 AM

I confirm what Petri Kaukasoina posted.

I do use nvidia, 470.182.03, the blob.

Markus Wiesner · 04-01-2023, 12:38 PM

Running a self-compiled clinfo also fails with the same error after upgrading to llvm-16.0.0-x86_64-1:

Code:

$ clinfo 
: CommandLine Error: Option 'use-dbg-addr' registered more than once!
LLVM ERROR: inconsistency in registered CommandLine options
Aborted

Just recompiling clinfo does not help and it also does not (direct) depend on something from LLVM:

Code:

$ ldd /usr/bin/clinfo 
	linux-vdso.so.1 (0x00007ffe39515000)
	libOpenCL.so.1 => /usr/lib64/libOpenCL.so.1 (0x00007fead4d35000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007fead4d30000)
	libc.so.6 => /lib64/libc.so.6 (0x00007fead4b39000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fead4d6b000)

volkerdi · 04-01-2023, 12:56 PM

Interesting. I made the switch to DYLIB (again) since -DBUILD_SHARED_LIBS=ON broke the compile for llvm16, and I could not find any way around that. Plus, I could not find anyone else still building that way, and remembered the upstream recommendation. But it's looking like DYLIB suffers the same duplicate symbol rot as SHARED_LIBS=ON (perhaps worse). How's Arch getting away with this and not running into these bugs I wonder?

In spite of the bloat it would cause, it might be best to just stop trying to build any sort of shared LLVM libraries.

ppr:kut · 04-01-2023, 02:57 PM

For those following along, this is the underlying issue: https://github.com/KhronosGroup/SPIR...or/issues/1936

Not sure what the best solution is at this point. Errors like these are why we did the "not recommended" way of building all llvm libs as shared libs before, but apparently, like volkerdi mentioned, that's no longer working either.

Markus Wiesner · 04-01-2023, 03:24 PM

Quote:

Originally Posted by volkerdi

How's Arch getting away with this and not running into these bugs I wonder?

Seems to be a special problem with Mesa/OpenCL when multiple drivers are dynamically loaded with the same statically linked libraries: https://bugs.llvm.org/show_bug.cgi?id=30587 / https://bugs.llvm.org/show_bug.cgi?id=22952

They mention something about LLVM_DYLIB_COMPONENTS – maybe it's this part from Arch (-DLLVM_DISTRIBUTION_COMPONENTS) that works around the issue? https://github.com/archlinux/svntogi...k/PKGBUILD#L26 – and here the Gentoo script they are referring to that also uses -DLLVM_DISTRIBUTION_COMPONENTS: https://gitweb.gentoo.org/repo/gento...-16.0.0.ebuild

reddog83 · 04-01-2023, 08:23 PM

Worked for me until I relogged in to my desktop. It never showed in my exports.

Quote:

Originally Posted by ppr:kut

Does it help if you put

Code:

export SAL_DISABLE_OPENCL=1

in /etc/profile.d/libreoffice.sh and then relogin?

chrisretusn · 04-01-2023, 10:19 PM

Quote:

Originally Posted by Markus Wiesner

Running a self-compiled clinfo also fails with the same error after upgrading to llvm-16.0.0-x86_64-1:

Same issue.

USUARIONUEVO · 04-02-2023, 06:30 AM

Quote:

Originally Posted by volkerdi

Interesting. I made the switch to DYLIB (again) since -DBUILD_SHARED_LIBS=ON broke the compile for llvm16, and I could not find any way around that. Plus, I could not find anyone else still building that way, and remembered the upstream recommendation. But it's looking like DYLIB suffers the same duplicate symbol rot as SHARED_LIBS=ON (perhaps worse). How's Arch getting away with this and not running into these bugs I wonder?

In spite of the bloat it would cause, it might be best to just stop trying to build any sort of shared LLVM libraries.

Probably cause stucks on llvm-15 , all know archlinux is kamikaze on updates , when stay on one version and no upgrade is cause problems detected.

https://archlinux.org/packages/?q=llvm
https://archlinux.org/packages/extra/x86_64/llvm/
https://github.com/archlinux/svntogi...trunk/PKGBUILD

Quote:

-DCMAKE_BUILD_TYPE=Release
-DCMAKE_INSTALL_DOCDIR=share/doc
-DCMAKE_INSTALL_PREFIX=/usr
-DCMAKE_SKIP_RPATH=ON
-DLLVM_BINUTILS_INCDIR=/usr/include
-DLLVM_BUILD_DOCS=ON
-DLLVM_BUILD_LLVM_DYLIB=ON
-DLLVM_BUILD_TESTS=ON
-DLLVM_ENABLE_BINDINGS=OFF
-DLLVM_ENABLE_FFI=ON
-DLLVM_ENABLE_RTTI=ON
-DLLVM_ENABLE_SPHINX=ON
-DLLVM_HOST_TRIPLE=$CHOST
-DLLVM_INCLUDE_BENCHMARKS=OFF
-DLLVM_INSTALL_UTILS=ON
-DLLVM_LINK_LLVM_DYLIB=ON
-DLLVM_USE_PERF=ON
-DSPHINX_WARNINGS_AS_ERRORS=OFF

And linux from scratch , stay on same version , like archlinux

https://www.linuxfromscratch.org/blf...eral/llvm.html

volkerdi · 04-02-2023, 01:07 PM

Quote:

Originally Posted by USUARIONUEVO

And linux from scratch , stay on same version , like archlinux

https://www.linuxfromscratch.org/blf...eral/llvm.html

When I started working on llvm16 LFS was on 16.0.0 as well. Then at some point it switched back to the earlier version... perhaps I should have taken the hint.

the3dfxdude · 04-02-2023, 09:12 PM

Oh the pain. I built chromium-110 against my own build of llvm-16.0.0rc3 a few weeks ago on Slackware 15.0, because chromium-110 seemingly required a snapshot of the prerelease (beta, untested code?) of llvm 16. I just had to spend a day and figure out more about this...

Anyway, this was not a thing that went without a hitch. I can't remember exactly all the ways that didn't work, but here is at least how I built llvm 16rc3 after some attempts and hacking away. I don't think I started with the prior slackbuild, but a sort of BLFS/Slackware hybrid put in /opt.

Code:

cmake -DCMAKE_INSTALL_PREFIX=/opt/llvm16               \
    -DCMAKE_C_COMPILER="clang" \
    -DCMAKE_CXX_COMPILER="clang++" \
    -DCMAKE_C_FLAGS:STRING="-O2 -fPIC" \
    -DCMAKE_CXX_FLAGS:STRING="-O2 -fPIC" \
      -DLLVM_ENABLE_FFI=ON                      \
      -DCMAKE_BUILD_TYPE=Release                \
    -DLLVM_USE_LINKER=gold \
    -DLLVM_ENABLE_RTTI=ON \
    -DLLVM_ENABLE_FFI=ON \
    -DLLVM_ENABLE_ASSERTIONS=OFF \
    -DLLVM_INSTALL_UTILS=OFF \
    -DLLVM_INCLUDE_UTILS=OFF \
    -DLLVM_INCLUDE_TESTS=OFF \
      -DLLVM_TARGETS_TO_BUILD="host;AMDGPU;BPF" \
      -DLLVM_BINUTILS_INCDIR=/usr/include       \
      -DLLVM_INCLUDE_BENCHMARKS=OFF             \
      -DCOMPILER_RT_BUILD_LIBFUZZER=OFF \
      -G Ninja ..   2>&1 | tee /tmp/build/configure.log

I might have used BLFS as the guide here, but don't remember at what exact instance it would have been either. I guess it would not have been at llvm16 in BLFS yet as llvm had not released it yet. Also, I might have been unsettled with shared linking with llvm16 on something one-off for slackware-15. Now this thread has me questioning stability of some of these projects again.

USUARIONUEVO · 04-03-2023, 01:10 AM

If its supossed llvm-16.0.1 is on the road , we can wait these days and test the point release.

Its expected tomorrow the new point release , ... big number of commits, hope some of more than 6000 commits fix our problems.

Quote:

6813 commits to main since this release
llvmorg-16.0.0
08d094a

reddog83 · 04-03-2023, 04:54 AM

Im up for it.

marav · 04-03-2023, 06:19 AM

Quote:

Originally Posted by ppr:kut

For those following along, this is the underlying issue: https://github.com/KhronosGroup/SPIR...or/issues/1936

Not sure what the best solution is at this point. Errors like these are why we did the "not recommended" way of building all llvm libs as shared libs before, but apparently, like volkerdi mentioned, that's no longer working either.

gentoo & opensuse build spirv without -DBUILD_SHARED_LIBS=ON
is there any reason to have it in the slackbuild ?

Tested here

Code:

$ clinfo 
Number of platforms                               0

ICD loader properties
  ICD loader Name                                 OpenCL ICD Loader
  ICD loader Vendor                               OCL Icd free software
  ICD loader Version                              2.3.1
  ICD loader Profile                              OpenCL 3.0

also, libclc builds fine as well as mesa