GNOME Bugzilla – Bug 546870
Many warning when compiling gstreamer-0.10.20 on OpenSolaris
Last modified: 2008-08-18 02:55:03 UTC
Please describe the problem: I downloaded GStreamer from here: http://gstreamer.freedesktop.org/src/gstreamer/gstreamer-0.10.20.tar.bz2 OpenSolaris does not have Qt4 (only Qt3) and I desire to compile: ftp://ftp.trolltech.com/qt/source/qt-x11-opensource-src-4.4.1.tar.gz with Phenon enabled so I can compile gcc 4.x with Qt, so I need to compile Gstreamer as one of the dependencies. Bugs / Difficulties: 1.): OpenSolaris is a 64-bit Operating System and it's Vender supplied gcc 3.4.3 (that is why I am compiling a 4.x series gcc) is compiled to support multilib but Gstreamer's configure does not utilize the "--enable-multilib" option and automatically build both 32-bit and 64-bit versions of it's libraries and install them in the correct locations. In this day and age it is kind of people to write their configure scripts to support 64-bit OSes. 2.): Your web page: http://gstreamer.freedesktop.org/data/doc/gstreamer/head/faq/html/chapter-cvs.html#werror mentions that CVS versions are retrieved with "-Wall -Werror" enabled, but that "release" versions are not. I am getting a lot of warnings when I compile gstreamer-0.10.20 fewer would be better. 3.): When I get to the "gtk-doc: Running scanner gstreamer-libs-scan" section of the make the build fails with this error (did not occur with older version of gstreamer that I tried): gstreamer-libs-scan.c:1070: warning: comparison is always false due to limited range of data type gtk-doc: Linking scanner gcc -o .libs/gstreamer-libs-scan .libs/gstreamer-libs-scan.o ../../libs/gst/controller/.libs/libgstcontroller-0.10.so -L/usr/lib/amd64 -lm ../../libs/gst/base/.libs/libgstbase-0.10.so ../../libs/gst/net/.libs/libgstnet-0.10.so /aux0/gstreamer-0.10.20_build_32/gst/.libs/libgstreamer-0.10.so -lnsl ../../gst/.libs/libgstreamer-0.10.so -lxml2 -ldl -lgobject-2.0 -lgthread-2.0 -lpthread -lthread -lgmodule-2.0 -lglib-2.0 -lintl -R/opt/csw/tmp32/lib ld: warning: file ../../gst/.libs/libgstreamer-0.10.so: linked to /aux0/gstreamer-0.10.20_build_32/gst/.libs/libgstreamer-0.10.so: attempted multiple inclusion of file creating gstreamer-libs-scan gtk-doc: Running scanner gstreamer-libs-scan (<unknown>:18602): GLib-GObject-CRITICAL **: file gparamspecs.c: line 1711: assertion `default_value >= minimum && default_value <= maximum' failed (<unknown>:18602): GLib-GObject-CRITICAL **: file gobject.c: line 309: assertion `G_IS_PARAM_SPEC (pspec)' failed (<unknown>:18602): GLib-GObject-CRITICAL **: file gparamspecs.c: line 1711: assertion `default_value >= minimum && default_value <= maximum' failed (<unknown>:18602): GLib-GObject-CRITICAL **: file gobject.c: line 309: assertion `G_IS_PARAM_SPEC (pspec)' failed (<unknown>:18602): GLib-GObject-CRITICAL **: file gparamspecs.c: line 1685: assertion `default_value >= minimum && default_value <= maximum' failed (<unknown>:18602): GLib-GObject-CRITICAL **: file gobject.c: line 309: assertion `G_IS_PARAM_SPEC (pspec)' failed (<unknown>:18602): GLib-GObject-CRITICAL **: file gparamspecs.c: line 1685: assertion `default_value >= minimum && default_value <= maximum' failed (<unknown>:18602): GLib-GObject-CRITICAL **: file gobject.c: line 309: assertion `G_IS_PARAM_SPEC (pspec)' failed (<unknown>:18602): GLib-GObject-CRITICAL **: file gparamspecs.c: line 1711: assertion `default_value >= minimum && default_value <= maximum' failed (<unknown>:18602): GLib-GObject-CRITICAL **: file gobject.c: line 309: assertion `G_IS_PARAM_SPEC (pspec)' failed (<unknown>:18602): GLib-GObject-CRITICAL **: file gparamspecs.c: line 1711: assertion `default_value >= minimum && default_value <= maximum' failed (<unknown>:18602): GLib-GObject-CRITICAL **: file gobject.c: line 309: assertion `G_IS_PARAM_SPEC (pspec)' failed ** ** ERROR:(../../../../gstreamer-0.10.20/libs/gst/net/gstnettimeprovider.c:139):gst_net_time_provider_class_init: assertion failed: (sizeof (GstClockTime) == 8) Abort - core dumped Scan failed: gmake[4]: *** [scan-build.stamp] Error 134 gmake[4]: Leaving directory `/aux0/gstreamer-0.10.20_build_32/docs/libs' gmake[3]: *** [all-recursive] Error 1 gmake[3]: Leaving directory `/aux0/gstreamer-0.10.20_build_32/docs' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/aux0/gstreamer-0.10.20_build_32/docs' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/aux0/gstreamer-0.10.20_build_32' gmake: *** [all] Error 2 Using 'ldd' it seems to find all it's files OK: # ldd docs/libs/.libs/gstreamer-libs-scan libgstcontroller-0.10.so.0 => /usr/lib/libgstcontroller-0.10.so.0 libm.so.2 => /lib/libm.so.2 libgstbase-0.10.so.0 => /usr/lib/libgstbase-0.10.so.0 libgstnet-0.10.so.0 => /usr/lib/libgstnet-0.10.so.0 libgstreamer-0.10.so.0 => /usr/lib/libgstreamer-0.10.so.0 libnsl.so.1 => /lib/libnsl.so.1 libxml2.so.2 => /lib/libxml2.so.2 libdl.so.1 => /lib/libdl.so.1 libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 libpthread.so.1 => /lib/libpthread.so.1 libthread.so.1 => /lib/libthread.so.1 libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 libintl.so.1 => /lib/libintl.so.1 libc.so.1 => /lib/libc.so.1 libmp.so.2 => /lib/libmp.so.2 libmd.so.1 => /lib/libmd.so.1 libscf.so.1 => /lib/libscf.so.1 libz.so.1 => /lib/libz.so.1 libsocket.so.1 => /lib/libsocket.so.1 libuutil.so.1 => /lib/libuutil.so.1 libgen.so.1 => /lib/libgen.so.1 Perhaps the assertions are caused by the copious warnings given during the compilation, here are a few: if /bin/bash ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../../gstreamer-0.10.20/gst -I.. -D_GNU_SOURCE -DG_LOG_DOMAIN=g_log_domain_gstreamer -DGST_MAJORMINOR=\""0.10"\" -DGST_DISABLE_DEPRECATED -I../../gstreamer-0.10.20/libs -I../../gstreamer-0.10.20 -I.. -D_REENTRANT -D_PTHREADS -I/usr/include/glib-2.0 -I/usr/lib/amd64/glib-2.0/include -I/usr/include/libxml2 -Wall -g -m32 -MT libgstreamer_0.10_la-gstobject.lo -MD -MP -MF ".deps/libgstreamer_0.10_la-gstobject.Tpo" -c -o libgstreamer_0.10_la-gstobject.lo `test -f 'gstobject.c' || echo '../../gstreamer-0.10.20/gst/'`gstobject.c; \ then mv -f ".deps/libgstreamer_0.10_la-gstobject.Tpo" ".deps/libgstreamer_0.10_la-gstobject.Plo"; else rm -f ".deps/libgstreamer_0.10_la-gstobject.Tpo"; exit 1; fi gcc -DHAVE_CONFIG_H -I. -I../../gstreamer-0.10.20/gst -I.. -D_GNU_SOURCE -DG_LOG_DOMAIN=g_log_domain_gstreamer -DGST_MAJORMINOR=\"0.10\" -DGST_DISABLE_DEPRECATED -I../../gstreamer-0.10.20/libs -I../../gstreamer-0.10.20 -I.. -D_REENTRANT -D_PTHREADS -I/usr/include/glib-2.0 -I/usr/lib/amd64/glib-2.0/include -I/usr/include/libxml2 -Wall -g -m32 -MT libgstreamer_0.10_la-gstobject.lo -MD -MP -MF .deps/libgstreamer_0.10_la-gstobject.Tpo -c ../../gstreamer-0.10.20/gst/gstobject.c -fPIC -DPIC -o .libs/libgstreamer_0.10_la-gstobject.o ../../gstreamer-0.10.20/gst/gstobject.c: In function `gst_object_set_name_default': ../../gstreamer-0.10.20/gst/gstobject.c:606: warning: passing arg 1 of `g_atomic_pointer_get' from incompatible pointer type ../../gstreamer-0.10.20/gst/gstobject.c:616: warning: passing arg 1 of `g_atomic_pointer_get' from incompatible pointer type if /bin/bash ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../../gstreamer-0.10.20/gst -I.. -D_GNU_SOURCE -DG_LOG_DOMAIN=g_log_domain_gstreamer -DGST_MAJORMINOR=\""0.10"\" -DGST_DISABLE_DEPRECATED -I../../gstreamer-0.10.20/libs -I../../gstreamer-0.10.20 -I.. -D_REENTRANT -D_PTHREADS -I/usr/include/glib-2.0 -I/usr/lib/amd64/glib-2.0/include -I/usr/include/libxml2 -Wall -g -m32 -MT libgstreamer_0.10_la-gstbin.lo -MD -MP -MF ".deps/libgstreamer_0.10_la-gstbin.Tpo" -c -o libgstreamer_0.10_la-gstbin.lo `test -f 'gstbin.c' || echo '../../gstreamer-0.10.20/gst/'`gstbin.c; \ then mv -f ".deps/libgstreamer_0.10_la-gstbin.Tpo" ".deps/libgstreamer_0.10_la-gstbin.Plo"; else rm -f ".deps/libgstreamer_0.10_la-gstbin.Tpo"; exit 1; fi gcc -DHAVE_CONFIG_H -I. -I../../gstreamer-0.10.20/gst -I.. -D_GNU_SOURCE -DG_LOG_DOMAIN=g_log_domain_gstreamer -DGST_MAJORMINOR=\"0.10\" -DGST_DISABLE_DEPRECATED -I../../gstreamer-0.10.20/libs -I../../gstreamer-0.10.20 -I.. -D_REENTRANT -D_PTHREADS -I/usr/include/glib-2.0 -I/usr/lib/amd64/glib-2.0/include -I/usr/include/libxml2 -Wall -g -m32 -MT libgstreamer_0.10_la-gstbin.lo -MD -MP -MF .deps/libgstreamer_0.10_la-gstbin.Tpo -c ../../gstreamer-0.10.20/gst/gstbin.c -fPIC -DPIC -o .libs/libgstreamer_0.10_la-gstbin.o ../../gstreamer-0.10.20/gst/gstbin.c: In function `gst_bin_element_set_state': ../../gstreamer-0.10.20/gst/gstbin.c:1920: warning: integer overflow in expression ../../gstreamer-0.10.20/gst/gstbin.c:1920: warning: integer overflow in expression (a couple of dozen of those warnings) ... (some more files with a few warnings) if /bin/bash ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../../gstreamer-0.10.20/gst -I.. -D_GNU_SOURCE -DG_LOG_DOMAIN=g_log_domain_gstreamer -DGST_MAJORMINOR=\""0.10"\" -DGST_DISABLE_DEPRECATED -I../../gstreamer-0.10.20/libs -I../../gstreamer-0.10.20 -I.. -D_REENTRANT -D_PTHREADS -I/usr/include/glib-2.0 -I/usr/lib/amd64/glib-2.0/include -I/usr/include/libxml2 -Wall -g -m32 -MT libgstreamer_0.10_la-gstclock.lo -MD -MP -MF ".deps/libgstreamer_0.10_la-gstclock.Tpo" -c -o libgstreamer_0.10_la-gstclock.lo `test -f 'gstclock.c' || echo '../../gstreamer-0.10.20/gst/'`gstclock.c; \ then mv -f ".deps/libgstreamer_0.10_la-gstclock.Tpo" ".deps/libgstreamer_0.10_la-gstclock.Plo"; else rm -f ".deps/libgstreamer_0.10_la-gstclock.Tpo"; exit 1; fi gcc -DHAVE_CONFIG_H -I. -I../../gstreamer-0.10.20/gst -I.. -D_GNU_SOURCE -DG_LOG_DOMAIN=g_log_domain_gstreamer -DGST_MAJORMINOR=\"0.10\" -DGST_DISABLE_DEPRECATED -I../../gstreamer-0.10.20/libs -I../../gstreamer-0.10.20 -I.. -D_REENTRANT -D_PTHREADS -I/usr/include/glib-2.0 -I/usr/lib/amd64/glib-2.0/include -I/usr/include/libxml2 -Wall -g -m32 -MT libgstreamer_0.10_la-gstclock.lo -MD -MP -MF .deps/libgstreamer_0.10_la-gstclock.Tpo -c ../../gstreamer-0.10.20/gst/gstclock.c -fPIC -DPIC -o .libs/libgstreamer_0.10_la-gstclock.o ../../gstreamer-0.10.20/gst/gstclock.c: In function `gst_clock_entry_new': ../../gstreamer-0.10.20/gst/gstclock.c:161: warning: integer overflow in expression ../../gstreamer-0.10.20/gst/gstclock.c:161: warning: integer overflow in expression (a couple of dozen of those warnings) ... (some more files with a few warnings) if /bin/bash ../../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../../../../gstreamer-0.10.20/libs/gst/base -I../../.. -I../../../../gstreamer-0.10.20/libs -I../../../../gstreamer-0.10.20 -I../../.. -D_REENTRANT -D_PTHREADS -I/usr/include/glib-2.0 -I/usr/lib/amd64/glib-2.0/include -I/usr/include/libxml2 -Wall -g -m32 -MT libgstbase_0.10_la-gstbasesink.lo -MD -MP -MF ".deps/libgstbase_0.10_la-gstbasesink.Tpo" -c -o libgstbase_0.10_la-gstbasesink.lo `test -f 'gstbasesink.c' || echo '../../../../gstreamer-0.10.20/libs/gst/base/'`gstbasesink.c; \ then mv -f ".deps/libgstbase_0.10_la-gstbasesink.Tpo" ".deps/libgstbase_0.10_la-gstbasesink.Plo"; else rm -f ".deps/libgstbase_0.10_la-gstbasesink.Tpo"; exit 1; fi gcc -DHAVE_CONFIG_H -I. -I../../../../gstreamer-0.10.20/libs/gst/base -I../../.. -I../../../../gstreamer-0.10.20/libs -I../../../../gstreamer-0.10.20 -I../../.. -D_REENTRANT -D_PTHREADS -I/usr/include/glib-2.0 -I/usr/lib/amd64/glib-2.0/include -I/usr/include/libxml2 -Wall -g -m32 -MT libgstbase_0.10_la-gstbasesink.lo -MD -MP -MF .deps/libgstbase_0.10_la-gstbasesink.Tpo -c ../../../../gstreamer-0.10.20/libs/gst/base/gstbasesink.c -fPIC -DPIC -o .libs/libgstbase_0.10_la-gstbasesink.o ../../../../gstreamer-0.10.20/libs/gst/base/gstbasesink.c: In function `gst_base_sink_class_init': ../../../../gstreamer-0.10.20/libs/gst/base/gstbasesink.c:353: warning: integer constant is too large for "long" type ../../../../gstreamer-0.10.20/libs/gst/base/gstbasesink.c:354: warning: overflow in implicit constant conversion ../../../../gstreamer-0.10.20/libs/gst/base/gstbasesink.c:385: warning: integer constant is too large for "long" type ../../../../gstreamer-0.10.20/libs/gst/base/gstbasesink.c:385: warning: integer constant is too large for "long" type ../../../../gstreamer-0.10.20/libs/gst/base/gstbasesink.c:386: warning: overflow in implicit constant conversion ../../../../gstreamer-0.10.20/libs/gst/base/gstbasesink.c: In function `gst_base_sink_query_latency': ../../../../gstreamer-0.10.20/libs/gst/base/gstbasesink.c:952: warning: integer overflow in expression ../../../../gstreamer-0.10.20/libs/gst/base/gstbasesink.c:952: warning: integer overflow in expression (a few hundred of those warnings) ... (some more files with a few warnings) That continues for many files, ultimatly 1000's of warnings. The warnings immediatley before the failure of ".libs/gstreamer-libs-scan" are these: gtk-doc: Compiling scanner mkdir .libs gcc -I../.. -I../../libs -I../../../gstreamer-0.10.20/libs -I../../../gstreamer-0.10.20 -I../.. -D_REENTRANT -D_PTHREADS -I/usr/include/glib-2.0 -I/usr/lib/amd64/glib-2.0/include -I/usr/include/libxml2 -Wall -g -c gstreamer-libs-scan.c -fPIC -DPIC -o .libs/gstreamer-libs-scan.o gstreamer-libs-scan.c: In function `describe_signed_constant': gstreamer-libs-scan.c:901: warning: integer constant is too large for "long" type gstreamer-libs-scan.c:901: warning: comparison is always false due to limited range of data type gstreamer-libs-scan.c:903: warning: integer constant is too large for "long" type gstreamer-libs-scan.c: In function `describe_unsigned_constant': gstreamer-libs-scan.c:924: warning: integer constant is too large for "long" type gstreamer-libs-scan.c:924: warning: comparison is always false due to limited range of data type gstreamer-libs-scan.c:926: warning: integer constant is too large for "unsigned long" type gstreamer-libs-scan.c:926: warning: comparison is always false due to limited range of data type gstreamer-libs-scan.c: In function `describe_type': gstreamer-libs-scan.c:1049: warning: integer constant is too large for "long" type gstreamer-libs-scan.c:1049: warning: integer constant is too large for "long" type gstreamer-libs-scan.c:1049: warning: comparison is always false due to limited range of data type gstreamer-libs-scan.c:1051: warning: integer constant is too large for "long" type gstreamer-libs-scan.c:1053: warning: integer constant is too large for "long" type gstreamer-libs-scan.c:1053: warning: comparison is always false due to limited range of data type gstreamer-libs-scan.c:1066: warning: integer constant is too large for "unsigned long" type gstreamer-libs-scan.c:1066: warning: comparison is always false due to limited range of data type gstreamer-libs-scan.c:1070: warning: integer constant is too large for "unsigned long" type gstreamer-libs-scan.c:1070: warning: comparison is always false due to limited range of data type gtk-doc: Linking scanner gcc -o .libs/gstreamer-libs-scan .libs/gstreamer-libs-scan.o ../../libs/gst/controller/.libs/libgstcontroller-0.10.so -L/usr/lib/amd64 -lm ../../libs/gst/base/.libs/libgstbase-0.10.so ../../libs/gst/net/.libs/libgstnet-0.10.so /aux0/gstreamer-0.10.20_build_32/gst/.libs/libgstreamer-0.10.so -lnsl ../../gst/.libs/libgstreamer-0.10.so -lxml2 -ldl -lgobject-2.0 -lgthread-2.0 -lpthread -lthread -lgmodule-2.0 -lglib-2.0 -lintl -R/opt/csw/tmp32/lib ld: warning: file ../../gst/.libs/libgstreamer-0.10.so: linked to /aux0/gstreamer-0.10.20_build_32/gst/.libs/libgstreamer-0.10.so: attempted multiple inclusion of file creating gstreamer-libs-scan gtk-doc: Running scanner gstreamer-libs-scan (<unknown>:18602): GLib-GObject-CRITICAL **: file gparamspecs.c: line 1711: assertion `default_value >= minimum && default_value <= maximum' failed I'm fairly good at programming so I'll likely fix this myself. I'm just filing a bug report so you are aware of this difficulty (and to request better support for 64-bit platforms (please use --enable-multilib and have "make install" place the 64-bit libraries into the correct directory) it is a nusance to have to set CFLAGS=-m32 / CFLAGS=-m64 and compile twice, then move the libraries (and pkgconfig files) manually). Thanks, Rob Steps to reproduce: 1. Details in "Please describe the problem" section. 2. Download http://gstreamer.freedesktop.org/src/gstreamer/gstreamer-0.10.20.tar.bz 3. Compile with gcc 3.4.3 (on OpenSolaris, probably other platforms too). Actual results: Build fails, did not fail with (much) older version of gstreamer. Expected results: 32-bit ought to work. Have yet to get to build this version in 64-bit mode (adding -m64 to CFLAGS). Does this happen every time? Yes. Other information: Thanks for the free software.
Your compilation is completely borked. You're building the 32 bit version with: -I/usr/lib/amd64/glib-2.0/include This output: assertion failed: (sizeof (GstClockTime) == 8) implies that you've managed to set things up so that guint64 is not a 64 bit variable => go fix it. GStreamer builds fine on Nevada and on plenty of 64 bit linux distros. If a system needs multilib binaries, building them seems like the job of the package management system to me.
> Jan Schmidt 2008-08-07 21:51 UTC wrote: > Your compilation is completely borked. You're building the 32 bit version with: > -I/usr/lib/amd64/glib-2.0/include > This output: assertion failed: (sizeof (GstClockTime) == 8) > implies that you've managed to set things up so that guint64 is not a 64 bit variable => go fix it. Thanks for spotting that. I configured my 32-bit build with this line: ../gstreamer-0.10.2/configure --prefix=/opt/csw/tmp32 --with-libiconv-prefix=/opt/csw --with-libintl-prefix=/opt/csw --enable-failing-tests --enable-docbook --enable-gtk-doc --with-as=/opt/gnu/bin/as --with-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-shared --disable-static CFLAGS=-m32 I don't know why "-I/usr/lib/amd64/glib-2.0/include" is being used but I'll look into it. I suspected (from the errors) some difficulty with the casts (or size of variables) so I went to a new build directory and did a 64-bit build with this configure script: ../gstreamer-0.10.2/configure --prefix=/opt/csw/tmp64 --with-libiconv-prefix=/opt/csw --with-libintl-prefix=/opt/csw --enable-failing-tests --enable-docbook --enable-gtk-doc --with-as=/opt/gnu/bin/as --with-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-shared --disable-static CFLAGS=-m64 That is the exact same configure script _except_ for the CFLAGS. When I build the 64-bit version I only get a couple of dozen warning (as opposed to 1000's) but ultimately the build fails here: gtk-doc: Compiling scanner mkdir .libs gcc -I../../../gstreamer-0.10.20/libs -I../../../gstreamer-0.10.20 -I../.. -D_REENTRANT -D_PTHREADS -I/usr/include/glib-2.0 -I/usr/lib/amd64/glib-2.0/include -I/usr/include/libxml2 -Wall -g -c gstreamer-scan.c -fPIC -DPIC -o .libs/gstreamer-scan.o gstreamer-scan.c: In function `describe_signed_constant': gstreamer-scan.c:901: warning: integer constant is too large for "long" type gstreamer-scan.c:901: warning: comparison is always false due to limited range of data type gstreamer-scan.c:903: warning: integer constant is too large for "long" type gstreamer-scan.c: In function `describe_unsigned_constant': gstreamer-scan.c:924: warning: integer constant is too large for "long" type gstreamer-scan.c:924: warning: comparison is always false due to limited range of data type gstreamer-scan.c:926: warning: integer constant is too large for "unsigned long" type gstreamer-scan.c:926: warning: comparison is always false due to limited range of data type gstreamer-scan.c: In function `describe_type': gstreamer-scan.c:1049: warning: integer constant is too large for "long" type gstreamer-scan.c:1049: warning: integer constant is too large for "long" type gstreamer-scan.c:1049: warning: comparison is always false due to limited range of data type gstreamer-scan.c:1051: warning: integer constant is too large for "long" type gstreamer-scan.c:1053: warning: integer constant is too large for "long" type gstreamer-scan.c:1053: warning: comparison is always false due to limited range of data type gstreamer-scan.c:1066: warning: integer constant is too large for "unsigned long" type gstreamer-scan.c:1066: warning: comparison is always false due to limited range of data type gstreamer-scan.c:1070: warning: integer constant is too large for "unsigned long" type gstreamer-scan.c:1070: warning: comparison is always false due to limited range of data type gtk-doc: Linking scanner gcc -o .libs/gstreamer-scan .libs/gstreamer-scan.o ../../gst/.libs/libgstreamer-0.10.so -L/usr/lib/amd64 -lxml2 -ldl -lgobject-2.0 -lgthread-2.0 -lpthread -lthread -lgmodule-2.0 -lglib-2.0 -lintl -R/opt/csw/tmp64/lib ld: fatal: file ../../gst/.libs/libgstreamer-0.10.so: wrong ELF class: ELFCLASS64 ld: fatal: File processing errors. No output written to .libs/gstreamer-scan collect2: ld returned 1 exit status Linking of scanner failed: gmake[5]: *** [scan-build.stamp] Error 1 gmake[5]: Leaving directory `/aux0/gstreamer-0.10.20_build_amd64/docs/gst' gmake[4]: *** [all] Error 2 gmake[4]: Leaving directory `/aux0/gstreamer-0.10.20_build_amd64/docs/gst' gmake[3]: *** [all-recursive] Error 1 gmake[3]: Leaving directory `/aux0/gstreamer-0.10.20_build_amd64/docs' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/aux0/gstreamer-0.10.20_build_amd64/docs' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/aux0/gstreamer-0.10.20_build_amd64' gmake: *** [all] Error 2 I had the same problem when I compiled a much earlier version of GStreamer and repaired it by editing docs/gst/Makefile and changing (line 178): GST_ALL_CFLAGS = -I$(top_srcdir)/libs -I$(top_srcdir) -I$(top_builddir) -D_REENTRANT -D_PTHREADS -I/usr/include/glib-2.0 -I/usr/lib/amd64/glib-2.0/include -I/usr/include/libxml2 $(GST_OPTION_CFLAGS) to GST_ALL_CFLAGS = -I$(top_srcdir)/libs -I$(top_srcdir) -I$(top_builddir) -D_REENTRANT -D_PTHREADS -I/usr/include/glib-2.0 -I/usr/lib/amd64/glib-2.0/include -I/usr/include/libxml2 $(GST_OPTION_CFLAGS) $(CFLAGS) and changing (line 768): CFLAGS="$(GTKDOC_CFLAGS)" LDFLAGS="$(GTKDOC_LIBS)" \ to CFLAGS="$(GTKDOC_CFLAGS)" LDFLAGS="$(GTKDOC_LIBS) $(CFLAGS)" \ My CFLAGS are simply either "CFLAGS=-m32" or "CFLAGS=-m64". When I get this new version running I will find the correct file to put a proper fix into and submit a tiny "gdiff". The use of "non-g-prefixed" utilities is another issue (on Solaris). The main configure script checks for "sed" _before_ it checks for gsed. Solaris has it's own "sed" that does not accept all the commands that GNU sed does. Configure scripts that run on Solaris must check for g-prefixed versions of utilities before they look for the non-g-prefixed version (and can test the "/usr/xpg4/bin" and "/usr/xpg6/bin" directories for Posix compatable utilities instead of searching for the "traditional" Sun versions of these utilites (unless the configure script wants to use the Sun command parameters when using the Sun utilites). Let's not worry about that in _this_ bug report. Lets stick with "http://gstreamer.freedesktop.org/src/gstreamer/gstreamer-0.10.20.tar.bz2" does not compile without warnings on gcc 3.4.3 (Solaris's "vendor supplied gcc" - which I am trying to upgrade to 4.x series). Thanks for reading my post, Jan.
I also noticed that the above commands are using "-R/opt/csw/tmp32/lib". A portion of my configure options are: "--prefix=/opt/csw/tmp32" thus we know that directory is _empty_ (until I complete the build and _finish_ 'install'), so what purpose does "-R"ing that directory serve? Seeing that, I decided to ensure that the main (root) configure had all it's utility commands "g-prefixed" to ensure that GNU programs were used and not Solaris' "traditional" utilities (which unfortunately have the same name as some of the GNU programs but different command line options and different function). The list of "g-prefixed commands is: gcmp, gdiff, gdiff3, gegrep, gfgrep, ggettext, ggrep, gm4, gmake, gmsgfmt, gpatch, gsdiff, gtar, gsed (etc, possibly I missed one). There were quite a few to change. When building the 64-bit version the build fails here: mkdir .libs gcc -m64 -o .libs/typefind typefind-typefind.o ../../../gst/.libs/libgstreamer-0.10.so -L/usr/lib/amd64 -lxml2 -lgobject-2.0 -lgthread-2.0 -lpthread -lthread -lgmodule-2.0 -lglib-2.0 -lintl -ldl -R/opt/csw/tmp64/lib creating typefind gmake[4]: Leaving directory `/aux0/gstreamer-0.10.20_build_amd64/tests/examples/typefind' ... gtk-doc: Compiling scanner mkdir .libs gcc -I../../../gstreamer-0.10.20/libs -I../../../gstreamer-0.10.20 -I../.. -D_REENTRANT -D_PTHREADS -I/usr/include/glib-2.0 -I/usr/lib/amd64/glib-2.0/include -I/usr/include/libxml2 -Wall -g -c gstreamer-scan.c -fPIC -DPIC -o .libs/gstreamer-scan.o gtk-doc: Linking scanner gcc -o .libs/gstreamer-scan .libs/gstreamer-scan.o ../../gst/.libs/libgstreamer-0.10.so -L/usr/lib/amd64 -lxml2 -ldl -lgobject-2.0 -lgthread-2.0 -lpthread -lthread -lgmodule-2.0 -lglib-2.0 -lintl -R/opt/csw/tmp64/lib ld: fatal: file ../../gst/.libs/libgstreamer-0.10.so: wrong ELF class: ELFCLASS64 ld: fatal: File processing errors. No output written to .libs/gstreamer-scan collect2: ld returned 1 exit status Linking of scanner failed: gmake[5]: *** [scan-build.stamp] Error 1 gmake[5]: Leaving directory `/aux0/gstreamer-0.10.20_build_amd64/docs/gst' ... Both of those last two commands would need to have "-m64" tagged on the end to ensure that the object files were all 64-bit (since the default compilation mode of Sun's "vendor supplied" gcc 3.4.3 is 32-bit). The Makefiles _were_ adding "-m64" to all gcc commands up to that point but the last two "gcc ..." commands saw fit not to include them; thus the build fails at that point (in 64-bit compilations on Solaris Operating Systems). So lets try building the 32-bit version (where missing an "-mXX" would not matter (on _this_ platform)). With everything un-borked the build succeeds (with a few dozen warnings). Most common warnings are (occurs in a few files): ../../config.h:212:1: warning: "_FILE_OFFSET_BITS" redefined ../../gstreamer-0.10.2/gst/gstobject.c:679: warning: passing arg 1 of `g_atomic_pointer_get' from incompatible pointer type Running "gmake check" on the 32-bit build passes. Summary: Only problem is the aforementioned lack of the "-m??" in _some_ of the "gcc ..." commands. Since my compiler defaults to 32-bit mode (as if it were using "-m32", but it in fact, does not) the lack of "-m32" has no effect. In 64-bit compilation mode the lack of "-m64" is a problem since the compiler defaults to 32-bit mode and the Makefile causes gcc to try to link mostly 64-bit object files with one 32-bit object file and tells 'ld' they are all 32-bit object files. The "fix": Need to use "-m32" for 32-bit mode (in case someone's compiler has a 64 bit default) and _I_ need for that Makefile to be created with "-m64" since my multilib compiler (gcc) defaults to 32-bit mode. So the "bugs" are (see first post): 1.): ... Gstreamer's configure does not utilize the "--enable-multilib" option and automatically build both 32-bit and 64-bit versions of it's libraries (and install them in the correct locations). >> Jan Schmidt wrote: > If a system needs multilib binaries, building them seems like the job of the package management system to me. Sure would be nice but the Solaris Package Manager simply downloads pre-existing packages, unpacks them, and installs them. The author of the package must build both 32-bit and 64-bit versions and package both. Some Solaris versions (Solaris Express Community Edition) don't have a "Package Management GUI" you need to use pkgadd from the command line. Some programs are simply not available (mostly "GNU programs") but a small (large?) number of GNU programs are available from Blastwave - they are notorious for not providing _both_ 32-bit _and_ 64-bit versions (yes, I've emailed them). So IF I want a 'GNUish program' and it is not available in the correct version (usually the newest version is my preference, certainly not a three year old version) and with both 32 and 64 bit libraries then building them becomes my job (I wish the Package Manager would do it :) ). 2.): ... CVS versions are retrieved with "-Wall -Werror" enabled, but that "release" versions are not. I am getting a lot of warnings when I compile gstreamer-0.10.20 fewer would be better. Lets change that to "I am getting "some" warnings (not really quite "a lot"). 3.): When I get to the "gtk-doc: Running scanner gstreamer-libs-scan" section of the make the build fails with ... Lets clarify that comment. The 32-bit compilation works by chance (there is a missing "-m32" option and the compiler defaults to 32-bit mode so this has no effect). The 64-bit compilation fails since there is a missing "-m64" option (and the compiler defaults to 32-bit) mode so this causes a mis-compiled object file and a link failure. YT, Rob
As your build seem to break when building the api docs (where it runs a freshly build introspection binary), I'd usggest to turn gtk-doc off to see if the issue lies there.
(In reply to comment #4) > As your build seem to break when building the api docs (where it runs a freshly > build introspection binary), I'd usggest to turn gtk-doc off to see if the > issue lies there. > That "works" but does not "correct" the real problem. Since the 32-bit compilation is completed correctly and the install stage works properly I already have the API docs installed so, for _me_ (someone who also compiled a 32-bit version with a "multilib capable gcc") this is not a problem. If I had chosen to only compile 64-bit only (with my compiler that defaults to using "-m32" internally) the "API docs build mechanism" (Makefiles, shell and perl scripts) are missing the correct placement of one usage of "-m64" which mis-compiles a file and causes a linkage error. I now have both 32-bit and 64-bit libraries installed with the docs, binaries and ".pc" files all working correctly. I am now building "gst-plugins-base-0.10.20". Thanks for your comments everyone. This bug is still open.
Disabling gtk-doic was just to confirm that the problem lies entierly there. Could you please let us knwo which version you have?
(In reply to comment #6) > Disabling gtk-doic was just to confirm that the problem lies entierly there. > Could you please let us knwo which version you have? > Yes, in the location mentioned in the prior comment in this thread.
rob, I mean which version of gtk-doc ?
(In reply to comment #8) > rob, I mean which version of gtk-doc ? It is the one included in the source. I'm not using a different one. Comment 2 says this is where it breaks. This is the one, no other. Linking of scanner failed: gmake[5]: *** [scan-build.stamp] Error 1 gmake[5]: Leaving directory `/aux0/gstreamer-0.10.20_build_amd64/docs/gst'
> > rob, I mean which version of gtk-doc ? > > It is the one included in the source. I'm not using a different one. > > Comment 2 says this is where it breaks. This is the one, no other. gtk-doc is an external tool. Could you please run: gtkdoc-scangobj --version
(In reply to comment #10) > > > rob, I mean which version of gtk-doc ? > > > > It is the one included in the source. I'm not using a different one. > > > > Comment 2 says this is where it breaks. This is the one, no other. > > gtk-doc is an external tool. Could you please run: > > gtkdoc-scangobj --version > It is the gstreamer Makefile that broke (unless you have "gcc ..." commands embeded within "gtk-doc" (which 'appears' to me as being built when I build gstreamer)). But to comply with your request, here is what happens from a _fresh_ _boot_ of Solaris and _is_ _not_ promised to be the same paths setting as when I actually compiled gstreamer (over a week ago). $gtkdoc-scangobj --version 1.10 --- As I recall, and it's been a busy week in COMMENT 3 this is where it breaks, when the Makefile attempts to build ".libs/gstreamer-scan.o" without tossing an "-m64" (or "-m32" for gcc compilers that default to "-m64" (rarer)). gtk-doc: Linking scanner gcc -o .libs/gstreamer-scan .libs/gstreamer-scan.o ../../gst/.libs/libgstreamer-0.10.so -L/usr/lib/amd64 -lxml2 -ldl -lgobject-2.0 -lgthread-2.0 -lpthread -lthread -lgmodule-2.0 -lglib-2.0 -lintl -R/opt/csw/tmp64/lib ld: fatal: file ../../gst/.libs/libgstreamer-0.10.so: wrong ELF class: ELFCLASS64 ld: fatal: File processing errors. No output written to .libs/gstreamer-scan collect2: ld returned 1 exit status Linking of scanner failed: As I see it, nothing to do with "gtkdoc-scangobj" _BUT_ as long as one of you fixes it I care not how you do it... I already have it compiled and installed (in both flavors) and would be finished the plugins if other work had not come up. Thanks for the free source. Thanks for receiving my bug report. Best of luck fixing it. YT, Rob OaO
*** This bug has been marked as a duplicate of 536978 ***