Hi Christopher, thank you for your reply.
> -----Original Message----- > From: Christopher Schultz [mailto:ch...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
