You are not logged in.
Hi all,
I've been trying to write a PKGBUILD for the latest Lattice Radiant (which seems to be a dormant AUR package at the moment) 2023.1.0.43.3.
I've posted a message which explains the issue there: https://aur.archlinux.org/packages/lattice-radiant
The Radiant package from Lattice is distributed as binaries.
Here's the content of my post for convenience:
Installation goes fine but there are some dependency issues. The Radiant app runs properly until we open an existing project.
This is due to a dependency problem with libstdc++ which ships with the radiant executable. The MESA drivers (using amdgpu here) fail to load due to the inconsistency betwween the local version of libstdc++ shipped with radiant and the system-wide version. So anything in the app requiring libGL fails to work.
The following errors appear in the console:
libGL error: MESA-LOADER: failed to open radeonsi: /usr/local/radiant/2023.1.0.43.3/bin/lin64/libstdc++.so.6: version GLIBCXX_3.4.29' not found (required by /usr/lib/dri/radeonsi_dri.so) (search paths /usr/lib/dri, suffix _dri) libGL error: failed to load driver: radeonsi libGL error: MESA-LOADER: failed to open swrast: /usr/local/radiant/2023.1.0.43.3/bin/lin64/libstdc++.so.6: versionGLIBCXX_3.4.29' not found (required by /usr/lib/dri/swrast_dri.so) (search paths /usr/lib/dri, suffix _dri) libGL error: failed to load driver: swrast
When opening a project, it crashes with a coredump:
[23:16:19.657 <fatal>] unknown:0 - Failed to create OpenGL context for format QSurfaceFormat(version 2.0, options QFlags<QSurfaceFormat::FormatOption>(), depthBufferSize 24, redBufferSize -1, greenBufferSize -1, blueBufferSize -1, alphaBufferSize -1, stencilBufferSize 8, samples 0, swapBehavior QSurfaceFormat::DefaultSwapBehavior, swapInterval 1, colorSpace QSurfaceFormat::DefaultColorSpace, profile QSurfaceFormat::NoProfile) Abandon (core dumped)
Which just shows it fails to create the OpenGL context and the app crashes instead of handling it gracefully.
I have tried removing the local libstdc++ to force radiant to use the system one. The above messages disappear but the app crashes at a later stage when opening a project, probably due to the incompatibility with the system libstdc++ and the one that the app was linked against.
Any hope of solving these dependency issues? If using the system libstdc++ makes the app crash, I guess one option would be the other way around, letting it use its own version of libstdc++ but also add a local older version of mesa for compatibility. I don't know how possible it even is.
Any idea welcome. Or is it a lost cause and we'll have to wait until Lattice releases a new version that is compatible with newer versions of libstdc++ ?
Thanks!
Offline
https://wiki.archlinux.org/title/Arch_p … irectories
/usr/local is typically left alone by packages so users can install things manually there.
Is this proprietary software ?
If so check https://wiki.archlinux.org/title/Nonfre … guidelines
Looking at the PKGBUILD in the aur you're better off with starting from scratch then using the existing PKGBUILD .
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Yes it's proprietary software: https://www.latticesemi.com/Products/De … DS/Radiant
As usual with this kind of tools, the Linux version is officially supported only on Red Hat and Ubuntu.
The version in AUR (3.0) does run 100% fine on Arch, but there's this dependency issue with the latest 2023.1.
The PKGBUILD I wrote based on the previous one does install it in /usr/local/radiant/2023.1.0.43.3/ , no problem with that.
Regarding the PKGBUILD for https://aur.archlinux.org/packages/lattice-radiant , could you tell me what is wrong with it?
Anyway, the issue here is probably a pretty classic dependency issue, not particularly related to Arch or the AUR per se, but just related to the fact the application is distributed as binaries, but I don't quite know how to solve it. I certainly don't want to have to downgrade my system to make this app run.
The above posted message relative to MESA and the GLIBCXX version should probably give a hint to people who are used to this, I am not yet. In similar cases, deleting the shipped libstdc++ library is enough to solve the problem, but in this case it makes the app crash probably because it doesn't like a newer version of libstdc++.
It only affects the GUI as it's a problem with libGL (if using the shipped libstdc++), there is a command-line version of radiant (radiantc, installed in /usr/local/radiant/2023.1.0.43.3/bin/lin64/radiantc ), which appears to work fine.
So the tool is usable if we can do without the GUI.
Offline
An important task of package managers is keeping track of what is installed where by who.
/usr/local is meant to be used for manual installs and all it takes to change things there is running one install command with root rights.
Tracking things in that folder is near impossible.
Packages that install stuff in /usr/local WILL cause severe issues and break things at some point.
That's one major issue with the package.
makepkg is perfectly capable of extracting a zip file and does place the content in $srdcir .
Manually extracting the zipped sourcecode in prepare() to get the .run-file is unnecessary and wastes resources.
Installers meant for other distros tend to screw up things when run on archlinux . Fortunately .run files often have an option to extract the files in it without running any scripts.
By using that option , the PKGBUILD stays in control of what happens.
Since the newest distro support by the software is ubuntu 20.04 LTS the differences between that an any uptodate archlinux install are massive.
If it turns out the cli part works but the gui part doesn't, the PKGBUILD should remove the gui part from the software to avoid problems.
TL;DR : If you are ok with putting stuff in /usr/local , don't bother creating a package for it.
Just run the install command.
Last edited by Lone_Wolf (2023-08-10 09:09:30)
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Thanks, got it!
Offline