Quantcast

Serious CentOS 6.x blocker for MapGuide 2.6 final release

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Serious CentOS 6.x blocker for MapGuide 2.6 final release

Jackie Ng
Hi All,

There is a serious defect in the CentOS 6.x build of MapGuide that is preventing release of 2.6 final for this particular build at least.

It concerns the use of iconv_* family of APIs which fail under MapGuide on CentOS 6.x. Basically, calls to iconv_open() from within the mgserver process will almost always return -1 in the charsets we want to convert to/from. This breaks the macros conv_wide_to_utf8 and conv_utf8_to_wide in FdoCommonStringUtil.h, that is used in the FdoCommonFile class and by any FDO provider that needs to do some sort of file operation that would be using this class.

The most apparent symptom of this defect is that it is not possible to open any SHP file FDO connection in MapGuide as it will throw back an FdoException with FDO_1_BADALLOC (Memory allocation failed), which if you step through the code with gdb will trace back to the above macros that use the iconv_* APIs.

Now the thing that surprises me is that this API is working properly outside of MapGuide. A simple application like this (https://gist.github.com/jumpinjackie/6694c5c0a4e38f1396d0) will have iconv_open() return a valid iconv_t handle. It's only when this code is called from within the mgserver process that it will fail.

So currently, I'm currently suspecting that some combination of gcc/g++/ld flags that have somehow rendered iconv_open() un-usable from within MapGuide. I suspect this is also the cause of the mysterious "could not load a transcoding service" errors from xerces during mgserver startup that has caused me to configure an alternate transcoder for xerces when building MapGuide for 2.6 beta 1 and newer. Anyone have any idea why iconv_open() could fail from within MapGuide, but not fail in other applications?

Failing to solve the above issue, the alternative solution would be to rewrite the conv_wide_to_utf8 and conv_utf8_to_wide macros in FdoCommonStringUtil.h to use something other than iconv to convert char <-> wchar_t, I'm not sure how feasible/practical this is. Anyone from the FDO team care to chime in here?

Despite the above wall of text, I'd like to re-iterate that this issue only affects the CentOS 6.x build of MapGuide. SHP FDO connections work fine on Ubuntu and Windows. I don't want to put a 2.6 final release that has broken SHP file support on CentOS 6.x. Any help and/or pointers that would lead us to solving this problem would be much appreciated.

- Jackie

_______________________________________________
mapguide-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Serious CentOS 6.x blocker for MapGuide 2.6 final release

Jackie Ng
I have some good news.

I have identified the offending revision that broke the CentOS build and have verified the fix

A working CentOS build of MapGuide 2.6 will be uploaded shortly.

- Jackie
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Serious CentOS 6.x blocker for MapGuide 2.6 final release

Gabriele Monfardini
I have some good news.

I have identified the offending revision that broke the CentOS build and
have verified the fix

A working CentOS build of MapGuide 2.6 will be uploaded shortly.

Hi Jackie,

this is a good news indeed.
Thx for your work.

Gabriele 

_______________________________________________
mapguide-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-users
Loading...