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:ch...@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

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to