#> gst-transcoder-1.0 gst-transcoder-1.0: error while loading shared libraries: libgsttranscoder-1.0.so.0: cannot open shared object file: No such file or directory #> equery files media-plugins/gst-transcoder * Searching for gst-transcoder in media-plugins ... * Contents of media-plugins/gst-transcoder-1.8.1: /usr /usr/bin /usr/bin/gst-transcoder-1.0 /usr/include /usr/include/gstreamer-1.0 /usr/include/gstreamer-1.0/gst /usr/include/gstreamer-1.0/gst/transcoder /usr/include/gstreamer-1.0/gst/transcoder/gsttranscoder.h /usr/lib /usr/lib/girepository-1.0 /usr/lib/girepository-1.0/GstTranscoder-1.0.typelib /usr/lib/x86_64-linux-gnu /usr/lib/x86_64-linux-gnu/gstreamer-1.0 /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgsttranscoderplugin.so /usr/lib/x86_64-linux-gnu/libgsttranscoder-1.0.so -> libgsttranscoder-1.0.so.0 /usr/lib/x86_64-linux-gnu/libgsttranscoder-1.0.so.0 /usr/lib/x86_64-linux-gnu/pkgconfig /usr/lib/x86_64-linux-gnu/pkgconfig/gst-transcoder-1.0.pc /usr/share /usr/share/gir-1.0 /usr/share/gir-1.0/GstTranscoder-1.0.gir #> ln -s /usr/lib/x86_64-linux-gnu/libgsttranscoder-1.0.so.0 /usr/lib64/libgsttranscoder-1.0.so.0 #> gst-transcoder-1.0 Usage: gst-play [OPTION...] <source uri> <destination uri> <encoding target name>[/<encoding profile name>] Help Options: -h, --help Show help options --help-all Show all help options --help-gst Show GStreamer Options Application Options: -c, --cpu-usage The CPU usage to target in the transcoding process Reproducible: Always
I cannot reproduce this: # equery files gst-transcoder * Searching for gst-transcoder ... * Contents of media-plugins/gst-transcoder-1.8.1: /usr /usr/bin /usr/bin/gst-transcoder-1.0 /usr/include /usr/include/gstreamer-1.0 /usr/include/gstreamer-1.0/gst /usr/include/gstreamer-1.0/gst/transcoder /usr/include/gstreamer-1.0/gst/transcoder/gsttranscoder.h /usr/lib /usr/lib/girepository-1.0 /usr/lib/girepository-1.0/GstTranscoder-1.0.typelib /usr/lib64 /usr/lib64/gstreamer-1.0 /usr/lib64/gstreamer-1.0/libgsttranscoderplugin.so /usr/lib64/libgsttranscoder-1.0.so -> libgsttranscoder-1.0.so.0 /usr/lib64/libgsttranscoder-1.0.so.0 /usr/lib64/pkgconfig /usr/lib64/pkgconfig/gst-transcoder-1.0.pc /usr/share /usr/share/gir-1.0 /usr/share/gir-1.0/GstTranscoder-1.0.gir Please provide emerge --info gst-transcoder and the full build.log
Created attachment 443728 [details] emerge info
Created attachment 443730 [details] build log
Cannot reproduce this either with 1.8.2. Could you give a shot at this revision ?
The latest ebuild just fails completely for me. 'g-ir-scanner' '../gst-libs/gst/transcoding/transcoder/gsttranscoder.h' '../gst-libs/gst/transcoding/transcoder/gsttranscoder.c' '-pthread' '-I/usr/include/gobject-introspection-1.0' '-I/usr/lib64/libffi-3.2.1/include' '-I/usr/include/glib-2.0' '-I/usr/lib64/glib-2.0/include' '--no-libtool' '--namespace=GstTranscoder' '--nsversion=1.0' '--warn-all' '--output' 'GstTranscoder-1.0.gir' '--add-init-section=extern gboolean gst_init(gint *argc, gchar **argv); gst_init(NULL,NULL);' '--include=GObject-2.0' '--include=Gst-1.0' '--include=GstPbutils-1.0' '--symbol-prefix=gst_' '--identifier-prefix=Gst' '--add-include-path=/usr/share/gir-1.0' '-L/var/tmp/portage/media-plugins/gst-transcoder-1.8.2/work/gst-transcoder-1.8.2/mesonbuild/.' '--library' 'gsttranscoder-1.0' /usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/../../../../x86_64-pc-linux-gnu/bin/ld: tmp-introspectZhvvww/var/tmp/portage/media-plugins/gst-transcoder-1.8.2/work/gst-transcoder-1.8.2/mesonbuild/tmp-introspectZhvvww/GstTranscoder-1.0.o: undefined reference to symbol 'gst_init' /usr/lib64/libgstreamer-1.0.so.0: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status Traceback (most recent call last): File "/usr/bin/g-ir-scanner", line 66, in <module> sys.exit(scanner_main(sys.argv)) File "/usr/lib64/gobject-introspection/giscanner/scannermain.py", line 544, in scanner_main shlibs = create_binary(transformer, options, args) File "/usr/lib64/gobject-introspection/giscanner/scannermain.py", line 419, in create_binary gdump_parser.get_error_quark_functions()) File "/usr/lib64/gobject-introspection/giscanner/dumper.py", line 328, in compile_introspection_binary return dc.run() File "/usr/lib64/gobject-introspection/giscanner/dumper.py", line 174, in run self._link(bin_path, introspection_obj) File "/usr/lib64/gobject-introspection/giscanner/dumper.py", line 296, in _link raise LinkError(e) distutils.errors.LinkError: command 'x86_64-pc-linux-gnu-gcc' failed with exit status 1
After manually fixing the build.ninja file to add the missing '-lgstreamer-1.0' the files are still being installed to /usr/lib/x86_64-linux-gnu
This looks like bug #594172. I hate new build systems.
This looks like it's a result of the way src_configure is written for meson builds. I don't know where meson-0.33.0 gets the default directories, but at least the LIBDIR tends to get resolved as /usr/lib/x86_64-linux-gnu with me as well even though the build type is native. Could it be because of the cross compilation support I have here? Anyway, simply adding the libdir into the ebuild seems to fix it: diff --git a/gst-transcoder-1.8.2.ebuild b/gst-transcoder-1.8.2-r1.ebuild index dee0c8b..98784e0 100644 --- a/gst-transcoder-1.8.2.ebuild +++ b/gst-transcoder-1.8.2-r1.ebuild @@ -32,7 +32,7 @@ src_configure() { # Not a normal configure # --buildtype=plain needed for honoring CFLAGS/CXXFLAGS and not # defaulting to debug - ./configure --prefix=/usr --buildtype=plain || die + ./configure --prefix=/usr --libdir="$(get_libdir)" --buildtype=plain || die } src_compile() { This is enough for the configure in e.g. bug 597414 to find the installed pkgconfig file and use the installed gst-transcoder-1.0 instead of the bundled copy. Of course the pitivi ebuild in that bug would itself need the same change to install in the correct place too.
Please retry with latest meson version
Created attachment 450710 [details] emerge --info dev-util/meson (In reply to Pacho Ramos from comment #9) > Please retry with latest meson version This doesn't seem to change with dev-util/meson-0.35.0 : # ebuild media-plugins/gst-transcoder/gst-transcoder-1.8.2.ebuild configure * gst-transcoder-1.8.2.tar.gz SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ] >>> Unpacking source... >>> Unpacking gst-transcoder-1.8.2.tar.gz to /var/tmp/portage/media-plugins/gst-transcoder-1.8.2/work >>> Source unpacked in /var/tmp/portage/media-plugins/gst-transcoder-1.8.2/work >>> Preparing source in /var/tmp/portage/media-plugins/gst-transcoder-1.8.2/work/gst-transcoder-1.8.2 ... >>> Source prepared. >>> Configuring source in /var/tmp/portage/media-plugins/gst-transcoder-1.8.2/work/gst-transcoder-1.8.2 ... The Meson build system Version: 0.35.0 Source dir: /var/tmp/portage/media-plugins/gst-transcoder-1.8.2/work/gst-transcoder-1.8.2 Build dir: /var/tmp/portage/media-plugins/gst-transcoder-1.8.2/work/gst-transcoder-1.8.2/mesonbuild Build type: native build Project name: gst-renderer Native c compiler: ccache cc (gcc 4.9.3) Appending CFLAGS from environment: '-march=amdfam10 -O2 -pipe' Appending LDFLAGS from environment: '-Wl,-O1 -Wl,--as-needed' Build machine cpu family: x86_64 Build machine cpu: x86_64 Checking for function "getrusage": YES Found pkg-config: /usr/bin/pkg-config (0.29.1) Native dependency gobject-2.0 found: YES 2.48.2 Native dependency glib-2.0 found: YES 2.48.2 Native dependency gstreamer-1.0 found: YES 1.8.3 Native dependency gstreamer-pbutils-1.0 found: YES 1.8.3 Build targets in project: 5 >>> Source configured. # (cd /var/tmp/portage/media-plugins/gst-transcoder-1.8.2/work/gst-transcoder-1.8.2/mesonbuild; grep -rn LIBDIR .) ./config.h:38:#define LIBDIR "/usr/lib/x86_64-linux-gnu" ./common/meson/config.h:38:#define LIBDIR "/usr/lib/x86_64-linux-gnu"
After reading the meson sources, it's clear that this happens when app-arch/dpkg is installed. Meson uses /usr/bin/dpkg-architecture to construct the default libdir value if that executable exists. Since there are only two ebuilds that use meson in the tree at the moment and both already override the default prefix, is there a reason not to also override the default libdir?
Please report this issue to upstream and paste here the link to let us track the issue: https://github.com/mesonbuild/meson/issues
(In reply to Pacho Ramos from comment #12) Reported with a suggested fix as upstream prefers pull requests: https://github.com/mesonbuild/meson/pull/940 Setting libdir in the ebuild will still be necessary once the plugin goes multilib.
There is no intent to add multilib support if there is no application requesting it which is hopefully not going to happen.
(In reply to Gilles Dartiguelongue from comment #14) But it still stable and broken for anyone with app-arch/dpkg installed. My suggestion for the fix is in PR 2624, because it will be months before the upstream fix that will appear in >dev-util/meson-0.35.1 is in tree and stable.
I presume this is obsolete with the PR being pushed and especially stable meson in-tree at 0.40.1.
