<div dir="ltr"><div class="gmail_extra">Dear Jackie,</div><div class="gmail_extra"><br></div><div class="gmail_extra">we do care about MapGuide on 64-bit Linux.</div><div class="gmail_extra">We have some of them, even in production.</div><div class="gmail_extra"><br></div><div class="gmail_extra">But we just use FDO OGR provider, with gdal compiled with PostgreSQL support.</div><div class="gmail_extra">We're not using PostgreSQL provider since it need a connection per schema instead of a connection per db.</div><div class="gmail_extra">We would need many more database connections and to create a lot of datasources, which is not at all convenient for us.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Anyway we support your effort on this, and thank you for your work!</div><div class="gmail_extra"><br></div><div class="gmail_extra">Best regards,</div><div class="gmail_extra"><br></div><div class="gmail_extra">Gabriele Monfardini</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 15, 2018 at 3:33 PM, Jackie Ng <span dir="ltr"><<a href="mailto:jumpinjackie@gmail.com" target="_blank">jumpinjackie@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi All,<br>
<br>
In my MapGuide roadmap announcement I expressed my desire to hopefully see<br>
the "preview" label for MapGuide on 64-bit Linux removed for the next major<br>
release (3.3).<br>
<br>
The "preview" label has stuck for the longest time due to some major<br>
blockers in certain FDO providers. In the hopes of being able to pool in<br>
community effort and/or knowledge to solving this problem faster, I'm going<br>
to detail the blockers that currently lie in the following providers:<br>
<br>
 - SHP Provider<br>
 - PostgreSQL Provider<br>
 - King Oracle<br>
<br>
This is going to be super technical. Be warned.<br>
<br>
For the SHP Provider, the blocker is in the SHP spatial indexing code. It<br>
makes heavy use of the C++ "long" and "unsigned long" data types which is<br>
not portable across platform. sizeof(long) == 8 for 64-bit Linux, while<br>
sizeof(long) == 4 for every other platform we target. The incorrect size<br>
assumptions result in corrupted spatial queries which manifest as features<br>
from a SHP source "randomly" disappearing when queried. Another unrelated<br>
problem is that the SHP test suite currently has test failures on both<br>
Windows and Linux meaning we don't have an objective baseline for "it<br>
works". We should get the test suite back into a passing state first before<br>
being able to tackle this problem with confidence.<br>
<br>
For the PostgreSQL provider, the blocker is also due to use of "long" and<br>
"unsigned long" in the PostGISDriver code. I've partially fixed this<br>
(<a href="https://trac.osgeo.org/fdo/changeset/7621" rel="noreferrer" target="_blank">https://trac.osgeo.org/fdo/<wbr>changeset/7621</a>), so that the unit test suite at<br>
least runs to completion with test failures on 64-bit, instead of its<br>
previous behavior of segfaulting out due to incorrect size assumptions in<br>
the PostGISDriver. Now that the unit test suite runs, the majority of the<br>
failures are various overflow errors reported by libpq which once again I<br>
suspect is due to incorrect data type size assumptions. The "blocker" status<br>
can be removed from this provider when the unit test suite is all passing.<br>
<br>
For the King Oracle provider, I think it is (and has been) a complete<br>
non-starter on Linux. The provider code has built without errors against the<br>
Linux Oracle Instant Client SDK for the longest time, but admittedly I never<br>
actually tested this provider on Linux, so it's been a "use at your own<br>
risk" type deal for this provider (even on 32-bit linux). Has this provider<br>
ever worked for anyone on Linux? The key blocker I'm seeing here is mainly<br>
this *8 year old* issue (<a href="https://trac.osgeo.org/fdo/ticket/562" rel="noreferrer" target="_blank">https://trac.osgeo.org/fdo/<wbr>ticket/562</a>). I'm not<br>
well versed with this particular provider (nor the OCI library), so my<br>
ability to tackle this problem head-on is limited unlike the other FDO<br>
providers. The lack of an easy to setup and run unit test suite on this<br>
provider also hampers development somewhat.<br>
<br>
So that is what I think are the blockers that prevent me from considering<br>
MapGuide on 64-bit Linux to be production-ready.<br>
<br>
Which is a shame, because a production-ready MapGuide on 64-bit Linux is a<br>
gateway to better docker containers (nobody does and should run 32-bit<br>
applications inside a docker container!), and the reason why the docker<br>
angle is of major interest to me is that we can start to explore some<br>
highly-scalable and load-balanced architectures that are possible with a<br>
reliable MapGuide docker container. But if half the FDO providers don't work<br>
properly, well ... there's isn't really much of a point.<br>
<br>
So there's my thoughts on the state of 64-bit Linux support for MapGuide.<br>
Thoughts? Insights? Do you even care about MapGuide working on 64-bit Linux?<br>
Sound off right here on this thread.<br>
<br>
- Jackie<br>
<br>
<br>
<br>
--<br>
Sent from: <a href="http://osgeo-org.1560.x6.nabble.com/MapGuide-Users-f4182607.html" rel="noreferrer" target="_blank">http://osgeo-org.1560.x6.<wbr>nabble.com/MapGuide-Users-<wbr>f4182607.html</a><br>
______________________________<wbr>_________________<br>
mapguide-users mailing list<br>
<a href="mailto:mapguide-users@lists.osgeo.org">mapguide-users@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/mapguide-users" rel="noreferrer" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/mapguide-<wbr>users</a></blockquote></div><br></div></div>