Pharo on OpenSUSE (FFI / libgit2 errors)

Hello

I would like to use Pharo on OpenSUSE, which is only Linux distro on our
university PCs, however, I am getting FFI to libgit2 related errors just
about everywhere. By starting Launcher itself, by starting an image
(Pharo 7 and 8) and fetching probably any repository (tried Roassal 2 on
Pharo 6, 7, 8). I would really like to be able to use Pharo on
university PCs, but I need you help with finding out what might be wrong
and what to do about it. The main and only instruction for Linux is
currently "Unzip the archive in a place where you have write
privileges.", which obviously does not work for OpenSUSE. It works fine
for Ubuntu and Debian.

Thank you

Jan

Hi,

I just ran into the very same problem and into further problems when building from source. I will try to see which help I can provide to come to a solution:

libgit2 requires libssh2 which requires OpenSSL 1.0.x which is not installed/installable.

Building fails as OpenSUSE puts amd64 libraries into a lib64 folder. Manually copying it around fixes the build.

I am using OpenSUSE tumbleweed right now (a rolling release Linux distribution).

holger

Thank you for answer. I remember having to create link to
/usr/lib64/libcurl.so.4 2 years ago, with one of previous version of
OpenSUSE Leap. Currently there is OpenSUSE Leap 15 and even my package I
created 2 years ago for OpenSUSE with copy of libcurl library does not work
anymore (same error).

ldd libgit2.so gives me:
        linux-vdso.so.1 (0x00007ffe3e7e1000)
        libcurl-gnutls.so.4 => not found
        libz.so.1 => /lib64/libz.so.1 (0x00007f0abed73000)
        libssl.so.1.0.0 => not found
        libcrypto.so.1.0.0 => not found
        libssh2.so.1 => not found
        librt.so.1 => /lib64/librt.so.1 (0x00007f0abeb6b000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f0abe94d000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f0abe593000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f0abf2cd000)

So I tried copying all the libraries with "not found" from /usr/lib64 to
pharo-vm/lib/pharo/5.0-201901051900  but it does not seem recognize them
anyway - still the same result of ldd libssh2.so
Note that I am not very experienced with solving such kinds of problems, so
maybe I misunderstand what ldd is telling me. Also that even on Ubuntu I get
"not found" for libssh2.so.1, but Pharo works there fine. Probably ldd is
not looking for libraries in same directory, but runtime does?

Jan


Holger Freyther wrote
> jan.bliznicenko@.cvut





--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

It's exclusively due curl-gnutls (libcurl linked against GNUtls instead of OpenSSL for license preference). A version of OpenSSL1.0.0 seems to be in the bundle.

This was tested against http://files.pharo.org/get-files/80/pharo64-linux-stable.zip

1.) Download that file
2.) unzip that file somehwere
3.) In the same directory execute the below script. It fetches gnutls-curl from Ubuntu and its dependencies.
4.) Please report if that worked for you or not.



#!/usr/bin/env bash
# Fetches Ubuntu Xenial dependencies and copy them into the Pharo directory

set -ex

add_dependencies() {
local package="$1"
local url="http://mirrors.kernel.org/ubuntu/pool/${package}"
wget -O tmp.deb ${url}
# TODO(zecke): This avoids using dpkg-deb but assumes a third genration
ar x tmp.deb data.tar.xz

# TODO(zecke): This assumes multi-arch packaging. It's true now.
tar -xv --strip-components=3 -C lib/pharo/5.0-201902062351 -f data.tar.xz ./lib/x86_64-linux-gnu || \
tar -xv --strip-components=4 -C lib/pharo/5.0-201902062351 -f data.tar.xz ./usr/lib/x86_64-linux-gnu

# clean-up
rm tmp.deb data.tar.xz
}


add_dependencies main/c/curl/libcurl3-gnutls_7.47.0-1ubuntu2.14_amd64.deb
add_dependencies main/r/rtmpdump/librtmp1_2.4+20151223.gitfa8646d-1ubuntu0.1_amd64.deb
add_dependencies main/libi/libidn/libidn11_1.32-3ubuntu1.2_amd64.deb
add_dependencies main/n/nettle/libnettle6_3.2-1ubuntu0.16.04.1_amd64.deb
add_dependencies main/n/nettle/libhogweed4_3.2-1ubuntu0.16.04.1_amd64.deb
add_dependencies main/n/nas/libaudio2_1.9.4-4_amd64.deb

Hello

Thank you for this script. Unfortunately it does not seem to work for me.
After downloading that VM you linked and downloaded image with sources,
image opens and immediately crashes:

ioLoadModule(//home/honza/Downloads/pharo64-linux-stable/lib/pharo/5.0-201902062351/libgit2.so):
  /usr/lib64/libgnutls.so.30: symbol nettle_rsa_pss_sha384_sign_digest_tr,
version HOGWEED_4 not defined in file libhogweed.so.4 with link time
reference
External module not found
ExternalLibraryFunction(Object)>>error:
ExternalLibraryFunction(Object)>>externalCallFailed
ExternalLibraryFunction(ExternalFunction)>>invokeWithArguments:
LGitLibrary>>libgit2_init
FFICalloutAPI>>function:library:
LGitLibrary(Object)>>ffiCall:library:options:

During execution of the script, there are these suspicious lines exactly
repeated for each of the 6 add_dependencies call (so 6 times in whole
script):

+ tar -xv --strip-components=3 -C lib/pharo/5.0-201902062351 -f data.tar.xz
./lib/x86_64-linux-gnu
tar: ./lib/x86_64-linux-gnu: Not found in archive
tar: Exiting with failure status due to previous errors

Jan




--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

So it seems the good old
ln -s /usr/lib64/libcurl.so.4 (path to
pharo)/pharo-vm/lib/pharo/(version)/libcurl-gnutls.so.4
still works after all, just not with Pharo Launcher VM (where it causes
segfault). With regular VMs downloaded either manually or via the Launcher
itself it works.

Too bad it makes Launcher unusable on both systems for both reasons (cannot
hotfix launcher itself and have to hotfix all VMs it downloads).

Jan





--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

So it seems the good old
ln -s /usr/lib64/libcurl.so.4 (path to
pharo)/pharo-vm/lib/pharo/(version)/libcurl-gnutls.so.4
still works after all, just not with Pharo Launcher VM (where it causes
segfault). With regular VMs downloaded either manually or via the Launcher
itself it works.

Too bad it makes Launcher unusable on both systems for both reasons (cannot
hotfix launcher itself and have to hotfix all VMs it downloads).

Jan





--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Thank you for forwarding this. At first, I though "well, that is the same
solution I posted in previous mail/post, you just have libs in different
directory", but it is not. It creates link just once in lib64, not in each
VM, which is way better (but has be done by root). Unfortunately, it does
not work for Pharo Launcher on OpenSUSE - causes segfaults, don't know why.
Usual VM is OK.

Jan



--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

The VM crash for Launcher is not caused by having different VM, but by using
specific usage of SSL lib that does not work with this workaround. I added
more details into new issue I created for vm:
https://github.com/pharo-project/opensmalltalk-vm/issues/62

Jan



--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html