Bug 130418 – [GStreamer] FindGStreamer.cmake should also look for libraries in ${PC_${_component_prefix}_LIBDIR}/.libs

• Component: New Bugs
• Status: RESOLVED WONTFIX

[Brendan Long]

[GStreamer] FindGStreamer.cmake should also look for libraries in ${PC_${_component_prefix}_LIBDIR}/.libs

[Brendan Long]

Created attachment 227098 [details]
Patch

[Raphael Kubo da Costa (:rakuco)]

Comment on attachment 227098 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=227098&action=review

> ChangeLog:8
> +        When building GStreamer from git, it uses libtool, which creates libgstwhatever.la,
> +        but the real library goes in .libs/libgstwhatever.so. Another approach
> +        would be to compile with libtool, but that's much more involved.

This doesn't look like a very good reason to do this: why should this be done only to GStreamer and not any other dependency that is built with libtool? Why not just install your GStreamer copy somewhere and deal with it normally? This approach seems like a weird workaround for a very specific situation to me.

[Brendan Long]

(In reply to comment #2)
> This doesn't look like a very good reason to do this: why should this be done only to GStreamer and not any other dependency that is built with libtool? Why not just install your GStreamer copy somewhere and deal with it normally? This approach seems like a weird workaround for a very specific situation to me.

Because this is how GStreamer is meant to be used:

http://gstreamer.freedesktop.org/data/doc/gstreamer/head/faq/html/chapter-developing.html#idp55212752

I doubt many people will need to use this, but it's a trivial change that makes working with git checkouts of GStreamer significantly easier.

[Raphael Kubo da Costa (:rakuco)]

(In reply to comment #3)
> (In reply to comment #2)
> > This doesn't look like a very good reason to do this: why should this be done only to GStreamer and not any other dependency that is built with libtool? Why not just install your GStreamer copy somewhere and deal with it normally? This approach seems like a weird workaround for a very specific situation to me.
> 
> Because this is how GStreamer is meant to be used:
> 
> http://gstreamer.freedesktop.org/data/doc/gstreamer/head/faq/html/chapter-developing.html#idp55212752

I fail to see anything GStreamer-specific in this link, the content there applies to any libtool project -- it's all about changing environment variables.

> I doubt many people will need to use this, but it's a trivial change that makes working with git checkouts of GStreamer significantly easier.

My concern with this approach is that it's basically an undocumented hack for a very specific use case.

If you have already modified your other environment variables (PKG_CONFIG_PATH, for example, since you are relying on its output in the patch), wouldn't it work if you also just changed CMAKE_LIBRARY_PATH locally?

[Brendan Long]

(In reply to comment #4)
> If you have already modified your other environment variables (PKG_CONFIG_PATH, for example, since you are relying on its output in the patch), wouldn't it work if you also just changed CMAKE_LIBRARY_PATH locally?

The whole point of gst-git is that it sets up PKG_CONFIG_PATH automatically. Hard-coding every library directory is a much bigger hack than just looking in the libtool .libs directory. And there are hundreds of them, which change every time a new plugin is added to GStreamer..

[Brendan Long]

I also find it frustrating that it worked until we switched to CMake..

[Brendan Long]

(In reply to comment #4)
> My concern with this approach is that it's basically an undocumented hack for a very specific use case.

I could also document this with a comment that we're looking in .libs because GStreamer's git checkouts automatically use libtool, which puts libraries in .libs.

[Brendan Long]

philn, do you use a git checkout of GStreamer? If so, how do you handle building against it in WebKit?

[Raphael Kubo da Costa (:rakuco)]

(In reply to comment #5)
> (In reply to comment #4)
> > If you have already modified your other environment variables (PKG_CONFIG_PATH, for example, since you are relying on its output in the patch), wouldn't it work if you also just changed CMAKE_LIBRARY_PATH locally?
> 
> The whole point of gst-git is that it sets up PKG_CONFIG_PATH automatically. Hard-coding every library directory is a much bigger hack than just looking in the libtool .libs directory. And there are hundreds of them, which change every time a new plugin is added to GStreamer..

Doesn't `gst-git && export CMAKE_LIBRARY_PATH=${LD_LIBRARY_PATH}' work?

Additionally, if you just build GStreamer with ./autogen.sh won't the .pc files have "prefix=/usr/local" and thus the current patch will tell CMake to look at /usr/local/lib/.libs?

[Philippe Normand]

(In reply to comment #8)
> philn, do you use a git checkout of GStreamer? If so, how do you handle building against it in WebKit?

I usually rely on the version we have in jhbuild, which I make point to trunk whenever needed.

[Brendan Long]

Sorry, I didn't get emailed about the responses on here for some reason. I'll look into just using the jhbuild to do what I need (and hopefully GStreamer will fix this eventually).