[gst-devel] Solaris build issues

[Brian Cameron]

I have gotten gstreamer to build finally on Solaris.  I've attached
a patch I just committed.  I just found out that the CVS is moving
from sourceforge to freedesktop, so if this patch didn't make it
with the move, could it be applied?  Thanks.

I didn't really find a fix for problem #2 mentioned below.
gstreamer-scan still fails with the gthread problem, but I noticed
that it was failing for types that were defined with DEBUG, and
I notice that building gstreamer with the configure argument
--disable-gst_debug causes everything to work okay.  Not really
a fix, but at least a workaround.

Brian


Brian Cameron wrote:
> 
> Thomas/Others:
> 
> I am having some build issues with gstreamer on Solaris with Forte.
> 
> 1) in gst/parse/Makefile.am there is the following rule:
> 
>    lex._gst_parse_yy.c: parse.l grammar.tab.h
>       $(FLEX_PATH) -P_gst_parse_yy $^
> 
>    This causes a problem with Forte and generates the following error
>    message when compiling lex._gst_parse_yy.c:
> 
>    "parse.l", line 143: identifier redeclared: YYSTYPE
> 
>    I notice that the lex._gst_parse_yy.c seems to be built by
>    concatonating parse.l and grammer.tab.h.  The problem seems
>    to be that parse.l (and therefore lex._gst_parse_yy.c has
>    an include line near the top that says:
> 
>    #include "grammer.tab.h"
> 
>    But grammer.tab.h is also being concatinated at the bottom of
>    the lex._gst_parse_yy.c file.  Thus the redeclared identifier.
> 
>    I notice that if I change this rule in the Makefile.am that this
>    fixes the problem.  The original code says:
> 
>    lex._gst_parse_yy.c: parse.l grammar.tab.h
>       $(FLEX_PATH) -P_gst_parse_yy $^
> 
>    If I change that to:
> 
>    lex._gst_parse_yy.c: parse.l grammar.tab.h
>       $(FLEX_PATH) -P_gst_parse_yy parse.l
> 
>    Then, the grammer.tab.h file doesn't get concated to the end
>    of the lex._gst_parse_yy.c and everything works okay.
> 
>    I made this change and committed it, but Thomas changed it
>    back, so perhaps there is a better way to fix this?
> 
> 2) There is a problem building docs/gst/gstreamer-scan.  The make
>    displays this output:
> 
>    --make output start--
> 
>    cc -o .libs/gstreamer-scan .libs/gstreamer-scan.o -mt
>    -L/opt/gnome-2.4/lib   ../../gst/.libs/libgstreamer-0.7.so
>    -lxml2 -lz -lm -lsocket -lnsl -lgobject-2.0 -lgthread-2.0
>    -lgmodule-2.0 -ldl -lglib-2.0 -lpopt  -R/opt/gstreamer/lib
>    creating gstreamer-scan
> 
>    GLib-ERROR **: The thread system is not yet initialized.
>    aborting...
>    Scan failed
>    make: *** [scan-build.stamp] Error 255
> 
>    --make output end--
> 
>    It dumps core as well, and the stack trace is as follows:
> 
>    --stack output start--
> 
>    core 'core' of 2202:
>      /home/bc99092/build/gnome/gstreamer/gstreamer/docs/gst/.libs/lt-gstrea
>    fec9f22c _lwp_kill (6, 0, ffbfdd20, feda5114, fed86ccc, 1) + 8
>    fec369e8 abort    (2c638, 6, 2c638, 0, fed8bd1c, 0) + 100
>    fedd2560 g_logv   (fee0fe98, 4, fee0fea0, ffbfe2a8, ff3b08a8, 
> ffbfe284) + 5d8
>    fedd2660 g_log    (fee0fe98, 4, fee0fea0, ff1c0c6c, ff18f470, 1) + 40
>    fedecef8 g_thread_fail (ff1f7158, ff32510e, 0, 7efefeff, 0, 29390) + 48
>    ff1cbf40 gst_atomic_int_init (2c198, 0, 0, 0, 0, 0) + 48
>    ff1f7158 _gst_debug_category_new (ff3250e8, 2, ff3250f8, 0, 0, 0) + 140
>    ff239bc8 gst_type_find_factory_get_type (2c110, 0, 0, 0, 0, 0) + c0
>    00011e7c get_object_types (0, fecc1fb8, 30cb0, ff3c2a30, 0, ff3d6594) 
> + 20c
>    000120bc main     (1, ffbfe544, ffbfe54c, 24400, 0, 0) + 14
>    00011968 _start   (0, 0, 0, 0, 0, 0) + 108
> 
>    --stack output end--
> 
>    Since I notice that gstreamer-scan.c is built dynamically by a call to
>    gtkdoc-scangobj, it is not clear to me exactly how to fix this problem,
>    or why this problem is not seen on Linux.  Any ideas?
> 
> Thanks!
> 
> Brian
> 
> 


-- 

Brian