[GRASS5] Re: [problems with compilation] - Javier

Hi Javier

(cc grass5)

[short intro for grass5: Javier has a problem to compile 'gstat'
against GRASS 5.0pre3 precompiled binaries which provide libgis.a and
libdatetime.a in lib/ directory]

On Wed, Mar 13, 2002 at 11:21:20AM +0100, Javier wrote:

Hello Markus & Edzer

I've tried it with gstat-2.3.6 but the problem remains the same.

I installed grass5 from the precompiled binaries in the file:
grass5.0.0pre3_i686-pc-linux-gnu_bin.tar.gz

and it seems that the source of the problem is that I have a "strange
flavour" of libgis.a. So I send you the libgis.a that comes along with this
precompiled versión and the compile error:

--------------------------------------------------------
gcc -o gstat block.o data.o direct.o fig.o fit.o getest.o gls.o glvars.o
gstat.o
lex.o lm.o map2fig.o map2gd.o mapio.o maputils.o msim.o nsearch.o ossfim.o
pale
t.o parse.o plot.o polygon.o pqueue.o predict.o random.o read.o reml.o
report.o
sample.o select.o sem.o sem_main.o sim.o stat.o ui.o userio.o utils.o
vario.o va
rio_fn.o vario_io.o writecmd.o
xvalid.o -L../lib -lmeschach -lncurses -lcsf -
L/usr/local/grass5/lib -lgis -ldatetime -lz -lm
utils.o: In function `temp_name':
utils.o(.text+0x144f): the use of `tempnam' is dangerous, better use
`mkstemp'
data.o: In function `read_grass_data':
data.o(.text+0x560f): undefined reference to `G_projection'
data.o(.text+0x5618): undefined reference to `G_projection'
data.o(.text+0x5622): undefined reference to `G_projection'
data.o(.text+0x562f): undefined reference to `G_program_name'
data.o(.text+0x563b): undefined reference to `G_program_name'
data.o(.text+0x5649): undefined reference to `G_fatal_error'
data.o(.text+0x5661): undefined reference to `G_find_file'
data.o(.text+0x5678): undefined reference to `G_program_name'
data.o(.text+0x5686): undefined reference to `G_fatal_error'
data.o(.text+0x5691): undefined reference to `G_mapset'
data.o(.text+0x569d): undefined reference to `G_fopen_sites_old'
data.o(.text+0x56b6): undefined reference to `G_program_name'
data.o(.text+0x56c4): undefined reference to `G_fatal_error'

[...]

report.o(.text+0x1073): undefined reference to `G_site_free_struct'
report.o(.text+0x11b3): undefined reference to `G_site_put'
utils.o: In function `grass':
utils.o(.text+0x1421): undefined reference to `G_gisinit'
collect2: ld returned 1 exit status
make[1]: *** [gstat] Error 1
make[1]: Saliendo directorio
`/usr/local/geoestadistica/gstat-2.3.6/gstat-2.3.6/
src'
make: *** [src/gstat] Error 2
----------------------------------------------------------------------------
----------

Best Regards
------
Javier

I tried Javier's libgis.a (as shipping with pre3 Linux binaries), and
in fact they show above problem. My local version works fine. There
are heavy size differences:

-rw------- 1 neteler ssi 348600 Mar 13 11:34 libgis.a_javier
-rw-r--r-- 1 neteler ssi 4417590 Mar 13 11:38 libgis.a

Perhaps because:
nm libgis.a_extern | grep G_projection
nm: adj_cellhd.o: no symbols
nm: align_window.o: no symbols
nm: alloc.o: no symbols
[...]

The symbols are stripped off or whatever? It seems that we have to
re-think the generation of libgis.a and libdatetime.a during compilation
for the binary package ('bindist' target in Makefile) to avoid that
problem in future. Both libraries are also needed for the GRASS/R interface
and probably other software. It may be better to automate that than adding
another manual sequence into the release_rules.txt file.

Suggestions are welcome (or a modification to the 'bindist' target?)

Markus

PS: Javier, I'll send you my libgis.a personally

Markus Neteler wrote:

[short intro for grass5: Javier has a problem to compile 'gstat'
against GRASS 5.0pre3 precompiled binaries which provide libgis.a and
libdatetime.a in lib/ directory]

[snip]

I tried Javier's libgis.a (as shipping with pre3 Linux binaries), and
in fact they show above problem. My local version works fine. There
are heavy size differences:

-rw------- 1 neteler ssi 348600 Mar 13 11:34 libgis.a_javier
-rw-r--r-- 1 neteler ssi 4417590 Mar 13 11:38 libgis.a

Perhaps because:
nm libgis.a_extern | grep G_projection
nm: adj_cellhd.o: no symbols
nm: align_window.o: no symbols
nm: alloc.o: no symbols
[...]

The symbols are stripped off or whatever? It seems that we have to
re-think the generation of libgis.a and libdatetime.a during compilation
for the binary package ('bindist' target in Makefile) to avoid that
problem in future. Both libraries are also needed for the GRASS/R interface
and probably other software. It may be better to automate that than adding
another manual sequence into the release_rules.txt file.

Suggestions are welcome (or a modification to the 'bindist' target?)

Try adding "-perm +111" to the find command in the "strip" target, so
that it only strips files with execute permission, e.g.

  ${SHELL} -c "cd ${GISBASE} ; find . -type f -perm +111 -exec strip {} \; ; true"

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

On Wed, Mar 13, 2002 at 11:17:21AM +0000, Glynn Clements wrote:

Markus Neteler wrote:

> [short intro for grass5: Javier has a problem to compile 'gstat'
> against GRASS 5.0pre3 precompiled binaries which provide libgis.a and
> libdatetime.a in lib/ directory]

[snip]

> I tried Javier's libgis.a (as shipping with pre3 Linux binaries), and
> in fact they show above problem. My local version works fine. There
> are heavy size differences:
>
> -rw------- 1 neteler ssi 348600 Mar 13 11:34 libgis.a_javier
> -rw-r--r-- 1 neteler ssi 4417590 Mar 13 11:38 libgis.a
>
> Perhaps because:
> nm libgis.a_extern | grep G_projection
> nm: adj_cellhd.o: no symbols
> nm: align_window.o: no symbols
> nm: alloc.o: no symbols
> [...]
>
> The symbols are stripped off or whatever? It seems that we have to
> re-think the generation of libgis.a and libdatetime.a during compilation
> for the binary package ('bindist' target in Makefile) to avoid that
> problem in future. Both libraries are also needed for the GRASS/R interface
> and probably other software. It may be better to automate that than adding
> another manual sequence into the release_rules.txt file.
>
> Suggestions are welcome (or a modification to the 'bindist' target?)

Try adding "-perm +111" to the find command in the "strip" target, so
that it only strips files with execute permission, e.g.

  ${SHELL} -c "cd ${GISBASE} ; find . -type f -perm +111 -exec strip {} \; ; true"

Thanks, Glynn.

I have updated the Makefile.in and also the
documents/release_rules.txt
to reflect the change.

Markus