[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