[gst-devel] gstreamer legal patch

Brian Cameron Brian.Cameron at Sun.COM
Wed Dec 17 15:16:01 CET 2003


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






More information about the gstreamer-devel mailing list