GNOME Bugzilla – Bug 522142
Bad flag passing during build (CPPFLAGS/CFLAGS)
Last modified: 2014-05-19 14:42:24 UTC
I get some compiler crashes for gstreamer-0.10.17 on OS X 10.4 caused by the "wrong" .h being found. The problem is that some Makefiles list global -I flags (for external support libraries) before local ones, so an #include that is expected to access a .h that is part of the distro is instead getting an unrelated/wrong-version/whatever version somewhere else on my system. Should always pass all local -I before any global ones.
Created attachment 107195 [details] [review] Local -I before global flags GTKDOC_CFLAGS in docs/libs/Makefile.am was already correct.
Created attachment 107196 [details] [review] patch .am not .in
On closer inspection, there are other widespread problems in the Makefiles. tests/examples/controller/Makefile.am is a good example of what's wrong in virtually all of them: audio_example_CFLAGS = -I$(top_builddir)/libs $(GST_OBJ_CFLAGS) audio_example_LDADD = $(GST_OBJ_LIBS) audio_example_LDFLAGS = $(top_builddir)/libs/gst/controller/libgstcontroller-@GST_MAJORMINOR@.la 1. -I flags are for the compiler (.c -> .o), not the linker, so they belong in _CPPFLAGS not _CFLAGS (documented in the automake manual). This is important so that the flags are passed in the correct precedence (user environment vs implicit automake values vs configure script variables). Also, passing lots of useless -I flags to the linker makes linker commands more verbose and therefore harder to debug. 2. Dependent library .la go in _LDADD (or _LIBADD if compiling a library), not _LDFLAGS (documented in the libtool manual). One benefit is that _LDADD and _LIBADD, but not _LDFLAGS, generate automatic _DEPENDENCIES entries (cf. the explicit _DEPENDENCIES scattered in various other Makefile.am).
You're right: -I should be in CPPFLAGS, -L in LDFLAGS, libraries in LIBADD/LDADD, etc... this should be fixed in almost every Makefile.am unfortunately. Would be nice if you could create a patch, otherwise I'll look into it in a few days or weeks...
I can do it, what should I use as the base (SVN trunk, a branch of it, or the latest release)?
Latest CVS... and for every module you want of course, I guess every module is affected unfortunately :/ Thanks for looking into this :)
dmacks, any update on this bug ?
Created attachment 124483 [details] [review] Overhaul flags in "gstreamer" module Man, I patched it a while ago for fink the fink package...and then promptly forgot to pass it upstream! Here's against CVS HEAD. I successfully autogen.sh with enabling everything except doc generation (I'm missing some of the toolchain converters there) and make; all libs are linked, all symbols resolved, no global -I before local -I even though I have hellacious CPPFLAGS and other vars set.
ping? Anyone up for commiting this?
Irks, this got lost. While we did quite some changed, this hasn't been fixed yet. Daniel, do you still carry a patch for fink?
I've got a bunch for current or nearly-current source-releases of various gst*. I can rebase on current source-control archive, but I don't know where to find it (the "git" link for this project in bugzilla points to http://git.gnome.org/browse/gstreamer but that only looks like a few bindings not the core).
http://gstreamer.freedesktop.org/modules/
Have you had a chance to rebase yet? (Note: master branch may switch to 0.11 next week, so could / may have to rebase against 0.10 branch instead)
Daniel, did you rebase the patch ?
I'll try to get to this in the next few weeks or so...the whole gnome stack is in a pretty poor state for darwin right now so it's all low-priority I'm afraid, but I think I can get gst at least as far as the building stage without hitting the trouble-spots.
So what shall we do with this bug? reject the patch, INCOMPLETE the bug report and then have it reopened once you can update the patch? Otherwise, a non-NEEDINFO state would be appreciated. I.e. if this is indeed a bug that should be fixed, the report should be set to NEW.
I would prefer for it to stay in NEEDINFO state, so people keep looking at it regularly and nag :-) (The bug squad should feel free to skip triaging of NEEDINFO bugs for GStreamer if that doesn't fit their work flow.)
Daniel, is this still an issue with current gstreamer 1.x ?
Since all of gst builds fine with cerbero osx/ios , I'm closing this bug.