[Slackbuilds-users] Problems building wezterm

[Luveh Keraph]

Wezterm looks interesting, but I could not build it for 15.0 using sbopkg:

freetype2-e4586d960f339cf75e2e0b34aee30a0ed8353c0d/tests/issue-1063/
freetype2-e4586d960f339cf75e2e0b34aee30a0ed8353c0d/tests/issue-1063/main.c
freetype2-e4586d960f339cf75e2e0b34aee30a0ed8353c0d/tests/meson.build
freetype2-e4586d960f339cf75e2e0b34aee30a0ed8353c0d/tests/scripts/
freetype2-e4586d960f339cf75e2e0b34aee30a0ed8353c0d/tests/scripts/download-test-fonts.py
freetype2-e4586d960f339cf75e2e0b34aee30a0ed8353c0d/vms_make.com
tar:
/var/lib/sbopkg/SBo/15.0/system/wezterm/image-fe069785ae245a2c510fd724ef96da283b05a236.tar.gz:
Cannot open: No such file or directory
tar: Error is not recoverable: exiting now

However, check this out:

$ ls -l
/var/lib/sbopkg/SBo/15.0/system/wezterm/image-fe06978fe069785ae245a2c510fd724ef96da283b05a236.tar.gz

lrwxrwxrwx 1 root root 78 Sep  9 12:30
/var/lib/sbopkg/SBo/15.0/system/wezterm/image-fe06978fe069785ae245a2c510fd724ef96da283b05a236.tar.gz
->
/var/cache/sbopkg/image-fe06978fe069785ae245a2c510fd724ef96da283b05a236.tar.gz

The block fe06978f is duplicated here. It does look fishy.

This may be just a problem with sbopkg. But, since building wezterm with
the Slackbuilds script directly involves downloading many dozens of crate
files by hand, I'll pass on checking that out.

Anyway, this issue can be overcome by creating the appropriate symbolic
link by hand. Once this is done, the next stumbling block is the following:

zvariant_utils-1.0.1/LICENSE
zvariant_utils-1.0.1/README.md
zvariant_utils-1.0.1/src/case.rs
zvariant_utils-1.0.1/src/lib.rs
zvariant_utils-1.0.1/src/macros.rs
error: process didn't exit successfully: `rustc -vV` (exit status: 127)
--- stderr
rustc: error while loading shared libraries:
librustc_driver-7adeb809cd07c1ca.so: cannot open shared object file: No
such file or directory

That shared library is present in the system, but under /opt/rust16/lib64 -
which, at least in my case, does not seem to be in the shared libraries
search path.

In turn, this issue can be sorted out by defining the LD_LIBARY_PATH
environment variable appropriately in the shell where the build is taking
place.

After this, and a rather long time in a relatively beefy system, the
installation package can be built. Perhaps it would be a good idea to
provide a binary build package, just as it already is done for tools like
pandoc or sage, and in essence for the same reasons.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.slackbuilds.org/pipermail/slackbuilds-users/attachments/20230909/240f4991/attachment.htm>