rpath setup doesn't take user-specified LIBDIR path into account

[rathann]

The rpath set-up code in CMakeLists:81 doesn't account for setting CMAKE_INSTALL_LIBDIR and the built binaries cannot find libbinaryen.so:

asm2wasm: error while loading shared libraries: libbinaryen.so: cannot open shared object file: No such file or directory

rpath is always set to $ORIGIN/../lib, regardless of the user-specified install location. Is libbinaryen.so supposed to be installed system-wide for other software to consume or is it an internal implementation detail? If the former, then it should have a proper SONAME and care should be taken to avoid making incompatible ABI changes without bumping SONAME. If the latter, then it should not be installed into /usr/lib or /usr/lib64 by default.

[rathann]

Similar issue with check.py:307. If you try to use binaries installed to a temporary directory (--binaryen-bin /tmp/foo/usr/bin) for running tests, it'll fail trying to find libbinaryen.so in /tmp/foo/usr/lib.

[rathann]

Would adding a new --binaryen-lib option to scripts/test/shared.py and using it in check.py be an acceptable fix?

[kripken]

@sbc100 this might be something you know about? (I don't...)

[sbc100]

Just to be clear you are specifying a custom CMAKE_INSTALL_LIBDIR to install libraries into.. but that path is not part of the default library search path?

How do other application that you build in this way find their own libraries?

What are you specifying for CMAKE_INSTALL_LIBDIR?

My understanding was the that RPATH hack is mostly about local testing where we don't want to installing into a system location (or use sudo at all).

To answer the broader question: "should libbinaryen.so be installed into a system-wide location". I don't think we have put enough thought into that to be able to answer it right now. Probably worth opening a separate issue for that. We only recently added the shared library so this is all relatively new. I guess the distro packagers should be involved in that decision is possible.

[sbc100]

Actually the RPATH hack is needed in emsdk I think .. which can be unzipped into any location and expected to work with relative .. where libraries are always install in ../lib relative to the binaries.

[rathann]

Just to be clear you are specifying a custom CMAKE_INSTALL_LIBDIR to install libraries into.. but that path is not part of the default library search path?

Correct. libbinaryen.so is an unversioned internal shared library not meant for system-wide usage (unless I'm mistaken), so it must not be installed in the default library search path (i.e. system-wide) according to Fedora Packaging Guidelines.

How do other application that you build in this way find their own libraries?

They are installed in private directories and RPATH is configured accordingly.

What are you specifying for CMAKE_INSTALL_LIBDIR?

-DCMAKE_INSTALL_LIBDIR=/usr/lib64/binaryen \

My understanding was the that RPATH hack is mostly about local testing where we don't want to installing into a system location (or use sudo at all).

The other use case is private shared libraries that we don't want exposed system-wide. I.e. exactly this issue, if I understand things correctly.

To answer the broader question: "should libbinaryen.so be installed into a system-wide location". I don't think we have put enough thought into that to be able to answer it right now. Probably worth opening a separate issue for that. We only recently added the shared library so this is all relatively new. I guess the distro packagers should be involved in that decision is possible.

Well, I'm attempting to package binaryen for Fedora. Our Guidelines say what I mentioned above.

[sbc100]

Thanks for the responses. That makes a lot of sense. I think are correct then that we should set the RPATH dynamically somehow.

It would still be for testing purposes there was still an option for the rpath to be relative to the executables. Perhaps we can find a way to do that.