[GRASS-user] GRASS 6.4.1RC1 wxPython problems on Solaris

GRASS GRASS user
1

Hi,

Today I compiled GRASS 6.4.1RC1 on Solaris 10 (SPARC) and encountered some problems with the wxPython-based GUI. When I try to open a preferences Dialog in Layer Manager, I get some error output (see further below) and nothing happens. This error also existed in version 6.4.0 and seems to be related to the following posts:

http://trac.osgeo.org/grass/ticket/882
http://lists.osgeo.org/pipermail/grass-user/2011-February/059569.html

My desktop is configured for a German locale and UTF-8. However, when entering "r.cost --interface-description", I get "<?xml version="1.0" encoding="646"?>" - so this might be something specific to Solaris.

I hope you can help me with this.

Thanks,

Ulli Wölfel

-----
here comes the error output:
-----

Traceback (most recent call last):
   File "/opt/local/grass-6.4.1RC1/etc/wxpython/gui_modules/l
ayertree.py", line 587, in OnPopupProperties

self.PropertiesDialog(self.layer_selected)
   File "/opt/local/grass-6.4.1RC1/etc/wxpython/gui_modules/l
ayertree.py", line 904, in PropertiesDialog

parentframe=self)
   File "/opt/local/grass-6.4.1RC1/etc/wxpython/gui_modules/m
enuform.py", line 2051, in ParseCommand

self.grass_task = self.ParseInterface(cmd)
   File "/opt/local/grass-6.4.1RC1/etc/wxpython/gui_modules/m
enuform.py", line 2022, in ParseInterface

tree = etree.fromstring(getInterfaceDescription(cmd[0]))
   File "/usr/local/lib/python2.6/xml/etree/ElementTree.py",
line 963, in XML

parser.feed(text)
   File "/usr/local/lib/python2.6/xml/etree/ElementTree.py",
line 1245, in feed

self._parser.Parse(data, 0)
xml.parsers.expat
.
ExpatError
:
XML declaration not well-formed: line 1, column 30

--
NEU: FreePhone - kostenlos mobil telefonieren und surfen!
Jetzt informieren: http://www.gmx.net/de/go/freephone

2

On Tue, Feb 22, 2011 at 3:30 PM, Ulli Wölfel <uwoelfel@gmx.de> wrote:

Hi,

Today I compiled GRASS 6.4.1RC1 on Solaris 10 (SPARC) and encountered some
problems with the wxPython-based GUI. When I try to open a preferences
Dialog in Layer Manager, I get some error output (see further below) and
nothing happens. This error also existed in version 6.4.0 and seems to be
related to the following posts:

http://trac.osgeo.org/grass/ticket/882
http://lists.osgeo.org/pipermail/grass-user/2011-February/059569.html

My desktop is configured for a German locale and UTF-8. However, when
entering "r.cost --interface-description", I get "<?xml version="1.0"
encoding="646"?>" - so this might be something specific to Solaris.

I have searched and found
http://gcc.gnu.org/ml/java/2001-05/msg00111.html
"It's the default encoding for the "C" locale."

Found also something about "charset.alias"
http://www.stata.com/support/faqs/unix/charset.html

I wonder if you have any charset.alias file on your Solaris system which
could be tuned.

Markus

3

Ulli Wölfel wrote:

Today I compiled GRASS 6.4.1RC1 on Solaris 10 (SPARC) and encountered
some problems with the wxPython-based GUI. When I try to open a
preferences Dialog in Layer Manager, I get some error output (see
further below) and nothing happens. This error also existed in
version 6.4.0 and seems to be related to the following posts:

http://trac.osgeo.org/grass/ticket/882
http://lists.osgeo.org/pipermail/grass-user/2011-February/059569.html

My desktop is configured for a German locale and UTF-8. However, when
entering "r.cost --interface-description", I get "<?xml version="1.0"
encoding="646"?>" - so this might be something specific to Solaris.

The encoding is obtained from nl_langinfo(CODESET). In this case,
"646" is probably used as a shorthand for ISO-646, which specifies
ASCII as well as national variants. I suspect that Python doesn't
accept "646" as a valid encoding.

Was GRASS configured with the --with-nls switch? If not, it will
operate in the "C" locale, which uses ASCII.

--
Glynn Clements <glynn@gclements.plus.com>

4

Am 10.03.2011 um 16:03 schrieb Glynn Clements:

Ulli Wölfel wrote:

Today I compiled GRASS 6.4.1RC1 on Solaris 10 (SPARC) and encountered
some problems with the wxPython-based GUI. When I try to open a
preferences Dialog in Layer Manager, I get some error output (see
further below) and nothing happens. This error also existed in
version 6.4.0 and seems to be related to the following posts:

http://trac.osgeo.org/grass/ticket/882
http://lists.osgeo.org/pipermail/grass-user/2011-February/059569.html

My desktop is configured for a German locale and UTF-8. However, when
entering "r.cost --interface-description", I get "<?xml version="1.0"
encoding="646"?>" - so this might be something specific to Solaris.

The encoding is obtained from nl_langinfo(CODESET). In this case,
"646" is probably used as a shorthand for ISO-646, which specifies
ASCII as well as national variants. I suspect that Python doesn't
accept "646" as a valid encoding.

Was GRASS configured with the --with-nls switch? If not, it will
operate in the "C" locale, which uses ASCII.

Thanks a lot! That was my mistake - I now recompiled it with --with-nls and it works fine.
Btw. in order to get it to compile, I had to edit include/Make/Platform.make and set INTLLIB = -lintl
Maybe this should be fixed in the configure script.

Ulli Wölfel

5

Ulli Wölfel wrote:

Btw. in order to get it to compile, I had to edit include/Make/
Platform.make and set INTLLIB = -lintl
Maybe this should be fixed in the configure script.

The configure script sets INTLLIB according to the location of the
gettext() function. If gettext() is available in the standard C lib,
INTLLIB will be empty, otherwise -lintl is tried.

What error were you getting before you changed INTLLIB? If GRASS needs
libintl for a function other than gettext(), we need to know which
one.

--
Glynn Clements <glynn@gclements.plus.com>

6

Am 11.03.2011 um 18:30 schrieb Glynn Clements:

Ulli Wölfel wrote:

Btw. in order to get it to compile, I had to edit include/Make/
Platform.make and set INTLLIB = -lintl
Maybe this should be fixed in the configure script.

The configure script sets INTLLIB according to the location of the
gettext() function. If gettext() is available in the standard C lib,
INTLLIB will be empty, otherwise -lintl is tried.

What error were you getting before you changed INTLLIB? If GRASS needs
libintl for a function other than gettext(), we need to know which
one.

It was a linking error. The undefined symbols were:
libintl_bindtextdomain
libintl_dgettext

7

Ulli Wölfel wrote:

>> Btw. in order to get it to compile, I had to edit include/Make/
>> Platform.make and set INTLLIB = -lintl
>> Maybe this should be fixed in the configure script.
>
> The configure script sets INTLLIB according to the location of the
> gettext() function. If gettext() is available in the standard C lib,
> INTLLIB will be empty, otherwise -lintl is tried.
>
> What error were you getting before you changed INTLLIB? If GRASS needs
> libintl for a function other than gettext(), we need to know which
> one.

It was a linking error. The undefined symbols were:
libintl_bindtextdomain
libintl_dgettext

Ugh. My guess is that both libc and libintl have the relevant
functions, but libintl.h provides macros which redirect to the
libintl_* versions. So configure detects that libintl isn't needed,
but the inclusion of <libintl.h> by glocale.h changes that.

Can you test the attached patch (after patching configure.in, the
configure script needs to be re-built with autoconf 2.13)?

--
Glynn Clements <glynn@gclements.plus.com>

(attachments)

libintl.patch (649 Bytes)