With this little move $ grk_compress -h (grok-jpeg2000 installed from AUR) did not complain any more: “error while loading shared libraries: libperl.so: cannot open shared object file: No such file or directory” but happily listed it’s options. (I didn’t use it quite for a while after I found opj_compress doing almost the same, but now decided to check back after a recent update was showing up in pamac.)
While searching I found a topic in an archlinux forum stating that you’re on your own when using AUR. Well - but I found several topics (e.g. “Urxvt won’t start …”) on various forums reporting almost all the same: After a certain perl package update several other packages which worked until then came up with that failure “libperl.so not found”. In the archlinux forum there continued a discussion about some version (dependency?) markings, that I dind not quite follow; sorry. Another advise was to re-build the package in question - that was what I just had done…
Anyway, to whom might I as a user address a complaint - if? I see two parts of the issue:
The core package perl does not install a link to libperl.so in /lib (-> /usr/lib).
The grok-jpeg2000 AUR script/package doesn’t even refer to perl as a dependency, and is obviously not aware of the path /usr/lib/perl5/5.40/core_perl/CORE/ where libperl.so is installed.
– To the AUR script builder?
– To the GROK maintainer?
– To the perl package maintainer?
If having a link to libperl.so in /lib is something deprecated, of course the GROK maintainer should be notified, but I’m not a developer, and I doubt that I can find that answer quickly.
When you see that error (typically is versioned like libXXX.so.XXX) for an open source program that you build yourself mean that you need to rebuild it (not reinstall the previous builded package)
The stance is much the same with Manjaro; the AUR is officially unsupported. For those who insist on using the AUR, regardless, it is generally suggested to switch to the Unstable branch, which is arguably the closest to Arch Stable.
Users may still offer advice on occasion, but technically (as with Arch) you’re on your own. Often the best source of help for a particular package is the AUR package maintainer themselves.
– I’m lost with this – I had told pamac to deinstall the package (after “build” failed), that step also removed the downloaded files and the temporary directories. Then I told it to install again, and if I not completely misunderstood the output on the display, the sources were downloaded, the package newly built and then installed. Then I got the same error.
(When once SimpleScreenRecorder refused to start, a rebuild from updated sources gave a different result.) Perhaps I’m the only one to try grok while there’s opj available.
– Did you mean by “you need to rebuild…” that I’d need to read and understand the source for understanding and fixing the issue?
This again puzzles me, I built(?) the AUR package that was updated last Friday, and the other comment tells me to switch to Manjaro-unstable for being nearer to Arch-stable, but my guess would be that 5.38 is older than 5.40 which is installed on my Manjaro-stable… Is Manjaro-stable ahead of Manjaro-unstable in regard of the “pearl” packet version?
That’s what I thought, but …
From all I read to this point the only solution would be to not install this AUR package (as I want to live rather with Manjaro-stable); maybe to set up a separate system with Manjaro-unstable for it (to see if it’s running on that one). – Or (while running/trying this one program) temporarily do something that I shouldn’t… (There’s this one libperl.so in my whole system.)
Maybe, just out of curiosity, I’ll try to set up an Arch installation between the holidays, if I find nothing else to relax.
Anyway, many many thanks for spending your time commenting on my question and explaining the cascaded dependency that was hidden to me.
There are a few things on AUR, that I wouldn’t like to miss - Free42, SSR, and a few packages went from repositories to AUR if I remember them right.
Since the manjaro perl is coming directly from arch, and aur is for arch, it is safe to say the problem is by the developer or the aur packager. Usually happens with packages for debian not at all tested on arch, that are then unofficially fixed to work with arch from some 3rd party volunteer. In this particular project it is not immediately clear from the github page if arch is officially supported, i mean if the developer of the project is also the packager of the AUR.
You can try clean rebuild with some aur helper like yay for example. If the problem persists - write the aur packager. I do not think in this particular case it matters if you are on stable or unstable. The whole path is wrong, not only the expected version.
The “other comment” was in response to only one of your many meandering questions - in this instance, regarding the AUR. No instruction was given for you to actually switch branches, or that doing so would help in finding a solution.
At that point it was unclear what the issue was; and it still is.
Quick tip: When you receive an error please provide both the command you used and the command output. This is potentially much more useful for those trying to help than giving your description of whatever you think might have happened.
$ grk_compress -h
grk_compress: error while loading shared libraries: libperl.so: cannot open shared object file: No such file or directory
That’s where I was at the beginning - placing a link to libperl.so in /lib would ‘fix’ that for the instant.
Were you able to check that in the source? If it’s a general issue, it might be important for the devolopers to know, but then - before reporting I might need to check on debian or ubuntu e.g. - and learn myself something about the version dependencies.
Yet the INSTALL.md on github explicitly lists the AUR package…
Actually I’m becoming unsure whether to bother the developer(s) before I come to the conclusion that I’ll wish to use rather grok-jpeg2000 for compressing images. The AUR packager indeed seems to be an independent volunteer, as the github page refers to a .com entity.
My original intention was to get better compression for PDFs from scanned paper in colour or greyscale (for b/w I’d use CCITT-Group-4-Fax), and I struggled to find a way for creating jpeg2000-images (high compression ratio, supported by PDF-A). Even gimp only imports it, but doesn’t offer export. Searching pamac GUI for “jpeg2000” just pops up grok-jpeg2000 alone.
Later I learned that I have openjpeg2 with opj_compress as a dependency of ffmpeg e.g. ($ apropos jpeg2000 - I’d never have guessed it’s already there after not showing up in pamac).
Now I got a notice from pamac that there’s a fresh update for grok-jpeg2000 from my old version 11 used long ago to 14 and wanted to run a comparison again between grok_ and opj_compress to see whether it’s worth to keep either for quality/compression ratio advantages. And stuck on the libperl.so issue. For this testing I have a workaround now, but as I absolutely agree with Lolix that there’s certainly a good reason for libperl.so to be not listed in /lib, I’ll need to follow up on fixing this situation - at least, if I come to continue using grok-jpeg2000. Otoh. judging from the options list it may appear that the focus of this project is rather on streaming than on still image quality. That’s why I’ll have to test. A little later… If the thread won’t be closed by then, I’ll report about my results and may ask again for support on properly reporting this perl version reference question.
First, I didn’t actually run the the program until very late yesterday night (after you said it took to long)
Another thing; the pkgbuild on AUR have a quite a number of flaws; like not actually using the indicated system’s depends, the maintainer have been informed
About libperl.so: cannot open shared object file: No such file or directory in this case isn’t a matter of rebuilding the package but effectively the program is looking for libperl.so in the wrong place
My updated grok-jpeg2000 pkgbuild can be found here, in the g folder
git clone https://github.com/FabioLolix/AURFIX
As temporary solution I have made a pkgbuild libperl-shim with the perl symlink so it packaged and can be easily removed (NB this will need to be updated for major perl version), located at
