You're aware that OSGEO4w python gdal bindings are python 2.7 right? I haven't actually seen working in the wild python gdal with python 3+ (though it might exist, sounds like you might have built it).
As for dll madness, its often unclear what dll comes from where and what it does. I'm not surprised that random things conflict with no obvious reason. Since you're using Virtual Machines, have you considered just using a linux VM, all this is pretty simple to setup under that. We even have one with all the goodies included http://live.osgeo.org Enjoy, Alex On 06/13/2012 12:25 AM, Casper Børgesen (CABO) wrote: > I finally got time to work on this problem again. Using the famous Dependency > Walker, I found that on my local machine (which has a normal installation of > GDAL 1.9 and Python3.2) that libeay32.dll also is part of the problem with > importing GDAL, though here GDAL+Python actually works. That installation is > not through OSGEO though! > > I have several virtual machines (various configurations) where I want to do > some batch processing. I have placed Python 3.2 and GDAL 1.9 on a network > path. Using a batch script I setup the PATH to point at the GDAL and the > Python folder on the network drive. This leads me to the same problem as with > OSGEO, though the dependency walker complains about MSVCP100.dll, > MSVCR100.dll and IESHIMS.dll (Error opening file. The system cannot find the > file specified (2).). > > From other posts I gather that the IESHIMS.dll file is related to Internet > Explorer, but I fail to see what GDAL and IE has to do with each other. Thus > I find it hard to determine what exactly that Dependency Walker is telling me. > > Exactly what folders is required on the PATH to get Python and GDAL to be > able to work together? Import GDAL in the Python console only gives me > "ImportError: DLL load failed: The specified module could not be found." > while referring to '_gdal', which I guess is _gdal.pyd. > > I know that my approach is outside the OSGEO package at this point, but I > think solving this problem can help me solve my original OSGEO installation > problem. > > /Casper > > From: Matt Wilkie [mailto:[email protected]] > Sent: 9. maj 2012 19:47 > To: Casper Børgesen (CABO) > Cc: [email protected] > Subject: Re: [osgeo4w-dev] ImportError: OSGeo4W problems with Python/GDAL > > That's interesting. Today I get the same problem Casper reported. Yesterday I > didn't; likely because I'd been running from a command shell several days old > and it didn't have my current full system path in it. > > I eventually tracked it down to a certain dll in PATH, outside the osgeo4w > tree: libeay32.dll. It's part of OpenSSL. Moving that external file elsewhere > enabled python to carry on as normal. > > > matt wilkie > > -------------------------------------------- > > Geomatics Analyst > > Information Management and Technology > > Yukon Department of Environment > > 10 Burns Road * Whitehorse, Yukon * Y1A 4Y9 > > 867-667-8133 Tel * 867-393-7003 Fax > > http://environmentyukon.gov.yk.ca/geomatics/ > > -------------------------------------------- > > On 08-May-2012 10:21 AM, Matt Wilkie wrote: > Hi Casper, > > I think you'll need to start from as clean an environment as possible and add > items to path until things break again. > For example, from a command shell (start > run > cmd.exe): > > {{{ > :: clear whole PATH > set path= > > :: clear PYTHONPATH, PYTHONHOME > set pythonpath= > set pythonhome= > > :: set basic o4w environment > cd /d c:\osgeo4w > set osgeo4w_root=%cd% > path=%osgeo4w_root%\bin > }}} > > Now run python and import gdal. > > If it works, from the same command shell run each bat in "osgeo4w\etc\ini" > and test the python import again until something fails. > > If it doesn't work, something is wrong with the current o4w package ecosystem > and we'll try and dig it out. > > If you get through all the ini bat's without error, then the problem lies > somewhere in the host Windows environment. Likely culprits include things > like other python directories or .dll's in PATH, PYTHONPATH or PYTHONHOME > (not necessarily gdal dll's). > > let us know how you make out, > > > matt wilkie > > -------------------------------------------- > > Geomatics Analyst > > Information Management and Technology > > Yukon Department of Environment > > 10 Burns Road * Whitehorse, Yukon * Y1A 4Y9 > > 867-667-8133 Tel * 867-393-7003 Fax > > http://environmentyukon.gov.yk.ca/geomatics/ > > -------------------------------------------- > > On 07-May-2012 11:40 PM, Casper Børgesen (CABO) wrote: > Hi! > > I am new to the GDAL world and I'm struggling with installing OSGeo4W to a > working state. > > I have downloaded and installed the latest edition OSGeo4W. The install goes > smoothly. I open the OSGeo4W Command shell and enter Python. I have seen that > I can test the basic Python/GDAL binding(?) by entering > >>>> from osgeo import gdal > > This results in the following error: > > Traceback (most recent call last): > File "<stdin>", line 1, in <module> > File "C:\OSGeo4W\apps\Python27\lib\site-packages\osgeo\__init__.py", line > 21, > in <module> > _gdal = swig_import_helper() > File "C:\OSGeo4W\apps\Python27\lib\site-packages\osgeo\__init__.py", line > 17, > in swig_import_helper > _mod = imp.load_module('_gdal', fp, pathname, description) > ImportError: DLL load failed: The operating system cannot run %1. > > I have read that this error might indicate that the installed python/gdal > libraries are incompatible, but I'm wondering if my OSGeo4W installation is > obstructed by another installation? The following three lines are added to my > path by the OSGeo4W Command shell: > > > C:\OSGeo4W\bin > > C:\OSGeo4W\\apps\msys\bin > > C:\OSGeo4W\\apps\Python27\Scripts > > I have searched through my system looking for gdal*.dll, but I have found > none located within any of the folders in my PATH. > > What can I do to troubleshoot this problem? > > Regards, Casper > > > _______________________________________________ osgeo4w-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/osgeo4w-dev
