[Gdal-dev] Problems compiling 1.4.0 with intel 9.0 compilers

[Huw Lynch]

Hi

I've had to work through some problems compiling gdal 1.4.0 with the intel v9.1 compilers (specifically 9.1.043) that I though others may encounter too. I am not sure if the problems are related to my particular environment or to the GDAL build scripts. Here goes anyway;

1. during the configure stage the configure script tests the compiler for _GNU* #defs to decide whether it is invoking the GNU C compiler or not. By default the Intel C compilers define these flags for GNU compatibility. configure ends up deciding that it is invoking GNU C by another name, so starts invoking gcc directly, at which point it is using GCC and no longer doing what I want.

To work around this set the following environment variables;

    CC=icc # you must already have this!
    CFLAGS="-gcc-version=330 -no-gcc"
    CXXFLAGS="-gcc-version=330 -no-gcc"

The -no-gcc stops icc from pre-defining the _GNU #defs and avoids the configure confusion.

2. During make install the ngpython build fails. It attempts to invoke a C compiler but leaves out the compiler name (ie no gcc or icc in the command line). This results in an error "invalid option -d" (reported by /bin/sh when trying to handle args intended for a compiler).

3. Compilation of the swig python glue files fails with lots of pre-processor related logic regarding _GNU #defs. The swig code uses lots of #def checks for GNU compiler versions.

To fix 2 and 3 I had to do the following;

  - manually edit swig/python/GNUmakefile to add AFTER include ../../GDALmake.opt;
     CFLAGS="-w -gcc-version=330"     # this un-does part of what we did in the fix for (1)
  - after running a make install (which will still fail with "invalid option -d")
     cd swig/python
     CC=icc CFLAGS="-w -gcc-version=330" python setup.py install 

I could not figure out why it is necessary to invoke the python setup.py install step out-side the make install job, but this is the only way I could get the compiler choice to be enacted correctly.

Cheers
     



    

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20070207/0417f25d/attachment.html