[GRASS-dev] [GRASS GIS] #165: compilation error

#165: compilation error
---------------------+------------------------------------------------------
Reporter: watti | Owner: grass-dev@lists.osgeo.org
     Type: defect | Status: new
Priority: major | Milestone: 6.3.1
Component: default | Version: svn-trunk
Keywords: |
---------------------+------------------------------------------------------
when compiling Grass 6.3 on RHEL 4 64 bit I get the following errors

Errors in:
/data/users/soi534/GRASS/grass63_release/lib/gmath
/data/users/soi534/GRASS/grass63_release/lib/imagery
/data/users/soi534/GRASS/grass63_release

going to the directories

/lib/gmath:

-gnu/svd.o -lgrass_gis -lgrass_datetime -lz -lfftw3 -lm && \
(cd /data/users/soi/GRASS/grass63_release/dist.x86_64-unknown-linux-
gnu/lib; ln -f -s libgrass_gmath.6.3.1svn.so
/data/users/soi/GRASS/grass63_release/dist.x86_64-unknown-linux-
gnu/lib/libgrass_gmath.so)
/usr/bin/ld: /usr/local/lib/libfftw3.a(mapflags.o): relocation R_X86_64_32
against `a local symbol' can not be used when making a shared object;
recompile with -fPIC
/usr/local/lib/libfftw3.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
make: *** [/data/users/soi/GRASS/grass63_release/dist.x86_64-unknown-
linux-gnu/lib/libgrass_gmath.6.3.1svn.so] Error 1

in /lib/imagery I get the error propagation

/usr/bin/ld: cannot find -lgrass_gmath

same in /lib/rst/interp_float

/usr/bin/ld: cannot find -lgrass_gmath

I use fftw-3.1.2.

Any suggestions ?

Cheers,

Martin

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/165&gt;
GRASS GIS <http://grass.osgeo.org>

#165: compilation error
----------------------+-----------------------------------------------------
  Reporter: watti | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: major | Milestone: 6.3.1
Component: default | Version: svn-trunk
Resolution: | Keywords:
----------------------+-----------------------------------------------------
Comment (by glynn):

See if you can get hold of shared FFTW libraries. Or maybe you already
have them and need to point --with-fftw-libs= to the right place.

Or you could just build --without-fftw; there are only a handful of
modules which need it (i.fft, i.ifft, i.zc, r.surf.fractal).

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/165#comment:1&gt;
GRASS GIS <http://grass.osgeo.org>

#165: compilation error
----------------------+-----------------------------------------------------
  Reporter: watti | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: major | Milestone: 6.3.1
Component: default | Version: svn-trunk
Resolution: | Keywords:
----------------------+-----------------------------------------------------
Comment (by watti):

Replying to [comment:1 glynn]:
> See if you can get hold of shared FFTW libraries. Or maybe you already
have them and need to point --with-fftw-libs= to the right place.
>
> Or you could just build --without-fftw; there are only a handful of
modules which need it (i.fft, i.ifft, i.zc, r.surf.fractal).

Hi,

I did some more research about the problem and solved it. The problem
arises from the -fPIC flag when compiling the Code. The FFTW configuration
script seems to assume it can not use -fPIC in the make file. see
http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&chap=3
for more details !

Cheers,

Martin

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/165#comment:2&gt;
GRASS GIS <http://grass.osgeo.org>

#165: compilation error
----------------------+-----------------------------------------------------
  Reporter: watti | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: major | Milestone: 6.3.1
Component: default | Version: 6.3.0
Resolution: | Keywords:
----------------------+-----------------------------------------------------
Changes (by martinl):

  * version: svn-trunk => 6.3.0

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/165#comment:3&gt;
GRASS GIS <http://grass.osgeo.org>

#165: compilation error
----------------------+-----------------------------------------------------
  Reporter: watti | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: closed
  Priority: major | Milestone: 6.3.1
Component: default | Version: 6.3.0
Resolution: invalid | Keywords:
----------------------+-----------------------------------------------------
Changes (by neteler):

  * status: new => closed
  * resolution: => invalid

Comment:

See also GRASS' INSTALL file "(C) COMPILATION NOTES for 64bit platforms"

{{{
grep fPIC INSTALL
FFTW2 library has to be compiled with -fPIC flag:
     CFLAGS="-fPIC" ./configure

}}}

Closing.

Markus

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/165#comment:4&gt;
GRASS GIS <http://grass.osgeo.org>

GRASS GIS wrote:

#165: compilation error
----------------------+-----------------------------------------------------
  Reporter: watti | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: closed
  Priority: major | Milestone: 6.3.1
Component: default | Version: 6.3.0
Resolution: invalid | Keywords:
----------------------+-----------------------------------------------------
Changes (by neteler):

  * status: new => closed
  * resolution: => invalid

Comment:

See also GRASS' INSTALL file "(C) COMPILATION NOTES for 64bit platforms"

{{{
grep fPIC INSTALL
FFTW2 library has to be compiled with -fPIC flag:
     CFLAGS="-fPIC" ./configure

}}}

Closing.

It might be worth adding a "task" for enhancing the build system to
better support static libraries.

[Or we could just refuse to support static libraries. I have no idea
why RHEL's FFTW is a static library.]

On Unix, you could make a non-PIC libfftw.a work by adding -lfftw to
each executable which uses the gmath library, and removing it from any
commands for linking shared libraries.

Adding $(FFTWLIB) to the value of GMATHLIB and removing it from the
EXTRA_LIBS setting in lib/gmath/Makefile would almost work, except
that:

1. $(GMATHLIB) is included in the definition of EXTRA_LIBS in
lib/rst/interp_float/Makefile and vector/lidar/lidarlib/Makefile, so
you would run into the same problem when building those libraries.

2. It doesn't work on Windows, where dependencies have to be satisfied
when the shared library is built. You can't omit dependencies and
leave it to the executable to satisfy them (ISTR that there are ways
to do this, but they're quite messy, and require everything to be
spelled out in detail).

To get around this, you would need to split each *LIB variable into
two versions, one for shared libraries and one for executables. Static
libraries (which normally don't contain PIC) would only be added to
the "executable" version.

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