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 _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
