GNOME Bugzilla – Bug 556570
Version 0.9.7 fails to build due to call to ``GstBase::wrap_init()'' in gstreamer/gstreamermm/init.cc
Last modified: 2011-01-16 23:37:46 UTC
gstreamermm 0.9.7 build fails when linking. See the relevant build log below: /bin/sh ../../libtool --tag=CXX --mode=link g++ -g -O2 -g -Wall -O2 -version-info 2:1:0 -Wl,-z,defs -Wl,-O1 -Wl,--as-needed -o libgstreamermm-0.10.la -rpath /usr/lib bin.lo buffer.lo bus.lo caps.lo childproxy.lo clock.lo element.lo elementfactory.lo enums.lo error.lo event.lo filter.lo format.lo index.lo indexfactory.lo interface.lo iterator.lo message.lo pad.lo padtemplate.lo parse.lo pipeline.lo plugin.lo pluginfeature.lo query.lo registry.lo segment.lo structure.lo systemclock.lo tagsetter.lo task.lo urihandler.lo value.lo xml.lo basesrc.lo basesink.lo basetransform.lo pushsrc.lo wrap_init.lo init.lo miniobject.lo object.lo version.lo wrap.lo gst_wrap_init.lo taglist.lo structurevalue.lo -pthread -lgstbase-0.10 -lgstreamer-0.10 -lgmodule-2.0 -ldl -lgthread-2.0 -lrt -lxml++-2.6 -lxml2 -lglibmm-2.4 -lgobject-2.0 -lsigc-2.0 -lglib-2.0 g++ -shared -nostdlib /usr/lib/gcc/i486-linux-gnu/4.3.2/../../../../lib/crti.o /usr/lib/gcc/i486-linux-gnu/4.3.2/crtbeginS.o .libs/bin.o .libs/buffer.o .libs/bus.o .libs/caps.o .libs/childproxy.o .libs/clock.o .libs/element.o .libs/elementfactory.o .libs/enums.o .libs/error.o .libs/event.o .libs/filter.o .libs/format.o .libs/index.o .libs/indexfactory.o .libs/interface.o .libs/iterator.o .libs/message.o .libs/pad.o .libs/padtemplate.o .libs/parse.o .libs/pipeline.o .libs/plugin.o .libs/pluginfeature.o .libs/query.o .libs/registry.o .libs/segment.o .libs/structure.o .libs/systemclock.o .libs/tagsetter.o .libs/task.o .libs/urihandler.o .libs/value.o .libs/xml.o .libs/basesrc.o .libs/basesink.o .libs/basetransform.o .libs/pushsrc.o .libs/wrap_init.o .libs/init.o .libs/miniobject.o .libs/object.o .libs/version.o .libs/wrap.o .libs/gst_wrap_init.o .libs/taglist.o .libs/structurevalue.o -Wl,--as-needed /usr/lib/libgstbase-0.10.so -L/usr/lib /usr/lib/libgstreamer-0.10.so /usr/lib/libgmodule-2.0.so -ldl /usr/lib/libgthread-2.0.so -lrt /usr/lib/libxml++-2.6.so /usr/lib/libxml2.so /usr/lib/libglibmm-2.4.so /usr/lib/libgobject-2.0.so /usr/lib/libsigc-2.0.so /usr/lib/libglib-2.0.so -L/usr/lib/gcc/i486-linux-gnu/4.3.2 -L/usr/lib/gcc/i486-linux-gnu/4.3.2/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/i486-linux-gnu/4.3.2/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/i486-linux-gnu/4.3.2/crtendS.o /usr/lib/gcc/i486-linux-gnu/4.3.2/../../../../lib/crtn.o -Wl,-z -Wl,defs -Wl,-O1 -pthread -Wl,-soname -Wl,libgstreamermm-0.10.so.2 -o .libs/libgstreamermm-0.10.so.2.0.1 .libs/init.o: In function `Gst::initialize_wrap_system()': /tmp/buildd/gstreamermm-0.9.7/gstreamer/gstreamermm/init.cc:44: undefined reference to `GstBase::wrap_init()' collect2: ld returned 1 exit status make[6]: *** [libgstreamermm-0.10.la] Error 1 make[6]: Leaving directory `/tmp/buildd/gstreamermm-0.9.7/gstreamer/gstreamermm' make[5]: *** [all-recursive] Error 1 make[5]: Leaving directory `/tmp/buildd/gstreamermm-0.9.7/gstreamer/gstreamermm' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/tmp/buildd/gstreamermm-0.9.7/gstreamer' make[3]: *** [all] Error 2 make[3]: Leaving directory `/tmp/buildd/gstreamermm-0.9.7/gstreamer' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/tmp/buildd/gstreamermm-0.9.7' make[1]: *** [all] Error 2 make[1]: Leaving directory `/tmp/buildd/gstreamermm-0.9.7' make: *** [debian/stamp-makefile-build] Error 2 The cause is that in gstreamer/gstreamermm/init.cc, there's an invocation of GstBase::wrap_init(), but gstreamer/gstreamermm/Makefile.am doesn't add corresponding linking stuff of gstreamerbasemm. OTOH, is there any reason to call GstBase stuff in Gst binding?
For some odd reason, I can't reproduce this. I'm not using any special flags when running autogen.sh (except --prefix=/usr) or in the CC variable. Are you using any special flags? As far as calling GstBase::wrap_init() in Gst::init() (this is the function that calls Gst::initialize_wrap_system()), the reason I decided to do it this way is that in C, after gst_init() is called, the gst-plugins-base API can be used freely without needing an "init" for the base plugins API. I wanted to keep things as much as how things are done in the C API in gstreamermm. This can, however, change, but I think it is easier this way.
One more thing: I am noticing some errors with doc parsing because some xml files are missing in the release tarballs so I will try to release a new tarball in the next few days. Hopefully this bug will also be resolved by then.
Indeed, the failure was caused by the following custom LDFLAGS: LDFLAGS += -Wl,-z,defs -Wl,-O1 -Wl,--as-needed Removing this whole line let it link. So please consider this bug resolved, though it'll be better to support the LDFLAGS optimization as it used to.
Okay. I'll see what can be done.
Unfortunately, the problem here is that gstreamerbasemm (a sub-branch of gstreamermm) cannot be built before the gstreamermm branch because a couple of recent changes (in particular, the addition of GstBase::AudioClock which inherits from Gst::SystemClock) have made it depend on gstreamermm API. Before these changes, the problem did not exist because gstreamerbasemm was built first and, gstreamer/gstreamermm/Makefile.am had the necessary linking (as you suggest above). After the changes, gstreamermm must be built first (building gstreamerbasemm would fail), but Gst::initialize_wrap_system() should still call GstBase::init() to make it convenient for users not to have initializations for each branch of gstreamermm (this is the only thing I think could change). For now, I think we'll have to avoid using the "-Wl,-z,defs" and the "-Wl,--as-needed" linking options.
(In reply to comment #5) > Unfortunately, the problem here is that gstreamerbasemm (a sub-branch of > gstreamermm) cannot be built before the gstreamermm branch because a couple of > recent changes (in particular, the addition of GstBase::AudioClock which > inherits from Gst::SystemClock) have made it depend on gstreamermm API. Before > these changes, the problem did not exist because gstreamerbasemm was built > first and, gstreamer/gstreamermm/Makefile.am had the necessary linking (as you > suggest above). > > After the changes, gstreamermm must be built first (building gstreamerbasemm > would fail), but Gst::initialize_wrap_system() should still call > GstBase::init() to make it convenient for users not to have initializations for > each branch of gstreamermm (this is the only thing I think could change). For > now, I think we'll have to avoid using the "-Wl,-z,defs" and the > "-Wl,--as-needed" linking options. > Thanks for digging out the problem. IMHO it'll be good to document this in INSTALL file and close this bug as WONTFIX.
Deng, are these options used by default anywhere? Or did you choose to use them explicitly?
(In reply to comment #7) > Deng, are these options used by default anywhere? Or did you choose to use them > explicitly? > I use them explicitly in Debian packages for the rest of -mm packages, but they are not mandatory. Currently in Debian, debhelper defaults LDFLAGS to blank. Not quite familiar with other distros.
So, José, is this a WONTFIX? Or is there something we should want to do?
I'm thinking it is a WONTFIX unless we decide to merge the gstreamerbasemm branch into the gstreamermm branch. The gstreamermm and the gstreamerbasemm branches exist because they are a reflection of the core and the gst-plugins-base modules of GStreamer, but if it is convenient they can be merged in gstreamermm. I can't modify the status of this bug, but if I had to decide, I'd close it as a WONTFIX and suggest that it be re-opened in the future if something else arises.
Closed then. Deng, do tell us if this is a serious problem for you. Jose, I have added you to the list of developers for gnomemm in bugzilla. If that is not enough then please ask the bugsquad.
(In reply to comment #11) > Closed then. Deng, do tell us if this is a serious problem for you. > Not at all, and it'll be helpful to have it documented to avoid further misunderstanding.
Created attachment 121989 [details] [review] gstreamermm-ldflags.patch Proposed patch, please modify it if it should be documented elsewhere.
Thanks. Committed with minor adaptation: 2008-11-05 José Alburquerque <jaalburqu@svn.gnome.org> * INSTALL: Added standard install instructions with specific comment about unsupported linking flags (adapted from patch). Bug #556570 (Deng Xiyue)
A fix for this came up because of a recent bug[1] so I'm marking this as fixed. Deng, thanks for taking the time to report this and suggest a fix. You can now use the options that were not possible because of this bug. Thanks again. [1] http://bugzilla.gnome.org/show_bug.cgi?id=560601