[gdal-dev] GDAL python bindings build error (gcc command replaced by bash)

[Even Rouault]

Le mercredi 02 novembre 2016 12:19:23, Kai Muehlbauer a écrit :
> Am 02.11.2016 um 11:00 schrieb Even Rouault:
> > Le mercredi 02 novembre 2016 10:48:32, Kai Muehlbauer a écrit :
> >> Hi Even,
> >> 
> >> Am 01.11.2016 um 16:32 schrieb Even Rouault:
> >>> Le vendredi 01 juillet 2016 13:17:54, Kai Muehlbauer a écrit :
> >>>> Hi James,
> >>>> 
> >>>> I did experience the same issue. See
> >>>> 
> >>>> https://lists.osgeo.org/pipermail/gdal-dev/2016-July/044678.html
> >>>> 
> >>>> Although I did not find the root cause of this, I found that in my use
> >>>> case, copying and unsetting CC and CXX environment variables did the
> >>>> trick.
> >>>> 
> >>>> So what I did is:
> >>>> 
> >>>> export CF_CC=$CC
> >>>> export CF_CXX=$CXX
> >>>> unset CC CXX
> >>>> ./configure CC=$CF_CC \
> >>>> 
> >>>>              CXX=$CF_CXX \
> >>>>              --prefix=$PREFIX
> >>>> 
> >>>> make
> >>>> 
> >>>> Hoping for more insight by gdal-devs.
> >>> 
> >>> I've just hit that issue too and pushed
> >>> https://trac.osgeo.org/gdal/changeset/36067 to fix/workaround it.
> >>> By instrumenting Python distutils code, I concluded that this is a bad
> >>> interaction between the CXX variable of the GDALmake.opt and Python
> >>> distutils when CXX is made of several "words" (that occurs only when
> >>> CXX is defined in the environment too, whatever its value ! Which is
> >>> probably a standard GNU make behaviour)
> >>> 
> >>> James, if you still have a tree with the configuration that hit the
> >>> issue, could you have a look at the value of the CXX variable in
> >>> GDALmake.opt ? From the error message, it would seem that there is
> >>> /bin/bash in it, which is a bit surprising.
> >>> 
> >>> Even
> >> 
> >> I took the chance to run the two builds I mentioned in my above linked
> >> list-email once again.
> >> 
> >> GDALmake.opt is identical in both working and breaking version.
> > 
> > Yes that depends if CXX is defined or not as environmenet variable.
> > 
> >> Excerpt:
> >> 
> >> SHELL    =   /bin/sh
> >> LIBTOOL	=	$(SHELL) $(top_builddir)/libtool
> >> LIBTOOL_COMPILE_CC =	$(LIBTOOL) --mode=compile --tag=CC
> >> LIBTOOL_COMPILE_CXX =	$(LIBTOOL) --mode=compile --tag=CXX
> >> CC	=	$(LIBTOOL_COMPILE_CC) gcc
> >> CXX	=	$(LIBTOOL_COMPILE_CXX) g++
> >> 
> >> The only difference (for working and breaking) after running
> >> 
> >> $ ./configure --prefix=/usr/local --with-python
> >> 
> >> is within config.log and config.status.
> > 
> > ok, this is a libtool build, so CXX will expand to "/bin/sh libtool  --
> > mode=compile --tag=CXX g++".
> 
> Even,
> 
> I applied your workaround to setup.py, but some calls differ (eg.
> -pthread is missing). I'll attach gdal-working.txt (no CC, CXX set in
> env), gdal-breaking.txt (CC, CXX set in env) and gdal-workaround.txt
> (CC, CXX set in env, with applied workaround) which contain the python
> build logs.
> 
> Is the missing -pthread problematic?

I don't think so. We could also apply the same logic for CC as the one I added 
for CXX if it proved to be needed.

> 
> - Kai

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com