Missing run package for distro

#1

I have Crystal running in Manjaro and Antergos VirtualBox instances with no problem.
I installed 0.28.0 on PCLinuxOS and get this error message when I attempt to run code.

[jzakiya@localhost]$ crystal -v
Crystal 0.28.0 [639e4765f] (2019-04-17)

LLVM: 4.0.0
Default target: x86_64-unknown-linux-gnu


[jzakiya@localhost]$ crystal run test1.cr
/usr/bin/ld: cannot find -lpcre (this usually means you need to install the development package for libpcre)
/usr/bin/ld: skipping incompatible /usr/lib/libm.so when searching for -lm
collect2: error: ld returned 1 exit status
Error: execution of command failed with code: 1: `cc "${@}" -o '/home/jzakiya/.cache/crystal/crystal-run-fft1.tmp'  -rdynamic  -lpcre -lm /home/jzakiya/crystal/bin/../lib/crystal/lib/libgc.a -lpthread /home/jzakiya/crystal/share/crystal/src/ext/libcrystal.a -levent -lrt -ldl -L/home/jzakiya/crystal/bin/../lib/crystal/lib -L/usr/lib -L/usr/local/lib`

I searched the distors repos for libprcre but couldn’t find anything with that name.
What do I have to do to to get this working in PCLinuxOS?

#2

I originally used the *.tar.gz download with the symlink.
When I tried to install with the rpm package I got this.

[root@localhost Downloads]# rpm -iv crystal-0.28.0-1.x86_64.rpm
warning: crystal-0.28.0-1.x86_64.rpm: Header V4 RSA/SHA1 Signature, key ID 7cc06b54: NOKEY
error: Failed dependencies:
        libevent-devel is needed by crystal-0.28.0-1.x86_64
        pcre-devel is needed by crystal-0.28.0-1.x86_64

So then I went into the PCLOS reps and searched on libevent, and installed these two, libverto-libevent and libverto-libevent-devel, which satisfied the first dependency.

The I did a repo search on pcre and installed about 6 files with prefix lib64pcrexxxxx until the dependency was satisfied.

This allowed me to run some code, but other code gave me this errror:

/usr/bin/ld: cannot find -lgmp (this usually means you need to install the development package for libgmp)
/usr/bin/ld: skipping incompatible /usr/lib/libm.so when searching for -lm
collect2: error: ld returned 1 exit status
Error: execution of command failed with code: 1: `cc "${@}" -o '/home/jzakiya/.cache/crystal/crystal-run-hickerson.tmp'  -rdynamic  -lgmp -lpcre -lm /usr/bin/../lib/crystal/lib/libgc.a -lpthread /usr/share/crystal/src/ext/libcrystal.a -levent -lrt -ldl -L/usr/bin/../lib/crystal/lib -L/usr/lib -L/usr/local/lib`

So I did a repo search on gmp, saw this was installed lib64gmp10, and then installed lib64gmp-devel, which seems (for now) to have fixed the problem. I won’t be sure until I run all my old project code to verify.

This may be something to be aware of for the build process to accommodate different names for these dependencies, at least for PCLinuxOs, which is an rpm based Linux distro (but also uses apt-get).

#3

OK, seems like code will run, but I get all of this output when I run code:

[jzakiya@localhost rosettacode]$ crystal run fft1.cr
/usr/bin/ld: skipping incompatible /usr/lib/libm.so when searching for -lm
/usr/bin/ld: skipping incompatible /usr/lib/libpthread.so when searching for -lpthread
/usr/bin/ld: skipping incompatible /usr/lib/librt.so when searching for -lrt
/usr/bin/ld: skipping incompatible /usr/lib/libdl.so when searching for -ldl
/usr/bin/ld: skipping incompatible /usr/lib/libgcc_s.so when searching for -lgcc_s
/usr/bin/ld: skipping incompatible /usr/lib/libgcc_s.so.1 when searching for libgcc_s.so.1
/usr/bin/ld: skipping incompatible /usr/lib/libc.so when searching for -lc
/usr/bin/ld: skipping incompatible /usr/lib/libgcc_s.so when searching for -lgcc_s
/usr/bin/ld: skipping incompatible /usr/lib/libgcc_s.so.1 when searching for libgcc_s.so.1
4.0 + 0.0i
1.0 - 2.414213562373095i
0.0 + 0.0i
1.0 - 0.4142135623730949i
0.0 + 0.0i
0.9999999999999999 + 0.4142135623730949i
0.0 + 0.0i
0.9999999999999997 + 2.414213562373095i
#4

I get similar warning messages (though not so many) when I compile on OpenSUSE Tumbleweed. I think I remember hearing somewhere that it’s a by-product of the way certain OSes organize their 32- and 64-bit shared libraries. The sense I got at the time was that the solution is “ignore it”, but it’s possible someone has figured out a way to get rid of the warnings since then.