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 132045 - incorrect dependency causes rebuilding of libgstreamer on "make install"
incorrect dependency causes rebuilding of libgstreamer on "make install"
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
0.7.3
Other Linux
: High trivial
: 0.7.5
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2004-01-20 23:38 UTC by Mikhail Zabaluev
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Fix dependencies and build order in gst/parse/ (927 bytes, patch)
2004-01-23 00:01 UTC, Mikhail Zabaluev
none Details | Review

Description Mikhail Zabaluev 2004-01-20 23:38:26 UTC
When I build an rpm for GStreamer, I do the usual
"./configure ...; make; make install" routine as suggested elsewhere.
However, on "make install" I see that a part of the build tree, including
libgstreamer-0.7.la, gets rebuilt. This can be nasty, because a typical
"run make install" rpm macro in many distributions relocates $(libdir) and
other makefile variables to a temporary install root. As the result, the
rebuilt libstreamer-0.7.la gets this bogus libdir setting written into it,
and, by the time a dependant libgstcontrol shared library is installed, it
gets relinked with a bogus rpath. A pedantic packaging verify script frowns
at such things.

The cause of the problem was tracked down to the following rule in
'gst/parse/Makefile.am':

lex._gst_parse_yy.c: parse.l grammar.tab.h
        $(FLEX_PATH) -P_gst_parse_yy $^

'grammar.tab.h' is rebuilt by a bison invocation _after_ the first flex
invocation at the "make" stage, making the target stale. In fact, this
header file doesn't affect the flex's output and should never be made a
dependency in this rule in the first place.
Comment 1 Mikhail Zabaluev 2004-01-23 00:01:57 UTC
Created attachment 23655 [details] [review]
Fix dependencies and build order in gst/parse/
Comment 2 Mikhail Zabaluev 2004-01-23 00:08:15 UTC
The attachment mentioned above corrects a few more rules and
uncomments the BUILT_SOURCES listing. I don't know or care much about
how BUILT_SOURCES affects the dist target, but it should be there to
make sure the generated parser sources are created early, so as to
avoid botching the gcc-built dependencies.
Comment 3 Benjamin Otte (Company) 2004-02-03 03:30:08 UTC
should be fixed in HEAD, please reopen if not.