atom feed32 messages in org.apache.tomcat.devBuilding tcnative on win32
FromSent OnAttachments
Christopher SchultzJun 13, 2014 2:36 pm 
Konstantin KolinkoJun 13, 2014 2:56 pm 
Konstantin PreißerJun 13, 2014 3:20 pm 
Christopher SchultzJun 18, 2014 10:04 am 
Christopher SchultzJun 18, 2014 10:50 am 
Christopher SchultzJun 18, 2014 10:58 am 
Christopher SchultzJun 18, 2014 12:53 pm 
Konstantin PreißerJun 18, 2014 2:00 pm 
Konstantin PreißerJun 18, 2014 2:41 pm 
Konstantin PreißerJun 18, 2014 2:54 pm 
Christopher SchultzJun 18, 2014 4:30 pm 
Konstantin PreißerJun 18, 2014 4:40 pm 
Christopher SchultzJun 18, 2014 5:01 pm 
Christopher SchultzJun 19, 2014 6:21 am.bat
Konstantin PreißerJun 19, 2014 9:20 am 
Christopher SchultzJun 19, 2014 9:35 am.bat
Christopher SchultzJun 19, 2014 9:57 am 
Konstantin PreißerJun 19, 2014 10:45 am 
Christopher SchultzJun 19, 2014 11:25 am.bat
Christopher SchultzJun 19, 2014 12:11 pm 
Christopher SchultzJun 19, 2014 12:21 pm 
Konstantin KolinkoJun 22, 2014 10:40 am 
Christopher SchultzJun 24, 2014 9:13 am 
Mark ThomasJun 30, 2014 2:47 am 
Mark ThomasJun 30, 2014 6:45 am 
Mark ThomasJun 30, 2014 1:23 pm 
Mladen TurkJun 30, 2014 1:32 pm 
Mark ThomasJun 30, 2014 2:29 pm 
Christopher SchultzJul 1, 2014 8:40 am 
Mark ThomasJul 1, 2014 9:18 am 
Christopher SchultzJul 1, 2014 9:24 am 
Mark ThomasJul 1, 2014 1:22 pm 
Subject:Building tcnative on win32
From:Christopher Schultz (chr@christopherschultz.net)
Date:Jun 13, 2014 2:36:29 pm
List:org.apache.tomcat.dev

All,

I've spent some time trying to script a soup-to-nuts repeatable build of tcnative on win32. I've made some progress but I'm hitting a few snags that perhaps some folks could help with.

First, I want the script to fetch as much stuff as possible for the user instead of relying on a great deal of previously-installed software. My current requirements -- other than MSVC++ -- are for wget.exe and 7za.exe to be available. If anyone knows how to script an HTTP download or a ZIP-decompress from a Windows command-line without either of those tools, I'd greatly appreciate some insight.

(This is where I mention that, really, getting anything done on Windows that doesn't involve Microsoft Excel and nothing else is absolutely excruciating. Running Windows 8 in a VM means that even editing my batch script is a challenge, as the meta keys from Mac -> Windows don't match up and I feel like I'm learning to type all over again. Sign.)

We need to patch both openssl and libapr before building them, so we need "patch". There's a GNU win32 ports project where I can get patch.exe, but its got two problems:

1. It needs to be patched (ha!) to *not* require administrator access. Why does patch.exe need administrator access to run? Your guess is as good as mine.

2. It seems to be crashing when I try to actually patch something: C:\Users\IEUser\AppData\Local\Temp\build-tcnative\build\openssl-1.0.1h>\Users\IEUser\Desktop\tools\patch.exe -i ..\tomcat-native-1.1.30-win32-src\jni\native\srclib\openssl\openssl-msvcrt.patch -p 0 --dry-run patching file util/pl/VC-32.pl

Assertion failed: hunk, file ../patch-2.5.9-src/patch.c, line 354

This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information.

If anyone knows of a good "patch" program for win32, I'd really appreciate that, too.

I've gotten some help from the apr folks with building APR on win32 as well. Their instructions on the web site are outright lies, but it seems that instructions that can be found elsewhere (like in the source distro) that are significantly less complicated (e.g. "run nmake") and seem to work. I have to get apr building against OpenSSL but that is apparently fairly trivial. Once I get get those beasts built, I can follow Mladen's instructions for building tcnative which are fairly straightforward.

Ultimately, my goal is to get a script that can be maintained that does the following: 1. Obtains all sources necessary (openssl, apr, tcnative) 2. Patches all sources as necessary 3. Builds each component 4. Produces a statically-linked binary for distribution

Does anyone know why we bother with a statically-linked tcnative.dll rather than just shipping a "regular" DLL and have users provide their own apr.dll and openssl.dll? It seems like it might be easier if we didn't have to build everything ourselves. Also, for things like "upgrading OpenSSL", it would often be a drop-in replacement instead of having to re-build everything from scratch.

Thanks, -chris