gregcman/sucle

glfw is unfriendly to non-FHS complient systems (e.g. Nix, Guix)

Ambrevar opened this issue · 3 comments

Ambrevar commented

On Guix, trying to quickload sucle, I get this error:

Unable to load foreign library (LIBGLFW.SO.BODGED-586).
  Error opening shared object "/home/ambrevar/.quicklisp/dists/quicklisp/software/glfw-blob-stable-5af92db3-git/x86_64/libglfw.so.bodged":
  libX11.so.6: cannot open shared object file: No such file or directory.

Indeed:

> ldd libglfw.so.bodged 
ldd: warning: you do not have execution permission for `./libglfw.so.bodged'
	linux-vdso.so.1 (0x00007fff48701000)
	librt.so.1 => /gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/librt.so.1 (0x00007f05cd4d9000)
	libm.so.6 => /gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/libm.so.6 (0x00007f05cd358000)
	libdl.so.2 => /gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/libdl.so.2 (0x00007f05cd353000)
	libX11.so.6 => not found
	libpthread.so.0 => /gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/libpthread.so.0 (0x00007f05cd332000)
	libXrandr.so.2 => not found
	libXinerama.so.1 => not found
	libXxf86vm.so.1 => not found
	libXcursor.so.1 => not found
	libc.so.6 => /gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/libc.so.6 (0x00007f05cd177000)
	/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/ld-linux-x86-64.so.2 (0x00007f05cd705000)

This is because Guix (like Nix) does not follow the FHS and the libraries are stored in /gnu/store, with symlinks created to ~/.guix-profile/ if the user installs them.

I can hard-patch the libraries, but this is not ideal.
Any other way?

More generally, why do we need to rely on binary libraries here, why not glfw as provided by the system?

I'm also uncomfortable running a random untrusted binary distributed over the Internet, this is a huge security issue. What do you think?

gregcman commented

Sorry for the long wait.

There is no reason to rely on binary libraries here, it was just more convenient for me to include them.
Yes, this is security issue, but I think at this scale nobody would notice.

However, I updated it so that it

  1. First checks for a glfw3 provided by the system and if it exists loads it or
  2. Downloads a binary from quicklisp, here: https://github.com/borodust/glfw-blob.

This is the patch: 7faf5ab

So now if you have glfw3 installed, it won't try to download a binary.
This is still somewhat of a security issue. If https://github.com/borodust/ is malicious or has his account hacked and uploads malicious code to quicklisp, it could be dangerous. To prevent this, I could include the glfw3 binaries in the repository, but that would take up space.

I'm not sure what the solution to this is, do you know?

Ambrevar commented
gregcman commented

There's no particular reason, its just a lot easier. There are a lot of binaries distributed by borodust named *-blob, that are all available on quicklisp.