After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 397899 - gstreamer/gst-plugins build broken; gstreamer installs to wrong location and gst-plugins can't find it
gstreamer/gst-plugins build broken; gstreamer installs to wrong location and ...
Status: RESOLVED DUPLICATE of bug 344112
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal blocker
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2007-01-18 05:35 UTC by Elijah Newren
Modified: 2007-01-18 18:22 UTC
See Also:
GNOME target: ---
GNOME version: 2.17/2.18



Description Elijah Newren 2007-01-18 05:35:51 UTC
When I get to gst-plugins in jhbuild, I get the error:

checking for GST... no
configure: Package gstreamer-0.10 was not found in the pkg-config search path.
Perhaps you should add the directory containing `gstreamer-0.10.pc'
to the PKG_CONFIG_PATH environment variable
No package 'gstreamer-0.10' found
configure: error: no gstreamer-0.10 >= 0.10.11.1 (GStreamer) found
  configure failed

Apparently this is caused by the fact that gstreamer installs to /opt/gnome2/lib instead of the correct path of /opt/gnome2/lib64.  Even if you argue that gstreamer always builds 32 bit binaries or something and thus should be in $prefix/lib, why can't gst-plugins find what is installed by gstreamer?

I think this is just bug 307352 returning, but I'm kind of new to this whole x86_64 thing.
Comment 1 Elijah Newren 2007-01-18 05:38:34 UTC
This does indeed look like bug 307352 returning; a simple rerun of jhbuild buildone -a gstreamer shows:

*** Configuring gstreamer *** [1/1]

./autogen.sh --prefix /opt/gnome2 --libdir '${exec_prefix}/lib64' -- --disable-tests --disable-static --disable-gtk-doc
DEBUG: /opt/gnome2
+ passing --prefix=/opt/gnome2 to configure
- ignoring unknown autogen.sh argument --libdir
- ignoring unknown autogen.sh argument ${exec_prefix}/lib64
+ options passed to configure:  --prefix=/opt/gnome2 --disable-tests --disable-static --disable-gtk-doc

Comment 2 Tim-Philipp Müller 2007-01-18 11:05:09 UTC
We didn't change anything in this respect recently AFAIK (also see bug #344112), must have been a change in jhbuild.

I suggest fixing it / working around it in jhbuild for the time being.
Comment 3 Elijah Newren 2007-01-18 16:18:16 UTC
Tim: Even if you ignore the issue about --libdir and how it should be passed or not (punting the issue as a jhbuild problem), there's an additional problem here in that gst-plugins cannot find stuff which gstreamer installs, even when both builds occur with the same environment.  You've got a bug either way, as far as I can tell.  ;-)
Comment 4 Tim-Philipp Müller 2007-01-18 17:59:44 UTC
FWIW, my suggestion was based on the fact that Thomas has strong opinions on this subject and is in Australia at the moment, I don't really care either way ;)


> ..., there's an additional problem here in that gst-plugins
> cannot find stuff which gstreamer installs, even when both
> builds occur with the same environment.  You've got a bug
> either way, as far as I can tell.  ;-)

Maybe I'm not understanding the problem correctly, but

(a) isn't it jhbuild that sets the PKG_CONFIG_PATH variable based on what it passed as --libdir, assuming that that's really the libdir that is going to be used/was used?

(b) doesn't the gst-plugins configure look for gstreamer-0.10.pc based on PKG_CONFIG_PATH and not based on whatever gets passed or assumed as libdir?

I thought the problem was this:
 - gstreamer (core) installs gstreamer-0.10.pc into $prefix/lib/pkgconfig
 - jhbuild adds $libdir ($prefix/lib64/pkgconfig) to PKG_CONFIG_PATH
 - gst-plugins* looks for gstreamer-0.10.pc in $libdir/pkgconfig/ != $prefix/lib/pkgconfig/

So 
 - where does the gstreamer-0.10.pc file actually get installed to?
 - what is the content of the PKG_CONFIG_PATH variable?

Another question: Isn't gst-plugins the GStreamer-0.8 plugins module? Why does that check for GStreamer-0.10? Or is this gst-plugins-base?
Comment 5 Elijah Newren 2007-01-18 18:22:59 UTC
(In reply to comment #4)
> Maybe I'm not understanding the problem correctly, but

Actually, it looks like I was.

> (a) isn't it jhbuild that sets the PKG_CONFIG_PATH variable based on what it
> passed as --libdir, assuming that that's really the libdir that is going to be
> used/was used?

I just checked; yes that is correct.  jhbuild/jhbuild/config.py does that.

> (b) doesn't the gst-plugins configure look for gstreamer-0.10.pc based on
> PKG_CONFIG_PATH and not based on whatever gets passed or assumed as libdir?
> 
> I thought the problem was this:
>  - gstreamer (core) installs gstreamer-0.10.pc into $prefix/lib/pkgconfig
>  - jhbuild adds $libdir ($prefix/lib64/pkgconfig) to PKG_CONFIG_PATH
>  - gst-plugins* looks for gstreamer-0.10.pc in $libdir/pkgconfig/ !=
> $prefix/lib/pkgconfig/

Yes, it looks like that is correct.

> Another question: Isn't gst-plugins the GStreamer-0.8 plugins module? Why does
> that check for GStreamer-0.10? Or is this gst-plugins-base?

Sorry, I meant gst-plugins-base.  So, not only did you foil my attempts to try to pin something to you guys, you've also exposed some mistakes of mine.  Looks like this bug is best marked as a dupe of the one filed by JP that you pointed out. 



*** This bug has been marked as a duplicate of 344112 ***