> I was not aware of programs like Blender writing into there
Blender depends on intel-oneapi-compiler-shared-runtime-libs[^1] that is
a subset of `intel-oneapi-basekit`. This is installed on all PCs no
matter if intel graphics is used.
One option here to avoid the `intel-oneapi-basekit` is to have the intel
cpp compiler & headers as make dependencies, and runtime libs as
dependencies, just as how the blender[^2] package did.
Maintaining a specific version of oneAPI libraries is fine for sure,
which is commonly used when the libraries the package depends on are not
compatible with arch's packages.
e.g. 3D Slicer relies on python 3.9, while the upstream python is 3.14.
So the package have to build another version of python itself to avoid
incompatibility[^3].
IMO, as `oneapi` is stable and quite big in size, the first option may
sound better to me. But anyway, since we don't have a maintained sycl
version of llama.cpp at present, either option would be fine. Keep the
package smaller in size is in lower priority in compared with having no
maintained versions. Any effort you make to build the package is well
appreciated.
[^1]:
https://archlinux.org/packages/extra/x86_64/intel-oneapi-compiler-shared-runtime-libs/
[^2]: https://archlinux.org/packages/extra/x86_64/blender/
[^3]: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=3dslicer#n104
Regards,
Zhenhui Xie
On 5/13/26 10:49 PM, Can Tosun wrote:
Okay, I was not aware of programs like Blender writing into there, I assumed
it's literally just people running local AI that likely will only have one
package installed anyway. In that case maybe I'll also move the oneAPI folder
to /opt/llama.cpp-sycl/oneapi/, that way everything the package installs is
located there apart from the bins. That should really make it a next to zero
possible conflicts install apart from having another llama.cpp build, right?
-------- Original Message --------
On Wednesday, 05/13/26 at 09:39 Zoho <[email protected]> wrote:
Thank you for your instant response. I'm glad these recommendations can
be of some help to you.
I have to warn you again that the `intel-oneapi-basekit` is not the only
package that writes to `/opt/intel/oneapi`. There are many others (see
`pacman -Ss oneapi`) and some famous packages such as blender depend on
them. Please be *very careful* if you truly want to write into that
directory rather than simply depend on `intel-oneapi-basekit`.
Regards,
Zhenhui Xie
On 5/13/26 2:24 PM, Can Tosun wrote:
Good morning Zhenhui,
Thank you for the feedback, I will get to work on addressing your points
shortly.
For point 1, I plan to add intel-oneapi-toolkit to the conflicts array since
true coexistence under pacman is not practical given the shared target path. I
feel like the full toolkit only has a use for the handful of people that
actually develop with oneAPI, which in reality wouldn't use this package
anyway. The actual intended enduser will almost certainly never touch any of
these tools.
For point 2, very valid point so I plan to move the llama.cpp install prefix to
/opt/llama.cpp-sycl so that libggml.so and other shared libraries stay out of
/usr/lib entirely, with RPATH set so the binaries find their libraries without
any environment changes. Binaries will be symlinked into /usr/bin as usual.
For point 3, you are also correct and I plan to add !buildflags to options and
simplify the build according to the official documentation.
Regarding llama.cpp-sycl-f16, I am happy to delay the deletion request by a
month or two as you suggest. However I would prefer not to adopt it. There are
already four SYCL llama.cpp packages in the AUR, now five due to mine but my
aim was to keep it up to date since I use it on my B70 myself and to minimize
confusion for the end user by only providing one definitive package. I hope you
understand.
Thanks again for taking the time to write.
Best regards from Germany
Can Tosun
-------- Original Message --------
On Wednesday, 05/13/26 at 03:39 Zoho <[email protected]> wrote:
Thank you for your packaging on `llama.cpp-sycl`. I am the current
maintainer of `llama.cpp-sycl-f16`.
This package is currently unmaintained, as the original maintainer txtsd
orphaned it and I don't have access to an intel dGPU now. It would be
great if we could have a single well-maintained llama.cpp sycl package
that works under different settings.
However, I would kindly recommend delaying the deletion of package
`llama.cpp-sycl-f16` for a month or two. Despite out of date, it is
verified to work on the PC of txtsd and me, so that users will have some
fallbacks in case the latest version don't compile on their PC.
Here are my recommendations on your package. Hope it could be some help
to you:
- You said that your package bundled *essential oneAPI components*
without need to installing the full `intel-oneapi-toolkit`. Do they
conflict if a person have to install both on their PC?
- `libggml.so`, if installed to /usr/lib, could have conflict with other
packages (e.g. `https://aur.archlinux.org/packages/whisper.cpp`).
Probably installing that shared object to a different folder (e.g.
/opt/llama.cpp-sycl) and override LD_LIBRARY_PATH would solve the conflict.
- In my previous experiment, `makepkg` won't setup the environment
correctly by `source "${oneapi_root}/setvars.sh"` if `!buildflags` was
not set. Was it solved in the latest oneapi?
If you could maintain compatibility with previous versions (e.g.
dependencies on `intel-oneapi-toolkit`), I would be happy to hand over
`llama.cpp-sycl-f16` to you.
Regards,
Zhenhui Xie
On 5/12/26 2:38 PM, [email protected] wrote:
cantosun99 [1] filed a deletion request for llama.cpp-sycl-f16 [2]:
llama.cpp-sycl-f16, llama.cpp-sycl-f16-git, llama.cpp-sycl-f32 and
llama.cpp-sycl-f32-git are all out of date since they have last been
updated a year ago or even orphaned, llama.cpp-sycl aims to fix this
and should therefore replace the four.
[1] https://aur.archlinux.org/account/cantosun99/
[2] https://aur.archlinux.org/pkgbase/llama.cpp-sycl-f16/
