[gdal-dev] building gdal with python and libtool

Kai Mühlbauer kai.muehlbauer at uni-bonn.de
Mon Jun 27 14:12:45 PDT 2016


Thanks Andrew,

Am 27.06.2016 um 22:54 schrieb Andrew C Aitchison:
 > On Mon, 27 Jun 2016, Kai Mühlbauer wrote:
 >
 >> Hi all,
 >>
 >> while trying to build gdal on linux (on CircleCi in a CentOS based
 >> docker image using conda/conda-forge) like this:
 >
 >> /bin/bash -pthread -shared -L/home/sam/miniconda3/envs/_build/lib
 >> -Wl,-rpath=/home/sam/miniconda3/envs/_build/lib,--no-as-needed
 >> -L/home/sam/miniconda3/envs/_build/lib
 >> -L/home/sam/miniconda3/envs/_build/lib -m64 -Wall
 >> -Wdeclaration-after-statement -Wextra -Winit-self -Wunused-parameter
 >> -Wmissing-prototypes -Wmissing-declarations -Wformat
 >> -Werror=format-security -Wno-format-nonliteral -Wlogical-op -Wshadow
 >> -Werror=vla -Wdeclaration-after-statement -DOGR_ENABLED
 >> -I/home/sam/miniconda3/envs/_build/include
 >> -I/home/sam/miniconda3/conda-bld/work/gdal-2.1.0/port
 >> -I/home/sam/miniconda3/envs/_build/include
 >> -I/home/sam/miniconda3/envs/_build/include
 >> -I/home/sam/miniconda3/envs/_build
 >> -I/home/sam/miniconda3/envs/_build/include
 >> -I/home/sam/miniconda3/envs/_build/include
 >> -I/home/sam/miniconda3/envs/_build
 >> -I/home/sam/miniconda3/envs/_build/include
 >> -I/home/sam/miniconda3/envs/_build
 >> -I/home/sam/miniconda3/envs/_build/include -DGDAL_COMPILATION
 >> build/temp.linux-x86_64-3.4/extensions/gdal_wrap.o -L../../.libs
 >> -L../../ -L/home/sam/miniconda3/envs/_build/lib
 >> -L/home/sam/miniconda3/conda-bld/work/gdal-2.1.0/lib -lpython3.4m
 >> -lgdal -o build/lib.linux-x86_64-3.4/osgeo/_gdal.cpython-34m.so
 >> /bin/bash: -d: invalid option
 >> error: command '/bin/bash' failed with exit status 1
 >> make[2]: *** [build] Error 1
 >> make[2]: Leaving directory
 >> `/home/sam/miniconda3/conda-bld/work/gdal-2.1.0/swig/python'
 >> make[1]: *** [build] Error 2
 >> make[1]: Leaving directory
 >> `/home/sam/miniconda3/conda-bld/work/gdal-2.1.0/swig'
 >
 > I'm surprised to see python3.4 on a CentOS system;
 > I'd be very suprised if it is the default python (as
 > opposed to an additional python from SCL).
 > If I'm right, I'd guess python34 needs extra environment variables,
 > perhaps set with something like "scl python34 ..."

This is done in a conda build environment within a CentOS docker 
container. We build gdal for python 2.7, 3.4 and 3.5, IIRC. The same 
error happens with python 2.7. I can upload the complete build logs for 
all versions, if necessary.

 > But, I'm not sure how that would make bash fail like that.

The error is indicating that bash is failing, but that's a red herring. 
Between "/bin/bash" and "-pthread" the full path/filename of libtool is 
missing. I do not know why it is suddenly missing, but somehow it is. It 
worked all the time until diving into swig/python. To add more 
weirdness, the first two calls of libtool (compiling gdal_wrap.c) are 
working, but the linking command gets wrong (with the above error message).

So any help in sorting this out is appreciated.

Cheers,
Kai



More information about the gdal-dev mailing list