Re: native connector tool chain
On 21 May 2012 21:01, Mark Thomas ma...@apache.org wrote: On 21/05/2012 17:52, Mladen Turk wrote: On 05/21/2012 02:05 PM, Mark Thomas wrote: I am trying to build the 1.1.x native connector from trunk so I can test the changes I plan to make to support per socket time outs. I can build using dynamic linking but not statically. What tool chain are folks currently using to build the native connector binaries we currently ship? My current issue relates to statically linking to OpenSSL. I get the same failure with 1.0.c, 0.9.8x and 0.9.8k. I am using: - Visual Studio 6 + SP6 - Win 2003 r2 Platform SDK - OpenSSL binaries from http://slproweb.com/products/Win32OpenSSL.html If those binaries were not compiled with VS6 you can't statically link them. When I build binaries I build both of those (and apr) with the same compiler. Yeah, it's not trivial task. :) Got it working! For the benefit of the archives, I ended up using: Maybe this info should also be saved somewhere in SVN? - Visual Studio 6 + SP6 - Win 2003 r2 Platform SDK - OpenSSL source bundle 0.9.x - APR 1.4.x src (I used the 1.4.6 tag) - native source (I used the 1.1.x branch) OpenSSL 1.x will not work with the VS6 tool chain. My aim is to build the 64-bit APR/native DLL. 32-bit should be pretty similar. Stage 1: OpenSSL build This is pretty close to the OpenSSL docs INSTALL.W64 - Set up the environment to build with the Platform SDK %PLATFORM_SDK_HOME%\SetEnv.Cmd /X64 /RETAIL - Follow the OpenSSL build instructions perl Configure VC-WIN64A ms\do_win64a nmake -f ms\nt.mak The *.lib files you'll need are in the out32 directory. Stage 2: Start VS6 in x64 mode You'll need a batch file that looks something like this: call C:\Program Files\PlatformSDK\SetEnv.Cmd /X64 /RETAIL start C:\Program Files (x86)\Microsoft Visual Studio\Common\MSDev98\Bin\MSDEV.EXE /useenv Stage 3: Open the workspace Depending on where APR is, you'll need to specify paths to the projects Stage 4: Build APR Make sure you can build the apr x64 Release target You may need to tweak src and library paths. Stage 5: Create a tcnative x64 target Copy the Win32 release configuration and name it x64 Release Add /machine:AMD64 to the link options (you can't remove the I368 option - just make sure you add the new one after it) Tweak the src and library paths as required. For both stage 4 and 5 you may need to add additional standard libraries. Google the linking error you get to figure out which. HTH, Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
native connector tool chain
I am trying to build the 1.1.x native connector from trunk so I can test the changes I plan to make to support per socket time outs. I can build using dynamic linking but not statically. What tool chain are folks currently using to build the native connector binaries we currently ship? My current issue relates to statically linking to OpenSSL. I get the same failure with 1.0.c, 0.9.8x and 0.9.8k. I am using: - Visual Studio 6 + SP6 - Win 2003 r2 Platform SDK - OpenSSL binaries from http://slproweb.com/products/Win32OpenSSL.html - Targeting 64-bit platform I am working through the VS6 GUI and the errors I am getting are variations of this: ssleay32MT.lib(t1_enc.obj) : error LNK2001: unresolved external symbol __GSHandlerCheck Cheers, Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: native connector tool chain
Sorry, haven't compiled on windows in last 10 years. I suspect the easiest path would be cygwin and gcc. If you want to use vcc - you need to find a way to generate the project file with the right flags. One option would be to use the CMakeLists.txt - you'll probably need to adjust the options and file list for windows. It can generate native projects for both visual studio and eclipse. The file is still there in main branch, the official solution is autoconf, but sometimes it's good to consider alternatives too. Costin On Mon, May 21, 2012 at 5:05 AM, Mark Thomas ma...@apache.org wrote: I am trying to build the 1.1.x native connector from trunk so I can test the changes I plan to make to support per socket time outs. I can build using dynamic linking but not statically. What tool chain are folks currently using to build the native connector binaries we currently ship? My current issue relates to statically linking to OpenSSL. I get the same failure with 1.0.c, 0.9.8x and 0.9.8k. I am using: - Visual Studio 6 + SP6 - Win 2003 r2 Platform SDK - OpenSSL binaries from http://slproweb.com/products/Win32OpenSSL.html - Targeting 64-bit platform I am working through the VS6 GUI and the errors I am getting are variations of this: ssleay32MT.lib(t1_enc.obj) : error LNK2001: unresolved external symbol __GSHandlerCheck Cheers, Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: native connector tool chain
On 21/05/2012 15:35, Costin Manolache wrote: Sorry, haven't compiled on windows in last 10 years. I suspect the easiest path would be cygwin and gcc. If you want to use vcc - you need to find a way to generate the project file with the right flags. One option would be to use the CMakeLists.txt - you'll probably need to adjust the options and file list for windows. It can generate native projects for both visual studio and eclipse. The file is still there in main branch, the official solution is autoconf, but sometimes it's good to consider alternatives too. I have Visual studio working for 95% of the build. As long as I link OpenSSL dynamically, all is fine. It is just the static linking I am having trouble with. This is good enough for what I need right now but I'd like to be able to repeat the binary build process if only as protection against the current release manager being run over by a bus. Mark Costin On Mon, May 21, 2012 at 5:05 AM, Mark Thomas ma...@apache.org wrote: I am trying to build the 1.1.x native connector from trunk so I can test the changes I plan to make to support per socket time outs. I can build using dynamic linking but not statically. What tool chain are folks currently using to build the native connector binaries we currently ship? My current issue relates to statically linking to OpenSSL. I get the same failure with 1.0.c, 0.9.8x and 0.9.8k. I am using: - Visual Studio 6 + SP6 - Win 2003 r2 Platform SDK - OpenSSL binaries from http://slproweb.com/products/Win32OpenSSL.html - Targeting 64-bit platform I am working through the VS6 GUI and the errors I am getting are variations of this: ssleay32MT.lib(t1_enc.obj) : error LNK2001: unresolved external symbol __GSHandlerCheck Cheers, Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: native connector tool chain
On 05/21/2012 02:05 PM, Mark Thomas wrote: I am trying to build the 1.1.x native connector from trunk so I can test the changes I plan to make to support per socket time outs. I can build using dynamic linking but not statically. What tool chain are folks currently using to build the native connector binaries we currently ship? My current issue relates to statically linking to OpenSSL. I get the same failure with 1.0.c, 0.9.8x and 0.9.8k. I am using: - Visual Studio 6 + SP6 - Win 2003 r2 Platform SDK - OpenSSL binaries from http://slproweb.com/products/Win32OpenSSL.html If those binaries were not compiled with VS6 you can't statically link them. When I build binaries I build both of those (and apr) with the same compiler. Yeah, it's not trivial task. Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: native connector tool chain
On 21/05/2012 17:52, Mladen Turk wrote: On 05/21/2012 02:05 PM, Mark Thomas wrote: I am trying to build the 1.1.x native connector from trunk so I can test the changes I plan to make to support per socket time outs. I can build using dynamic linking but not statically. What tool chain are folks currently using to build the native connector binaries we currently ship? My current issue relates to statically linking to OpenSSL. I get the same failure with 1.0.c, 0.9.8x and 0.9.8k. I am using: - Visual Studio 6 + SP6 - Win 2003 r2 Platform SDK - OpenSSL binaries from http://slproweb.com/products/Win32OpenSSL.html If those binaries were not compiled with VS6 you can't statically link them. When I build binaries I build both of those (and apr) with the same compiler. Yeah, it's not trivial task. :). Thanks. That explains what is going on. I might look into building OpenSSL with Visual Studio 6 if I get a spare week and a desire to make my brain hurt :) Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: native connector tool chain
On Mon, May 21, 2012 at 10:31 AM, Mark Thomas ma...@apache.org wrote: On 21/05/2012 17:52, Mladen Turk wrote: On 05/21/2012 02:05 PM, Mark Thomas wrote: I am trying to build the 1.1.x native connector from trunk so I can test the changes I plan to make to support per socket time outs. I can build using dynamic linking but not statically. What tool chain are folks currently using to build the native connector binaries we currently ship? My current issue relates to statically linking to OpenSSL. I get the same failure with 1.0.c, 0.9.8x and 0.9.8k. I am using: - Visual Studio 6 + SP6 - Win 2003 r2 Platform SDK - OpenSSL binaries from http://slproweb.com/products/Win32OpenSSL.html If those binaries were not compiled with VS6 you can't statically link them. When I build binaries I build both of those (and apr) with the same compiler. Yeah, it's not trivial task. :). Thanks. That explains what is going on. I might look into building OpenSSL with Visual Studio 6 if I get a spare week and a desire to make my brain hurt :) I think chrome has some build files for openssl similar with cmake, i.e. one config that can generate visual studio, eclipse, makefile, etc. My brain hurts whenever I touch autoconfig, I suppose the pain with VS6 is similar. Costin Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: native connector tool chain
On 21/05/2012 17:52, Mladen Turk wrote: On 05/21/2012 02:05 PM, Mark Thomas wrote: I am trying to build the 1.1.x native connector from trunk so I can test the changes I plan to make to support per socket time outs. I can build using dynamic linking but not statically. What tool chain are folks currently using to build the native connector binaries we currently ship? My current issue relates to statically linking to OpenSSL. I get the same failure with 1.0.c, 0.9.8x and 0.9.8k. I am using: - Visual Studio 6 + SP6 - Win 2003 r2 Platform SDK - OpenSSL binaries from http://slproweb.com/products/Win32OpenSSL.html If those binaries were not compiled with VS6 you can't statically link them. When I build binaries I build both of those (and apr) with the same compiler. Yeah, it's not trivial task. :) Got it working! For the benefit of the archives, I ended up using: - Visual Studio 6 + SP6 - Win 2003 r2 Platform SDK - OpenSSL source bundle 0.9.x - APR 1.4.x src (I used the 1.4.6 tag) - native source (I used the 1.1.x branch) OpenSSL 1.x will not work with the VS6 tool chain. My aim is to build the 64-bit APR/native DLL. 32-bit should be pretty similar. Stage 1: OpenSSL build This is pretty close to the OpenSSL docs INSTALL.W64 - Set up the environment to build with the Platform SDK %PLATFORM_SDK_HOME%\SetEnv.Cmd /X64 /RETAIL - Follow the OpenSSL build instructions perl Configure VC-WIN64A ms\do_win64a nmake -f ms\nt.mak The *.lib files you'll need are in the out32 directory. Stage 2: Start VS6 in x64 mode You'll need a batch file that looks something like this: call C:\Program Files\PlatformSDK\SetEnv.Cmd /X64 /RETAIL start C:\Program Files (x86)\Microsoft Visual Studio\Common\MSDev98\Bin\MSDEV.EXE /useenv Stage 3: Open the workspace Depending on where APR is, you'll need to specify paths to the projects Stage 4: Build APR Make sure you can build the apr x64 Release target You may need to tweak src and library paths. Stage 5: Create a tcnative x64 target Copy the Win32 release configuration and name it x64 Release Add /machine:AMD64 to the link options (you can't remove the I368 option - just make sure you add the new one after it) Tweak the src and library paths as required. For both stage 4 and 5 you may need to add additional standard libraries. Google the linking error you get to figure out which. HTH, Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
