[Zoo-discuss] Fwd: Problems building zoo kernel
Gérald Fenoy
gerald.fenoy at geolabs.fr
Sat Oct 13 02:24:22 PDT 2012
Dear Farkas,
I suppose that there is still some issue in PYTHOPATH settings.
To make sure that my assumption is correct, please can you try to run the same request from the command line ?
To run ZOo-Kernel from the command line, you simply need to use the following command:
cd c:\OSGeo4W\bin
.\zoo_loader.cgi "<YOUR_REQUEST>"
Where <YOUR_REQUEST> should be replaced by by your parameters, for instance <YOUR_REQUEST> can take the following value:
"request=Getcapabilities&service=WPS"
I suppose you will get more informations about issue with the Python setup.
Hope this helps and to hear from you,
Best regards,
Gérald Fenoy
gerald.fenoy at geolabs.fr
Le 12 oct. 2012 à 22:31, Farkas H <farkas.dus at gmail.com> a écrit :
> Hi Gérald,
>
> thanks for your response. Yes, the HelloPy service is working.
>
> I did as suggested but I still got the following exception:
> "<ows:ExceptionText>Python module ogr_sp cannot be loaded.
> </ows:ExceptionText>".
>
> The ogr_sp.py file in C:\OSGeo4W\bin was compiled to ogr_sp.pyc. I
> think that's good news.
> Hope you have any further advice and I hear from you.
>
> Regards,
> Farkas
>
>
> On 12 October 2012 09:28, Gérald Fenoy <gerald.fenoy at geolabs.fr> wrote:
>> Dear Farkas,
>> if I understand well it seems that the HelloPy service is working, I know it is nothing but from my point of view it is promising as it means that other services should work.
>>
>> Nevertheless, I'm wondering about the .zo and zcfg you are speaking about and you said "provided .zcfg and .zo" which make me suppose that you try to use the old win32 binaries we published some years ago. You should know that this version of the binary use old GDAL version which should not be present.
>>
>> From my point of view the most efficient way to get the base vector operations working on your platform is to use the python version which is available on your SVN local copy. You can rename zcfg from BufferPy to Buffer then rename the BufferPy function in the pythen script to use same requests. Moreover the base vector operations are of more use than its C counterpart by now.
>>
>> As you are on windows platform, you will have to add a [env] section in your main.cfg file to define PYTHONPATH. To get the value, use the following:
>>
>> python
>> import sys
>> print sys.path
>>
>> Then copy and paste the value and remove quotes and remember that main.cfg file can contains "\" characters (so no need to escape themas it is the case in sys.path).
>>
>> Hope this helps and we can hear news from you,
>> Best regards,
>>
>> Gérald Fenoy
>> gerald.fenoy at geolabs.fr
>>
>>
>> Le 11 oct. 2012 à 19:13, Farkas H <farkas.dus at gmail.com> a écrit :
>>
>>> Hi Gérald,
>>>
>>> thanks again for your support to build the zoo-kernel on Windows.
>>> Building the kernel with Python and Java support works fine.
>>>
>>> I'm sorry but the built kernel doesn't work on my machine (Win7_32
>>> Guest (VM), Win7_64 Host).
>>> I got still the error: "Premature end of script headers" when trying
>>> to run an execute command.
>>>
>>> That's my approach.
>>> - built zoo-kernel with Python support,
>>> - installed OSGeo4W with Apache, GDAL and MapServer support to C:\OSGeo4W,
>>> - copied zoo_loader.cgi to C:\OSGeo4W\bin,
>>> - copied the provided .zcfg and .zo files to C:\OSGeo4W\bin,
>>> - copied the provided files test_service.py and HelloPy.zcfg to C:\OsGeo4W\bin,
>>> - modified main.cfg and copied the file to C:\OSGeo4W\bin,
>>> - copied the following built .dlls to C:\OSGeo4W\bin: python27, zlib1,
>>> libcurl, libxml2, libfcgi, ssleay32, libeay32, gdal19, intl.
>>> - started ApacheOSGeo4W
>>> tested zooWPS
>>> - Hello Python: ok
>>> - GetCapabilities: ok
>>> - DescribeProcess: ok
>>> - Execute: Internal Server Error; Apache log: "Premature end of script
>>> headers: zoo_loader.cgi"
>>>
>>> I tried different execute commands, e.g.
>>> http://localhost/cgi-bin/zoo_loader.cgi?serviceprovider=&metapath=&request=Execute&service=WPS&version=1.0.0&Identifier=Centroid&DataInputs=InputPolygon=Reference@xlink:href=http%3A%2F%2Fdemo.opengeo.org%2Fgeoserver%2Fows%3FSERVICE%3DWFS%26REQUEST%3DGetFeature%26VERSION%3D1.0.0%26typename%3Dtopp%3Astates%26SRS%3DEPSG%3A4326%26FeatureID%3Dstates.15&ResponseDocument=Result@mimeType=text/xml
>>>
>>> The execute commands work on http://zoo-project.org/zoosoo/ but not on
>>> my machine.
>>> I would appreciate any advice.
>>>
>>> Hope to hear from you.
>>>
>>> Regards,
>>> Farkas
>>>
>>>
>>> ---------- Forwarded message ----------
>>> From: Farkas H <farkas.dus at gmail.com>
>>> Date: 8 October 2012 22:39
>>> Subject: Re: [Zoo-discuss] Problems building zoo kernel
>>> To: OSGeo zoo-discuss OSGeo zoo-discuss <zoo-discuss at lists.osgeo.org>
>>>
>>>
>>> Hi Gérald,
>>>
>>> just a quick response.
>>> Finally I could build the zoo-kernel on my Windows platform.
>>> Thanks again for your help and patience.
>>>
>>> Installation seems to work also. There are still some issues.
>>> Probably I will come back after a few more tests but not before thursday.
>>>
>>> Regards,
>>> Farkas
>>>
>>>
>>> On 8 October 2012 08:47, Gérald Fenoy <gerald.fenoy at geolabs.fr> wrote:
>>>> Hello Farkas,
>>>> for building the intl dll you should go directly into gettext-0.14.6/gettext-runtime/intl.
>>>> This will build only the intl.dll and int.lib you need to build ZOO-Kernel.
>>>>
>>>> So You should use the following command:
>>>>
>>>> cd gettext-0.14.6\gettext-runtime\intl
>>>> nmake /f Makefile.msvc DLL=1 MFLAGS=/MD
>>>>
>>>> It is normal behavior to not return dependencies for .lib files. It should be used on DLL files or executables.
>>>>
>>>> I do not get your point about cleaning the source tree from ZOO-Kernel directory, it should work this way:
>>>>
>>>> nmake /f Makefile.vc clean
>>>>
>>>> I hope this will help you to go further and you can build ZOO-Kernel on your windows platform.
>>>>
>>>> Waiting for your feedbacks,
>>>> Best regards,
>>>>
>>>> Gérald Fenoy
>>>> gerald.fenoy at geolabs.fr
>>>>
>>>> Le 8 oct. 2012 à 06:47, Farkas H <farkas.dus at gmail.com> a écrit :
>>>>
>>>>> Hi Gérald,
>>>>>
>>>>> you were right, I have built the libiconv library with the /MF flag.
>>>>> I changed the flag to /MD and rebuilt all libraries with the /MD flag.
>>>>>
>>>>> I couldn't build the iconv library (gettext-0.14.6) and got these errors [1].
>>>>> commands:
>>>>> cd gettext-0.14.6
>>>>> nmake -f Makefile.msvc MFLAGS=-MD
>>>>>
>>>>> This could be the (main) problem, because the errors are concerning
>>>>> the intl.lib.
>>>>> Do you have any ideas?
>>>>>
>>>>> The dumpbin command for static libraries doesn't show any lines
>>>>> containing MSVCR100.dll.
>>>>> For example:
>>>>> dumpbin /dependents K:\zooWPS\prg\src\zlib-1.2.7\zlib.lib
>>>>> File Type: LIBRARY
>>>>> Summary
>>>>> 3C .data
>>>>> 1CAFC .debug$S
>>>>> 3FC .debug$T
>>>>> 2C1 .drectve
>>>>> 429A .rdata
>>>>> 9BD4 .text
>>>>>
>>>>> The dumpbin command for dynamic libraries shows lines containing MSVCR100.dll.
>>>>> For example:
>>>>> dumpbin /dependents K:\zooWPS\prg\src\zlib-1.2.7\zlib1.dll
>>>>> File Type: DLL
>>>>> Image has the following dependencies:
>>>>> MSVCR100.dll
>>>>> KERNEL32.dll
>>>>>
>>>>> Summary
>>>>> 1000 .data
>>>>> 5000 .rdata
>>>>> 1000 .reloc
>>>>> 1000 .rsrc
>>>>> B000 .text
>>>>>
>>>>>
>>>>> I couldn't run a clean before building the kernel.
>>>>> I got the following error.
>>>>> NMAKE : fatal error U1052: file 'clean' not found
>>>>>
>>>>> Hope to hear from you.
>>>>>
>>>>> Regards,
>>>>> Farkas
>>>>>
>>>>>
>>>>> [1]
>>>>> Creating library msgcmp.lib and object msgcmp.exp
>>>>> gettextlib.lib(xerror.obj) : warning LNK4049: locally defined symbol _program_na
>>>>> me imported
>>>>> msgcmp.obj : warning LNK4217: locally defined symbol _program_name imported in f
>>>>> unction _usage
>>>>> gettextsrc.lib(msgl-iconv.obj) : warning LNK4049: locally defined symbol _progra
>>>>> m_name imported
>>>>> gettextsrc.lib(po-charset.obj) : warning LNK4049: locally defined symbol _progra
>>>>> m_name imported
>>>>> gettextlib.lib(error-progname.obj) : warning LNK4049: locally defined symbol _pr
>>>>> ogram_name imported
>>>>> msgcmp.obj : warning LNK4217: locally defined symbol _optind imported in functio
>>>>> n _main
>>>>> msgcmp.obj : warning LNK4217: locally defined symbol _optarg imported in functio
>>>>> n _main
>>>>> msgcmp.obj : warning LNK4217: locally defined symbol _input_syntax imported in f
>>>>> unction _main
>>>>> msgcmp.obj : warning LNK4217: locally defined symbol _gram_max_allowed_errors im
>>>>> ported in function _main
>>>>> msgcmp.obj : warning LNK4217: locally defined symbol _error_print_progname impor
>>>>> ted in function _main
>>>>> gettextsrc.lib(po-lex.obj) : warning LNK4217: locally defined symbol _error_mess
>>>>> age_count imported in function _po_gram_error
>>>>> gettextsrc.lib(read-po-abstract.obj) : warning LNK4049: locally defined symbol _
>>>>> error_message_count imported
>>>>> gettextlib.lib(xerror.obj) : warning LNK4049: locally defined symbol _error_mess
>>>>> age_count imported
>>>>> gettextsrc.lib(po-lex.obj) : warning LNK4217: locally defined symbol _error_with
>>>>> _progname imported in function _po_gram_error
>>>>> gettextsrc.lib(read-properties.obj) : warning LNK4049: locally defined symbol _e
>>>>> rror_with_progname imported
>>>>> gettextsrc.lib(read-stringtable.obj) : warning LNK4217: locally defined symbol _
>>>>> error_with_progname imported in function _phase1_getc
>>>>> gettextlib.lib(xerror.obj) : warning LNK4049: locally defined symbol _error_with
>>>>> _progname imported
>>>>> gettextsrc.lib(po-lex.obj) : warning LNK4217: locally defined symbol _po_lex_cha
>>>>> rset imported in function _mb_width
>>>>> gettextsrc.lib(po-lex.obj) : warning LNK4217: locally defined symbol _po_lex_ico
>>>>> nv imported in function _mb_width
>>>>> gettextsrc.lib(po-lex.obj) : warning LNK4217: locally defined symbol _po_lex_wei
>>>>> rd_cjk imported in function _mbfile_getc
>>>>> gettextsrc.lib(po-lex.obj) : warning LNK4217: locally defined symbol _po_gram_lv
>>>>> al imported in function _po_gram_lex
>>>>> gettextsrc.lib(msgl-iconv.obj) : warning LNK4217: locally defined symbol _po_cha
>>>>> rset_ascii imported in function _iconv_message_list
>>>>> gettextsrc.lib(read-po.obj) : warning LNK4217: locally defined symbol _gram_pos
>>>>> imported in function _default_set_domain
>>>>> gettextsrc.lib(po-gram-gen.obj) : warning LNK4049: locally defined symbol _gram_
>>>>> pos imported
>>>>> gettextsrc.lib(read-po.obj) : warning LNK4217: locally defined symbol _po_charse
>>>>> t_utf8 imported in function _read_po
>>>>> gettextsrc.lib(read-po-abstract.obj) : warning LNK4217: locally defined symbol _
>>>>> format_language imported in function _po_parse_comment_special
>>>>> gettextsrc.lib(po-gram-gen.obj) : warning LNK4217: locally defined symbol _pass_
>>>>> obsolete_entries imported in function _po_gram_parse
>>>>> gettextsrc.lib(po-lex.obj) : error LNK2019: unresolved external symbol __imp__po
>>>>> _error referenced in function _po_gram_error
>>>>> gettextsrc.lib(read-po-abstract.obj) : error LNK2001: unresolved external symbol
>>>>> __imp__po_error
>>>>> gettextsrc.lib(po-lex.obj) : error LNK2019: unresolved external symbol __imp__po
>>>>> _error_at_line referenced in function _po_gram_error_at_line
>>>>> gettextsrc.lib(po-charset.obj) : error LNK2019: unresolved external symbol __imp
>>>>> __po_multiline_warning referenced in function _po_lex_charset_set
>>>>> gettextlib.lib(obstack.obj) : error LNK2019: unresolved external symbol __imp__e
>>>>> xit_failure referenced in function _print_and_abort
>>>>> msgcmp.exe : fatal error LNK1120: 4 unresolved externals
>>>>> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 10.0
>>>>> \VC\BIN\cl.EXE"' : return code '0x2'
>>>>> Stop.
>>>>> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 10.0
>>>>> \VC\BIN\nmake.exe"' : return code '0x2'
>>>>> Stop.
>>>>> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 10.0
>>>>> \VC\BIN\nmake.exe"' : return code '0x2'
>>>>>
>>>>>
>>>>> On 5 October 2012 13:46, Gérald Fenoy <gerald.fenoy at geolabs.fr> wrote:
>>>>>> Hello Farkas,
>>>>>> I don't think that the issue with linkage is due to the ZOO-Kernel itself but on the way you built the dependencies. Indeed, it seems that you mixed /MT and /MD on the way. Which means that I suppose you built some dependent library using /MT flag when you should use /MD.
>>>>>>
>>>>>> To verify that my supposition is correct, please use the following command on each of your dependent libraries (after running the vcvars32.bat script from Visual Studio 10.0):
>>>>>>
>>>>>> dumpbin /dependents <MY_LIBRARY>
>>>>>>
>>>>>> By replacing <MY_LIBRARY> by the full path of your dependent library. Make sure that you always get the following lines:
>>>>>>
>>>>>> MSVCR100.dll
>>>>>>
>>>>>> For each library which doesn't contain this line, please rebuild after making sure you use well /MD flags for code generation rather than /MT.
>>>>>>
>>>>>> Note that, in the log provided it seems that you tried first to build the ZOO-Kernel with JAVA activated then you go back on the same tree to compile again deactivating this support. This is one of the trouble you faced corresponding to your first LNK2019 message. Tosolve this issue, you may try to run nmake /d Makefile.vc clean before trying to build the ZOO-Kernel.
>>>>>>
>>>>>> For the libiconv library, I remember getting similar issue before. I think that it may be of some help so I've uploaded an archive [1] containing the source tree I used to build the library. Note that the archive also contains the 32 Bits version of the dll pre-build.
>>>>>>
>>>>>> I hope this help you to go further and that you can build the ZOO-Kernel on Windows.
>>>>>>
>>>>>> Hope to hear back from you,
>>>>>> Best regards,
>>>>>>
>>>>>> [1] http://zoo-project.org/dl/libiconv-win32-1.14.7z
>>>>>>
>>>>>> Gérald Fenoy
>>>>>> gerald.fenoy at geolabs.fr
>>>>>>
>>>>>> Le 4 oct. 2012 à 18:05, Farkas H <farkas.dus at gmail.com> a écrit :
>>>>>>
>>>>>>> Hi Gérald,
>>>>>>>
>>>>>>> thank you for your quick response.
>>>>>>>
>>>>>>> I tried to build the zoo-kernel without JS and MapServer support and
>>>>>>> got these linker errors [1].
>>>>>>> What am I doing wrong?
>>>>>>> I would appreciate any advice.
>>>>>>>
>>>>>>> Further I got these compiler errors building the intl library. I
>>>>>>> couldn't find a workaround for version 0.14.6. I commented the
>>>>>>> relevant lines and built the intl library.
>>>>>>> Do you know a solution?
>>>>>>>
>>>>>>> Hope to hear from you.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Farkas
>>>>>>>
>>>>>>> [1]
>>>>>>> LIBCMT.lib(dosmap.obj) : error LNK2005: __errno already defined in
>>>>>>> MSVCRT.lib(MSVCR100.dll)
>>>>>>> LIBCMT.lib(crt0dat.obj) : error LNK2005: _exit already defined in
>>>>>>> MSVCRT.lib(MSVCR100.dll)
>>>>>>> LIBCMT.lib(setmode.obj) : error LNK2005: __setmode already defined in
>>>>>>> MSVCRT.lib(MSVCR100.dll)
>>>>>>> LIBCMT.lib(winsig.obj) : error LNK2005: _signal already defined in
>>>>>>> MSVCRT.lib(MSVCR100.dll)
>>>>>>> LIBCMT.lib(winsig.obj) : error LNK2005: _raise already defined in
>>>>>>> MSVCRT.lib(MSVCR100.dll)
>>>>>>> MSVCRT.lib(MSVCR100.dll) : error LNK2005: __write already defined in
>>>>>>> LIBCMT.lib(write.obj)
>>>>>>> MSVCRT.lib(MSVCR100.dll) : error LNK2005: __open already defined in
>>>>>>> LIBCMT.lib(open.obj)
>>>>>>> MSVCRT.lib(MSVCR100.dll) : error LNK2005: __close already defined in
>>>>>>> LIBCMT.lib(close.obj)
>>>>>>> Creating library zoo_loader.lib and object zoo_loader.exp
>>>>>>> LINK : warning LNK4098: defaultlib 'MSVCRT' conflicts with use of
>>>>>>> other libs; use /NODEFAULTLIB:library
>>>>>>> zoo_service_loader.obj : error LNK2019: unresolved external symbol
>>>>>>> _zoo_java_support referenced in function "void __cdecl
>>>>>>> loadServiceAndRun(struct maps * *,struct service *,struct map *,struct
>>>>>>> maps * *,struct maps * *,int *)"
>>>>>>> (?loadServiceAndRun@@YAXPAPAUmaps@@PAUservice@@PAUmap@@00PAH at Z)
>>>>>>> intl.lib(loadmsgcat.obj) : error LNK2019: unresolved external symbol
>>>>>>> __imp__libiconv_open referenced in function __nl_init_domain_conv
>>>>>>> intl.lib(loadmsgcat.obj) : error LNK2019: unresolved external symbol
>>>>>>> __imp__libiconv_close referenced in function __nl_free_domain_conv
>>>>>>> intl.lib(dcigettext.obj) : error LNK2019: unresolved external symbol
>>>>>>> __imp__libiconv referenced in function __nl_find_msg
>>>>>>> intl.lib(relocatable.obj) : error LNK2019: unresolved external symbol
>>>>>>> __imp__libiconv_set_relocation_prefix referenced in function
>>>>>>> _libintl_set_relocation_prefix
>>>>>>> zoo_loader.cgi : fatal error LNK1120: 5 unresolved externals
>>>>>>>
>>>>>>> [2]
>>>>>>> localename.c
>>>>>>> .\localename.c(1360) : error C2196: case value '1' already used
>>>>>>> .\localename.c(1368) : error C2196: case value '1' already used
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 4 October 2012 11:58, Gérald Fenoy <gerald.fenoy at geolabs.fr> wrote:
>>>>>>>> Dear Farkas,
>>>>>>>> to be able to build curl I modified the line 175 of the MakefileBuild.vc to add the following to the CFLAGS:
>>>>>>>>
>>>>>>>> /DWANT_IDN_PROTOTYPES
>>>>>>>>
>>>>>>>> This was quoted here [1].
>>>>>>>>
>>>>>>>> Then, I used the following command to build the library:
>>>>>>>>
>>>>>>>> cd winbuild
>>>>>>>> copy ..\..\zlib-1.2.7\*.h ..\..\deps\include
>>>>>>>> nmake /f Makefile.vc mode=dll WITH_ZLIB=dll VC=10 ENALE_IDN=yes
>>>>>>>>
>>>>>>>> Note that the method described to build zlib should work correctly using cmake, here I used cmake version 2.8.7 windows binary.
>>>>>>>>
>>>>>>>> Hope this helps,
>>>>>>>>
>>>>>>>> [1] http://www.mail-archive.com/curl-library@cool.haxx.se/msg13683.html
>>>>>>>>
>>>>>>>> Gérald Fenoy
>>>>>>>> gerald.fenoy at geolabs.fr
>>>>>>>>
>>>>>>>> Le 4 oct. 2012 à 00:18, Farkas H <farkas.dus at gmail.com> a écrit :
>>>>>>>>
>>>>>>>>> Hi Gérald,
>>>>>>>>>
>>>>>>>>> thanks to your support I'm slowly getting the ropes together.
>>>>>>>>> I've updated on Microsoft Visual Express 2010 and SDK 7.1.
>>>>>>>>>
>>>>>>>>> Building zlib library worked fine. I had to change the nmake command though.
>>>>>>>>> nmake -f win32/Makefile.msc OBJA=inffast.obj
>>>>>>>>>
>>>>>>>>> I had no problems building libiconv library and libxml2 library.
>>>>>>>>>
>>>>>>>>> But I couldn't build libcurl library. I got the following errors:
>>>>>>>>> idn_win32.obj : error LNK2019: unresolved external symbol _IdnToAscii
>>>>>>>>> referenced in function _curl_win32_idn_to_ascii
>>>>>>>>> idn_win32.obj : error LNK2019: unresolved external symbol
>>>>>>>>> _IdnToUnicode referenced in function _curl_win32_ascii_to_idn
>>>>>>>>> Do you have any idea?
>>>>>>>>>
>>>>>>>>> I would appreciate any advice and if you could also provide your build
>>>>>>>>> commands for the other libraries.
>>>>>>>>>
>>>>>>>>> Hope to hear from you.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Farkas
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 3 October 2012 11:18, Gérald Fenoy <gerald.fenoy at geolabs.fr> wrote:
>>>>>>>>>> Hi Farkas,
>>>>>>>>>> sorry for late reply.
>>>>>>>>>>
>>>>>>>>>> Thanks for notifying the double target which explain why I got the error message when trying to compile again the same tree… This is now fixed in trunk.
>>>>>>>>>>
>>>>>>>>>> Personally I am using the Microsoft Visual Express Edition 2010 and SDKs 7.0A or 7.1. I saw that you used 6.0A but this should not cause issue I guess.
>>>>>>>>>>
>>>>>>>>>> To compile the curl library I used the following command:
>>>>>>>>>>
>>>>>>>>>> cd winbuild
>>>>>>>>>> copy ..\..\zlib-1.2.7\*.h ..\..\deps\include
>>>>>>>>>> nmake /f Makefile.vc mode=dll WITH_ZLIB=dll VC=10 ENALE_IDN=yes
>>>>>>>>>>
>>>>>>>>>> In your case I guess that you should use VC=9 .
>>>>>>>>>>
>>>>>>>>>> Note that I built zlib first using the following command:
>>>>>>>>>>
>>>>>>>>>> cd zlib-1.2.7
>>>>>>>>>> cmake . -DCMAKE_BUILD_TYPE=Release
>>>>>>>>>> nmake
>>>>>>>>>>
>>>>>>>>>> To build the libxml2 I used the following command:
>>>>>>>>>>
>>>>>>>>>> cd \MMBK\SRCS\libxml2-2.8.0\win32\
>>>>>>>>>> cscript configure.js compiler=msvc zlib=yes python=yes
>>>>>>>>>> mkdir include
>>>>>>>>>> mkdir bin.msvc
>>>>>>>>>> copy \MMBK\SRCS\zlib-1.2.7\zconf.h include
>>>>>>>>>> copy \MMBK\SRCS\zlib-1.2.7\zlib.h include
>>>>>>>>>> copy D:\MMBK\SRCS\libiconv-win32-1.14\libiconv-win32-1.14\iconv.h include
>>>>>>>>>> copy \MMBK\SRCS\libiconv-win32-1.14\obj\libiconv-win32-1.14\Release_Win32\libiconv-win32-1.14.lib bin.mscv
>>>>>>>>>> nmake
>>>>>>>>>>
>>>>>>>>>> Note that one more time I built the libiconv first. For this you can follow instructions from [1]
>>>>>>>>>>
>>>>>>>>>> I hope that this will answer your question and will help you to go further.
>>>>>>>>>>
>>>>>>>>>> Hope to hear back from you,
>>>>>>>>>> Best regards,
>>>>>>>>>>
>>>>>>>>>> [1] http://www.codeproject.com/Articles/302012/How-to-Build-libiconv-with-Microsoft-Visual-Studio
>>>>>>>>>>
>>>>>>>>>> Gérald Fenoy
>>>>>>>>>> gerald.fenoy at geolabs.fr
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Le 1 oct. 2012 à 18:15, Farkas H <farkas.dus at gmail.com> a écrit :
>>>>>>>>>>
>>>>>>>>>>> Hi Gérald,
>>>>>>>>>>>
>>>>>>>>>>> thank you very much for updating the source code.
>>>>>>>>>>>
>>>>>>>>>>> Compiling the source code of the zoo-kernel works fine.
>>>>>>>>>>> I got a few warning messages. The makefile.vc contains two rules for
>>>>>>>>>>> the target service_internal_java.obj.
>>>>>>>>>>>
>>>>>>>>>>> Unfortunately I cannot link the .obj files because I didn't manage to
>>>>>>>>>>> build the required libraries.
>>>>>>>>>>> I was trying different ways, but I didn't manage it. Maybe it's a
>>>>>>>>>>> general problem with my setup?!
>>>>>>>>>>> I give you two examples [3], [4].
>>>>>>>>>>>
>>>>>>>>>>> Does it make sense instead of building the required libraries, copying
>>>>>>>>>>> the necessary .lib files to the file-structure?
>>>>>>>>>>> I really appreciate any advice.
>>>>>>>>>>>
>>>>>>>>>>> Hope to here back from you.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Farkas
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> [2]
>>>>>>>>>>> Curl: nmake /f Makefile.vc mode=dll
>>>>>>>>>>> idn_win32.obj : error LNK2019: unresolved external symbol _IdnToAscii
>>>>>>>>>>> referenced in function _curl_win32_idn_to_ascii
>>>>>>>>>>> idn_win32.obj : error LNK2019: unresolved external symbol
>>>>>>>>>>> _IdnToUnicode referenced in function _curl_win32_ascii_to_idn
>>>>>>>>>>> ..\builds\libcurl-release-dll-ipv6-sspi-winssl-obj-lib\libcurl.dll :
>>>>>>>>>>> fatal error LNK1120: 2 unresolved externals
>>>>>>>>>>>
>>>>>>>>>>> [3]
>>>>>>>>>>> libxml2: nmake /f Makefile.msvc
>>>>>>>>>>> ..\include\libxml/nanoftp.h(34) : warning C4005: 'INVALID_SOCKET' :
>>>>>>>>>>> macro redefinition
>>>>>>>>>>> C:\Program Files\Microsoft
>>>>>>>>>>> SDKs\Windows\v6.0A\include\winsock2.h(387) : see previous definition
>>>>>>>>>>> of 'INVALID_SOCKET'
>>>>>>>>>>> nanohttp.c
>>>>>>>>>>> ..\nanohttp.c(574) : error C2065: 'EINPROGRESS' : undeclared identifier
>>>>>>>>>>> ..\nanohttp.c(574) : error C2051: case expression not constant
>>>>>>>>>>> ..\nanohttp.c(581) : error C2065: 'ECONNRESET' : undeclared identifier
>>>>>>>>>>> ..\nanohttp.c(581) : error C2051: case expression not constant
>>>>>>>>>>> ..\nanohttp.c(922) : error C2065: 'EINPROGRESS' : undeclared identifier
>>>>>>>>>>> ..\nanohttp.c(922) : error C2051: case expression not constant
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 29 September 2012 16:19, Gérald Fenoy <gerald.fenoy at geolabs.fr> wrote:
>>>>>>>>>>>> Dear Farkas,
>>>>>>>>>>>> many thanks for your perseverance :)
>>>>>>>>>>>>
>>>>>>>>>>>> First of all I would like to thanks specifically: Espen Messel, Knut Landmark and Bernd Härtwig for providing patches during their own testings in building ZOO-Kernel on Windows Platforms. I can applied their patches easily and they made my work easier by providing first feedbacks.
>>>>>>>>>>>>
>>>>>>>>>>>> I would also like to thanks you Frakas for continuously ask for Windows support in ZOO-Project privately and even better using the ZOO-Discuss mailing list.
>>>>>>>>>>>>
>>>>>>>>>>>> Anyway, I'm please to tell you that after long time I finally updated the SVN source tree on the official ZOO-Project SVN server to follow the developments I made some times ago. Nevertheless, as discussed with Angelos I was not able, before this morning, to run properly the Java Services but I finally succeed on that side of the ZOO-Kernel also and it successfully build (which was not the worth case finally) but *run* also successfully using the JDK-1.7.0_07.
>>>>>>>>>>>>
>>>>>>>>>>>> About the specific requirements for running Java Services on windows platform, if you run ZOO-Kernel in 32 bits mode then ZOO-Kernel will have to fix the maximum size of the JVM to 512M (note that, following JNI instructions, we should be able togo until 1G and a bit more) using the -Xmx512M option to run initialize the JVM. Note that this will probably cause trouble to those which are requiring more than 512 M of memory to run their services, so mate we should think about a [jvm] section in main.cfg to setup all this. You will also need to define your PATH environment variable to add to it your local jdk setup, you never have to mode the jvm.dll to the ZOO-Kernel directory else when initializing the JVM you will get error message mentioning: "Can't find dependent libraries ".
>>>>>>>>>>>>
>>>>>>>>>>>> Note that now, you can also activate the ZOO-Kernel MapServer internal support which let you automatically publish results out of your services as WMS/WFS/WCS. As many knows on windows platforms you will need some specific parameters defined into the MapFile at the map level to define CONFIG options such as PROJ_LIB and GDAL-DATA. So to solve this issue, we added a dedicated [mapserver] section in the main.cfg which let you define all the specific options you need to set to make your MapServer setup working.
>>>>>>>>>>>>
>>>>>>>>>>>> The tests I've run on Windows platforms was based on a ZOO-Kernel including the following support : Python, JavaScript, Java and MapServer and the tests runs successfully.
>>>>>>>>>>>>
>>>>>>>>>>>> As you can see in the nmake.opt and following method used in GDAL and MapServer nmake.opt, we setup parameters to pass to your nmake command to add supports to your ZOO-Kernel. So, this way, Python, JavaScript, Java and MapServer are now optional and can be defined at compile time.
>>>>>>>>>>>>
>>>>>>>>>>>> For instance, I personally used the following command line to compile the ZOO-Kernel on my windows platform:
>>>>>>>>>>>>
>>>>>>>>>>>> nmake /f makefile.vc FCGI_DIR=\MMBK\SRCS\fcgi-2.4.1-SNAP-0311112127 INTL_DIR=\MMBK\SRCS\gettext-0.14.6\gettext-runtime\intl SSL_DIR=\MMBK\SRCS\openssl-1.0.1c CURL_DIR=D:\MMBK\SRCS\curl-7.27.0\builds\libcurl-release-dll-zlib-dll-ipv6-sspi-winssl XML2_DIR=\MMBK\SRCS\libxml2-2.8.0 ICONV_DIR=\MMBK\SRCS\libiconv-win32-1.14\libiconv-win32-1.14 PY_DIR=\MMBK\SRCS\Python-2.7.3 PY_LIBRARY=\MMBK\SRCS\Python-2.7.3\PCbuild\python27.lib MS_DIR=\MMBK\SRCS\mapserver-6.0.3 GDAL_DIR=\MMBK\SRCS\gdal-1.9.1 GD_DIR=\MMBK\SRCS\pierrejoye-gd-libgd-733361a31aab\src JS_DIR=\MMBK\SRCS\js-1.8.5\js\src JDK_DIR="c:\Program Files (x86)\Java\jdk1.7.0_07"
>>>>>>>>>>>>
>>>>>>>>>>>> So to conclude, I think that you should start compiling the ZOO-Kernel again using the latest source code available in the official ZOO-Project SVN server and you should succeed.
>>>>>>>>>>>>
>>>>>>>>>>>> Hope to hear back from you to know how it works on your side.
>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>
>>>>>>>>>>>> Gérald Fenoy
>>>>>>>>>>>> gerald.fenoy at geolabs.fr
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Le 28 sept. 2012 à 16:49, Farkas H <farkas.dus at gmail.com> a écrit :
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi list,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I try to build the zoo kernel (Win7-64, MSVC9). Amongst others I got
>>>>>>>>>>>>> these warnings and error messages [1].
>>>>>>>>>>>>> It would be nice if someone could help me. I got stuck.
>>>>>>>>>>>>> I really appreciate any advice.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Farkas
>>>>>>>>>>>>>
>>>>>>>>>>>>> [1]
>>>>>>>>>>>>> K:\zooWPS\zoo-project\..\libs\fcgi\include\fcgio.h(53) : warning
>>>>>>>>>>>>> C4251: 'std::basic_streambuf<_Elem,_Traits>::_Mylock' : class
>>>>>>>>>>>>> 'std::_Mutex' needs to have dll-interface to be used by clients of
>>>>>>>>>>>>> class 'std::basic_streambuf<_Elem,_Traits>'
>>>>>>>>>>>>> with
>>>>>>>>>>>>> [
>>>>>>>>>>>>> _Elem=char,
>>>>>>>>>>>>> _Traits=std::char_traits<char>
>>>>>>>>>>>>> ]
>>>>>>>>>>>>> C:\Program Files (x86)\Microsoft Visual Studio
>>>>>>>>>>>>> 9.0\VC\INCLUDE\yvals.h(723) : see declaration of 'std::_Mutex'
>>>>>>>>>>>>> K:\zooWPS\zoo-project\..\libs\fcgi\include\fcgio.h(107) : warning
>>>>>>>>>>>>> C4996: 'std::basic_streambuf<_Elem,_Traits>::xsgetn': Function call
>>>>>>>>>>>>> with parameters that may be unsafe - this call relies on the caller to
>>>>>>>>>>>>> check that the passed values are correct. To disable this warning, use
>>>>>>>>>>>>> -D_SCL_SECURE_NO_WARNINGS. See documentation on how to use Visual C++
>>>>>>>>>>>>> 'Checked Iterators'
>>>>>>>>>>>>> with
>>>>>>>>>>>>> [
>>>>>>>>>>>>> _Elem=char,
>>>>>>>>>>>>> _Traits=std::char_traits<char>
>>>>>>>>>>>>> ]
>>>>>>>>>>>>> C:\Program Files (x86)\Microsoft Visual Studio
>>>>>>>>>>>>> 9.0\VC\INCLUDE\streambuf(323) : see declaration of
>>>>>>>>>>>>> 'std::basic_streambuf<_Elem,_Traits>::xsgetn'
>>>>>>>>>>>>> with
>>>>>>>>>>>>> [
>>>>>>>>>>>>> _Elem=char,
>>>>>>>>>>>>> _Traits=std::char_traits<char>
>>>>>>>>>>>>> ]
>>>>>>>>>>>>> K:\zooWPS\zoo-project\..\libs\fcgi\include\fcgio.h(113) : warning
>>>>>>>>>>>>> C4275: non dll-interface class 'std::ios_base' used as base for
>>>>>>>>>>>>> dll-interface class 'std::basic_ios<_Elem,_Traits>'
>>>>>>>>>>>>> with
>>>>>>>>>>>>> [
>>>>>>>>>>>>> _Elem=char,
>>>>>>>>>>>>> _Traits=std::char_traits<char>
>>>>>>>>>>>>> ]
>>>>>>>>>>>>> C:\Program Files (x86)\Microsoft Visual Studio
>>>>>>>>>>>>> 9.0\VC\INCLUDE\xiosbase(195) : see declaration of 'std::ios_base'
>>>>>>>>>>>>> k:\zoowps\zoo-project\zoo-kernel\service.h(51) : warning C4005:
>>>>>>>>>>>>> 'SERVICE_PAUSED' : macro redefinition
>>>>>>>>>>>>> C:\Program Files\Microsoft
>>>>>>>>>>>>> SDKs\Windows\v6.0A\include\winsvc.h(116) : see previous definition of
>>>>>>>>>>>>> 'SERVICE_PAUSED'
>>>>>>>>>>>>> k:\zoowps\zoo-project\zoo-kernel\service.h(154) : warning C4996:
>>>>>>>>>>>>> 'strdup': The POSIX name for this item is deprecated. Instead, use the
>>>>>>>>>>>>> ISO C++ conformant name: _strdup. See online help for details.
>>>>>>>>>>>>> C:\Program Files (x86)\Microsoft Visual Studio
>>>>>>>>>>>>> 9.0\VC\INCLUDE\string.h(207) : see declaration of 'strdup'
>>>>>>>>>>>>> k:\zoowps\zoo-project\zoo-kernel\service.h(173) : warning C4996:
>>>>>>>>>>>>> 'stricmp': The POSIX name for this item is deprecated. Instead, use
>>>>>>>>>>>>> the ISO C++ conformant name: _stricmp. See online help for details.
>>>>>>>>>>>>> C:\Program Files (x86)\Microsoft Visual Studio
>>>>>>>>>>>>> 9.0\VC\INCLUDE\string.h(215) : see declaration of 'stricmp'
>>>>>>>>>>>>> k:\zoowps\zoo-project\zoo-kernel\service.h(623) : warning C4996:
>>>>>>>>>>>>> 'strnicmp': The POSIX name for this item is deprecated. Instead, use
>>>>>>>>>>>>> the ISO C++ conformant name: _strnicmp. See online help for details.
>>>>>>>>>>>>> C:\Program Files (x86)\Microsoft Visual Studio
>>>>>>>>>>>>> 9.0\VC\INCLUDE\string.h(217) : see declaration of 'strnicmp'
>>>>>>>>>>>>> zoo_loader.c(63) : warning C4005: 'FALSE' : macro redefinition
>>>>>>>>>>>>> C:\Program Files\Microsoft
>>>>>>>>>>>>> SDKs\Windows\v6.0A\include\windef.h(68) : see previous definition of
>>>>>>>>>>>>> 'FALSE'
>>>>>>>>>>>>> zoo_loader.c(70) : warning C4996: 'dup2': The POSIX name for this item
>>>>>>>>>>>>> is deprecated. Instead, use the ISO C++ conformant name: _dup2. See
>>>>>>>>>>>>> online help for details.
>>>>>>>>>>>>> C:\Program Files (x86)\Microsoft Visual Studio
>>>>>>>>>>>>> 9.0\VC\INCLUDE\io.h(309) : see declaration of 'dup2'
>>>>>>>>>>>>> zoo_loader.c(298) : error C3861: 'strtok_r': identifier not found
>>>>>>>>>>>>> zoo_loader.c(303) : error C3861: 'strtok_r': identifier not found
>>>>>>>>>>>>> zoo_loader.c(309) : error C3861: 'strtok_r': identifier not found
>>>>>>>>>>>>> zoo_loader.c(316) : error C3861: 'strtok_r': identifier not found
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> Zoo-discuss mailing list
>>>>>>>>>>>>> Zoo-discuss at lists.osgeo.org
>>>>>>>>>>>>> http://lists.osgeo.org/cgi-bin/mailman/listinfo/zoo-discuss
>>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Zoo-discuss mailing list
>>>>>>>>>>> Zoo-discuss at lists.osgeo.org
>>>>>>>>>>> http://lists.osgeo.org/cgi-bin/mailman/listinfo/zoo-discuss
>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Zoo-discuss mailing list
>>>>>>>>> Zoo-discuss at lists.osgeo.org
>>>>>>>>> http://lists.osgeo.org/cgi-bin/mailman/listinfo/zoo-discuss
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Zoo-discuss mailing list
>>>>>>> Zoo-discuss at lists.osgeo.org
>>>>>>> http://lists.osgeo.org/cgi-bin/mailman/listinfo/zoo-discuss
>>>>>>
>>>>> _______________________________________________
>>>>> Zoo-discuss mailing list
>>>>> Zoo-discuss at lists.osgeo.org
>>>>> http://lists.osgeo.org/cgi-bin/mailman/listinfo/zoo-discuss
>>>>
>>> _______________________________________________
>>> Zoo-discuss mailing list
>>> Zoo-discuss at lists.osgeo.org
>>> http://lists.osgeo.org/cgi-bin/mailman/listinfo/zoo-discuss
>>
> _______________________________________________
> Zoo-discuss mailing list
> Zoo-discuss at lists.osgeo.org
> http://lists.osgeo.org/cgi-bin/mailman/listinfo/zoo-discuss
More information about the Zoo-discuss
mailing list