GRASS GIS wrote: > #165: compilation error > ----------------------+----------------------------------------------------- > Reporter: watti | Owner: [email protected] > 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 <[EMAIL PROTECTED]> _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
