Evan, <div><br></div><div>Thanks for the info.  I used universal, purely as a descriptor of the functionality I was hoping for.  I will have to experiment with installing GDAL in separate locations to see if I can get both installations to get along.</div>
<div><br></div><div>Thanks!</div><div>Jay</div><div><br><div class="gmail_quote">On Mon, Aug 20, 2012 at 12:24 PM, Even Rouault <span dir="ltr"><<a href="mailto:even.rouault@mines-paris.org" target="_blank">even.rouault@mines-paris.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">> A few questions:<br>
> Can a 64-bit installation of gdal support the 32-bit python bindings, ie is<br>
> a universal binary buildable?<br>
<br>
</div>Not sure what you mean by "universal binary" (this is a OSX concept, but I'm<br>
not aware it exists for Windows), but the most general answer is : No<br>
<br>
The python bindings contain DLL, that must have the same bit size as the GDAL<br>
core DLL.<br>
<br>
A 64bit DLL cannot link with a 32bit DLL, and vice versa.<br>
<div class="im"><br>
> Is it possible to support both 32 and 63 bit installations of the python<br>
> bindings?<br>
<br>
</div>If you install them in separate locations, yes<br>
<div class="im"><br>
> Does this require both a 32-bit and a 64-bit installation of the<br>
> gdal core package?<br>
<br>
</div>Yes, according to above<br>
<div class="im"><br>
> If it is possible to support both, what order do I need to append my path<br>
> in?  Currently I have the gdal install directory first to avoid dll loading<br>
> issues (from an earlier mail).<br>
<br>
</div>I would believe that you can put the paths to the 32bit and 64bit binaries and<br>
that the windows loader will select the right version, but I'm not sure at<br>
all. That might require confirmation by experimenting<br>
<br>
><br>
> Thanks,<br>
> Jay<br>
</blockquote></div><br></div>