This is because gtksourceview requires GNU's
regex which are not on Solaris's:

  re_compile_pattern
  re_compile_fastmap
  re_search
  re_match

gtksourceview may have own src/regex.[ch] copy
from glibc-2.3, and compile it in for #ifndef __GNU__ cases.

Hidetoshi: I prefer an implementation using POSIX regular expressions.
 Can I assume they are present in Solaris' C library?

Another question: I think the definition of __GNU__ only says we are
compiling with GCC.  Do you know of any other safe way to know if we
are using the GNU libc headers?

We have 3 possible solutions :

- have a private copy of regex.[ch] as suggested by Hidetoshi
- using POSIX regex as suggested by Gustavo
- using PCRE (www.pcre.org)

Is PCRE already dstributed by Sun with Solaris?

Created attachment 16362 [details] [review]
implementation using POSIX regexps

The attached patch conditionally implements GtkSourceRegex with POSIX
regexps or GNU regexps.

Could you please test the patch in Solaris and see if it compiles and
works ok?

The POSIX implementation has a slight performance penalty due to two
missing features: a) length constraint in the regex searching; and b)
matching operation (as opossed to searching).  Nevertheless
GtkSourceView still feels fast enough, at least in my machine.

I applied the patch.  Now when I compile gtksourceregex.c, I get:

gtksourceregex.c: In function `gtk_source_regex_compile':
gtksourceregex.c:200: structure has no member named `translate'
gtksourceregex.c:201: structure has no member named `fastmap'
gtksourceregex.c:202: structure has no member named `allocated'
gtksourceregex.c:203: structure has no member named `buffer'
gtksourceregex.c:204: structure has no member named `can_be_null'
gtksourceregex.c:205: structure has no member named `no_sub'
gmake[4]: *** [gtksourceregex.lo] Error 1

Created attachment 16369 [details] [review]
corrected patch

Sorry about that.  Those lines were left from the GNU regexp
implementation.  Could you please try this new patch instead?  Thanks.

Ok, with the new patch it compiles ok.  I then compiled gedit-2.3.1
and gedit-plugins-2.3.1.  I can't tell if gtksourceview is
working...if I open a .c file in gedit, it doesn't color-tag anything.
 Is there something else I need to do to test it?

Try to run the test-widget program in the tests directory.

Which icon do gedit show you in the tab?

I'm wondering if gedit is getting the right mime type.

if I run the test-widget for gtksourceview, I get a window with a c
source file.  None of the syntax is color-highlighted, all of the text
is b/w.

In gedit, when I open a .c file, the tiny icon for the file is visibly
different from a random text file.

Does test-widget print some text on the console?

Here's the console output:

bugs{poshea}53: ./test-widget

(lt-test-widget:21172): GLib-GObject-CRITICAL **: file gobject.c: line
1337 (g_object_unref): assertion `G_IS_OBJECT (object)' failed

(lt-test-widget:21172): GLib-GObject-CRITICAL **: file gobject.c: line
1337 (g_object_unref): assertion `G_IS_OBJECT (object)' failed
Finalize lang: Ada
Finalize lang: C
Finalize lang: C++
Finalize lang: Diff
Finalize lang: .desktop
Finalize lang: HTML
Finalize lang: IDL
Finalize lang: Java
Finalize lang: Latex
Finalize lang: Perl
Finalize lang: gettext translation
Finalize lang: Python
Finalize lang: XML
bugs{poshea}54: 

Nothing is highlighted probably because the Solaris' regex
implementation doesn't understand our regular expressions.

We use a pair of GNU extensions, and some of them don't have a POSIX
counterpart (word boundary operator for example) as I've just come to
notice.

So, we have no other choice but to include GNU's regex library as
Hidetoshi first suggested.  The other alternative would be to use
PCRE, but that would add another dependency to the Gnome Desktop,
which is not something we can do now.

I'll work a patch to compile the GNU regex library on systems which
don't use the GNU implementation.

Gustavo: BTW, I think the still relevant part of your patch should go in.

Paolo: ok, agreed.

Peter: those warnings in the console output of test-widget don't seem
related to this bug.  Could you please run test-widget with
--g-fatal-warnings and attach the resulting backtrace?  Thanks.

Created attachment 16402 [details]
updated patch

The attached file is a gzipped patch.  The patch does the following:

a) includes a GNU regex implementation (copied verbatim from glibc
2.3.2) in a gnu-regex directory
b) detects at configure time if the C library has the GNU regex API
and otherwise sets a conditional to build and link to the private library
c) abstracts GtkSourceRegex by hiding its members, so we can later
change the regex implementation if we have to
d) changes the regular expression syntax used for POSIX extended + GNU
operators
e) changes the c.lang file to the chosen regex syntax

I only ported the c.lang to the POSIX extended syntax, so other
mimetypes will not be highlighted after this patch is applied.

I'm not sure if the conditional part is right.  It works in my
machine, but if somebody could double check configure.in and
Makefile.am files I would really appreciate it.

Could you please see if this compiles and works for you?  If this is
ok, I'll port the rest of the .lang files and commit.  Thanks.

I applied the new patch to the original source, and it fails during
compile with the below output:
Undefined                       first referenced
 symbol                             in file
re_match                           
../gtksourceview/.libs/libgtksourceview-1.0.so
re_syntax_options                  
../gtksourceview/.libs/libgtksourceview-1.0.so
re_compile_fastmap                 
../gtksourceview/.libs/libgtksourceview-1.0.so
re_compile_pattern                 
../gtksourceview/.libs/libgtksourceview-1.0.so
re_search                          
../gtksourceview/.libs/libgtksourceview-1.0.so
ld: fatal: Symbol referencing errors. No output written to
.libs/test-widget


If I go into the gtksourceview/gnu-regex subdir, I see that there's on
ly a Makefile.am, no Makefile, and none of the files have been
compiled.  Is there some additional configure bit needed?

Did the patch apply cleanly?  And did you re-run autogen.sh
afterwards?  It's weird because Makefile in gnu-regex directoy should
have been generated irregardless of whether it is used or not, and if
it's missing the build should have failed before trying to build the
tests.

If this is not the problem, could you please attach your config.log
file?  Could be that the test in configure.in for the GNU regex API is
wrong.

The patch applied cleanly, but I didn't know I needed to run
autogen.sh.  I don't have autogen.sh, and it isn't included in the
gtksourceview distribution.  Remember, this is a Solaris system that
doesn't have a complete set of Gnu build tools.  I rely on a working
configure program, not a configure.in.

I've just committed a patch which should fix this issue.  I already
checked with Peter and it seems to work for him.  Could somebody else
running Solaris (without GNU C library) please try latest CVS version
and tell me if it compiles and works fine?  Thanks.

I confirmed the patch has fixed compilation error on
my Solris 9 x86 box. 

I also built and ran a gedit with patched gtksourceview. 
With C source code opened, hightlighting with colors
seems to work fine.

I'd agree to mark this fixed.

Marking fixed then.  Thanks.

*** Bug 115491 has been marked as a duplicate of this bug. ***