Arch Linux User Repository

Wow. I thought that maybe this could be improved so I deleted the link to libswt-gtk-4924r25.so and then restarted BiglyBT. BiglyBT remade libswt-gtk-4934r5.so the instant I opened it. The file is different than the libswt-gtk-4934r5.so that was already on it, ie. different sum. It appears that libswt-gtk-4934r5.so was corrupt. If anyone else has the problem then rename that file so BiglyBT can remake the file.

Thanks mrxx. Got it working. When I saw your post the first thing I thought of is that Manjaro didn't offer openjdk 14. I had 13 as the default because that was the highest version I had. I installed jdk 14 from the AUR and set it as default but I get the exact same error. Maybe its an Arch vs. Manjaro thing going on here. So I then uninstalled jdk 14 since that wasn't it. Then I noticed that libswt-gtk-4934r5.so is actually on my computer and biglybt is loading it. I left out a part of the error message because I had to type it in. Something about a PowerPC library was not compatible with an AMD platform. So I renamed the libswt-gtk-4934r5.so file to libswt-gtk-4934r5.so.bak and made a link from libswt-gtk-4924r25.so to libswt-gtk-4934r5.so. This last part fixed it. Your post helped immensely. Thanks again.

centqwerG7890FCT, on my machines it starts like this:

Starting BiglyBT...

Suitable java version found [java = openjdk 14.0.1 2020-04-14]

Using swt/swt-x86_64.jar v4.924

Maybe you're using an incompatible java package.

Use "archlinux-java" to fix your java environment or select a different one (I've installed jre-openjdk).

Can't launch. I get the following errors: GUI could not be loaded. java.lang.UnsatisfiedLinkError: Could not find SWT library. Reasons: no swt-gtk-4934r5 in java.library.path [/opt/biglybt] no swt-gtk in java.library.path [/opt/biglybt] ~/.swtlib/linux/x86_64/libswt-gtk-4934r5.so Can't load library: ...

Thanks, eschwartz and SolarAquarion.

A fake homedir is created below $srcdir now and the installer writes everything into it.

Can't you trick the installer into writing those files into the $srcdir by faking the $HOME?

SolarAquarion, I've changed this back to the situation as it was when I adopted the package (where neither the app launcher link nor the link on the Desktop worked on the build machine because the .desktop files created by the program installer had a wrong execution path).

Now, on the build machine, the program installer again creates a link on the user's Desktop, and even worse, still with wrong Exec= content.

As proposed by you this link is no longer removed immediately, but a message in post-install directs the users to remove it on their own (and, just in case it reappears one day, also the link in .local/share/applications).

trick the installer into "HOME=$srcdir" or something like it

you should probably do an if for the " ~/.local/share/applications", because what if you build it in a chroot?

You should probably do a post_upgrade and post_install message instead of deleting stuff in the PKGBUILD or something that isn't in the build chroot

Added armv7h to archs.