[GRASS5] release branch testers wanted (tarball provided)

Markus_Neteler1 · August 22, 2002, 4:05pm

Hi,

I have written an build-script which follows the release_rules
for binaries and
- downloads the release_branch from cvs
- builds GRASS without PostgreSQL support (needed for NVIZ)
- builds in a next step the PostgreSQL modules
- packages everything

The result is the common tarball with install script.
It runs fully automated.

So I would like to know if someone could test this tarball:

http://mpa.itc.it/markus/tmp/grass5_i686-pc-linux-gnu_install.sh
http://mpa.itc.it/markus/tmp/grass5.0.0_test_RB20020822_i686-pc-linux-gnu_bin.tar.gz
36695777 bytes, Release branch from today, 22 Aug 2002.

Since we want to get out the stable version the next days (at
least me), some people should test above.
Later we can use the script to post binaries on the web,
I can provide that for GNU/Linux/ix86 and maybe Solaris/SUN.

Cheers,

Markus

Andreas_C_Lange · August 22, 2002, 6:19pm

Markus Neteler wrote:

Hi,

I have written an build-script which follows the release_rules
for binaries and
- downloads the release_branch from cvs
- builds GRASS without PostgreSQL support (needed for NVIZ)
- builds in a next step the PostgreSQL modules
- packages everything

The result is the common tarball with install script.
It runs fully automated.

So I would like to know if someone could test this tarball:

http://mpa.itc.it/markus/tmp/grass5_i686-pc-linux-gnu_install.sh
http://mpa.itc.it/markus/tmp/grass5.0.0_test_RB20020822_i686-pc-linux-gnu_bin.tar.gz
36695777 bytes, Release branch from today, 22 Aug 2002.

Since we want to get out the stable version the next days (at
least me), some people should test above.
Later we can use the script to post binaries on the web,
I can provide that for GNU/Linux/ix86 and maybe Solaris/SUN.

Hi,

installation on Red Hat Linux 7.0 was successful. tcltkgrass starts, i
tested the usual things (d.mon, g.region, d.rast, d.vect, d.sites, some
others). But i have currently not the time for a closer inspection of
the modules (nviz, pgsql etc.).

I think the tcltkgrass d.scale error needs to be fixed (see bugreport).

Andreas

--
Andreas Lange, 65187 Wiesbaden, Germany, Tel. +49 611 807850

Stephan_Holl2 · August 23, 2002, 6:17am

At Thu, 22 Aug 2002 18:05:49 +0200 Markus Neteler wrote:

Hello Markus

The result is the common tarball with install script.
It runs fully automated.

So I would like to know if someone could test this tarball:

http://mpa.itc.it/markus/tmp/grass5_i686-pc-linux-gnu_install.sh
http://mpa.itc.it/markus/tmp/grass5.0.0_test_RB20020822_i686-pc-linux-gnu_bin.tar.gz
36695777 bytes, Release branch from today, 22 Aug 2002.

The installation procedure finishes without any errors, but I could not
start until I set the correct $GISBASE in $DESTDIR/grass5. It pointed to
/tmp/grass5bin_cvsTMP/grass5. also the file $BINDIR/grass$NAME_VER was
empty. I am using debian testing on amd athlon

Perhaps I should say, that I changed the variable $NAME_VER from
NAME_VER=5 to NAME_VER=5_stable in grass5_i686-pc-linux-gnu_install.sh
in order to keep my running GRASS installation clean and working

But after cleaning up this difficulties I could launch GRASS as usual.
- tcltkgrass works
- db.* modules work
- d.*.pg work
- nviz does _not_ launch -> it says that something relating to wish
couldn't be found, but my usuall GRASS_intallation can start nviz
without probs.

perhaps I should try to build on my maschine?

cheers
stephan

--
--------------------------------------
Stephan Holl
GnuPG Key-ID: 11946A09
ICQ# 117277975
--------------------------------------

Markus_Neteler1 · August 23, 2002, 8:11am

Hi Stephan,

On Fri, Aug 23, 2002 at 08:17:41AM +0200, Stephan Holl wrote:

At Thu, 22 Aug 2002 18:05:49 +0200 Markus Neteler wrote:
Hello Markus
> The result is the common tarball with install script.
> It runs fully automated.
>
> So I would like to know if someone could test this tarball:
>
> http://mpa.itc.it/markus/tmp/grass5_i686-pc-linux-gnu_install.sh
> http://mpa.itc.it/markus/tmp/grass5.0.0_test_RB20020822_i686-pc-linux-gnu_bin.tar.gz
> 36695777 bytes, Release branch from today, 22 Aug 2002.

The installation procedure finishes without any errors, but I could not
start until I set the correct $GISBASE in $DESTDIR/grass5. It pointed to
/tmp/grass5bin_cvsTMP/grass5. also the file $BINDIR/grass$NAME_VER was
empty. I am using debian testing on amd athlon

this is strange. The default settings should be
NAME_VER=5
BINDIR=/usr/local/bin
DESTDIR=/usr/local/grass$NAME_VER

as defined at top of the script. There *is* defined
/tmp/grass5bin_cvsTMP/grass5 on top of the script, but that's not
used.

Perhaps I should say, that I changed the variable $NAME_VER from
NAME_VER=5 to NAME_VER=5_stable in grass5_i686-pc-linux-gnu_install.sh
in order to keep my running GRASS installation clean and working

Should not be neccessary, since there is a test if /usr/local/grass5 already
exists.

But after cleaning up this difficulties I could launch GRASS as usual.
- tcltkgrass works
- db.* modules work
- d.*.pg work

good.

- nviz does _not_ launch -> it says that something relating to wish
couldn't be found, but my usuall GRASS_intallation can start nviz
without probs.

Strange again. Could you please cp/paste the error message?

perhaps I should try to build on my maschine?

This will certainly work. But we have to test, if such builds run
on a different machine. I have Redhat 7.x (how to find out?)

Linux thuille 2.4.9-31smp #1 SMP Tue Feb 26 06:55:00 EST 2002 i686 unknown

with a lot of locally updated libs which may cause compatibility problems.
Next I'll try my script on grass.itc.it with standard libs.

Thanks again for testing.
I also found that I have to implement gdal compilation into my build-script.

Markus

Sergiusz_Pawlowicz1 · August 26, 2002, 9:18am

--->[Quoting Markus Neteler <neteler@itc.it>:]

Since we want to get out the stable version the next days (at
least me), some people should test above.
Later we can use the script to post binaries on the web,

There is good idea to prepare standard test templates.

cheers - Sergiusz
--
private: http://ibiblio.org/ser/ company: http://it-zone.org/
______________________________________________________________
on wallpaper: tldp.org, gnu.org, pld-linux.org, hyperreal.info

Markus_Neteler1 · August 26, 2002, 2:50pm

As a follow-up:

my build-script now compiles separated a 24bit PNG driver:
http://mpa.itc.it/markus/tmp/pngdriver24_i686-pc-linux-gnu.tar.gz
(65kb)

Installation (PNG driver upgrade from 8bit to 24bit):
1. start grass5
2. cd $GISBASE
3. mv driver/PNG driver/PNG.8bit
4. tar xvfz pngdriver24_i686-pc-linux-gnu.tar.gz

I had to hardcode library paths inside, please let
me know if you get it working (ldd may help).

Markus

mlennert · August 26, 2002, 3:55pm

On Mon, Aug 26, 2002 at 04:50:34PM +0200, Markus Neteler wrote:

As a follow-up:

my build-script now compiles separated a 24bit PNG driver:
http://mpa.itc.it/markus/tmp/pngdriver24_i686-pc-linux-gnu.tar.gz
(65kb)

Installation (PNG driver upgrade from 8bit to 24bit):
1. start grass5
2. cd $GISBASE
3. mv driver/PNG driver/PNG.8bit
4. tar xvfz pngdriver24_i686-pc-linux-gnu.tar.gz

I had to hardcode library paths inside, please let
me know if you get it working (ldd may help).

On my Debian 3.0 I had to do

ln -s /usr/lib/libgd.so /usr/local/lib

and now I get

error while loading shared libraries: libpng12.so.0

but I have

/usr/lib/libpng.a
/usr/lib/libpng.so -> libpng.so.2
/usr/lib/libpng.so.2 -> libpng.so.2.1.0.12
/usr/lib/libpng.so.2.1.0.12
/usr/lib/libpng.so.3 -> libpng.so.3.1.2.1
/usr/lib/libpng.so.3.1.2.1

When I try

ln -s /usr/lib/libpng.so.2 /usr/lib/libpng12.so.0

the driver seems to function, but I get a black&white image, even though GRASS_TRUECOLOR=TRUE.

When I try

ln -s /usr/lib/libpng.so.3 /usr/lib/libpng12.so.0

I get

GRASS:~ > d.mon stop=PNG
libpng warning: Application was compiled with png.h from libpng-1.0.12
libpng warning: Application is running with png.c from libpng-1.2.1
gd-png: fatal libpng error: Incompatible libpng version in application and library
Monitor 'PNG' terminated

Moritz

Markus_Neteler1 · August 26, 2002, 4:16pm

On Mon, Aug 26, 2002 at 05:55:37PM +0200, Moritz Lennert wrote:

On Mon, Aug 26, 2002 at 04:50:34PM +0200, Markus Neteler wrote:
> As a follow-up:
>
> my build-script now compiles separated a 24bit PNG driver:
> http://mpa.itc.it/markus/tmp/pngdriver24_i686-pc-linux-gnu.tar.gz
> (65kb)
>
> Installation (PNG driver upgrade from 8bit to 24bit):
> 1. start grass5
> 2. cd $GISBASE
> 3. mv driver/PNG driver/PNG.8bit
> 4. tar xvfz pngdriver24_i686-pc-linux-gnu.tar.gz
>
> I had to hardcode library paths inside, please let
> me know if you get it working (ldd may help).
>

Thanks for the quick test!

On my Debian 3.0 I had to do

ln -s /usr/lib/libgd.so /usr/local/lib

and now I get

error while loading shared libraries: libpng12.so.0

yes, expected
It is a mess with GD and version numbering.

but I have

/usr/lib/libpng.a
/usr/lib/libpng.so -> libpng.so.2
/usr/lib/libpng.so.2 -> libpng.so.2.1.0.12
/usr/lib/libpng.so.2.1.0.12
/usr/lib/libpng.so.3 -> libpng.so.3.1.2.1
/usr/lib/libpng.so.3.1.2.1

I have:

/usr/lib/libpng.so.2.1.0.13
/usr/lib/libpng.so.2
/usr/lib/libpng.so.3.1.2.2
/usr/lib/libpng.so.3
/usr/lib/libpng.a
/usr/lib/libpng.so

When I define -lpng it still picks up libpng12.so.0:
ldd grass5.0.0relcand/dist.i686-pc-linux-gnu/driver/PNG
[...]
/usr/local/lib/libgd.so => /usr/local/lib/libgd.so (0x40025000)
libpng12.so.0 => /usr/lib/libpng12.so.0 (0x400b4000)

There is a possibility for me to change the machine which is
in a cleaner state. I have to try later.

When I try

ln -s /usr/lib/libpng.so.2 /usr/lib/libpng12.so.0

the driver seems to function, but I get a black&white image, even though GRASS_TRUECOLOR=TRUE.

brrr.

When I try

ln -s /usr/lib/libpng.so.3 /usr/lib/libpng12.so.0

I get

GRASS:~ > d.mon stop=PNG
libpng warning: Application was compiled with png.h from libpng-1.0.12
libpng warning: Application is running with png.c from libpng-1.2.1
gd-png: fatal libpng error: Incompatible libpng version in application and library
Monitor 'PNG' terminated

Ok, I'll try on another machine (gd2 is currently missing there).

Thanks again,

Markus

Glynn_Clements · August 26, 2002, 11:38pm

Markus Neteler wrote:

my build-script now compiles separated a 24bit PNG driver:

I had to hardcode library paths inside

Hardcoding paths doesn't fix anything; it just makes it look that way
to you (because your /usr/local/lib/libgd.so is GD 2.x).

The right approach is to give the GD 2.x library a soname of
"libgd.so.2", by adding "-Wl,-soname,libgd.so.2" to the linking flags.

It should also have dependency information, which is obtained by
adding the necessary "-l" switches to the link command (although this
isn't strictly necessary; configure should handle all of the many
possible combinations of optional libraries).

Realistically, we need to provide a fixed version of GD 2.x along with
the 24-bpp version of the PNG driver.

The alternative is to simply state that GD 2.x is unsupported, until
either the GD developers fix the problems, or OS vendors start
shipping GD 2.x (the OS vendors will handle the version problems
themselves if the GD developers don't).

--
Glynn Clements <glynn.clements@virgin.net>

Markus_Neteler1 · August 27, 2002, 7:12am

On Tue, Aug 27, 2002 at 12:38:41AM +0100, Glynn Clements wrote:

Markus Neteler wrote:

> my build-script now compiles separated a 24bit PNG driver:

> I had to hardcode library paths inside

Hardcoding paths doesn't fix anything; it just makes it look that way
to you (because your /usr/local/lib/libgd.so is GD 2.x).

The right approach is to give the GD 2.x library a soname of
"libgd.so.2", by adding "-Wl,-soname,libgd.so.2" to the linking flags.

Thanks for this hint! But were to add it (sorry, speak slowly please).
I tried to add it in PNGdriver/Gmakefile but it still picks up
the wrong lib:

gmake5
[...]
gcc -L/hardmnt/thuille1/ssi/cvsgrass_exp/src/libes/LIB.i686-pc-linux-gnu -o
/ssi0/ssi/neteler/cvsgrass_exp/dist.i686-pc-linux-gnu/driver/PNG
OBJ.i686-pc-linux-gnu/Can_do.o OBJ.i686-pc-linux-gnu/Clr_table.o
OBJ.i686-pc-linux-gnu/Color.o OBJ.i686-pc-linux-gnu/Draw_line.o
OBJ.i686-pc-linux-gnu/Get_w_box.o OBJ.i686-pc-linux-gnu/Get_w_line.o
OBJ.i686-pc-linux-gnu/Get_w_pnt.o OBJ.i686-pc-linux-gnu/Graph_Clse.o
OBJ.i686-pc-linux-gnu/Graph_Set.o OBJ.i686-pc-linux-gnu/Panel.o
OBJ.i686-pc-linux-gnu/Polygn_abs.o -ldriver -lgis -lz -L/usr/local/lib
-lgd -lfreetype -ljpeg -lpng -lz -lm -Wl,-soname,libgd.so.2

[sorry, I don't know anything about this soname trick]

ldd /ssi0/ssi/neteler/cvsgrass_exp/dist.i686-pc-linux-gnu/driver/PNG
libgd.so => /usr/lib/libgd.so (0x40017000)

ls -l /usr/lib/libgd.so
lrwxrwxrwx 1 root root 14 Aug 1 2001 /usr/lib/libgd.so -> libgd.so.1.8.3

It should also have dependency information, which is obtained by
adding the necessary "-l" switches to the link command (although this
isn't strictly necessary; configure should handle all of the many
possible combinations of optional libraries).

Realistically, we need to provide a fixed version of GD 2.x along with
the 24-bpp version of the PNG driver.

The alternative is to simply state that GD 2.x is unsupported, until
either the GD developers fix the problems, or OS vendors start
shipping GD 2.x (the OS vendors will handle the version problems
themselves if the GD developers don't).

Well, even for us here at IRST I need a solution, an 8bit PNG driver
ist just too poor.

Markus

Markus_Neteler1 · August 27, 2002, 9:31am

Hi all,

now we have a NVIZ with PGSQL support:
http://mpa.itc.it/markus/tmp/nviz_postgresql_i686-pc-linux-gnu.tar.gz
(270kb)

NVIZ with PSQL support installation:
  1. start grass5
  2. cd $GISBASE
  3. tar xvfz nviz_postgresql_i686-pc-linux-gnu.tar.gz

Moritz tested so far, it opens after setting some links:

On Tue, Aug 27, 2002 at 10:56:18AM +0200, Moritz Lennert wrote:

Nach

ln -s /usr/lib/libtk8.3.so /usr/lib/libtk.so.0

und

ln -s /usr/lib/libtcl8.3.so /usr/lib/libtcl.so.0

started nviz normal.

well, I feel that I should not hardcode the tcl/tk version
numbers.

Can anyone test if the PGSQL stuff works inside NVIZ (see
"What's here" menu entry).

Thanks,

Markus

Glynn_Clements · August 27, 2002, 3:14pm

Markus Neteler wrote:

> > my build-script now compiles separated a 24bit PNG driver:
>
> > I had to hardcode library paths inside
>
> Hardcoding paths doesn't fix anything; it just makes it look that way
> to you (because your /usr/local/lib/libgd.so is GD 2.x).
>
> The right approach is to give the GD 2.x library a soname of
> "libgd.so.2", by adding "-Wl,-soname,libgd.so.2" to the linking flags.

Thanks for this hint! But were to add it (sorry, speak slowly please).

In the GD 2.x Makefile; replace:

ld -shared -o libgd.so.${VERSION} ${LIBOBJS}
with:
ld -shared -soname libgd.so.${MAJOR_VERSION} -o libgd.so.${VERSION} ${LIBOBJS}

The net result is that any program which is linked against the library
will depend upon "libgd.so.2" rather than just "libgd.so":

libgd.so.2 => /usr/local/lib/libgd.so.2 (0x4001c000)

--
Glynn Clements <glynn.clements@virgin.net>

Glynn_Clements · August 27, 2002, 3:31pm

Markus Neteler wrote:

> ln -s /usr/lib/libtk8.3.so /usr/lib/libtk.so.0
>
> und
>
> ln -s /usr/lib/libtcl8.3.so /usr/lib/libtcl.so.0
>
> started nviz normal.

well, I feel that I should not hardcode the tcl/tk version
numbers.

You don't really have much choice; while the Tcl-level functionality
(i.e. the Tcl language and the Tcl bindings for Tk) remains compatible
between versions, the C-level interface changes significantly between
minor versions; particularly for Tk, and even more so for any code
which creates its own Tk widgets (e.g. Togl, the Tk-OpenGL widget used
by NVIZ).

If a binary was compiled for Tcl/Tk 8.3, it will only run with Tcl/Tk
8.3 libraries. And, while Tcl/Tk's version scheme (including the
version in the base name rather than as a version, e.g. libtk.so.8.3)
isn't the one which most libraries use, my experience is that the
Tcl/Tk libraries tend to versioned in this way consistently across
various operating systems.

--
Glynn Clements <glynn.clements@virgin.net>