[gstreamer-bugs] [Bug 546870] Many warning when compiling gstreamer-0.10.20 on OpenSolaris

Thu Aug 7 21:52:13 PDT 2008

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=546870

  GStreamer | gstreamer (core) | Ver: 0.10.x

------- Comment #3 from rob1weld at aol.com  2008-08-08 04:52 UTC -------
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

-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=546870.