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