mingw build

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

mingw build

Pete Nagy

I'm trying to build gdal using mingw and cygwin on windows, but I get a
configure error:

checking where python Makefiles are... found
checking Python makefile... C:\Python24/lib/python2.4/config/Makefile
missing, python disabled.

I try to use prebuilt windows binaries whenever possible, and did not
build python myself.  Does anyone have any hints on getting gdal to
build with the least amount of effort?  If I just download the python
source and find this Makefile that gdal seems to be looking for, would
this be sufficient?

Thanks for any advice,

-> Pete

--------------------------------------------------------------------

====================================================================
Pete Nagy                                        tel: (303) 583-0248
Vexcel Corporation                               fax: (303) 583-0246
http://www.vexcel.com                           home: (303) 823-2336
====================================================================

_______________________________________________
Gdal-dev mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: mingw build

Eric Sokolowsky
On Fri, 16 Sep 2005, Pete Nagy wrote:

>
> I'm trying to build gdal using mingw and cygwin on windows, but I get a
> configure error:
>
> checking where python Makefiles are... found
> checking Python makefile... C:\Python24/lib/python2.4/config/Makefile
> missing, python disabled.
>
> I try to use prebuilt windows binaries whenever possible, and did not
> build python myself.  Does anyone have any hints on getting gdal to
> build with the least amount of effort?  If I just download the python
> source and find this Makefile that gdal seems to be looking for, would
> this be sufficient?

If you don't require python, just use --without-python as an option
to configure. I do this for my builds on Linux, because we don't need
to use gdal from python.
_______________________________________________
Gdal-dev mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: mingw build

Pete Nagy

Thanks Eric, but I do need python.  I'm trying to make some OpenEV
enhancements, and OpenEV uses gdal with python.

I just found a pyMinGW site
http://jove.prohosting.com/iwave/ipython/pyMinGW.html
which says that

"This project is for those who, armed with the fact that Python is itself
an open source project, have many a time asked that Python support an open
source compiler on the Windows platform."

I have found myself asking this question about project after project, as
I try to build things like vtk or openev dependencies using mingw and
cygwin.  Sigh.

Maybe I'll just make this change in linux and try to persuade Frank that
it should be added to gdal, and then just use the next windows binary
(compiled using the preferred(?!) VC)!

-> Pete

--------------------------------------------------------------------

====================================================================
Pete Nagy                                        tel: (303) 583-0248
Vexcel Corporation                               fax: (303) 583-0246
http://www.vexcel.com                           home: (303) 823-2336
====================================================================


On Fri, 16 Sep 2005, Eric Sokolowsky wrote:

> On Fri, 16 Sep 2005, Pete Nagy wrote:
>
> >
> > I'm trying to build gdal using mingw and cygwin on windows, but I get a
> > configure error:
> >
> > checking where python Makefiles are... found
> > checking Python makefile... C:\Python24/lib/python2.4/config/Makefile
> > missing, python disabled.
> >
> > I try to use prebuilt windows binaries whenever possible, and did not
> > build python myself.  Does anyone have any hints on getting gdal to
> > build with the least amount of effort?  If I just download the python
> > source and find this Makefile that gdal seems to be looking for, would
> > this be sufficient?
>
> If you don't require python, just use --without-python as an option
> to configure. I do this for my builds on Linux, because we don't need
> to use gdal from python.
> _______________________________________________
> Gdal-dev mailing list
> [hidden email]
> http://lists.maptools.org/mailman/listinfo/gdal-dev
>
_______________________________________________
Gdal-dev mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: mingw build

Pete Nagy

P.S. -

My apologies to all who have been helpful answering my questions on this
very topic the first time I tried this.  I very much appreciate those
earlier comments (Norman).  I'd like to become a configure, pkg-config and
mingw guru someday and make all this stuff easier.

Cheers,

-> Pete
_______________________________________________
Gdal-dev mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: mingw build

Mario Beauchamp
In reply to this post by Pete Nagy
Hi Pete,

Pete Nagy wrote:
> I'm trying to build gdal using mingw and cygwin on windows, but I get a
> configure error:
>
> checking where python Makefiles are... found
> checking Python makefile... C:\Python24/lib/python2.4/config/Makefile
> missing, python disabled.

When I was building GDAL on MinGW, the only way I could get the Python support was by compiling
the gdal module separately. I was using Dev-Cpp and made a makefile that did the job.

I attached it so you (and other folks who may need it) can use it as a base to write your own
makefile.

Hope this helps.
--
Mario B.

# Project: gdalpython
# Makefile created by Dev-C++ 4.9.8.7

CPP  = g++.exe
CC   = gcc.exe
WINDRES = windres.exe
RES  =
OBJ  = numpydataset.o gdalnumeric.o gdal_wrap.o $(RES)
LINKOBJ  = numpydataset.o gdalnumeric.o gdal_wrap.o $(RES)
LIBS = -mwindows -L../ -lgdal12 -L../../python23/libs -lpython23
INCS = -I../../python23/include -I/local/include
CXXINCS = -I../../python23/include -I/local/include
BIN  = _gdal.dll
CXXFLAGS = $(CXXINCS) -DHAVE_NUMPY -w -O2
CFLAGS = $(INCS) -DHAVE_NUMPY -w -O2

.PHONY: all all-before all-after clean clean-custom

all: all-before _gdal.dll all-after


clean: clean-custom
        rm -f $(OBJ) $(BIN)

DLLWRAP=g++ -shared
DEFFILE=_gdal.def
STATICLIB=lib_gdal.a

$(BIN): $(LINKOBJ)
        $(DLLWRAP) -Wl,$(DEFFILE) -Wl,-out-implib,$(STATICLIB) $(LINKOBJ) $(LIBS) -o $(BIN)

numpydataset.o: numpydataset.cpp
        $(CPP) -c numpydataset.cpp -o numpydataset.o $(CXXFLAGS)

gdalnumeric.o: gdalnumeric.cpp
        $(CPP) -c gdalnumeric.cpp -o gdalnumeric.o $(CXXFLAGS)

gdal_wrap.o: gdal_wrap.c
        $(CC) -c gdal_wrap.c -o gdal_wrap.o $(CFLAGS)

_______________________________________________
Gdal-dev mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: mingw build

Mario Beauchamp
In reply to this post by Pete Nagy
Hi Pete and list,

Pete Nagy wrote:
> P.S. -
>
> My apologies to all who have been helpful answering my questions on this
> very topic the first time I tried this.  I very much appreciate those
> earlier comments (Norman).

Seems Norman beat me to the punch once again :)

But where are those earlier comments? I didn't get that...
--
Mario B.
_______________________________________________
Gdal-dev mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: mingw build

Pete Nagy
In reply to this post by Mario Beauchamp

Thanks Mario.

Actually, as you know I have been thinking about this stuff in the context
of packaging up OpenEV for GTK2, which we cannot do until I can clean up
the build process.  I guess I would like to take advantage of as many
precompiled windows binaries for all of the dependencies, like gtk and
gdal, and at the same time provide mingw cygwin windows build capability,
since that's what I'm using.  If someone wants to use openev with their
own modified gdal driver, I guess they just need to jump through the hoops
at the time, if they use mingw.  I'm just thinking it would be nice if
every one of these packages could 'configure' + 'make install' and work.
Oh well.

By the way, Norman's advice came to me last December.  Cheers,

-> Pete

--------------------------------------------------------------------

====================================================================
Pete Nagy                                        tel: (303) 583-0248
Vexcel Corporation                               fax: (303) 583-0246
http://www.vexcel.com                           home: (303) 823-2336
====================================================================


On Fri, 16 Sep 2005, Mario Beauchamp wrote:

> Hi Pete,
>
> Pete Nagy wrote:
> > I'm trying to build gdal using mingw and cygwin on windows, but I get a
> > configure error:
> >
> > checking where python Makefiles are... found
> > checking Python makefile... C:\Python24/lib/python2.4/config/Makefile
> > missing, python disabled.
>
> When I was building GDAL on MinGW, the only way I could get the Python support was by compiling
> the gdal module separately. I was using Dev-Cpp and made a makefile that did the job.
>
> I attached it so you (and other folks who may need it) can use it as a base to write your own
> makefile.
>
> Hope this helps.
> --
> Mario B.
>
_______________________________________________
Gdal-dev mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: mingw build

Frank Warmerdam
In reply to this post by Pete Nagy
On 9/16/05, Pete Nagy <[hidden email]> wrote:

>
> Thanks Eric, but I do need python.  I'm trying to make some OpenEV
> enhancements, and OpenEV uses gdal with python.
>
> I just found a pyMinGW site
> http://jove.prohosting.com/iwave/ipython/pyMinGW.html
> which says that
>
> "This project is for those who, armed with the fact that Python is itself
> an open source project, have many a time asked that Python support an open
> source compiler on the Windows platform."
>
> I have found myself asking this question about project after project, as
> I try to build things like vtk or openev dependencies using mingw and
> cygwin.  Sigh.
>
> Maybe I'll just make this change in linux and try to persuade Frank that
> it should be added to gdal, and then just use the next windows binary
> (compiled using the preferred(?!) VC)!

Pete,

You can always configure --without-python and then fixup the
GDALmake.opt file manually.  It will require some fiddling though.

I would add that supporting two development environments
(unix-like, and win32) is already a substantial effort.  Asking for
support to build something half way between, where it is hard to
get the unix build environment to work properly (as in this case)
is a stretch.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, [hidden email]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent

_______________________________________________
Gdal-dev mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: mingw build

Mario Beauchamp
In reply to this post by Pete Nagy
Hi Pete,

Pete Nagy wrote:
> Thanks Mario.
>
> Actually, as you know I have been thinking about this stuff in the context
> of packaging up OpenEV for GTK2, which we cannot do until I can clean up
> the build process.

I thought so...

> I'm just thinking it would be nice if
> every one of these packages could 'configure' + 'make install' and work.
> Oh well.

I guess the only solution is to hack the configure script itself... but this is definitely not
my turf :)

> By the way, Norman's advice came to me last December.

Ah... it's just that sometimes I see replies to posts I didn't receive and thought it was the
case again.

Cheers,
--
Mario B.
_______________________________________________
Gdal-dev mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

mingw build, MSVCR71.DLL problem

Pete Nagy

Hello again ->

  I was able to build gdal fairly easily with mingw, but I have a python
module problem.

  On the mingw build, it is very close to working out of the box.  The
HAVE_BOOLEAN in jmorecfg.h is defined though boolean is not (see earlier
posts), and I had to use --without-pg.  --without-python was not necessary
because configure set it up that way anyway, where the mingw procedure for
python is to run:
  python setup.py build --force --compiler=mingw32 and
  python setup.py install --force
I had to use Norman Vine's setup.py as posted to the list instead of the
one provided with gdal, with the addition of os.path.join("alg") in the
INCLUDE_DIRS.

  OK, so after that, everything builds fine.  I can use gdal.dll in c++
programs, and when I open this dll in Dependency Walker everything is fine
(it depends on MSVCRT.DLL).  However, when I try to import gdal in python,
I get the error 'The procedure entry point _ctype could not be located in
the dynamic link library msvcr71.dll'.  If I open _gdal.pyd it shows that
it depends on MSVCR71.DLL, and everything comes up green except for refs
to _ctype.  Other web posts show similar problems, where it was mentioned
that MSVCR71.DLL does not have the _ctype array for use by the 'is' macros
(like isspace), so I tried to #undef all of these macros in cpl_port.h
after #include <ctype.h>, to force use of functions instead of macros, to
no avail.

  My question is, can anyone explain the use of msvcr71.dll with gdal?
This is a newer dependency; I just needed to grab it when I went to 1.2.6.
Why is it needed instead of msvcrt.dll?  Any ideas why the gdal.dll does
not have this dependency, and the python module does?  Any ideas of
workarounds?

  Thanks,

-> Pete

--------------------------------------------------------------------

====================================================================
Pete Nagy                                        tel: (303) 583-0248
Vexcel Corporation                               fax: (303) 583-0246
http://www.vexcel.com                           home: (303) 823-2336
====================================================================
_______________________________________________
Gdal-dev mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: mingw build, MSVCR71.DLL problem

Frank Warmerdam
On 9/22/05, Pete Nagy <[hidden email]> wrote:
>   My question is, can anyone explain the use of msvcr71.dll with gdal?
> This is a newer dependency; I just needed to grab it when I went to 1.2.6.
> Why is it needed instead of msvcrt.dll?  Any ideas why the gdal.dll does
> not have this dependency, and the python module does?  Any ideas of
> workarounds?

Peter,

My understanding is that MSVCR71.DLL is what is used by
Visual Studio.NET built applications and that Python 2.4 binaries
are now normally built this way.  Is it possible that switching to Python
2.4 actually introduced this requirement?

I don't know a good solution, though switching back to Python 2.3
would likely help.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, [hidden email]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent

_______________________________________________
Gdal-dev mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: mingw build, MSVCR71.DLL problem

Pete Nagy

Hi Frank ->

  It may be that python 2.4.x had something to do with it; I've seen
postings of similar problems with other packages.  Thanks.

-> Pete

--------------------------------------------------------------------

====================================================================
Pete Nagy                                        tel: (303) 583-0248
Vexcel Corporation                               fax: (303) 583-0246
http://www.vexcel.com                           home: (303) 823-2336
====================================================================


On Thu, 22 Sep 2005, Frank Warmerdam wrote:

> On 9/22/05, Pete Nagy <[hidden email]> wrote:
> >   My question is, can anyone explain the use of msvcr71.dll with gdal?
> > This is a newer dependency; I just needed to grab it when I went to 1.2.6.
> > Why is it needed instead of msvcrt.dll?  Any ideas why the gdal.dll does
> > not have this dependency, and the python module does?  Any ideas of
> > workarounds?
>
> Peter,
>
> My understanding is that MSVCR71.DLL is what is used by
> Visual Studio.NET built applications and that Python 2.4 binaries
> are now normally built this way.  Is it possible that switching to Python
> 2.4 actually introduced this requirement?
>
> I don't know a good solution, though switching back to Python 2.3
> would likely help.
>
> Best regards,
> --
> ---------------------------------------+--------------------------------------
> I set the clouds in motion - turn up   | Frank Warmerdam, [hidden email]
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush    | Geospatial Programmer for Rent
>
> _______________________________________________
> Gdal-dev mailing list
> [hidden email]
> http://lists.maptools.org/mailman/listinfo/gdal-dev
>
_______________________________________________
Gdal-dev mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: mingw build, MSVCR71.DLL problem

Pete Nagy
In reply to this post by Frank Warmerdam

Thanks to those who sent me replies on this.  As Frank said this has to do
with how the python binaries were built, and for anyone needing help with
this type of problem there is some discussion at:
http://jove.prohosting.com/iwave/ipython/issues.html

-> Pete

--------------------------------------------------------------------

====================================================================
Pete Nagy                                        tel: (303) 583-0248
Vexcel Corporation                               fax: (303) 583-0246
http://www.vexcel.com                           home: (303) 823-2336
====================================================================


On Thu, 22 Sep 2005, Frank Warmerdam wrote:

> On 9/22/05, Pete Nagy <[hidden email]> wrote:
> >   My question is, can anyone explain the use of msvcr71.dll with gdal?
> > This is a newer dependency; I just needed to grab it when I went to 1.2.6.
> > Why is it needed instead of msvcrt.dll?  Any ideas why the gdal.dll does
> > not have this dependency, and the python module does?  Any ideas of
> > workarounds?
>
> Peter,
>
> My understanding is that MSVCR71.DLL is what is used by
> Visual Studio.NET built applications and that Python 2.4 binaries
> are now normally built this way.  Is it possible that switching to Python
> 2.4 actually introduced this requirement?
>
> I don't know a good solution, though switching back to Python 2.3
> would likely help.
>
> Best regards,
> --
> ---------------------------------------+--------------------------------------
> I set the clouds in motion - turn up   | Frank Warmerdam, [hidden email]
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush    | Geospatial Programmer for Rent
>
> _______________________________________________
> Gdal-dev mailing list
> [hidden email]
> http://lists.maptools.org/mailman/listinfo/gdal-dev
>
_______________________________________________
Gdal-dev mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/gdal-dev