You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Christopher Schultz <ch...@christopherschultz.net> on 2014/06/13 23:36:29 UTC
Building tcnative on win32
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
Re: Building tcnative on win32 [x86_64, failing]
Posted by Mark Thomas <ma...@apache.org>.
On 01/07/2014 17:24, Christopher Schultz wrote:
> On 7/1/14, 12:18 PM, Mark Thomas wrote:
<snip/>
>>> The IA64 build of OpenSSL *did* complete, but I'm not sure how
>>> to check its architecture, etc. What is the "depends" tool you
>>> guys have been talking about?
>>
>> The depends tool ships with various tools including Visual
>> Studio and the platform SDK.
>
> Okay, but where is it? What is it called? Tapping the "windows"
> key and searching for it doesn't find it, and there are tools
> literally everywhere related to VC++. With a filename I might have
> a chance of finding it.
Try looking in the start menu -> Platform SDK -> tools. It is called
"depends".
If you want to search for the file name try looking for "depends.exe"
On my build system it is located at:
"C:\Program Files\Microsoft Platform SDK for Windows Server 2003
R2\Bin\Depends.Exe"
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Building tcnative on win32 [x86_64, failing]
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Mark,
On 7/1/14, 12:18 PM, Mark Thomas wrote:
> On 01/07/2014 16:40, Christopher Schultz wrote:
>
>> My script seemed a bit cleaner than what you are documenting on
>> the wiki, plus you can get the tools for free (MS VS 12).
>
> None of the tools documented on the Wiki are paid for.
>
>> I was able to build a complete 32-bit statically-linked
>> libtcnative.dll plus the openssl.exe utility using the process I
>> knocked-up from scratch.
>
> Depending on which version of the MSVCRT DLL?
I'll check once I can run that depends tool.
>> Note that I have been compiling without using the nasm assembler.
>> I figured I'd try to get things working without it, then add that
>> component later once the build process was working.
>
> Back when I was working with VS6, I needed to use nasm as the
> assembler that shipped with VS6 didn't understand the syntax. I'm
> assuming that Mladen hasn't been using it.
>
>> I have been having trouble building pretty much any 64-bit stuff.
>> I happen to be running a 32-bit Windows 8.1 OS, but that shouldn't
>> really be a problem (should it?).
>
> In theory, that should be fine.
>
>> I started with OpenSSL and there are a couple of weird things:
>>
>> 1. Even when configuring for x86-64, the C flags still clearly say
>> WIN32. Maybe that just means "windows" and not necessarily 32-bit.
>> The "configure" Perl script does declare it's configuring for
>> x84-64 so hopefully that's right.
>
> No idea.
>
>> 2. OpenSSL's build script calls ml64 which can't be found in the
>> path. It's probably not good that the command fails, and the build
>> script doesn't even check to see if it succeeded.
>
> That suggests that you haven't got your paths set right to pick up the
> right versions of the build tools and/or libraries.
>
>> 3. The linker fails at the last step for me: link /nologo
>> /subsystem:console /opt:ref /debug /out:out32\md4test.exe @
>> C:\Users\IEUser\AppData\Local\Temp\nmC7C.tmp LINK : fatal error
>> LNK1207: incompatible PDB format in
>> 'C:\Users\IEUser\AppData\Local\Temp\build-tcnative\build\openssl-1.0.1h\out3\md4test.pdb';
>>
>>
> delete and rebuild
>> NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual
>> Studio 12.0\VC\BIN\link.EXE"' : return code '0x4b7' Stop.
>
> That might be a 32-bit vs 64-bit error but that is only a guess on my
> part.
>
>> Installing both MS VS 2013 (v12.0) and the SDK separately seems to
>> have set up a bunch of shortcuts for CLI development. I'm not sure
>> what is what anymore, but switching to the "VS2013 x64 Cross Tools
>> Command Prompt" and building OpenSSL in 64-bit mode seems to have
>> produced a set of binary files (e.g. openssl.exe) that I can't run
>> on my 32-bit version. That indicates to me that I've successfully
>> built OpenSSL in 64-bit mode. I have no idea why it will build
>> under that environment and not in my "other" invocation of
>> cmd.exe.
>
> Different environment settings for the various paths would be my guess.
>
>> The IA64 build of OpenSSL *did* complete, but I'm not sure how to
>> check its architecture, etc. What is the "depends" tool you guys
>> have been talking about?
>
> The depends tool ships with various tools including Visual Studio and
> the platform SDK.
Okay, but where is it? What is it called? Tapping the "windows" key and
searching for it doesn't find it, and there are tools literally
everywhere related to VC++. With a filename I might have a chance of
finding it.
-chris
Re: Building tcnative on win32 [x86_64, failing]
Posted by Mark Thomas <ma...@apache.org>.
On 01/07/2014 16:40, Christopher Schultz wrote:
> My script seemed a bit cleaner than what you are documenting on
> the wiki, plus you can get the tools for free (MS VS 12).
None of the tools documented on the Wiki are paid for.
> I was able to build a complete 32-bit statically-linked
> libtcnative.dll plus the openssl.exe utility using the process I
> knocked-up from scratch.
Depending on which version of the MSVCRT DLL?
> Note that I have been compiling without using the nasm assembler.
> I figured I'd try to get things working without it, then add that
> component later once the build process was working.
Back when I was working with VS6, I needed to use nasm as the
assembler that shipped with VS6 didn't understand the syntax. I'm
assuming that Mladen hasn't been using it.
> I have been having trouble building pretty much any 64-bit stuff.
> I happen to be running a 32-bit Windows 8.1 OS, but that shouldn't
> really be a problem (should it?).
In theory, that should be fine.
> I started with OpenSSL and there are a couple of weird things:
>
> 1. Even when configuring for x86-64, the C flags still clearly say
> WIN32. Maybe that just means "windows" and not necessarily 32-bit.
> The "configure" Perl script does declare it's configuring for
> x84-64 so hopefully that's right.
No idea.
> 2. OpenSSL's build script calls ml64 which can't be found in the
> path. It's probably not good that the command fails, and the build
> script doesn't even check to see if it succeeded.
That suggests that you haven't got your paths set right to pick up the
right versions of the build tools and/or libraries.
> 3. The linker fails at the last step for me: link /nologo
> /subsystem:console /opt:ref /debug /out:out32\md4test.exe @
> C:\Users\IEUser\AppData\Local\Temp\nmC7C.tmp LINK : fatal error
> LNK1207: incompatible PDB format in
> 'C:\Users\IEUser\AppData\Local\Temp\build-tcnative\build\openssl-1.0.1h\out3\md4test.pdb';
>
>
delete and rebuild
> NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual
> Studio 12.0\VC\BIN\link.EXE"' : return code '0x4b7' Stop.
That might be a 32-bit vs 64-bit error but that is only a guess on my
part.
> Installing both MS VS 2013 (v12.0) and the SDK separately seems to
> have set up a bunch of shortcuts for CLI development. I'm not sure
> what is what anymore, but switching to the "VS2013 x64 Cross Tools
> Command Prompt" and building OpenSSL in 64-bit mode seems to have
> produced a set of binary files (e.g. openssl.exe) that I can't run
> on my 32-bit version. That indicates to me that I've successfully
> built OpenSSL in 64-bit mode. I have no idea why it will build
> under that environment and not in my "other" invocation of
> cmd.exe.
Different environment settings for the various paths would be my guess.
> The IA64 build of OpenSSL *did* complete, but I'm not sure how to
> check its architecture, etc. What is the "depends" tool you guys
> have been talking about?
The depends tool ships with various tools including Visual Studio and
the platform SDK.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Building tcnative on win32 [x86_64, failing]
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Mark,
On 6/30/14, 4:23 PM, Mark Thomas wrote:
> On 30/06/2014 14:45, Mark Thomas wrote:
>> I've got OpenSSL and APR building on x64. Currently stuck on the tc
>> native build which is complaining about:
>> error LNK2001: unresolved external symbol __security_cookie
>>
>> I'm fairly sure I've hit this before and just need to remember how I
>> fixed it, find the right part of my notes, do the right Google search.
>>
>> I'm off out now but will be back on this later.
>
> OK. I think I have a working build for tc-native statically linked to
> OpenSSL and APR and dynamically linked to the MS runtime DLLs.
>
> As far as I can tell Mladen has been building with Visual Studio 6.
>
> I need to clean up my build process, script a few things etc and then
> test the result (at least on 32-bit and AMD 64-bit).
My script seemed a bit cleaner than what you are documenting on the
wiki, plus you can get the tools for free (MS VS 12). I was able to
build a complete 32-bit statically-linked libtcnative.dll plus the
openssl.exe utility using the process I knocked-up from scratch.
Note that I have been compiling without using the nasm assembler. I
figured I'd try to get things working without it, then add that
component later once the build process was working.
I have been having trouble building pretty much any 64-bit stuff. I
happen to be running a 32-bit Windows 8.1 OS, but that shouldn't really
be a problem (should it?). I started with OpenSSL and there are a couple
of weird things:
1. Even when configuring for x86-64, the C flags still clearly say
WIN32. Maybe that just means "windows" and not necessarily 32-bit. The
"configure" Perl script does declare it's configuring for x84-64 so
hopefully that's right.
2. OpenSSL's build script calls ml64 which can't be found in the path.
It's probably not good that the command fails, and the build script
doesn't even check to see if it succeeded.
3. The linker fails at the last step for me:
link /nologo /subsystem:console /opt:ref /debug
/out:out32\md4test.exe @
C:\Users\IEUser\AppData\Local\Temp\nmC7C.tmp
LINK : fatal error LNK1207: incompatible PDB format in
'C:\Users\IEUser\AppData\Local\Temp\build-tcnative\build\openssl-1.0.1h\out3\md4test.pdb';
delete and rebuild
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio
12.0\VC\BIN\link.EXE"' : return code '0x4b7'
Stop.
Installing both MS VS 2013 (v12.0) and the SDK separately seems to have
set up a bunch of shortcuts for CLI development. I'm not sure what is
what anymore, but switching to the "VS2013 x64 Cross Tools Command
Prompt" and building OpenSSL in 64-bit mode seems to have produced a set
of binary files (e.g. openssl.exe) that I can't run on my 32-bit
version. That indicates to me that I've successfully built OpenSSL in
64-bit mode. I have no idea why it will build under that environment and
not in my "other" invocation of cmd.exe.
The IA64 build of OpenSSL *did* complete, but I'm not sure how to check
its architecture, etc. What is the "depends" tool you guys have been
talking about?
Thanks,
-chris
Re: Building tcnative on win32 [x86_64, failing]
Posted by Mark Thomas <ma...@apache.org>.
On 30/06/2014 21:32, Mladen Turk wrote:
> On 06/30/2014 10:23 PM, Mark Thomas wrote:
>> On 30/06/2014 14:45, Mark Thomas wrote:
>>> I've got OpenSSL and APR building on x64. Currently stuck on the tc
>>> native build which is complaining about:
>>> error LNK2001: unresolved external symbol __security_cookie
>>>
>>> I'm fairly sure I've hit this before and just need to remember how I
>>> fixed it, find the right part of my notes, do the right Google search.
>>>
>>> I'm off out now but will be back on this later.
>>
>> OK. I think I have a working build for tc-native statically linked to
>> OpenSSL and APR and dynamically linked to the MS runtime DLLs.
>>
>> As far as I can tell Mladen has been building with Visual Studio 6.
>
> Nope.
> I'm building with Windows7 DDK, and some other tools:
> https://github.com/mturk/cmsc
Ah. Interesting. What OS are you running that little lot on?
> Think I'm gonna change that because Microsoft drop that
> in favor of standard Visual Studio.
Change to what? Whenever I have tried to use a newer version of Visual
Studio I have ended up with a dependency on a later version of the MS
runtime DLLs.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Building tcnative on win32 [x86_64, failing]
Posted by Mladen Turk <mt...@apache.org>.
On 06/30/2014 10:23 PM, Mark Thomas wrote:
> On 30/06/2014 14:45, Mark Thomas wrote:
>> I've got OpenSSL and APR building on x64. Currently stuck on the tc
>> native build which is complaining about:
>> error LNK2001: unresolved external symbol __security_cookie
>>
>> I'm fairly sure I've hit this before and just need to remember how I
>> fixed it, find the right part of my notes, do the right Google search.
>>
>> I'm off out now but will be back on this later.
>
> OK. I think I have a working build for tc-native statically linked to
> OpenSSL and APR and dynamically linked to the MS runtime DLLs.
>
> As far as I can tell Mladen has been building with Visual Studio 6.
Nope.
I'm building with Windows7 DDK, and some other tools:
https://github.com/mturk/cmsc
Think I'm gonna change that because Microsoft drop that
in favor of standard Visual Studio.
Regards
--
^TM
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Building tcnative on win32 [x86_64, failing]
Posted by Mark Thomas <ma...@apache.org>.
On 30/06/2014 14:45, Mark Thomas wrote:
> I've got OpenSSL and APR building on x64. Currently stuck on the tc
> native build which is complaining about:
> error LNK2001: unresolved external symbol __security_cookie
>
> I'm fairly sure I've hit this before and just need to remember how I
> fixed it, find the right part of my notes, do the right Google search.
>
> I'm off out now but will be back on this later.
OK. I think I have a working build for tc-native statically linked to
OpenSSL and APR and dynamically linked to the MS runtime DLLs.
As far as I can tell Mladen has been building with Visual Studio 6.
I need to clean up my build process, script a few things etc and then
test the result (at least on 32-bit and AMD 64-bit).
I also want to put together a step-by-step guide for creating the
necessary build environment from scratch.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Building tcnative on win32 [x86_64, failing]
Posted by Mark Thomas <ma...@apache.org>.
On 30/06/2014 10:47, Mark Thomas wrote:
> On 24/06/2014 17:13, Christopher Schultz wrote:
>> Konstantin,
>>
>> On 6/22/14, 1:40 PM, Konstantin Kolinko wrote:
>>> 2014-06-19 23:21 GMT+04:00 Christopher Schultz
>>> <ch...@christopherschultz.net>:
>>>> All,
>>>>
>>>> I'm stuck on trying to get tcnative to build for x86_64.
>>>>
>>>> When I run nmake with BUILD_CPU=x86_64, I get a bunch of
>>>> compiler warnings followed by a linker failure like this
>>>> (apologies for the lack of formatting).
>>>>
>>>> One problem may be that I am running a 32-bit OS: is it
>>>> possible to build 64-bit binaries from 32-bit OS? Given the
>>>> build instructions for x86_64 for tcnative, I would have
>>>> imagined that MSVC++ was a cross-compiler and that I would be
>>>> able to build IA32, IA64, and x86_64 all from the same
>>>> machine.
>>>>
>>>> Here's the command that I actually ran from my script: nmake -f
>>>> NMAKEMakefile BUILD_CPU=%TARGET_ARCH%
>>>> "WITH_APR=%MYTEMP%\build\apr"
>>>> "WITH_OPENSSL=%MYTEMP%\build\openssl" APR_DECLARE_STATIC=1
>>>> %TCNATIVE_ENABLE_OCSP%
>>>>
>>>> This command works when TARGET_ARCH=x86 but fails when
>>>> TARGET_ARCH=x86_64.
>>>>
>>>> (...)
>>>>
>>>> C:\Program Files\Microsoft Visual Studio
>>>> 10.0\VC\INCLUDE\string.h(112) : warning C4391: 'size_t
>>>> strlen(const char *)' : incorrect return type for intrinsic
>>>> function, expected 'unsigned int' C:\Program Files\Microsoft
>>>> Visual Studio 10.0\VC\INCLUDE\string.h(285) : warning C4391:
>>>> 'size_t wcslen(const wchar_t *)' : incorrect return type for
>>>> intrinsic f unction, expected 'unsigned int' rc /l 0x409 /d
>>>> "NDEBUG" /i ".\include" /fo WINXP_X64_DLL_RELEASE\tcnativ
>>>> e-1.res .\os\win32\libtcnative.rc Microsoft (R) Windows (R)
>>>> Resource Compiler Version 6.1.7600.16385 Copyright (C)
>>>> Microsoft Corporation. All rights reserved.
>>>>
>>>
>>> Cross-compilation should be possible. I think Mladen does not own
>>> an Itanium CPU to build i64 version of native.
>>>
>>> I think there either are several versions of the same header
>>> file, or an #if block that changes definition of that size type
>>> depending on architecture.
>>>
>>> In any case the good news is that something changed by changing
>>> TARGET_ARCH. So that flag is working (in some way).
>>
>> Agreed. I was hoping that Mladen would jump in at some point ;)
>>
>>> Several notes on previous mails in this thread 1. Please stick to
>>> some %Subject%. Changing %Subject% I causes GMail to break the
>>> thread.
>>
>> Oh, sorry. I didn't realize that. I'm spoiled by a list-compliant
>> mail agent ;)
>>
>>> 2. Please do not send .bat files as attachments. Those two mails
>>> happened to pass through mailing list server, but were silently
>>> rejected by GMail. I do not have them in my inbox. It is lucky
>>> that they can be viewed on an archive server.
>>>
>>> Maybe paste the contents of the bat file into the message text
>>> inetead of attaching it?
>>
>> Okay, I'll do that next time, assuming I do it again. I may start
>> putting the script somewhere more useful, like BZ, wiki, or even
>> svn with some significant warnings.
>>
>>> BTW, there exists paste.apache.org, but I have never used it.
>>> https://blogs.apache.org/infra/entry/paste_apache_org_sees_the
>>
>> I didn't know about that. Another possibility.
>>
>>> 3. The syntax for using double quotes with SET command is SET
>>> "FOO=BAR BAZ" or SET FOO=BAR BAZ
>>
>> Also very good to know: I'll start using that syntax.
>>
>>> We have an example in catalina.bat.
>>>
>>> 4. Regarding [1], the "license terms" link says that the
>>> installed OS version is time-limited (90 days). Be sure to
>>> archive your scripts and configuration before the time expires.
>>
>> Yup. I do have a "legit" Windows 8 environment as well. I first
>> wanted to find out if it could be done on a freely-available VM
>> because a) I didn't want top pollute my other environment and b) I
>> wanted others to be able to replicate my work without polluting
>> their own environments. Not everyone wants to install MSVC++, etc.
>>
>> Thanks for all your thoughts.
>
> I have been able to build the 64-bit native connector for Windows in
> the past using Visual Studio 6. I have a VM with this set up somewhere.
>
> However, I do recall that while my builds worked well enough for me to
> test whatever issue I was trying to fix at the time (usually some
> non-blocking IO issues) my builds were always very different sizes
> from Mladen's even allowing for static vs dynamic linking.
>
> I also recall an awful lot of trial and error to get things building
> correctly. I do have some notes (somewhere) on what I did at the time
> to get this working.
>
> I have one of the ASF's MSDN licenses so I should have access to any
> tools required to build this, free or otherwise.
>
> I'll dig out my notes, have a read of the current build instructions,
> Mladen's hints and Chris's notes and see if I can help progress this
> further.
I've got OpenSSL and APR building on x64. Currently stuck on the tc
native build which is complaining about:
error LNK2001: unresolved external symbol __security_cookie
I'm fairly sure I've hit this before and just need to remember how I
fixed it, find the right part of my notes, do the right Google search.
I'm off out now but will be back on this later.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Building tcnative on win32 [x86_64, failing]
Posted by Mark Thomas <ma...@apache.org>.
On 24/06/2014 17:13, Christopher Schultz wrote:
> Konstantin,
>
> On 6/22/14, 1:40 PM, Konstantin Kolinko wrote:
>> 2014-06-19 23:21 GMT+04:00 Christopher Schultz
>> <ch...@christopherschultz.net>:
>>> All,
>>>
>>> I'm stuck on trying to get tcnative to build for x86_64.
>>>
>>> When I run nmake with BUILD_CPU=x86_64, I get a bunch of
>>> compiler warnings followed by a linker failure like this
>>> (apologies for the lack of formatting).
>>>
>>> One problem may be that I am running a 32-bit OS: is it
>>> possible to build 64-bit binaries from 32-bit OS? Given the
>>> build instructions for x86_64 for tcnative, I would have
>>> imagined that MSVC++ was a cross-compiler and that I would be
>>> able to build IA32, IA64, and x86_64 all from the same
>>> machine.
>>>
>>> Here's the command that I actually ran from my script: nmake -f
>>> NMAKEMakefile BUILD_CPU=%TARGET_ARCH%
>>> "WITH_APR=%MYTEMP%\build\apr"
>>> "WITH_OPENSSL=%MYTEMP%\build\openssl" APR_DECLARE_STATIC=1
>>> %TCNATIVE_ENABLE_OCSP%
>>>
>>> This command works when TARGET_ARCH=x86 but fails when
>>> TARGET_ARCH=x86_64.
>>>
>>> (...)
>>>
>>> C:\Program Files\Microsoft Visual Studio
>>> 10.0\VC\INCLUDE\string.h(112) : warning C4391: 'size_t
>>> strlen(const char *)' : incorrect return type for intrinsic
>>> function, expected 'unsigned int' C:\Program Files\Microsoft
>>> Visual Studio 10.0\VC\INCLUDE\string.h(285) : warning C4391:
>>> 'size_t wcslen(const wchar_t *)' : incorrect return type for
>>> intrinsic f unction, expected 'unsigned int' rc /l 0x409 /d
>>> "NDEBUG" /i ".\include" /fo WINXP_X64_DLL_RELEASE\tcnativ
>>> e-1.res .\os\win32\libtcnative.rc Microsoft (R) Windows (R)
>>> Resource Compiler Version 6.1.7600.16385 Copyright (C)
>>> Microsoft Corporation. All rights reserved.
>>>
>>
>> Cross-compilation should be possible. I think Mladen does not own
>> an Itanium CPU to build i64 version of native.
>>
>> I think there either are several versions of the same header
>> file, or an #if block that changes definition of that size type
>> depending on architecture.
>>
>> In any case the good news is that something changed by changing
>> TARGET_ARCH. So that flag is working (in some way).
>
> Agreed. I was hoping that Mladen would jump in at some point ;)
>
>> Several notes on previous mails in this thread 1. Please stick to
>> some %Subject%. Changing %Subject% I causes GMail to break the
>> thread.
>
> Oh, sorry. I didn't realize that. I'm spoiled by a list-compliant
> mail agent ;)
>
>> 2. Please do not send .bat files as attachments. Those two mails
>> happened to pass through mailing list server, but were silently
>> rejected by GMail. I do not have them in my inbox. It is lucky
>> that they can be viewed on an archive server.
>>
>> Maybe paste the contents of the bat file into the message text
>> inetead of attaching it?
>
> Okay, I'll do that next time, assuming I do it again. I may start
> putting the script somewhere more useful, like BZ, wiki, or even
> svn with some significant warnings.
>
>> BTW, there exists paste.apache.org, but I have never used it.
>> https://blogs.apache.org/infra/entry/paste_apache_org_sees_the
>
> I didn't know about that. Another possibility.
>
>> 3. The syntax for using double quotes with SET command is SET
>> "FOO=BAR BAZ" or SET FOO=BAR BAZ
>
> Also very good to know: I'll start using that syntax.
>
>> We have an example in catalina.bat.
>>
>> 4. Regarding [1], the "license terms" link says that the
>> installed OS version is time-limited (90 days). Be sure to
>> archive your scripts and configuration before the time expires.
>
> Yup. I do have a "legit" Windows 8 environment as well. I first
> wanted to find out if it could be done on a freely-available VM
> because a) I didn't want top pollute my other environment and b) I
> wanted others to be able to replicate my work without polluting
> their own environments. Not everyone wants to install MSVC++, etc.
>
> Thanks for all your thoughts.
I have been able to build the 64-bit native connector for Windows in
the past using Visual Studio 6. I have a VM with this set up somewhere.
However, I do recall that while my builds worked well enough for me to
test whatever issue I was trying to fix at the time (usually some
non-blocking IO issues) my builds were always very different sizes
from Mladen's even allowing for static vs dynamic linking.
I also recall an awful lot of trial and error to get things building
correctly. I do have some notes (somewhere) on what I did at the time
to get this working.
I have one of the ASF's MSDN licenses so I should have access to any
tools required to build this, free or otherwise.
I'll dig out my notes, have a read of the current build instructions,
Mladen's hints and Chris's notes and see if I can help progress this
further.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Building tcnative on win32 [x86_64, failing]
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Konstantin,
On 6/22/14, 1:40 PM, Konstantin Kolinko wrote:
> 2014-06-19 23:21 GMT+04:00 Christopher Schultz <ch...@christopherschultz.net>:
>> All,
>>
>> I'm stuck on trying to get tcnative to build for x86_64.
>>
>> When I run nmake with BUILD_CPU=x86_64, I get a bunch of compiler
>> warnings followed by a linker failure like this (apologies for the lack
>> of formatting).
>>
>> One problem may be that I am running a 32-bit OS: is it possible to
>> build 64-bit binaries from 32-bit OS? Given the build instructions for
>> x86_64 for tcnative, I would have imagined that MSVC++ was a
>> cross-compiler and that I would be able to build IA32, IA64, and x86_64
>> all from the same machine.
>>
>> Here's the command that I actually ran from my script:
>> nmake -f NMAKEMakefile BUILD_CPU=%TARGET_ARCH%
>> "WITH_APR=%MYTEMP%\build\apr"
>> "WITH_OPENSSL=%MYTEMP%\build\openssl"
>> APR_DECLARE_STATIC=1
>> %TCNATIVE_ENABLE_OCSP%
>>
>> This command works when TARGET_ARCH=x86 but fails when TARGET_ARCH=x86_64.
>>
>> (...)
>>
>> C:\Program Files\Microsoft Visual Studio 10.0\VC\INCLUDE\string.h(112) :
>> warning
>> C4391: 'size_t strlen(const char *)' : incorrect return type for
>> intrinsic function, expected 'unsigned int'
>> C:\Program Files\Microsoft Visual Studio 10.0\VC\INCLUDE\string.h(285) :
>> warning
>> C4391: 'size_t wcslen(const wchar_t *)' : incorrect return type for
>> intrinsic f
>> unction, expected 'unsigned int'
>> rc /l 0x409 /d "NDEBUG" /i ".\include" /fo
>> WINXP_X64_DLL_RELEASE\tcnativ
>> e-1.res .\os\win32\libtcnative.rc
>> Microsoft (R) Windows (R) Resource Compiler Version 6.1.7600.16385
>> Copyright (C) Microsoft Corporation. All rights reserved.
>>
>
> Cross-compilation should be possible. I think Mladen does not own an
> Itanium CPU to build i64 version of native.
>
> I think there either are several versions of the same header file, or
> an #if block that changes definition of that size type depending on
> architecture.
>
> In any case the good news is that something changed by changing
> TARGET_ARCH. So that flag is working (in some way).
Agreed. I was hoping that Mladen would jump in at some point ;)
> Several notes on previous mails in this thread
> 1. Please stick to some %Subject%. Changing %Subject% I causes GMail
> to break the thread.
Oh, sorry. I didn't realize that. I'm spoiled by a list-compliant mail
agent ;)
> 2. Please do not send .bat files as attachments. Those two mails
> happened to pass through mailing list server, but were silently
> rejected by GMail. I do not have them in my inbox. It is lucky that
> they can be viewed on an archive server.
>
> Maybe paste the contents of the bat file into the message text inetead
> of attaching it?
Okay, I'll do that next time, assuming I do it again. I may start
putting the script somewhere more useful, like BZ, wiki, or even svn
with some significant warnings.
> BTW, there exists paste.apache.org, but I have never used it.
> https://blogs.apache.org/infra/entry/paste_apache_org_sees_the
I didn't know about that. Another possibility.
> 3. The syntax for using double quotes with SET command is
> SET "FOO=BAR BAZ"
> or
> SET FOO=BAR BAZ
Also very good to know: I'll start using that syntax.
> We have an example in catalina.bat.
>
> 4. Regarding [1], the "license terms" link says that the installed OS
> version is time-limited (90 days). Be sure to archive your scripts and
> configuration before the time expires.
Yup. I do have a "legit" Windows 8 environment as well. I first wanted
to find out if it could be done on a freely-available VM because a) I
didn't want top pollute my other environment and b) I wanted others to
be able to replicate my work without polluting their own environments.
Not everyone wants to install MSVC++, etc.
Thanks for all your thoughts.
Thanks,
-chris
Re: Building tcnative on win32 [x86_64, failing]
Posted by Konstantin Kolinko <kn...@gmail.com>.
2014-06-19 23:21 GMT+04:00 Christopher Schultz <ch...@christopherschultz.net>:
> All,
>
> I'm stuck on trying to get tcnative to build for x86_64.
>
> When I run nmake with BUILD_CPU=x86_64, I get a bunch of compiler
> warnings followed by a linker failure like this (apologies for the lack
> of formatting).
>
> One problem may be that I am running a 32-bit OS: is it possible to
> build 64-bit binaries from 32-bit OS? Given the build instructions for
> x86_64 for tcnative, I would have imagined that MSVC++ was a
> cross-compiler and that I would be able to build IA32, IA64, and x86_64
> all from the same machine.
>
> Here's the command that I actually ran from my script:
> nmake -f NMAKEMakefile BUILD_CPU=%TARGET_ARCH%
> "WITH_APR=%MYTEMP%\build\apr"
> "WITH_OPENSSL=%MYTEMP%\build\openssl"
> APR_DECLARE_STATIC=1
> %TCNATIVE_ENABLE_OCSP%
>
> This command works when TARGET_ARCH=x86 but fails when TARGET_ARCH=x86_64.
>
> (...)
>
> C:\Program Files\Microsoft Visual Studio 10.0\VC\INCLUDE\string.h(112) :
> warning
> C4391: 'size_t strlen(const char *)' : incorrect return type for
> intrinsic function, expected 'unsigned int'
> C:\Program Files\Microsoft Visual Studio 10.0\VC\INCLUDE\string.h(285) :
> warning
> C4391: 'size_t wcslen(const wchar_t *)' : incorrect return type for
> intrinsic f
> unction, expected 'unsigned int'
> rc /l 0x409 /d "NDEBUG" /i ".\include" /fo
> WINXP_X64_DLL_RELEASE\tcnativ
> e-1.res .\os\win32\libtcnative.rc
> Microsoft (R) Windows (R) Resource Compiler Version 6.1.7600.16385
> Copyright (C) Microsoft Corporation. All rights reserved.
>
Cross-compilation should be possible. I think Mladen does not own an
Itanium CPU to build i64 version of native.
I think there either are several versions of the same header file, or
an #if block that changes definition of that size type depending on
architecture.
In any case the good news is that something changed by changing
TARGET_ARCH. So that flag is working (in some way).
Several notes on previous mails in this thread
1. Please stick to some %Subject%. Changing %Subject% I causes GMail
to break the thread.
2. Please do not send .bat files as attachments. Those two mails
happened to pass through mailing list server, but were silently
rejected by GMail. I do not have them in my inbox. It is lucky that
they can be viewed on an archive server.
Maybe paste the contents of the bat file into the message text inetead
of attaching it?
BTW, there exists paste.apache.org, but I have never used it.
https://blogs.apache.org/infra/entry/paste_apache_org_sees_the
3. The syntax for using double quotes with SET command is
SET "FOO=BAR BAZ"
or
SET FOO=BAR BAZ
We have an example in catalina.bat.
4. Regarding [1], the "license terms" link says that the installed OS
version is time-limited (90 days). Be sure to archive your scripts and
configuration before the time expires.
[1] https://www.modern.ie/en-us/virtualization-tools
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Building tcnative on win32 [x86_64, failing]
Posted by Christopher Schultz <ch...@christopherschultz.net>.
All,
I'm stuck on trying to get tcnative to build for x86_64.
When I run nmake with BUILD_CPU=x86_64, I get a bunch of compiler
warnings followed by a linker failure like this (apologies for the lack
of formatting).
One problem may be that I am running a 32-bit OS: is it possible to
build 64-bit binaries from 32-bit OS? Given the build instructions for
x86_64 for tcnative, I would have imagined that MSVC++ was a
cross-compiler and that I would be able to build IA32, IA64, and x86_64
all from the same machine.
Here's the command that I actually ran from my script:
nmake -f NMAKEMakefile BUILD_CPU=%TARGET_ARCH%
"WITH_APR=%MYTEMP%\build\apr"
"WITH_OPENSSL=%MYTEMP%\build\openssl"
APR_DECLARE_STATIC=1
%TCNATIVE_ENABLE_OCSP%
This command works when TARGET_ARCH=x86 but fails when TARGET_ARCH=x86_64.
Any ideas?
Thanks,
-chris
cl -c -nologo -DWIN32 -D_WIN32 -D_WINDOWS -DWINNT -D_WINNT
-D_WIN32_WINN
T=0x0501 -DWINVER=0x0501 -D_WIN32_IE=0x0600 -W3 -EHsc -D_MBCS -DMBCS
-D_AMD64_=1
-DWIN64 -D_WIN64 -O2 -Ob2 -Zi -DNDEBUG -D_MT -MD -DAPR_DECLARE_STATIC
-DZLIB_WI
NAPI -DNO_IDEA -DNO_RC5 -DNO_MDC2 -DOPENSSL_NO_IDEA -DOPENSSL_NO_RC5
-DOPENSSL_
NO_MDC2 -DHAVE_OPENSSL -DHAVE_SSL_SET_STATE=1 -I.\include -I "C:\Program
Files\J
ava\jdk1.7.0_60\include" -I "C:\Program
Files\Java\jdk1.7.0_60\include\win32" -I
C:\Users\IEUser\AppData\Local\Temp\build-tcnative\build\apr\include
-IC:\Users\I
EUser\AppData\Local\Temp\build-tcnative\build\apr\include\arch\win32
-IC:\Users\
IEUser\AppData\Local\Temp\build-tcnative\build\openssl\include
-FoWINXP_X64_DLL_
RELEASE\ -FdWINXP_X64_DLL_RELEASE\tcnative-1-src .\os\win32\system.c
system.c
C:\Program Files\Microsoft Visual Studio 10.0\VC\INCLUDE\string.h(112) :
warning
C4391: 'size_t strlen(const char *)' : incorrect return type for
intrinsic function, expected 'unsigned int'
C:\Program Files\Microsoft Visual Studio 10.0\VC\INCLUDE\string.h(285) :
warning
C4391: 'size_t wcslen(const wchar_t *)' : incorrect return type for
intrinsic f
unction, expected 'unsigned int'
rc /l 0x409 /d "NDEBUG" /i ".\include" /fo
WINXP_X64_DLL_RELEASE\tcnativ
e-1.res .\os\win32\libtcnative.rc
Microsoft (R) Windows (R) Resource Compiler Version 6.1.7600.16385
Copyright (C) Microsoft Corporation. All rights reserved.
link.exe /NOLOGO /DLL /SUBSYSTEM:WINDOWS /MACHINE:AMD64 /OPT:REF
/version:1.1 user32.lib psapi.lib gdi32.lib shlwapi.lib wldap32.lib
ole32.lib apr-1.lib
libeay32.lib ssleay32.lib WINXP_X64_DLL_RELEASE\address.obj
WINXP_X64_DLL_RELE
ASE\bb.obj WINXP_X64_DLL_RELEASE\dir.obj
WINXP_X64_DLL_RELEASE\error.obj WINX
P_X64_DLL_RELEASE\file.obj WINXP_X64_DLL_RELEASE\info.obj
WINXP_X64_DLL_RELEAS
E\jnilib.obj WINXP_X64_DLL_RELEASE\lock.obj
WINXP_X64_DLL_RELEASE\misc.obj WI
NXP_X64_DLL_RELEASE\mmap.obj WINXP_X64_DLL_RELEASE\multicast.obj
WINXP_X64_DLL
_RELEASE\network.obj WINXP_X64_DLL_RELEASE\os.obj
WINXP_X64_DLL_RELEASE\poll.o
bj WINXP_X64_DLL_RELEASE\pool.obj WINXP_X64_DLL_RELEASE\proc.obj
WINXP_X64_DL
L_RELEASE\shm.obj WINXP_X64_DLL_RELEASE\ssl.obj
WINXP_X64_DLL_RELEASE\sslconte
xt.obj WINXP_X64_DLL_RELEASE\sslinfo.obj
WINXP_X64_DLL_RELEASE\sslnetwork.obj
WINXP_X64_DLL_RELEASE\sslutils.obj WINXP_X64_DLL_RELEASE\stdlib.obj
WINXP_X64
_DLL_RELEASE\user.obj WINXP_X64_DLL_RELEASE\thread.obj
WINXP_X64_DLL_RELEASE\n
tpipe.obj WINXP_X64_DLL_RELEASE\registry.obj
WINXP_X64_DLL_RELEASE\system.obj
WINXP_X64_DLL_RELEASE\tcnative-1.res kernel32.lib advapi32.lib
ws2_32.lib mswsock.lib ole32.lib shell32.lib rpcrt4.lib
/libpath:"C:\Users\IEUser\AppData\Local\Temp\build-tcnative\build\apr\lib"
/libpath:"C:\Users\IEUser\AppData\Local\Temp\build-tcnative\build\openssl\lib"
/pdb:WINXP_X64_DLL_RELEASE\tcnative-1.pdb /out:
WINXP_X64_DLL_RELEASE\tcnative-1.dll
WINXP_X64_DLL_RELEASE\address.obj : fatal error LNK1112: module machine
type 'X86' conflicts with target machine type 'x64'
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio
10.0\VC\Bin\link.exe"' : return code '0x458'
Stop.
Re: Building tcnative on win32 [progress!]
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Konstantin,
On 6/18/14, 7:40 PM, Konstantin Preißer wrote:
> Hi Christopher,
>
>> -----Original Message-----
>> From: Christopher Schultz [mailto:chris@christopherschultz.net]
>> Sent: Thursday, June 19, 2014 1:31 AM
>> To: Tomcat Developers List
>> Subject: Re: Building tcnative on win32 [progress!]
>>
>> Konstantin,
>>
>> On 6/18/14, 5:54 PM, Konstantin Preißer wrote:
>>>> -----Original Message-----
>>>> From: Konstantin Preißer [mailto:kpreisser@apache.org]
>>>> Sent: Wednesday, June 18, 2014 11:42 PM
>>>
>>>> Although Winrar.exe isn't a command-line tool, you can start it from
>>>> command-line to extract a file. Unfortunately, when I try to run this
>>>> command from an elevated cmd.exe to extract the OpenSSL source code
>>>> package, WinRAR fails to create the Symlinks ("the system cannot find the
>>>> specified path"):
>>>> Start /wait "" "%ProgramFiles%\WinRAR\winrar.exe" x openssl-
>> 1.0.1h.tar.gz
>>>
>>> OK, I think the problem is when running the above command, WinRAR uses
>> a relative path to create a symlink which fails. It works if you specify an
>> absolute path as target:
>>>
>>> Start /wait "" "%ProgramFiles%\WinRAR\winrar.exe" x openssl-
>> 1.0.1h.tar.gz C:\MyFolder\OpenSSL-Output\
>>>
>>> With this command it will extract it to C:\MyFolder\OpenSSL-Output\ and
>> create the symlinks successfully.
>>>
>>>
>>> Unfortunately, WinRAR is proprietary software (not free). I have
>>> tried 7-Zip, but instead of actually creating the symlinks, it just
>>> seems to copy the file to the path where the symlink should be
>>> created.
>>
>> I was using 7za.exe and it was creating files whose contents contained
>> the path-target of the symlink instead of what you describe above.
>>
>> I'd be perfectly happy if it would just duplicate the files instead of
>> creating symlinks, but that does not seem to be the actual behavior.
>
> Sorry, you are right: After I looked at the files, I saw that 7z.exe created files which contained only the path for the symlinks, instead of duplicating the file. :(
>
> Unfortunately, I also have not found another tool which could duplicate the symlink file or actually create the NTFS symlink other than WinRAR.
Seems like the intertubes agree. :(
After more digging, it appears that OpenSSL, after making things a pain
in the ass (broken "symlinks" on win32 tarball-expansions), the build
process creates an inc32/openssl directory containing all of the C
header files you might need.
So, instead of sensibly using the OPENSSL_HOME where I expanded the
source and build the library, I can simply copy inc32/openssl/*.h to
somewhere else that then has include/openssl/*.h where tcnative's build
can find it.
tcnative is now compling, but it's having trouble locating the APR
libraries. Time to take a break for some more World Cup action. It's
much more fun than fighting builds on Windows.
-chris
RE: Building tcnative on win32 [progress!]
Posted by Konstantin Preißer <kp...@apache.org>.
Hi Christopher,
> -----Original Message-----
> From: Christopher Schultz [mailto:chris@christopherschultz.net]
> Sent: Thursday, June 19, 2014 1:31 AM
> To: Tomcat Developers List
> Subject: Re: Building tcnative on win32 [progress!]
>
> Konstantin,
>
> On 6/18/14, 5:54 PM, Konstantin Preißer wrote:
> >> -----Original Message-----
> >> From: Konstantin Preißer [mailto:kpreisser@apache.org]
> >> Sent: Wednesday, June 18, 2014 11:42 PM
> >
> >> Although Winrar.exe isn't a command-line tool, you can start it from
> >> command-line to extract a file. Unfortunately, when I try to run this
> >> command from an elevated cmd.exe to extract the OpenSSL source code
> >> package, WinRAR fails to create the Symlinks ("the system cannot find the
> >> specified path"):
> >> Start /wait "" "%ProgramFiles%\WinRAR\winrar.exe" x openssl-
> 1.0.1h.tar.gz
> >
> > OK, I think the problem is when running the above command, WinRAR uses
> a relative path to create a symlink which fails. It works if you specify an
> absolute path as target:
> >
> > Start /wait "" "%ProgramFiles%\WinRAR\winrar.exe" x openssl-
> 1.0.1h.tar.gz C:\MyFolder\OpenSSL-Output\
> >
> > With this command it will extract it to C:\MyFolder\OpenSSL-Output\ and
> create the symlinks successfully.
> >
> >
> > Unfortunately, WinRAR is proprietary software (not free). I have
> > tried 7-Zip, but instead of actually creating the symlinks, it just
> > seems to copy the file to the path where the symlink should be
> > created.
>
> I was using 7za.exe and it was creating files whose contents contained
> the path-target of the symlink instead of what you describe above.
>
> I'd be perfectly happy if it would just duplicate the files instead of
> creating symlinks, but that does not seem to be the actual behavior.
Sorry, you are right: After I looked at the files, I saw that 7z.exe created files which contained only the path for the symlinks, instead of duplicating the file. :(
Unfortunately, I also have not found another tool which could duplicate the symlink file or actually create the NTFS symlink other than WinRAR.
Regards,
Konstantin Preißer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Building tcnative on win32 [progress!]
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Konstantin,
On 6/18/14, 5:54 PM, Konstantin Preißer wrote:
>> -----Original Message-----
>> From: Konstantin Preißer [mailto:kpreisser@apache.org]
>> Sent: Wednesday, June 18, 2014 11:42 PM
>
>> Although Winrar.exe isn't a command-line tool, you can start it from
>> command-line to extract a file. Unfortunately, when I try to run this
>> command from an elevated cmd.exe to extract the OpenSSL source code
>> package, WinRAR fails to create the Symlinks ("the system cannot find the
>> specified path"):
>> Start /wait "" "%ProgramFiles%\WinRAR\winrar.exe" x openssl-1.0.1h.tar.gz
>
> OK, I think the problem is when running the above command, WinRAR uses a relative path to create a symlink which fails. It works if you specify an absolute path as target:
>
> Start /wait "" "%ProgramFiles%\WinRAR\winrar.exe" x openssl-1.0.1h.tar.gz C:\MyFolder\OpenSSL-Output\
>
> With this command it will extract it to C:\MyFolder\OpenSSL-Output\ and create the symlinks successfully.
>
>
> Unfortunately, WinRAR is proprietary software (not free). I have
> tried 7-Zip, but instead of actually creating the symlinks, it just
> seems to copy the file to the path where the symlink should be
> created.
I was using 7za.exe and it was creating files whose contents contained
the path-target of the symlink instead of what you describe above.
I'd be perfectly happy if it would just duplicate the files instead of
creating symlinks, but that does not seem to be the actual behavior.
-chris
RE: Building tcnative on win32 [progress!]
Posted by Konstantin Preißer <kp...@apache.org>.
> -----Original Message-----
> From: Konstantin Preißer [mailto:kpreisser@apache.org]
> Sent: Wednesday, June 18, 2014 11:42 PM
> Although Winrar.exe isn't a command-line tool, you can start it from
> command-line to extract a file. Unfortunately, when I try to run this
> command from an elevated cmd.exe to extract the OpenSSL source code
> package, WinRAR fails to create the Symlinks ("the system cannot find the
> specified path"):
> Start /wait "" "%ProgramFiles%\WinRAR\winrar.exe" x openssl-1.0.1h.tar.gz
OK, I think the problem is when running the above command, WinRAR uses a relative path to create a symlink which fails. It works if you specify an absolute path as target:
Start /wait "" "%ProgramFiles%\WinRAR\winrar.exe" x openssl-1.0.1h.tar.gz C:\MyFolder\OpenSSL-Output\
With this command it will extract it to C:\MyFolder\OpenSSL-Output\ and create the symlinks successfully.
Unfortunately, WinRAR is proprietary software (not free). I have tried 7-Zip, but instead of actually creating the symlinks, it just seems to copy the file to the path where the symlink should be created.
Regards,
Konstantin Preißer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
RE: Building tcnative on win32 [progress!]
Posted by Konstantin Preißer <kp...@apache.org>.
Hi Christopher,
> -----Original Message-----
> From: Christopher Schultz [mailto:chris@christopherschultz.net]
> Sent: Wednesday, June 18, 2014 9:53 PM
> It seems that the OpenSSL source package contains symlinks. I haven't
> found a command-line tar program on win32 that can expand an archive
> containing symlinks.
>
> This is getting frustrating. :(
WinRAR can create Symlinks on Windows when extracting .tar.gz files (Note that by default, you need administrative rights to create a Symlink on a NTFS drive).
Although Winrar.exe isn't a command-line tool, you can start it from command-line to extract a file. Unfortunately, when I try to run this command from an elevated cmd.exe to extract the OpenSSL source code package, WinRAR fails to create the Symlinks ("the system cannot find the specified path"):
Start /wait "" "%ProgramFiles%\WinRAR\winrar.exe" x openssl-1.0.1h.tar.gz
However, when opening an elevated Winrar.exe (GUI Version) and extract the .tar.gz file there, WinRAR successfully creates the symlinks though. Maybe there is some bug in Winrar so it cannot create symlinks under some conditions.
Regards,
Konstantin Preißer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Building tcnative on win32 [progress!]
Posted by Christopher Schultz <ch...@christopherschultz.net>.
All,
On 6/18/14, 1:58 PM, Christopher Schultz wrote:
> I'm getting a lot of crypto-related build (not link) errors, so I'll
> have to follow-up on those.
Okay, so it seems that OpenSSL's include file is ... broken.
C:\Users\IEUser\Desktop>type
%MYTEMP%\build\openssl-1.0.1h\include\openssl\openslv.h
../../crypto/opensslv.h
That's not a valid C header file. It comes right out of the OpenSSL
source distribution, and its used by tcnative directly. All kinds of
compiler errors are thrown when that gets included from
include/ssl_private.h
The file OPENSSL_HOME/include/openssl/../../crypto/opensslv.h does
contain a legitimate C header file.
I checked on my Mac and a Linux box and I can confirm that
/usr/include/openssl/opensslv.h contains what the
../../crypto/opensslv.h file referenced above contains.
It seems that the OpenSSL source package contains symlinks. I haven't
found a command-line tar program on win32 that can expand an archive
containing symlinks.
This is getting frustrating. :(
-chris
Re: Building tcnative on win32 [progress!]
Posted by Christopher Schultz <ch...@christopherschultz.net>.
All,
On 6/18/14, 1:50 PM, Christopher Schultz wrote:
> All,
>
> On 6/13/14, 5:36 PM, Christopher Schultz wrote:
>> 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.
>
> I've got openssl and libapr patched and built. Now, I'm working on
> Mladen's instructions for building tcnative itself. Quoting from his BZ
> comment:
>
>> It's very simple. The biggest problem is compiling apr and openssl.
>> OpenSSL needs to be patched to allow /MD with static lib (something I
>> tried to convince openssl developers for years without luck). We have
>> the patch in the source dist. Then you have to put apr and openssl
>> include and lib files to some directory
>>
>> C:\foo\bar\include
>> C:\foo\bar\lib
>>
>> Then execute:
>> nmake -f NMAKEMakefile WITH_APR=C:\foo\bar WITH_OPENSSL=C:\foo\bar APR_DECLARE_STATIC=1 [ENABLE_OCSP=1]
>>
>> When building APR I also modify apr.hw and set APR_HAVE_IPV6 to 1.
>
> I have patched APR appropriately and executed this command:
>
> C:\work\tomcat-native-1.1.30-src> nmake -f NMAKEMakefile
> "WITH_APR=%MYTEMP%\build\apr"
> "WITH_OPENSSL=%MYTEMP%\build\openssl-%OPENSSL_VERSION%" APR_DECLARE_STATIC=1
>
> (MYTEMP\build\apr contains the apr build and
> MYTEMP\build\openssl-OPENSSL_VERSION contains the openssl build)
>
> nmake responds with the following:
>
> Microsoft (R) Program Maintenance Utility Version 10.00.30319.01
> Copyright (C) Microsoft Corporation. All rights reserved.
>
> NMAKEmakefile.inc(123) : fatal error U1050: Must specify CPU environment
> variable (X86, X64, I64) x86
> Stop.
>
> Okay, so I have to set the CPU environment variable. I didn't know that,
> but the build script helpfully tells me I have to, and gives me a list
> of recognized values.
>
> I also noticed that I hadn't installed Java (duh) and so the next build
> failed because jni.h could not be found. After installing Java and
> setting JAVA_HOME appropriately, nmake now reports:
>
> C:\work\tomcat-native-1.1.30-src> SET CPU=X86
> C:\work\tomcat-native-1.1.30-src> SET JAVA_HOME="C:\Program
> Files\Java\jdk1.7.0_60"
> C:\work\tomcat-native-1.1.30-src> nmake -f NMAKEMakefile
> "WITH_APR=%MYTEMP%\build\apr"
> "WITH_OPENSSL=%MYTEMP%\build\openssl-%OPENSSL_VERSION%" APR_DECLARE_STATIC=1
>
> Microsoft (R) Program Maintenance Utility Version 10.00.30319.01
> Copyright (C) Microsoft Corporation. All rights reserved.
>
> NMAKEmakefile.inc(330) : fatal error U1023: syntax error in expression
> Stop.
>
> This is NMAKEmakefile.inc, starting on line 330:
> !IF DEFINED(JAVA_HOME) && "$(JAVA_HOME)" != ""
> JAVA_INCLUDES=-I "$(JAVA_HOME)\include" -I "$(JAVA_HOME)\include\win32"
> !ENDIF
>
> I'm not nmake expert, but I don't see any problems with the above
> make-script. I checked to see that things like DEFINED(), &&, and != are
> used in other places, and everything seems in order.
>
> Any suggestions?
Aw, geez. Evidently, among other things, Windows is bad at quotes, too.
There is a difference between:
C:\work\tomcat-native-1.1.30-src> SET JAVA_HOME="C:\Program
Files\Java\jdk1.7.0_60"
AND
C:\work\tomcat-native-1.1.30-src> SET JAVA_HOME=C:\Program
Files\Java\jdk1.7.0_60
(note the lack of quotes around the path in the second example)
So, tcnative is building, now.
I'm getting a lot of crypto-related build (not link) errors, so I'll
have to follow-up on those.
-chris
Re: Building tcnative on win32 [progress!]
Posted by Christopher Schultz <ch...@christopherschultz.net>.
All,
On 6/13/14, 5:36 PM, Christopher Schultz wrote:
> 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.
I've got openssl and libapr patched and built. Now, I'm working on
Mladen's instructions for building tcnative itself. Quoting from his BZ
comment:
> It's very simple. The biggest problem is compiling apr and openssl.
> OpenSSL needs to be patched to allow /MD with static lib (something I
> tried to convince openssl developers for years without luck). We have
> the patch in the source dist. Then you have to put apr and openssl
> include and lib files to some directory
>
> C:\foo\bar\include
> C:\foo\bar\lib
>
> Then execute:
> nmake -f NMAKEMakefile WITH_APR=C:\foo\bar WITH_OPENSSL=C:\foo\bar APR_DECLARE_STATIC=1 [ENABLE_OCSP=1]
>
> When building APR I also modify apr.hw and set APR_HAVE_IPV6 to 1.
I have patched APR appropriately and executed this command:
C:\work\tomcat-native-1.1.30-src> nmake -f NMAKEMakefile
"WITH_APR=%MYTEMP%\build\apr"
"WITH_OPENSSL=%MYTEMP%\build\openssl-%OPENSSL_VERSION%" APR_DECLARE_STATIC=1
(MYTEMP\build\apr contains the apr build and
MYTEMP\build\openssl-OPENSSL_VERSION contains the openssl build)
nmake responds with the following:
Microsoft (R) Program Maintenance Utility Version 10.00.30319.01
Copyright (C) Microsoft Corporation. All rights reserved.
NMAKEmakefile.inc(123) : fatal error U1050: Must specify CPU environment
variable (X86, X64, I64) x86
Stop.
Okay, so I have to set the CPU environment variable. I didn't know that,
but the build script helpfully tells me I have to, and gives me a list
of recognized values.
I also noticed that I hadn't installed Java (duh) and so the next build
failed because jni.h could not be found. After installing Java and
setting JAVA_HOME appropriately, nmake now reports:
C:\work\tomcat-native-1.1.30-src> SET CPU=X86
C:\work\tomcat-native-1.1.30-src> SET JAVA_HOME="C:\Program
Files\Java\jdk1.7.0_60"
C:\work\tomcat-native-1.1.30-src> nmake -f NMAKEMakefile
"WITH_APR=%MYTEMP%\build\apr"
"WITH_OPENSSL=%MYTEMP%\build\openssl-%OPENSSL_VERSION%" APR_DECLARE_STATIC=1
Microsoft (R) Program Maintenance Utility Version 10.00.30319.01
Copyright (C) Microsoft Corporation. All rights reserved.
NMAKEmakefile.inc(330) : fatal error U1023: syntax error in expression
Stop.
This is NMAKEmakefile.inc, starting on line 330:
!IF DEFINED(JAVA_HOME) && "$(JAVA_HOME)" != ""
JAVA_INCLUDES=-I "$(JAVA_HOME)\include" -I "$(JAVA_HOME)\include\win32"
!ENDIF
I'm not nmake expert, but I don't see any problems with the above
make-script. I checked to see that things like DEFINED(), &&, and != are
used in other places, and everything seems in order.
Any suggestions?
Thanks,
-chris
RE: Building tcnative on win32
Posted by Konstantin Preißer <kp...@apache.org>.
Hi Christopher,
> -----Original Message-----
> From: Christopher Schultz [mailto:chris@christopherschultz.net]
> Sent: Friday, June 13, 2014 11:36 PM
> To: dev@tomcat.apache.org
> Subject: Building tcnative on win32
>
> 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.
If you look for a more powerful scripting environment included in Windows than cmd.exe, you can take a look at Windows Powershell [1] which has been introduced with Vista.
I haven't worked much with Powershell yet so I can't comment on how useful it is, but I know that is based on .Net so you should be able to do anything that you could do in C#/.Net.
For example, to download a file you should be able to use System.Web.WebClient like it is described at [2].
For extracting a ZIP file, you could use System.IO.Compression.ZipFile.ExtractToDirectory() as described at [3].
Regards,
Konstantin Preißer
[1] http://en.wikipedia.org/wiki/Windows_PowerShell
[2] http://answers.oreilly.com/topic/2006-how-to-download-a-file-from-the-internet-with-windows-powershell/
[3] http://serverfault.com/a/461812
> (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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
RE: Building tcnative on win32
Posted by Konstantin Preißer <kp...@apache.org>.
Hi Christopher,
> -----Original Message-----
> From: Christopher Schultz [mailto:chris@christopherschultz.net]
> Sent: Wednesday, June 18, 2014 7:05 PM
> >> 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.
> >
> > Maybe Java + Apache Ant?
> >
> > Or maybe NAnt has some tasks for that
> > http://nant.sourceforge.net/
>
> I considered Nant, but I wanted to limit the dependencies required to
> build tcnative.
Would Windows Powershell in this case work for you (as mentioned in my previous email)?
For example, to download a ZIP file and extract it, you could use a script like this that downloads Tomcat 8.0.8 x64 ZIP file and extract it to a "work" subfolder:
[[[
try
{
# Add "System.IO.Compression.FileSystem" assembly so we can extract ZIP archives.
# Note: This requires .Net 4.5 or higher (included since Windows 8 / Server 2012)
Add-Type -AssemblyName System.IO.Compression.FileSystem
# Work folder where we download and extract files.
$workFolder = Join-Path $pwd "work"
# Remove the work folder if it exists, then (re-)create it.
If (Test-Path $workFolder) {
Remove-Item $workFolder -Recurse
}
(New-Item $workFolder -ItemType directory) | Out-Null
$downloadUrl = "http://apache.openmirror.de/tomcat/tomcat-8/v8.0.8/bin/apache-tomcat-8.0.8-windows-x64.zip"
$downloadPath = Join-Path $workFolder "MyTomcatDownload.zip"
Write-Host "Downloading $downloadUrl to $downloadPath ..."
Write-Host ""
# Note: "Invoke-WebRequest http://xxx -OutFile xxx" will read the whole content to memory, then writing it to disk.
(New-Object System.Net.WebClient).DownloadFile($downloadUrl, $downloadPath)
# Extract the ZIP archive to the current directory.
Write-Host "Extracting ZIP archive..."
Write-Host ""
[System.IO.Compression.ZipFile]::ExtractToDirectory($downloadPath, $workFolder)
Write-Host "Finished."
}
catch
{
Write-Host ("Exception: " + $_.Exception.GetType().FullName) -ForegroundColor Red
Write-Host ("Message: " + $_.Exception.Message) -ForegroundColor Red
}
]]]
To run the script if it is saved as "MyScript1.ps" in the current directory, you can use the following command (setting ExecutionPolicy is required to allow to run scripts in the current session):
Powershell.exe -ExecutionPolicy RemoteSigned .\MyScript.ps1
Hope this helps.
Regards,
Konstantin Preißer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Building tcnative on win32
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Konstantin,
On 6/13/14, 5:56 PM, Konstantin Kolinko wrote:
> 2014-06-14 1:36 GMT+04:00 Christopher Schultz <ch...@christopherschultz.net>:
>> 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.
>
> Maybe Java + Apache Ant?
>
> Or maybe NAnt has some tasks for that
> http://nant.sourceforge.net/
I considered Nant, but I wanted to limit the dependencies required to
build tcnative.
>> 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:
>> (....)
>
> This package? How did you install it? (Interactive installer, or zip).
> http://gnuwin32.sourceforge.net/packages/patch.htm
>
> [quote] from "Installation, Usage and Help" of the above page
> On MS-Windows, the patchfile must be a text file, i.e. CR-LF must be
> used as line endings. A file with LF may give the error: "Assertion
> failed, hunk, file patch.c, line 343," unless the option '--binary' is
> given.
> [/quote]
Thanks for that. Adding --binary fixes the problem for the openssl
patch. The APR patch seems to not to apply no matter what. I think it
may be because the APR patch is for 1.4.x and the current version of
libapr is 1.5.1. I manually applied the patch and have a new patch
available. I'm not sure how to detect the version of libapr being used
to apply the right patch, but we can provide both patches and let users
apply the correct one for their environment.
Thanks,
-chris
Re: Building tcnative on win32
Posted by Konstantin Kolinko <kn...@gmail.com>.
2014-06-14 1:36 GMT+04:00 Christopher Schultz <ch...@christopherschultz.net>:
> 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.
Maybe Java + Apache Ant?
Or maybe NAnt has some tasks for that
http://nant.sourceforge.net/
> (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.)
For simple editing I use FAR Manager built-in editor.
http://www.farmanager.com/screenshots.php?l=en
> 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:
> (....)
This package? How did you install it? (Interactive installer, or zip).
http://gnuwin32.sourceforge.net/packages/patch.htm
[quote] from "Installation, Usage and Help" of the above page
On MS-Windows, the patchfile must be a text file, i.e. CR-LF must be
used as line endings. A file with LF may give the error: "Assertion
failed, hunk, file patch.c, line 343," unless the option '--binary' is
given.
[/quote]
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Building tcnative on win32 [alpha]
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Konstantin,
On 6/19/14, 12:20 PM, Konstantin Preißer wrote:
> One other thing: Do you know which version of VC++ was used to date
> to build Tomcat Native?
I tried removing the Windows SDK and I was unable to link the compiled
objects. I think there are some required libraries in the SDK.
-chris
RE: Building tcnative on win32 [alpha]
Posted by Konstantin Preißer <kp...@apache.org>.
Hi Christopher,
thank you for your reply.
> -----Original Message-----
> From: Christopher Schultz [mailto:chris@christopherschultz.net]
> Sent: Thursday, June 19, 2014 6:57 PM
>
> Konstantin,
>
> On 6/19/14, 12:20 PM, Konstantin Preißer wrote:
> > good work for creating a script to build tcnative. Below are some
> > comments/review of it.
>
> Thanks for your review. See below for more.
>
> FYI I *have* been reading your prior comments. I didn't want to get into
> Power Shell because of my lack of experience with it: working with
> plain-old batch files is something I am more familiar with, even though
> it is astoundingly miserable when compared to UNIX-style shell scripting.
OK, no problem. I admit it is not easy to learn using Powershell as it has completely new syntax/commands. (It has some aliases to make transition easier, e.g. you can write echo instead of Write-Host, wget/curl instead of Invoke-WebRequest, cd instead of Set-Location etc.)
> > Ah, I now understand why you wrote in an earlier mail that this
> > patch
> > tool needs administrator rights - it does not include a proper manifest.
> > Starting with Windows Vista, Windows uses such manifest to determine if
> > an EXE should be run with Administrator rights (showing an UAC dialog)
> > or user rights. For EXEs that don't include such a manifest, it cannot
> > know whether it should run as administrator, so it checks the filename
> > for patterns like "setup", "install", "patch", "update" etc.
>
> Oh, so it I just renamed the binary to something else, it probably
> wouldn't complain? That's great security right there.
Yes - "Not complain" here means it does not run with administrator priviliges (If you explicitely run it as administrator, then you still get the UAC dialog). It is just some guessing of Windows that automatically request you to run a tool as administrator (UAC dialog) if it doesn't have a correct manifest, so this shouldn't be security-related.
> > 4) The script seems to require perl.exe (you did not mention this in your
> mail ;-)
>
> Yeah, I totally forgot to mention that. I figured I'd include it with my
> next update (which I also forgot).
>
> > I have not yet tried to run it with perl installed, as I get an error
> > that patch.exe cannot find "apr-1.5.patch".
>
> Hah.. yes. The APR patch includes in the tcnative source distro doesn't
> seem to work with APR 1.5.1. I think it's because it was made against
> APR 1.4.8 and the two versions are different enough that patch gives up.
> Here's the patch for APR 1.5.1:
>
> ---
> \Users\IEUser\AppData\Local\Temp\build-tcnative\build\apr-
> 1.5.1\include\apr.hw
> Fri Jun 07 08:57:56 2013
> +++ apr.hw Wed Jun 18 07:49:57 2014
> @@ -282,7 +282,7 @@
> #define APR_HAVE_IN_ADDR 1
> #define APR_HAVE_INET_ADDR 1
> #define APR_HAVE_INET_NETWORK 0
> -#define APR_HAVE_IPV6 0
> +#define APR_HAVE_IPV6 1
> #define APR_HAVE_MEMMOVE 1
> #define APR_HAVE_SETRLIMIT 0
> #define APR_HAVE_SIGACTION 0
> @@ -346,7 +346,7 @@
> /* If we have a TCP implementation that can be "corked", what flag
> * do we use?
> */
> -#define APR_TCP_NOPUSH_FLAG @apr_tcp_nopush_flag@
> +#define APR_TCP_NOPUSH_FLAG 0
>
> /* Is the TCP_NODELAY socket option inherited from listening sockets?
> */
>
>
> > Regarding the dependency to wget.exe, I think that can be avoided by
> > making a Powershell Script (as said earlier) as it allows to directly
> > download a file from command line. I think this also will make the
> > script easier to write as you can write more in the style of an
> > programming/scripting language instead of Windows/DOS commands.
> >
> > I can look about creating a Powershell version of the script if you
> > have finished it. What do you think?
>
> Anything that makes this procedure replicable by someone else is a Good
> Thing.
>
> After Mladen's encouragement that "it just takes 10 minutes" it's been
> pretty frustrating trying to create these artifacts.
OK.
> > One other thing: Do you know which version of VC++ was used to date
> > to build Tomcat Native?
>
> Mladen mentioned it at one time, but I can't remember where. He also
> mentioned how to modify one of the components to build it statically.
> I'm searching for that reference right now but I'm having a hard time
> finding it.
>
> Basically, I'm working off of these resources:
> 1. https://issues.apache.org/bugzilla/show_bug.cgi?id=56363#c10
> 2. INSTALL.W32 script in OpenSSL distribution
> 3. Thread on apr-dev@ : http://markmail.org/thread/ecu3gwgr77cb6mtm
> 4. Random directory listings after things have built. ;)
> That's how I found out that OpenSSL puts their headers in inc32/
> after the build. That's also how I found that there is an out32/ and
> out32dll/ directory where the former has the statically-linked version
> of openssl.exe in it.
>
> > If I open it with some EXE inspection tools, I can see that it has a
> > dependency to msvcrt.dll, which seems like an older version of VC++
> > (maybe VC++ 6.0 which is a really old version - but I'm not sure).
> > I don't know much about building native (C/C++) apps; however if I
> > create a C++ DLL with Visual Studio 2013, then the DLL has a
> > dependency to msvcr120.dll, which maybe is not included by default in
> > Windows (at least not in earlier versions of Windows like Windows
> > 7/2008R2).
>
> Whatever Mladen tends to build it with is probably correct.
>
> How does one inspect a DLL in this way to see dependencies?
I used the tool "Dependency Walker" from [1]. When I open tcnative.dll from current Tomcat 8.0.8 Windows x64 build, it shows following entries:
User32.dll
Psapi.dll
Shlwapi.dll
Kernel32.dll
Advapi32.dll
Ws2_32.dll
Mswsock.dll
Msvcrt.dll
So it seems to use Msvcrt.dll as C runtime library. However, I have not yet tried your updated script to see what dependencies that build will have.
Regards,
Konstantin Preißer
[1] http://www.dependencywalker.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Building tcnative on win32 [alpha]
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Konstantin,
On 6/19/14, 12:20 PM, Konstantin Preißer wrote:
> good work for creating a script to build tcnative. Below are some
> comments/review of it.
Thanks for your review. See below for more.
FYI I *have* been reading your prior comments. I didn't want to get into
Power Shell because of my lack of experience with it: working with
plain-old batch files is something I am more familiar with, even though
it is astoundingly miserable when compared to UNIX-style shell scripting.
>> -----Original Message-----
>> From: Christopher Schultz [mailto:chris@christopherschultz.net]
>> Sent: Thursday, June 19, 2014 3:21 PM
>>
>> All,
>>
>> I have a first-stab at a Windows batch script that can do almost
>> everything. I've attached it to this post.
>>
>> *NOTE THAT YOU DO NOT HAVE TO BUY/OWN ANY MICROSOFT SOFTWARE
>> TO BUILD
>> OpenSSL, APR, and tcnative*
>>
>> I did all my work on a Windows 8.1 VirtualBox VM that I downloaded from
>> https://www.modern.ie/en-us/virtualization-tools. So, if you want to
>> configure a build environment and don't want to jack-up your own
>> computer to get this all done, you can build OpenSSL, APR, and tcnative
>> all without buying any software.
>>
>> When you are done, you can copy the binaries to a real machine and
>> scuttle the VM. Sounds like a good deal to me.
>>
>> There are a few prerequisites:
>>
>> 1. If you don't already have Microsoft Visual Studio C++ available,
>> download and install Microsoft Visual Studio Express 2013, which
>> you can find here:
>> http://www.microsoft.com/en-us/download/details.aspx?id=40787
>>
>> Note that, in desperation, at some point, I also installed the
>> Microsoft Windows SDK. I'm not sure if this is necessary, or if
>> either of these packages will be sufficient. In the future, I'll
>> untangle the web and post simpler instructions:
>> http://www.microsoft.com/en-us/download/details.aspx?id=8279
>
> If you installed Visual Studio, then you shouldn't need a Windows SDK
> as the necessary tools are already included in VS. (It would be more
> convenient if one doesn't need to install VS as it installs a lot of
> other components, but I don't think there is some other MS build
> environment - Windows SDK does not seem to include the necessary
> tools.)
Good to know. When I've got something that is mostly working, I'll
re-build the entire VM and document the procedure better.
>> 2. Download and install Java JDK. You might be able to get away with
>> the JRE but I got the whole JDK because I didn't want to mess-around
>> with missing components (like header files).
>>
>> 3. Download GnuWin32 wget from here:
>> http://gnuwin32.sourceforge.net/packages/wget.htm
>
> I downloaded the "Binaries Zip" file version of wget.exe, but it
> seems
> to require some additional DLLs that are not included. I then downloaded
> the "Setup" version of it, and copied wget.exe + all DLLs that the Setup
> installed to the tools directory.
I think I may have used a slightly different wget.exe. I'll track that
one down, too. The script gives you two possibilities for where you
might want to get wget.exe. I think I used the "first" of the two listed.
>> 4. Download 7zip command-line version (7za.exe) from here:
>> http://www.7-zip.org/download.html
>>
>> 5. Put wget.exe and 7za.exe into a directory called "tools" in some
>> work directory. build-tcnative.bat will use a working directory
>> under %TEMP% for downloads and builds. You can also change the
>> value of the %TOOLS% environment variable in the script to point
>> wherever you want, but I haven't gone back to replace all
>> references to tools\foo.exe to %TOOLS%\foo.exe so it might not work
>> yet. Also put build-tcnative.bat into this work directory
>> (not "tools", but one level up).
>>
>> 6. Dump this text into a file called patch.exe.manifest in your work
>> directory:
>>
>> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
>> <assembly xmlns="urn:schemas-microsoft-com:asm.v1"
>> manifestVersion="1.0">
>> <assemblyIdentity
>> version="2.5.0.0"
>> processorArchitecture="X86"
>> name="Patch"
>> type="win32"
>> />
>> <description>A tool for applying diff-generated patches.</description>
>> <!-- Identify the application security requirements. -->
>> <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
>> <security>
>> <requestedPrivileges>
>> <requestedExecutionLevel
>> level="asInvoker"
>> uiAccess="false"/>
>> </requestedPrivileges>
>> </security>
>> </trustInfo>
>> </assembly>
>
> Ah, I now understand why you wrote in an earlier mail that this
> patch
> tool needs administrator rights - it does not include a proper manifest.
> Starting with Windows Vista, Windows uses such manifest to determine if
> an EXE should be run with Administrator rights (showing an UAC dialog)
> or user rights. For EXEs that don't include such a manifest, it cannot
> know whether it should run as administrator, so it checks the filename
> for patterns like "setup", "install", "patch", "update" etc.
Oh, so it I just renamed the binary to something else, it probably
wouldn't complain? That's great security right there.
> So, you should be fine by renaming "patch.txt" to something like
> "pt.exe" - it will make the UAC symbol on the file go away, and it
> will run without administrator rights.
Nice. I'm happy patching it for now, but it does represent another
prerequisite for someone building the whole thing: getting the manifest
file onto the disk. If batch files had "here" documents, I'd just put
the manifest right into the script, but I can't... and escaping all that
stuff for ECHO line-of-manifest >> manifest.xml just isn't in the cards
today ;)
>> 7. Launch cmd.exe and run VC++'s vcvars32.bat script or, better yet,
>> launch the cmd.exe config that gets installed when you install
>> VC++.
>>
>> 8. Change to the directory containing your "tools" directory from step
>> 5, then run build-tcnative.bat.
>
> I think there are some problems with this BAT file.
>
> 1) I think you unintentionally used double-quotes on several places
> where normally they shouldn't be, e.g. for setting environment variables:
>
> SET MYTEMP="%TEMP%\build-tcnative"
While I agree, it does not seem to break anything. I made that mistake
with the PATH environment variable and then *everything* stopped
working. No fun figuring out that SET FOO="blah" and SET FOO=blah are
two different things. Thanks, DOS. :p
> Note, that in CMD.EXE, the SET command includes everything after the
> =, so the double quotes are actually included in the environment
> variable. This could cause problems if concatenating it with some
> command; however, cmd.exe seems to accept commands like
> '"C:\Windows\system32"\calc.exe'; but it would be better to correctly
> set the environment variables.
I'm happy to turn over my script to someone to do some cleanup before,
say, including it in the distribution.
> 2) When I run tcnative.dll from a CMD.exe that has run VC++'s
> vcvars32.bat, then I get a problem when downloading patch.exe. This
> seems because the URL that is included in the bat file
> (http://downloads.sourceforge.net/project/gnuwin32/patch/2.5.9-7/patch-2.5.9-7-bin.zip)
> leads to a HTML page which generates a download link, instead of
> actually downloading the EXE file.
Oops. Perhaps I pasted that link incorrectly at some point. I'll fix
that before final publication.
> It seems to work if I use a URL like
> http://vorboss.dl.sourceforge.net/project/gnuwin32/patch/2.5.9-7/patch-2.5.9-7-bin.zip,
> but I need to insert a 'md "%myTemp%\downloads' command to create the
> directory; otherwise wget seems unable to download it.
Okay, I'll check that out.
> 3) There also seems to be something wrong with this command:
> mt.exe -manifest "%MYTEMPpatch.exe.manifest "-outputresource:%TOOLS%\patch.exe;#1"
> I think it should be something like:
> mt.exe -manifest "patch.exe.manifest "-outputresource:%TOOLS%\patch.exe;#1"
Got it.
> 4) The script seems to require perl.exe (you did not mention this in your mail ;-)
Yeah, I totally forgot to mention that. I figured I'd include it with my
next update (which I also forgot).
> I have not yet tried to run it with perl installed, as I get an error
> that patch.exe cannot find "apr-1.5.patch".
Hah.. yes. The APR patch includes in the tcnative source distro doesn't
seem to work with APR 1.5.1. I think it's because it was made against
APR 1.4.8 and the two versions are different enough that patch gives up.
Here's the patch for APR 1.5.1:
---
\Users\IEUser\AppData\Local\Temp\build-tcnative\build\apr-1.5.1\include\apr.hw
Fri Jun 07 08:57:56 2013
+++ apr.hw Wed Jun 18 07:49:57 2014
@@ -282,7 +282,7 @@
#define APR_HAVE_IN_ADDR 1
#define APR_HAVE_INET_ADDR 1
#define APR_HAVE_INET_NETWORK 0
-#define APR_HAVE_IPV6 0
+#define APR_HAVE_IPV6 1
#define APR_HAVE_MEMMOVE 1
#define APR_HAVE_SETRLIMIT 0
#define APR_HAVE_SIGACTION 0
@@ -346,7 +346,7 @@
/* If we have a TCP implementation that can be "corked", what flag
* do we use?
*/
-#define APR_TCP_NOPUSH_FLAG @apr_tcp_nopush_flag@
+#define APR_TCP_NOPUSH_FLAG 0
/* Is the TCP_NODELAY socket option inherited from listening sockets?
*/
> Regarding the dependency to wget.exe, I think that can be avoided by
> making a Powershell Script (as said earlier) as it allows to directly
> download a file from command line. I think this also will make the
> script easier to write as you can write more in the style of an
> programming/scripting language instead of Windows/DOS commands.
>
> I can look about creating a Powershell version of the script if you
> have finished it. What do you think?
Anything that makes this procedure replicable by someone else is a Good
Thing.
After Mladen's encouragement that "it just takes 10 minutes" it's been
pretty frustrating trying to create these artifacts.
>> On my VM, the build gets as far as linking tcnative before it fails. It
>> fails because I haven't copied the artifacts for APR to the right
>> places, yet.
>>
>> Hopefully, this will be enough to get some other folks started who are
>> waiting for an update to tcnative-1.1.30 that includes OpenSSL 1.0.1h.
>>
>> Enjoy,
>> -chris
>
> One other thing: Do you know which version of VC++ was used to date
> to build Tomcat Native?
Mladen mentioned it at one time, but I can't remember where. He also
mentioned how to modify one of the components to build it statically.
I'm searching for that reference right now but I'm having a hard time
finding it.
Basically, I'm working off of these resources:
1. https://issues.apache.org/bugzilla/show_bug.cgi?id=56363#c10
2. INSTALL.W32 script in OpenSSL distribution
3. Thread on apr-dev@ : http://markmail.org/thread/ecu3gwgr77cb6mtm
4. Random directory listings after things have built. ;)
That's how I found out that OpenSSL puts their headers in inc32/
after the build. That's also how I found that there is an out32/ and
out32dll/ directory where the former has the statically-linked version
of openssl.exe in it.
> If I open it with some EXE inspection tools, I can see that it has a
> dependency to msvcrt.dll, which seems like an older version of VC++
> (maybe VC++ 6.0 which is a really old version - but I'm not sure).
> I don't know much about building native (C/C++) apps; however if I
> create a C++ DLL with Visual Studio 2013, then the DLL has a
> dependency to msvcr120.dll, which maybe is not included by default in
> Windows (at least not in earlier versions of Windows like Windows
> 7/2008R2).
Whatever Mladen tends to build it with is probably correct.
How does one inspect a DLL in this way to see dependencies?
Thanks,
-chris
RE: Building tcnative on win32 [alpha]
Posted by Konstantin Preißer <kp...@apache.org>.
Hi Christopher,
good work for creating a script to build tcnative. Below are some comments/review of it.
> -----Original Message-----
> From: Christopher Schultz [mailto:chris@christopherschultz.net]
> Sent: Thursday, June 19, 2014 3:21 PM
>
> All,
>
> I have a first-stab at a Windows batch script that can do almost
> everything. I've attached it to this post.
>
> *NOTE THAT YOU DO NOT HAVE TO BUY/OWN ANY MICROSOFT SOFTWARE
> TO BUILD
> OpenSSL, APR, and tcnative*
>
> I did all my work on a Windows 8.1 VirtualBox VM that I downloaded from
> https://www.modern.ie/en-us/virtualization-tools. So, if you want to
> configure a build environment and don't want to jack-up your own
> computer to get this all done, you can build OpenSSL, APR, and tcnative
> all without buying any software.
>
> When you are done, you can copy the binaries to a real machine and
> scuttle the VM. Sounds like a good deal to me.
>
> There are a few prerequisites:
>
> 1. If you don't already have Microsoft Visual Studio C++ available,
> download and install Microsoft Visual Studio Express 2013, which
> you can find here:
> http://www.microsoft.com/en-us/download/details.aspx?id=40787
>
> Note that, in desperation, at some point, I also installed the
> Microsoft Windows SDK. I'm not sure if this is necessary, or if
> either of these packages will be sufficient. In the future, I'll
> untangle the web and post simpler instructions:
> http://www.microsoft.com/en-us/download/details.aspx?id=8279
If you installed Visual Studio, then you shouldn't need a Windows SDK as the necessary tools are already included in VS. (It would be more convenient if one doesn't need to install VS as it installs a lot of other components, but I don't think there is some other MS build environment - Windows SDK does not seem to include the necessary tools.)
>
> 2. Download and install Java JDK. You might be able to get away with
> the JRE but I got the whole JDK because I didn't want to mess-around
> with missing components (like header files).
>
> 3. Download GnuWin32 wget from here:
> http://gnuwin32.sourceforge.net/packages/wget.htm
I downloaded the "Binaries Zip" file version of wget.exe, but it seems to require some additional DLLs that are not included. I then downloaded the "Setup" version of it, and copied wget.exe + all DLLs that the Setup installed to the tools directory.
>
> 4. Download 7zip command-line version (7za.exe) from here:
> http://www.7-zip.org/download.html
>
> 5. Put wget.exe and 7za.exe into a directory called "tools" in some
> work directory. build-tcnative.bat will use a working directory
> under %TEMP% for downloads and builds. You can also change the
> value of the %TOOLS% environment variable in the script to point
> wherever you want, but I haven't gone back to replace all
> references to tools\foo.exe to %TOOLS%\foo.exe so it might not work
> yet. Also put build-tcnative.bat into this work directory
> (not "tools", but one level up).
>
> 6. Dump this text into a file called patch.exe.manifest in your work
> directory:
>
> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
> <assembly xmlns="urn:schemas-microsoft-com:asm.v1"
> manifestVersion="1.0">
> <assemblyIdentity
> version="2.5.0.0"
> processorArchitecture="X86"
> name="Patch"
> type="win32"
> />
> <description>A tool for applying diff-generated patches.</description>
> <!-- Identify the application security requirements. -->
> <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
> <security>
> <requestedPrivileges>
> <requestedExecutionLevel
> level="asInvoker"
> uiAccess="false"/>
> </requestedPrivileges>
> </security>
> </trustInfo>
> </assembly>
Ah, I now understand why you wrote in an earlier mail that this patch tool needs administrator rights - it does not include a proper manifest. Starting with Windows Vista, Windows uses such manifest to determine if an EXE should be run with Administrator rights (showing an UAC dialog) or user rights. For EXEs that don't include such a manifest, it cannot know whether it should run as administrator, so it checks the filename for patterns like "setup", "install", "patch", "update" etc.
So, you should be fine by renaming "patch.txt" to something like "pt.exe" - it will make the UAC symbol on the file go away, and it will run without administrator rights.
> 7. Launch cmd.exe and run VC++'s vcvars32.bat script or, better yet,
> launch the cmd.exe config that gets installed when you install
> VC++.
>
> 8. Change to the directory containing your "tools" directory from step
> 5, then run build-tcnative.bat.
I think there are some problems with this BAT file.
1) I think you unintentionally used double-quotes on several places where normally they shouldn't be, e.g. for setting environment variables:
SET MYTEMP="%TEMP%\build-tcnative"
Note, that in CMD.EXE, the SET command includes everything after the =, so the double quotes are actually included in the environment variable. This could cause problems if concatenating it with some command; however, cmd.exe seems to accept commands like '"C:\Windows\system32"\calc.exe'; but it would be better to correctly set the environment variables.
2) When I run tcnative.dll from a CMD.exe that has run VC++'s vcvars32.bat, then I get a problem when downloading patch.exe. This seems because the URL that is included in the bat file (http://downloads.sourceforge.net/project/gnuwin32/patch/2.5.9-7/patch-2.5.9-7-bin.zip) leads to a HTML page which generates a download link, instead of actually downloading the EXE file.
It seems to work if I use a URL like http://vorboss.dl.sourceforge.net/project/gnuwin32/patch/2.5.9-7/patch-2.5.9-7-bin.zip, but I need to insert a 'md "%myTemp%\downloads' command to create the directory; otherwise wget seems unable to download it.
3) There also seems to be something wrong with this command:
mt.exe -manifest "%MYTEMPpatch.exe.manifest "-outputresource:%TOOLS%\patch.exe;#1"
I think it should be something like:
mt.exe -manifest "patch.exe.manifest "-outputresource:%TOOLS%\patch.exe;#1"
4) The script seems to require perl.exe (you did not mention this in your mail ;-)
I have not yet tried to run it with perl installed, as I get an error that patch.exe cannot find "apr-1.5.patch".
Regarding the dependency to wget.exe, I think that can be avoided by making a Powershell Script (as said earlier) as it allows to directly download a file from command line. I think this also will make the script easier to write as you can write more in the style of an programming/scripting language instead of Windows/DOS commands.
I can look about creating a Powershell version of the script if you have finished it. What do you think?
>
> On my VM, the build gets as far as linking tcnative before it fails. It
> fails because I haven't copied the artifacts for APR to the right
> places, yet.
>
> Hopefully, this will be enough to get some other folks started who are
> waiting for an update to tcnative-1.1.30 that includes OpenSSL 1.0.1h.
>
> Enjoy,
> -chris
One other thing: Do you know which version of VC++ was used to date to build Tomcat Native? If I open it with some EXE inspection tools, I can see that it has a dependency to msvcrt.dll, which seems like an older version of VC++ (maybe VC++ 6.0 which is a really old version - but I'm not sure).
I don't know much about building native (C/C++) apps; however if I create a C++ DLL with Visual Studio 2013, then the DLL has a dependency to msvcr120.dll, which maybe is not included by default in Windows (at least not in earlier versions of Windows like Windows 7/2008R2).
I don't know if it is possible to change the dependency to the older msvcrt.dll or include the DLL in the build; but if not, then maybe users will need to install a "Visual C++ Redistributable Packages for Visual Studio 2013" package [1], like PHP does this on their Windows binaries site [2].
[1] http://www.microsoft.com/en-us/download/details.aspx?id=40784
[2] http://windows.php.net/download/
Regards,
Konstantin Preißer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Building tcnative on win32 [alpha]
Posted by Christopher Schultz <ch...@christopherschultz.net>.
All,
It seems that a bit of cleanup, changing an option for OpenSSL build,
and a *complete* re-download and re-build of everything has resulted in
what appears to be a 1.5MiB tcnative-1.dll file, which without any
testing at all seems like I probably have done things right.
The attached script will build a statically-linked 32-bit tcnative-1.dll
binary and a statically-linked 32-bit openssl.exe binary. I'll work on
getting the other architectures built, soon.
Does anyone have a 32-bit Windows system on which the Tomcat APR (with
SSL) tests could be run? I'd like to send a DLL and have someone test it
more competently than I perhaps could.
There is another dependency I didn't mention before: ActiveState Perl.
You only need this if you are going to use OpenSSL with tcnative but,
honestly, who is going to bother building the whole thing without using
OpenSSL?
Anyhow, here are updated instructions for building OpenSSL, APR, and
tcnative on win32:
*NOTE THAT YOU DO NOT HAVE TO BUY/OWN ANY MICROSOFT SOFTWARE TO BUILD
OpenSSL, APR, and tcnative*
I did all my work on a Windows 8.1 VirtualBox VM that I downloaded from
https://www.modern.ie/en-us/virtualization-tools. So, if you want to
configure a build environment and don't want to jack-up your own
computer to get this all done, you can build OpenSSL, APR, and tcnative
all without buying any software.
When you are done, you can copy the binaries to a real machine and
scuttle the VM. Sounds like a good deal to me.
There are a few prerequisites:
1. If you don't already have Microsoft Visual Studio C++ available,
download and install Microsoft Visual Studio Express 2013, which
you can find here:
http://www.microsoft.com/en-us/download/details.aspx?id=40787
2. Download and install Java JDK. You might be able to get away with
the JRE but I got the whole JDK because I didn't want to mess-around
with missing components (like header files).
3. If you are going to use OpenSSL (which you are), you'll need
ActiveState Perl, which you can find here:
http://www.activestate.com/activeperl/downloads
3. Download GnuWin32 wget from here:
http://gnuwin32.sourceforge.net/packages/wget.htm
I've heard that the above wget.exe might have a problem, so you can
use http://users.ugent.be/~bpuype/cgi-bin/fetch.pl?dl=wget/wget.exe
instead. I believe the latter tool is the same but statically-linked.
4. Download 7zip command-line version (7za.exe) from here:
http://www.7-zip.org/download.html
5. Put wget.exe and 7za.exe into a directory called "tools" in some
work directory. build-tcnative.bat will use a working directory
under %TEMP% for downloads and builds. You can also change the
value of the %TOOLS% environment variable in the script to point
wherever you want.
6. Launch cmd.exe and run VC++'s vcvars32.bat script or, better yet,
launch the cmd.exe config that gets installed when you install
VC++.
7. Create a "work" directory and CD to it. Put build-tcnative.bat
in this directory and run it.
When you are done, there will be a "build" directory created
that contains all the binaries.
A few notes:
1. A few of the APR tests fail. I'm checking with the APR folks to see
if they are spurious or not. One the tests requires memcached to be
available and that one of course fails.
2. Only the 32-bit binary without OCSP is built. More architectures, later.
Hopefully, this will be enough to get some other folks started who are
waiting for an update to tcnative-1.1.30 that includes OpenSSL 1.0.1h.
Enjoy,
-chris
Re: Building tcnative on win32 [alpha]
Posted by Christopher Schultz <ch...@christopherschultz.net>.
All,
Attached is an updated script that can build *a* tcnative binary, but I
haven't tested anything, yet. I suspect the whole build is not correct
because tcnative-1.dll is far too small (in bytes) to be correct:
File My Build 1.1.30 Official Build
openssl.exe 1692160 1630208
tcnative-1.dll 176640 1141760
tcnative-1-src.pdb 176128 176128
So, tcnative does not seem to be building statically (wild guess). If
anyone can give me some clues as to why that's happening, it would be
very helpful to me.
This script also only builds the 32-bit binaries. Once I get these
working, switching to build the x86-64 and IA64 binaries should be trivial.
Enjoy,
-chris
On 6/19/14, 9:21 AM, Christopher Schultz wrote:
> All,
>
> I have a first-stab at a Windows batch script that can do almost
> everything. I've attached it to this post.
>
> *NOTE THAT YOU DO NOT HAVE TO BUY/OWN ANY MICROSOFT SOFTWARE TO BUILD
> OpenSSL, APR, and tcnative*
>
> I did all my work on a Windows 8.1 VirtualBox VM that I downloaded from
> https://www.modern.ie/en-us/virtualization-tools. So, if you want to
> configure a build environment and don't want to jack-up your own
> computer to get this all done, you can build OpenSSL, APR, and tcnative
> all without buying any software.
>
> When you are done, you can copy the binaries to a real machine and
> scuttle the VM. Sounds like a good deal to me.
>
> There are a few prerequisites:
>
> 1. If you don't already have Microsoft Visual Studio C++ available,
> download and install Microsoft Visual Studio Express 2013, which
> you can find here:
> http://www.microsoft.com/en-us/download/details.aspx?id=40787
>
> Note that, in desperation, at some point, I also installed the
> Microsoft Windows SDK. I'm not sure if this is necessary, or if
> either of these packages will be sufficient. In the future, I'll
> untangle the web and post simpler instructions:
> http://www.microsoft.com/en-us/download/details.aspx?id=8279
>
> 2. Download and install Java JDK. You might be able to get away with
> the JRE but I got the whole JDK because I didn't want to mess-around
> with missing components (like header files).
>
> 3. Download GnuWin32 wget from here:
> http://gnuwin32.sourceforge.net/packages/wget.htm
>
> 4. Download 7zip command-line version (7za.exe) from here:
> http://www.7-zip.org/download.html
>
> 5. Put wget.exe and 7za.exe into a directory called "tools" in some
> work directory. build-tcnative.bat will use a working directory
> under %TEMP% for downloads and builds. You can also change the
> value of the %TOOLS% environment variable in the script to point
> wherever you want, but I haven't gone back to replace all
> references to tools\foo.exe to %TOOLS%\foo.exe so it might not work
> yet. Also put build-tcnative.bat into this work directory
> (not "tools", but one level up).
>
> 6. Dump this text into a file called patch.exe.manifest in your work
> directory:
>
> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
> <assembly xmlns="urn:schemas-microsoft-com:asm.v1"
> manifestVersion="1.0">
> <assemblyIdentity
> version="2.5.0.0"
> processorArchitecture="X86"
> name="Patch"
> type="win32"
> />
> <description>A tool for applying diff-generated patches.</description>
> <!-- Identify the application security requirements. -->
> <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
> <security>
> <requestedPrivileges>
> <requestedExecutionLevel
> level="asInvoker"
> uiAccess="false"/>
> </requestedPrivileges>
> </security>
> </trustInfo>
> </assembly>
>
>
> 7. Launch cmd.exe and run VC++'s vcvars32.bat script or, better yet,
> launch the cmd.exe config that gets installed when you install
> VC++.
>
> 8. Change to the directory containing your "tools" directory from step
> 5, then run build-tcnative.bat.
>
> On my VM, the build gets as far as linking tcnative before it fails. It
> fails because I haven't copied the artifacts for APR to the right
> places, yet.
>
> Hopefully, this will be enough to get some other folks started who are
> waiting for an update to tcnative-1.1.30 that includes OpenSSL 1.0.1h.
>
> Enjoy,
> -chris
>
Re: Building tcnative on win32 [alpha]
Posted by Christopher Schultz <ch...@christopherschultz.net>.
All,
I have a first-stab at a Windows batch script that can do almost
everything. I've attached it to this post.
*NOTE THAT YOU DO NOT HAVE TO BUY/OWN ANY MICROSOFT SOFTWARE TO BUILD
OpenSSL, APR, and tcnative*
I did all my work on a Windows 8.1 VirtualBox VM that I downloaded from
https://www.modern.ie/en-us/virtualization-tools. So, if you want to
configure a build environment and don't want to jack-up your own
computer to get this all done, you can build OpenSSL, APR, and tcnative
all without buying any software.
When you are done, you can copy the binaries to a real machine and
scuttle the VM. Sounds like a good deal to me.
There are a few prerequisites:
1. If you don't already have Microsoft Visual Studio C++ available,
download and install Microsoft Visual Studio Express 2013, which
you can find here:
http://www.microsoft.com/en-us/download/details.aspx?id=40787
Note that, in desperation, at some point, I also installed the
Microsoft Windows SDK. I'm not sure if this is necessary, or if
either of these packages will be sufficient. In the future, I'll
untangle the web and post simpler instructions:
http://www.microsoft.com/en-us/download/details.aspx?id=8279
2. Download and install Java JDK. You might be able to get away with
the JRE but I got the whole JDK because I didn't want to mess-around
with missing components (like header files).
3. Download GnuWin32 wget from here:
http://gnuwin32.sourceforge.net/packages/wget.htm
4. Download 7zip command-line version (7za.exe) from here:
http://www.7-zip.org/download.html
5. Put wget.exe and 7za.exe into a directory called "tools" in some
work directory. build-tcnative.bat will use a working directory
under %TEMP% for downloads and builds. You can also change the
value of the %TOOLS% environment variable in the script to point
wherever you want, but I haven't gone back to replace all
references to tools\foo.exe to %TOOLS%\foo.exe so it might not work
yet. Also put build-tcnative.bat into this work directory
(not "tools", but one level up).
6. Dump this text into a file called patch.exe.manifest in your work
directory:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1"
manifestVersion="1.0">
<assemblyIdentity
version="2.5.0.0"
processorArchitecture="X86"
name="Patch"
type="win32"
/>
<description>A tool for applying diff-generated patches.</description>
<!-- Identify the application security requirements. -->
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel
level="asInvoker"
uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
</assembly>
7. Launch cmd.exe and run VC++'s vcvars32.bat script or, better yet,
launch the cmd.exe config that gets installed when you install
VC++.
8. Change to the directory containing your "tools" directory from step
5, then run build-tcnative.bat.
On my VM, the build gets as far as linking tcnative before it fails. It
fails because I haven't copied the artifacts for APR to the right
places, yet.
Hopefully, this will be enough to get some other folks started who are
waiting for an update to tcnative-1.1.30 that includes OpenSSL 1.0.1h.
Enjoy,
-chris