Cannot install and run JabRef portable, what do I need to do?

Hi All,
I downloaded JabRef version 5.4 from its tarball, from here:
https://builds.jabref.org/main/JabRef-5.4-portable_linux.tar.gz
This is a portable version, according to JabRef developers, all I have to do is to something like
tar -zxf JabRef-5.4-portable_linux.tar.gz and then
cd JabRef then do
bin/JabRef
and it would run a GUI version of JabRef.

When I did this with JabRef in NixOs, it did not work, the error was “bin/JabRef” does not exist.
If I did, cd bin; JabRef, NixOs would return, the command JabRef does not exist.
I did ldd JabRef no libraries were missing.
I obviously did something wrong and failed at this.
After this, I tried downloading the JabRef 5.4 debian binary with
wget <url of debian binary of JabRef-5.4xxx from
https://builds.jabref.org/main/jabref_5.4-1_amd64.deb
then,
opt/jabref/bin/JabRef
did not work.
I tried
patchelf --print-needed JabRef
It listed the libraries, nothing was missing at that point.
I tried
patchelf --set-interpreter "$(cat $NIX_CC/nix-support/dynamic-links)" JabRef
Nothing seems to work. Yet I can see a JabRef 5.1 version in the nix packages repo.

What can I do to correctly install JabRef 5.4 version?

1 Like

Could you run patchelf --print-interpreter and show the output? I realize you used patchelf already, but Linux reporting it doesn’t find a file on a binary that clearly exists means missing libraries.

Also share the output of ldd on the file, just so we know what you’re dealing with :slight_smile:

On an unrelated note, any reason you’re not using the NixOS package: jabref?

Thanks @TLATER . Here are the outputs:
patchelf --print-interpreter JabRef on ~/Downloads/JabRef/bin produces
/lib64/ld-linux-x86-64.so.2
ldd JabRef on ~/Downloads/JabRef/bin produces
linux-vdso.so.1 (0x00007ffe78d67000)
libdl.so.2 => /nix/store/2zchy9mdx3kk166i98cx5sriq2c1bdsn-glibc-2.33-55/lib/libdl.so.2 (0x00007f99e0644000)
libm.so.6 => /nix/store/2zchy9mdx3kk166i98cx5sriq2c1bdsn-glibc-2.33-55/lib/libm.so.6 (0x00007f99e0503000)
libc.so.6 => /nix/store/2zchy9mdx3kk166i98cx5sriq2c1bdsn-glibc-2.33-55/lib/libc.so.6 (0x00007f99e033e000)
/lib64/ld-linux-x86-64.so.2 => /nix/store/2zchy9mdx3kk166i98cx5sriq2c1bdsn-glibc-2.33-55/lib64/ld-linux-x86-64.so.2 (0x00007f99e0965000)

Why I am not using JabRef 5.1 is because JabRef itself is still quite buggy and they release fixes and patches every now and then. It is better to use their latest development build rather than the one that is dispatched with NixOs. I thought it’d be not too much of a hassle to use JabRef with NixOs since the whole idea is so intuitive, but NixOs is turning into a nightmare, if I have to go through the documentation page for every single app, this is not workable, when will I do work if I have to tinker with this thing?
Even though I have a sense that once I get the hang of it by reading the manuals and nix package management and pills, I will probably get a working knowledge to work with it, and so far this is perhaps the best solution to a reproducible data analysis set up, it is VERY frustrating if for every single thing, I will have to wade through the documentation and then everything fails!

Oh well!

/Arin

Your interpreter has clearly not changed. It still points to /lib64/ld-linux-x86-64.so.2, which doesn’t exist on NixOS (and is the core of the incompatibility problem). Probably a mistake with your patchelf invocation, did you read the “Starting Point” section and have stdenv.cc in your environment?

Having that path on your distro is inherently impure, since it introduces an un-versioned dependency into all your binaries, which is at the very core of what NixOS tries to avoid.

You’ll run into this a lot if you expect random binaries to just work™, unfortunately. Nix by definition clashes a bit with inconsiderate upstreams, it is just different from Ubuntu 16.04 and explicitly doesn’t try to support binaries built exclusively for it. While I understand the frustration, there isn’t really a way to change this without giving up the ideology behind NixOS, at least not until more projects provide nix flakes. It’s best to stick with pre-built nix packages where possible.

But hey, I know very well that that’s not easy. So let me cover your options:


The “correct” way of doing this would be to override the version of the package, by doing something like this:

jabrev_master = pkgs.jabrev.overrideAttrs(old: rec {
    version = "5.4";
    src = fetchurl {
         url = "https://github.com/JabRef/jabref/releases/download/v${version}/JabRef-${version}-portable_linux.tar.gz";
         sha256 = ""; # Update after nix complains and tells you the sha
    };
});

You should be able to add that snippet in a let block, and replace your jabrev with jabrev_master wherever you would otherwise install it. That said, this only works for upstreams whose build processes aren’t too complex and don’t change too much.

If it is more complex than that, you’ll need to look at how the package works, and fix the build instructions, at which point you might as well upstream your update. And then you’ll contribute to NixOS, and hopefully make it easier to use the things you care about for everybody else :slight_smile:


The second option is an “fhsUserEnv”, which is a bit like a sandbox or a container in your NixOS system. This blog post does it more justice than I can.

I’d call this the best option for getting a package running the quick and dirty way, but integration with your real system can be a bit limited.


patchelf. The really quick-and-dirty option. Clearly you’ve already tried this, it can be tricky to use.


Package with the autoPatchElfHook. A combination of the “proper” option and the one above.

This is more foolproof than patchelf, and it keeps your environment reproducible. It does mean you need to learn to write a package and not be too lazy to do so, though, which can be a tall order. It also doesn’t always work, particularly for naughty upstreams that insist on only working on a decade old Ubuntu version…


If all else fails, there’s always the nuclear option. Personally, I run into this problem rarely enough I haven’t even bothered to learn to use the fhsUserEnv, so for naughty upstreams where I need to mess with versions and custom builds (e.g. Bazel), I typically throw them in a ubuntu 16.04 VM, because it’s almost impossible to make them run anywhere else anyway.

You likely have your favorite VM software already, but personally I’ve found this a lot more viable since discovering GNOME Boxes, which makes this kind of thing extremely trivial.

1 Like

Thank you for your excellent response @TLATER ;
Unfortunately, when I tried the pkg.overrideAttr {} method, while Nix downloaded and compiled the binary from the tar.gz file, when I tried to run it, JRE returned a fatal error, and this programme did not run. I am back to Jabref version 5.1 from nixos pkg repository but from your post and through the two days of research, learned a lot of valuable lessons, so thank you once again!
I tried to download the default.nix from nixpkgs github repository but this did not work either.
JabRef’s site asks for using gradle and ./gradlew for building it.
I could not figure out how to use gradle with nix, :slight_smile:

Got to go back to the drawing board and start reading over.

Thanks again,
Arin

Ah, yes, gradle-based stuff is extremely difficult to package. I wish people wouldn’t use that build system because it’s awful. I’d even wager jabref hasn’t been updated since 5.1 because it switched to gradle as a build system.

It assumes that you always want to download your dependencies un-vetted from the internet, and dumps them into a directory with no manifest or “lockfile” to explain what the dump means. Somehow, during the build, it modifies the paths to be different from ones it stored it in. If you want to, you can install a maven repository to supply dependencies, but its structure is different.

There is no way to really predict what gradle will need. As a result, the best way to package this is to create a fixed-output derivation with the dependencies it downloads, but you need to mangle the paths to match a maven repo. This is horrible because it means you’re vendoring your dependencies and it’s super complicated.

There are a few packages in nixpkgs that have managed to tame builds with gradle, you can search around there to find some pointers. See for example nixpkgs/default.nix at a0dbe47318bbab7559ffbfa7c4872a517833409f · NixOS/nixpkgs · GitHub.

1 Like