search

conda-forge / gstreamer-feedstock

A conda-smithy repository for gstreamer.
BSD 3-Clause "New" or "Revised" License
9 stars 28 forks source link

Namespace GstAudio not available #21

Closed duncanmmacleod closed 5 years ago

duncanmmacleod commented 5 years ago

Issue:

I can't load the GstAudio plugin:

$ python -c "import gi; gi.require_version('GstAudio', '1.0')"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/duncan.macleod/opt/miniconda3/envs/gsttest/lib/python3.6/site-packages/gi/__init__.py", line 130, in require_version
    raise ValueError('Namespace %s not available' % namespace)
ValueError: Namespace GstAudio not available

Is this supposed to be provided by the gst-plugins-base package?

If I compare the conda package to the (hopefully equivalent) gstreamer1-plugings-base RPM, I see that the conda packge doesn't provide lib/girepository-1.0/GstAudio-1.0.typelib. Is that the issue?

I know nothing about the gstreamer ecosystem, so I'm sorry if I'm talking nonsense here.


Environment (conda list):

``` $ conda list # packages in environment at /home/duncan.macleod/opt/miniconda3/envs/gsttest: # # Name Version Build Channel ca-certificates 2018.11.29 ha4d7672_0 conda-forge cairo 1.14.12 h80bd089_1005 conda-forge fontconfig 2.13.1 h2176d3f_1000 conda-forge freetype 2.9.1 h94bbf69_1005 conda-forge gettext 0.19.8.1 h9745a5d_1001 conda-forge glib 2.56.2 had28632_1001 conda-forge gobject-introspection 1.56.1 py36h9e29830_1001 conda-forge gst-plugins-base 1.12.5 h3865690_1000 conda-forge gstreamer 1.12.5 h0cc0488_1000 conda-forge icu 58.2 hf484d3e_1000 conda-forge libffi 3.2.1 hf484d3e_1005 conda-forge libgcc-ng 7.3.0 hdf63c60_0 conda-forge libiconv 1.15 h14c3975_1004 conda-forge libpng 1.6.36 h84994c4_1000 conda-forge libstdcxx-ng 7.3.0 hdf63c60_0 conda-forge libuuid 2.32.1 h14c3975_1000 conda-forge libxcb 1.13 h14c3975_1002 conda-forge libxml2 2.9.8 h143f9aa_1005 conda-forge ncurses 6.1 hf484d3e_1002 conda-forge openssl 1.0.2p h14c3975_1002 conda-forge pcre 8.41 hf484d3e_1003 conda-forge pixman 0.34.0 h14c3975_1003 conda-forge pthread-stubs 0.4 h14c3975_1001 conda-forge pycairo 1.18.0 py36h1b9232e_1000 conda-forge pygobject 3.28.3 py36h89f6ae1_1001 conda-forge python 3.6.7 hd21baee_1001 conda-forge readline 7.0 hf8c457e_1001 conda-forge sqlite 3.26.0 h67949de_1000 conda-forge tk 8.6.9 h84994c4_1000 conda-forge xorg-kbproto 1.0.7 h14c3975_1002 conda-forge xorg-libice 1.0.9 h14c3975_1004 conda-forge xorg-libsm 1.2.3 h4937e3b_1000 conda-forge xorg-libx11 1.6.6 h14c3975_1000 conda-forge xorg-libxau 1.0.8 h14c3975_1006 conda-forge xorg-libxdmcp 1.1.2 h14c3975_1007 conda-forge xorg-libxext 1.3.3 h14c3975_1004 conda-forge xorg-libxrender 0.9.10 h14c3975_1002 conda-forge xorg-renderproto 0.11.1 h14c3975_1002 conda-forge xorg-xextproto 7.3.0 h14c3975_1002 conda-forge xorg-xproto 7.0.31 h14c3975_1007 conda-forge xz 5.2.4 h14c3975_1001 conda-forge zlib 1.2.11 h14c3975_1004 conda-forge ```


Details about conda and system ( conda info ):

``` $ conda info active environment : gsttest active env location : /home/duncan.macleod/opt/miniconda3/envs/gsttest shell level : 1 user config file : /home/duncan.macleod/.condarc populated config files : /home/duncan.macleod/.condarc conda version : 4.5.12 conda-build version : 3.17.6+12.g4fc12f89 python version : 3.7.1.final.0 base environment : /home/duncan.macleod/opt/miniconda3 (writable) channel URLs : https://conda.anaconda.org/conda-forge/linux-64 https://conda.anaconda.org/conda-forge/noarch https://repo.anaconda.com/pkgs/main/linux-64 https://repo.anaconda.com/pkgs/main/noarch https://repo.anaconda.com/pkgs/free/linux-64 https://repo.anaconda.com/pkgs/free/noarch https://repo.anaconda.com/pkgs/r/linux-64 https://repo.anaconda.com/pkgs/r/noarch https://repo.anaconda.com/pkgs/pro/linux-64 https://repo.anaconda.com/pkgs/pro/noarch package cache : /home/duncan.macleod/opt/miniconda3/pkgs /home/duncan.macleod/.conda/pkgs envs directories : /home/duncan.macleod/opt/miniconda3/envs /home/duncan.macleod/.conda/envs platform : linux-64 user-agent : conda/4.5.12 requests/2.21.0 CPython/3.7.1 Linux/3.10.0-957.1.3.el7.x86_64 scientific/7.6 glibc/2.17 UID:GID : 5308:5308 netrc file : /home/duncan.macleod/.netrc offline mode : False ```
duncanmmacleod commented 5 years ago

I think I've tracked this down to gst-plugins-base not depending upon gobject-introspection, which implies --disable-introspection in the build.

However, if I add that dependency on linux, and set --enable-introspection, the build fails with 

/path/to/build/_build_env/bin/../lib/gcc/x86_64-conda_cos6-linux-gnu/7.3.0/../../../../x86_64-conda_cos6-linux-gnu/bin/ld: warning: libglapi.so.0, needed by /path/to/build/_build_env/bin/../x86_64-conda_cos6-linux-gnu/sysroot/usr/lib64/libGL.so.1, not found (try using -rpath or -rpath-link)

Is this library available in a CDT package, or similar?

mingwandroid commented 5 years ago

Hi @duncanmmacloed, please see https://github.com/conda/conda-build/blob/ea99e2dc2fa473039dbeb73d92b3f5d5c59548fe/tests/test-recipes/metadata/cdt_linking/meta.yaml

duncanmmacleod commented 5 years ago

@mingwandroid, thanks, I had already discovered that the necessary library seems to be in mesalib. I'll hopefully be able to post a PR to fix this issue soon.

mingwandroid commented 5 years ago

@duncanmmacleod, I have a concern that using mesalib will use software GL only while using the CDTs will definitely allow use of full hardware acceleration (since it will use the end-user's libGL). I have not had time to investigate whether this is definitely the case or not. Also, we should, as an ecosystem either use CDTs for libGL or else use mesa for libGL. If we have some packages using mesa and some using libGL these then the order of e.g. python imports would change which gets used and that's really not something we want.

If we can prove my concern about hardware acceleration is unfounded (it may well be!) then I don't mind if mesa is the 'blessed' way of linking to libGL, otherwise we should stick to CDTs, either way we should avoid mixing both at all costs.

duncanmmacleod commented 5 years ago

@mingwandroid, I think I understand - in the end I think I can get the missing library from the mesa-dri-drivers CDT, and don't have to use mesalib at all, I just jumped the gun and used the first package I found without really understanding the implications.

mingwandroid commented 5 years ago

No problem @duncanmmacleod, to be explicit about what happens here:

  1. Every DSO (dynamically shared object) contains a field called SONAME.
  2. Each running process will only load one DSO with a given SONAME, so whichever gets loaded first is the one that is used for everything.

This is why things like the Python recommendation to "always sort your imports because the order shouldn't matter" is technically incorrect as soon as any DSOs get loaded (even transitively!)