[osgeo4w-dev] Proposal: starting 64 bit package tree

andrea antonello andrea.antonello at gmail.com
Tue Mar 6 03:13:16 EST 2012

> Anything that is available as 64 bit. My primary concern right now is
> QGIS, gdal/ogr. There's work on a current bug right now in QGIS where
> printing and some other operations might be limited by memory.
> Eventually everything will be available as 64 bit and we should just be
> ahead of the trend.

Sounds good to me.

>> I can only speak from a java tribe point of view. I would be happy to
>> do so. At first thought we would some parts with native components and
>> others that are interpreted and therefore for both OS. So I assume
>> something should be done at installer level also? Just thinking loud.
>> Anyways I would be very happy to load a 64 bit Java environment and uDig.
> Does Java installed on the end user machine needs to be 64 bit in order
> to run a 64 bit jar?

Yes. There would be two JVM in the tree. And those java apps that have
native components will need to be duplicated, while the "Pure" ones
should have just one copy but then pick the right (OS dependent) JVM
tree. Maybe that is too complex and they should all be duplicated for


> Thanks,
> Alex
>> Thanks,
>> Andrea
>> On Sun, Mar 4, 2012 at 9:08 PM, Alex Mandel <tech_dev at wildintellect.com> wrote:
>>> It seems to come up often in my discussions with Desktop users, 64 bit
>>> versions of QGIS and other major osgeo applications would be a great
>>> boon for power users. With most new workstations capable of 64 bit and
>>> many power users opting to install Win 7 64 bit (which is stable as
>>> compared to win xp 64 bit), I think we should start working towards
>>> providing binaries.
>>> Not only would it make users happy, but it would actually provide a
>>> competitive advantage over some other systems. Not being able to use the
>>> full 4-8 GB of ram common in GIS workstations is somewhat frustrating.
>>> I realize not everything in osgeo4w is available or ready for 64 bit,
>>> and 64 bit python can get messy due to lack of packages (but numpy is
>>> available). So my proposal is that we make a directory parallel to the
>>> current osgeo4w and either augment the current installer with an option
>>> to choose it or just have a separate setup.exe pretty much identical to
>>> the 32bit one currently and call it osgeo4w64. That way there's a place
>>> to at least start putting what packages are available into the system.
>>> I have 64 bit users/machines willing to test and might be able to get a
>>> dedicated build VM for 64 bit if needed.
>>> Thanks,
>>> Alex
> _______________________________________________
> osgeo4w-dev mailing list
> osgeo4w-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/osgeo4w-dev

More information about the osgeo4w-dev mailing list