[gdal-dev] gdal on cygwin

Marco Atzeri marco.atzeri at gmail.com
Mon Apr 25 05:35:00 PDT 2016


On 25/04/2016 13:02, Even Rouault wrote:
> Le lundi 25 avril 2016 12:46:36, Marco Atzeri a écrit :
>> Dear developers,
>>
>> building and testing latest 2.1.0 RCx on cygwin
>> enabling perl and python I hit some very curious build
>> issues:
>>
>> 1)
>> The configure requires that CXX is not defined for
>> building the python swig system
>> It seems a old issue not cygwin specific:
>> http://www.michael-joost.de/gdal_install.html
>
> The link doesn't work for me.

It works fine for me from two different networks.
His comment was:

"So, the solution is to
unset CC CPP CXX
before configure/make."

and he is referring to "versions 1.8 thru 1.10.1"

>>
>> It is an annoy issue impacting I suspect most of the
>> distribution build systems that usually predefine
>> variables like CXX. I lost several hours to
>> overcome the puzzling behavior of the build.
>
> What's the solution ? Any upstreamable patch ? Looking quickly we don't seem
> to do anything particular regarding the compiler for Python extension building
> and rely on distutils.command.build_ext
>
>>
>> 2)
>> I tried to overcome #1 using in autogen.sh
>> libtoolize --force --copy
>> aclocal --force -I ./m4
>> but it results in a cripple libtool, totally unusable.
>>
>> Any hope for a full working autoreconf ?
>
> I'm not sure how much effort woul be involved. GDAL autoconf stuff is rather ad-
> hoc.

I noticed. It seems a strange hybrid.
Building outside the source tree is also not expected

>> 3)
>> On ogr/ogrct.cpp there is a strange assumption that
>> shared lib will never be bumped
>>
>> #elif defined(__CYGWIN__)
>> #  define LIBNAME      "cygproj-0.dll"
>>
>> unfortunately current one is  /usr/bin/cygproj-9.dll
>> and previous was already /usr/bin/cygproj-1.dll.
>> Should be better to link with "-lproj" instead of assuming to
>> know the library name ?
>
> You can ./configure --with-static-proj4 (which, as not obvious in the name,
> also work with proj shared objects :-) "static" here means linking at build
> time, vs the default way which is at runtime) for more classic linking

As cygwin package maintainer (also of proj) , I abhor the word "static".
I will try such option. To see if solve the issue or I need to patch
the code..

Regards
Marco


More information about the gdal-dev mailing list