On Tue, 6 Jan 2009, Russell McOrmond wrote with Subject:
Re: [mapserver-users] Confirmation of status of UTF8 support,
and where transcoding to Latin-1 may be happening.
I hope people don't mind me posting as I learn things, hoping that it will
spark some ideas from other people.
Another issue, this time with iconv. I know this is not a mapserver issue,
but it is possible that someone has seen something similar.
As an update, I am still tracking this problem.
Like the binary created by the FGS folks http://maptools.org/fgs/ , we
are trying to compile mapserver against libraries we build ourselves so
that mapserver is not as dependant on the operating system environment.
The problem we are having comes down to some library incompatability
between iconv_open and some other library.
I have a simple test program.
#include <iconv.h>
int main() {
iconv_t cd;
cd = iconv_open("UTF-8", "UTF-16");
printf("iconv_open returns %d\n\n", (int)cd);
iconv_close(cd);
return 0;
}
If I compile this against the standard libc (gcc iconvbroke.c ; ./a.out)
, then I get a value other than -1.
If I compile with the same linking that mapserver is using, then I
always get -1
My successful test had the following environement:
1) all libraries/etc built with sepatate libiconv
2) back up and then remove libiconv and separate iconv.h
3) rebuild libxml2 and mapserver (now not linked against libiconv)
4) restore libiconv files.
If I build my 'iconvbroke' test after these steps then I get numbers
other than (-1). That is, it is not linking against libiconv (as it was
removed in step 2), but is linked against a libgd that was built with
libiconv still there.
If I put libiconv back and build just configure and build mapserver, it
is broken again. This suggests it isn't just something specific to
libxml2.
If I leave the library there, but just don't restore the iconv.h, then
mapserver also seems to be fine (it's linked against libiconv likely
because of libxml2, but its own usage of iconv isn't using that version).
This seems a bit odd to me and I expect that there is something else
broken when things are built this way (IE: things that gd, xml2, and other
libraries are using). I'm just testing data coming from SDE, and haven't
yet re-tested things like labels/etc.
Here is a list of all the stuff we are building. Not all of these
components are libraries that mapserver links against, but it is complete.
I'd rather be complete than manage to not mention something that turns out
to be relevant.
# 1. JDK 1.5.0_16
# 2. Oracle Client 10.2.0
# 3. ArcSDE 9.2 SP5
# 4. Zlib 1.2.3
# 5. Expat 2.0.1
# 6. iconv 1.12
# 7. Sablot 1.0.3
# 8. Python 2.5.2
# 9. Libxml2 2.6.30
# 10. LibJPEG 6b
# 11. Libpng 1.2.24
# 12. Libtiff 3.8.4
# 13. PDFlib Lite 7.0.2
# 14. curl 7.18.0
# 15. Freetype 2.3.5
# 16. Gettext 0.17
# 17. GD 2.0.35
# 18. GDBM 1.8.3
# 19. cronolog 1.6.2
# 20. GEOS 3.0.0rc4
# 21. Xerces 2.8.0
# 22. PROJ 4.5.0
# 23. Apache 2.2.9
# 24. PHP 5.2.6
# 25. Flex 2.5.35
# 26. Mod_python 3.3.1
# 27. TileCache 2.04
# 28. GDAL 1.4.4
# 29. Modjk 1.2.18
# 30. Tomcat 5.5.26
# 31. Swig 1.3.31
# 32. Open Market fcgi 2.4.0
# 33. mod_fastcgi 2.4.6
# 34. UMN MapServer 5.2.1
The build environment is CentOS 5, but I'm soon going to try to build in
RHEL4 (the ultimate target OS for the customer). I don't expect a
difference as other binaries targeted for this environment are broken in
the same way.
Any suggestions greatly appreciated.
--
Russell McOrmond, Internet Consultant: <http://www.flora.ca/>
Please help us tell the Canadian Parliament to protect our property
rights as owners of Information Technology. Sign the petition!
http://digital-copyright.ca/petition/ict/ http://KillBillC61.ca
"The government, lobbied by legacy copyright holders and hardware
manufacturers, can pry control over my camcorder, computer,
home theatre, or portable media player from my cold dead hands!"
_______________________________________________
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users
