ldconfig produces erroneous links for liborc and liborc-test

[mbargull]

ldconfig does something funky with the libraries, creating links named '\' and $'\003'.
Interestingly enough, I couldn't reproduce that on my host OS but could -- albeit with the same glibc version -- in a fedora:31 container:

~ >>>  podman run --rm -it centos:6 sh -c 'cd /tmp && curl -sL https://anaconda.org/conda-forge/gstreamer-orc/0.4.31/download/linux-64/gstreamer-orc-0.4.31-h516909a_0.tar.bz2 | tar -xjf- lib/liborc-test-0.4.so.0.31.0 && ldconfig --version | head -n1 && ldconfig -vnN ./lib'
ldconfig (GNU libc) 2.12
./lib:
	\ -> liborc-test-0.4.so.0.31.0 (changed)
~ >>>  podman run --rm -it fedora:31 sh -c 'dnf -qy install bsdtar && cd /tmp && curl -sL https://anaconda.org/conda-forge/gstreamer-orc/0.4.31/download/linux-64/gstreamer-orc-0.4.31-h516909a_0.tar.bz2 | bsdtar -xf- lib/liborc-test-0.4.so.0.31.0 && ldconfig --version | head -n1 && ldconfig -vnN ./lib'
ldconfig (GNU libc) 2.30
./lib:
	\ -> liborc-test-0.4.so.0.31.0 (changed)
~ >>>  podman run --rm -it archlinux/base sh -c 'cd /tmp && curl -sL https://anaconda.org/conda-forge/gstreamer-orc/0.4.31/download/linux-64/gstreamer-orc-0.4.31-h516909a_0.tar.bz2 | bsdtar -xf- lib/liborc-test-0.4.so.0.31.0 && ldconfig --version | head -n1 && ldconfig -vnN ./lib'              
ldconfig (GNU libc) 2.30
./lib:
	liborc-test-0.4.so.0 -> liborc-test-0.4.so.0.31.0 (changed)

I have no idea what the cause of this is.

xref: conda-forge/libvips-feedstock#4 (comment)

[sebastian-luna-valero]

Thanks @mbargull

gstreamer-orc-0.4.29 was the first version used to create this feedstock. Then, with the release of gstreamer-orc-0.4.30, upstream changed the packaging from autotools to meson, and I had to reflect that in version 0.4.30 of the conda-forge package in #1

According to the packaging over at https://github.com/conda-forge/libvips-feedstock, which uses gstreamer-orc downstream, it looks like only gstreamer-orc-0.4.29 works properly.

I am aware that the information provided may add little to the troubleshooting of this problem but It don't know where to start. Did it help you in any sense?

[kleisauke]

Maybe this patch will fix this:

diff --git a/orc/meson.build b/orc/meson.build
index 1111111..2222222 100644
--- a/orc/meson.build
+++ b/orc/meson.build
@@ -109,7 +109,8 @@ orc_lib = library ('orc-' + orc_api,
   include_directories : orc_inc,
   c_args : orc_c_args + ['-DBUILDING_ORC'],
   dependencies : orc_dependencies,
-  install : true)
+  install : true,
+  install_rpath : join_paths(get_option('prefix'), get_option('libdir'))
 
 orc_dep_cargs = []
 if get_option('default_library') == 'static'

See: conda-forge/glib-feedstock#40 (comment) and https://github.com/conda-forge/glib-feedstock/blob/master/recipe/meson-rpaths.patch.

Note that the libdir argument within recipe/build.sh should probably be set to lib instead of ${PREFIX}/lib.

/cc @sebastian-luna-valero.

[sebastian-luna-valero]

Many thanks @kleisauke

@mbargull please let us know your thoughts.

[kleisauke]

fwiw, libvips' orc version should be pinned to gstreamer-orc >=0.4.31,<0.4.30 (if the above patch works) since it cannot be compiled with orc v0.4.30. See: libvips/libvips#1426.

[mbargull]

Sounds good. Thank you both for giving context on the causes and providing the patch!
I'll open a PR.

[mbargull]

So, I'm no expert on Meson or GStreamer, so help me out on this:

1. Does it make sense to upstream this patch?
2. Is it likely that we encounter this problem on more feedstocks? If yes, can we come up with a reasonable, alternative way to achieve the same whilst avoiding the need to add patch files then?

[mbargull]

Did someone try to could come up with a MWE for mesonbuild/meson#4685 ? Minimal in the sense that it does not depend on conda-forge's build setup/conda-build.
It would be nice to have be able to show the Meson devs how the rpaths (whichldconfig/chrpath can't handle well) get created.

[sebastian-luna-valero]

Thanks @mbargull

I agree. For the time being I have opened an issue on gstreamer-orc repo to discuss it:
https://gitlab.freedesktop.org/gstreamer/orc/issues/28

[kleisauke]

An alternative way is to patch the meson-feedstock. See for example this patch:
https://gitlab.com/buildroot.org/buildroot/blob/master/package/meson/0001-Only-fix-RPATH-if-install_rpath-is-not-empty.patch

(I've added a comment here to discuss this)