I have been trying to create a runescape-launcher (providing the NXT Client of RuneScape for openSUSE) package, don’t worry I know that because of licensing limitations I can’t provide it via the OBS, but as this forum’s description is:
[blockquote]
Questions about creating packages for openSUSE and using the Build Service
[/blockquote]
and this is about building packages for openSUSE I thought this was the appropriate place to ask this question. This runescape-launcher package of mine builds fine but whenever I try to install it, zypper complains that nothing provides libcurl.so.4(CURL_OPENSSL_3)(64bit). I have built a libcurl-compat package in an effort to satisfy this dependency (and as this package is open-source I have uploaded it to the OBS so you can view its packaging files here) but it doesn’t seem to be satisfying this dependency. My libcurl-compat package is modelled after the corresponding Arch Linux package (https://www.archlinux.org/packages/community/x86_64/libcurl-compat/), as I modelled my runescape-launcher spec file partly after the runescape-launcher PKGBUILD in the Arch User Repository.
I even tried rebuilding the Arch Linux libcurl-compat package as an RPM (under the package name libcurl-compat-bin), but that still didn’t satisfy this dependency.
If it helps here is the error trace (shown by launching it with LD_DEBUG=libs) I get when trying to start runescape-launcher (after I forcibly install runescape-launcher despite the missing libcurl.so.4(CURL_OPENSSL_3)(64bit) library): http://paste2.org/V95WJ7Jm. It seems like the fatal error comes from libcanberra GTK+ widgets.
Short answer is - nothing; in openSUSE curl is built against mozilla_nss. If you provide alternative libcurl built against openssl, you need to update ld.so configuration to point to it (but you should understand that it will affect system wide curl) or explicitly build your package against private copy.
In addition to that, it would make sense to use a local copy of libcurl and link against it statically so it can’t interfere with the system wide library.
Addendum:
This of course implies you would not only have to build that static library of libcurl but also link that one statically against a version of openssl which provides the possibility of static linking itself. That would work and it is possible to do it (and I do not claim it is easy).
How would I do this? Build curl from source locally and install it to a non-system directory. Then build the NXT Client with LD_LIBRARY_PATH pointing to this non-system directory where curl is built?
You got two pointers for two different approaches.
In short, this will neither work for a dynamic nor for a static approach.
For a dynamic approach this might work at build time but not a runtime, for a static approach you will need static libraries and LD_LIBRARY_PATH is useless there (LD = _dynamic_loader).
For a dynamic approach IMHO the only way to do it in a clean manner, would be to build and link against a curl library which has been renamed and can not interfere with system’s libcurl.
The more dirty way for runtime would be to ship a respective libcurl inside the package and use a start script for the binary using LD_LIBRARY_PATH or other preloading mechanisms.
Addendum:
Is this “NXT Client” free or proprietary software?
I’ll be …ed! I got the NXT Client to work! This is the first time I’ve managed to run the NXT Client natively (without the use of chroots into a Manjaro/Ubuntu OS that can run the client flawlessly and without the use of Docker) on openSUSE. I also never managed to get this client to run on Fedora without chroot/Docker. What I did was I ran:
wget -cqO- https://curl.haxx.se/download/curl-7.53.1.tar.gz | tar xz
cd curl-7.53.1
./configure --prefix=/usr --with-ssl
make
cd ..
wget -cqO- http://downloads.sourceforge.net/glew/glew-1.10.0.tgz | tar xz
cd glew-1.10.0
make
cd ..
wget -c https://content.runescape.com/downloads/ubuntu/pool/non-free/r/runescape-launcher/runescape-launcher_2.2.3_amd64.deb
dpkg-deb -x runescape-launcher_2.2.3_amd64.deb
then I edited usr/bin/runescape-launcher to include the curl-7.53.1/lib/.lib and glew-1.10.0/lib directories in its LD_LIBRARY_PATH variable. I did this in my $HOME/Programs directory and here is my final usr/bin/runescape-launcher file
#!/bin/sh
if -z $1 ]; then
configURI=http://www.runescape.com/k=5/l=\$\(Language:0\)/jav_config.ws
else
configURI=$1
shift
fi
export PULSE_PROP_OVERRIDE="application.name='RuneScape' application.icon_name='runescape' media.role='game'"
export SDL_VIDEO_X11_WMCLASS="RuneScape"
export MESA_GL_VERSION_OVERRIDE=3.0
export DIR="/home/fusion809/Programs"
export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:$DIR/curl/curl-7.53.1/lib/.libs:$DIR/glew-1.10.0/lib"
unset XMODIFIERS
$DIR/usr/share/games/runescape-launcher/runescape --configURI $configURI $@
A “tiny” detail you should have mentioned from the start, so all other approaches than using some start script with preloading mechanisms can not work.
If LD_LIBRARY_PATH is empty this assignment makes it look in current directory at the time you run this script. This opens up rather wide door for hijacking your program. You should always check whether variable is set before doing such assignments. Something like
Good point, but wouldn’t it be better to put the additional paths in front of the “standard” ones?
This is a serious question, for setting $PATH it certainly matters.
Example:
I use a self compiled version of gpg (2.1.x) but can not switch to it completely (signing and signature checking of rpms still needs 2.0.x).
My solution looks like this, only for my normal user, root does not have /opt/gpg/bin/, so zypper/rpm are happy and my ~/.rpmmrc sets %__gpg explicitly to /usr/bin/gpg.