Re: [gtk-list] Problems with i18n under SunOS 4.1.3 - X11R5

[Owen Taylor <owt1 cornell edu>]

Raphael.Quinet@eed.ericsson.se writes:

> I would like to compile the latest GTK on a machine running SunOS
> 4.1.3 and X11R5.  

I think we have to support that... (My opinion is that SunOS 4
and X11R5 probably defines the oldest machine/X11 that we should
suport)

> Well, it doesn't work...  First, I had to make some
> patches to glib/glib.h (or more exactly, glib/glib_pre2.h) because the
> function atexit() doesn't exist under SunOS and I had to use on_exit()
> instead.  I think that autoconf provides a macro for that, and it
> should be used in this case.  But as a quick hack, I changed the
> #define to:
>   #define ATEXIT(proc) (on_exit (proc, NULL))

I don't think autoconf does provide a macro. But it shouldn't be
hard to write one. (on_exit, is, I believe, a SunOS'ism, but we
might as well do things generally)

> After that, I ran into some problems with the i18n stuff.  The
> functions mblen(), mbstowcs(), mbtowc(), wcstombs() and wctomb() do
> exist in libc, but for some reason GTK is built with -DX_LOCALE, which
> is annoying because X11R5 does not have the correct functions.
> 
> I tried to configure GTK with the options "--disable-xim" and
> "--without-locale", but this has no effect.  It looks like something
> is broken in the "configure" script, but I do not know enough about
> autoconf (yet) to fix it myself.  I see that similar problems occur
> with other operating systems and other versions of X11, so hopefully
> someone will fix that soon.  ;-)

You may need --disable-xim for X11R5, but that won't disable the use
of mblen et. al. But since you have them, that shouldn't be
a problem. The problem is that the configure script is deciding
that you need -DX_LOCALE. If you could help track that down, it
would be appreciated. For starters, could you mail me the results
of 'configure' and your config.log ?

> By the way, I managed to compile GTK under Solaris 2.5.1 + X11R6, but
> I had to take care of some conflicts between <wchar.h> and <wctype.h>.

Known; will be fixed.

Regards,
                                        Owen