Mark, On 7/8/14, 9:58 AM, Christopher Schultz wrote: > Mark, > > On 7/7/14, 11:31 AM, Mark Thomas wrote: >> On 07/07/2014 14:48, Christopher Schultz wrote: >>> Mark, >>> >>> On 7/1/14, 11:44 AM, Mark Thomas wrote: >>>> On 01/07/2014 16:04, Mark Thomas wrote: >>>>> With some additional information from Mladen regrading the >>>>> build tools to use, I now have a working build environment for >>>>> the Tomcat Native connector binaries. This is documented at: >>>>> http://wiki.apache.org/tomcat/BuildTcNativeWin >>>> >>>> (excluding a working I64 build that I am still looking at) >>> >>> I just glanced through the current contents of BuildTcNativeWin on >>> the wiki, and I can still see this comment: >>> >>>>> IA64 OpenSSL build failed. Commenting out destest from >>>>> ms\nt.mak >>> worked around the issue. >>> >>> The problem is that the tests require a compatible supporting >>> architecture. >> >> I don't believe that is the problem. I shouldn't need a supporting >> architecture to build the tests (that part that is failing), only to >> run them. > > Aah, I didn't realize that building the tests was failing, not running > them. I assumed without checking that "destest" was something like > "destination test" and therefore would require e.g. IA64 to be runnable. > Sorry for the noise. > >>> That is, if you cross-compile to IA64 then try to run the tests, >>> the tests will fail because you are running on x86_84 and IA64 is >>> not available. The same thing will happen if you try to build/test >>> on ia32: you can produce x86_64 binaries, but you will be unable to >>> test them. >> >> Agreed. >> >>> Therefore, it would be safest to specify in the instructions that >>> either x86_64 or IA64 should be used for the build -- that way, at >>> least one of the 64-bit architectures can be tested along with the >>> 32-bit one. It's also worth mentioning that a 32-bit environment >>> would need to comment-out *all* the 64-bit tests, and not just the >>> IA64 ones. >> >> I don't believe any of the tests are specifically 32-bit or 64-bit. > > The OpenSSL docs (INSTALL.W64) specifically say that to test the builds, > you must test on the target platform: > > " > Naturally test-suite itself has to be executed on the target platform. > " > >>> Thanks for continuing to work on this, Mark. I'm glad you've been >>> able to remove Cygwin as a requirement... looking at your initial >>> build instructions seemed overly complicated -- or at least had >>> many more requirements than strictly necessary. I'm not sure how >>> much of Mladen's magic environment is strictly necessary, either: I >>> think a lot of it could be put into scripts that ship with the >>> tcnative source distribution. >> >> Keep in mind that these are build instructions for a completely clean >> OS install so there are a number of tools lists that I would normally >> expect to be present on a developers machine. > > Right. Both of us are trying to come up with instructions that anyone -- > even someone without an existing dev environment -- can follow. > >> In terms of how much of this is necessary, experience suggests that >> most of it is required to avoid having to install a Visual C Runtime >> distribution. If you are prepared to do that (or more specifically >> prepared to make your users do that) then yes, this could get a lot >> simpler. Personally, I'm in favour of making the release manager jump >> through a few hoops rather than making our users jump through hoops. > > Agreed, though it would be nice if the procedure could be performed by > end users as well. > >>> I am still going to continue to work on getting all this stuff to >>> build using Microsoft Visual Studio Express: it should be possible >>> to do, and I *have* been able to get a 32-bit build working. But >>> these days, I think not having a 64-bit build available is not a >>> practical solution, of course. >> >> I'm not sure it is possible to build with Visual Studio Express >> without introducing a dependency on a Visual C Runtime distribution >> but if you can find a way around that issue that would be great. > > Evidently, the packages that I have installed do not include > depends.exe. A quick Google search yields this tool: > http://www.dependencywalker.com/ > > I'll rebuild the 32-bit version (which I can do reliably) and see what > the dependencies are.
Evidently, the VS Express 2013 package can't build due to some odd bugs described here: http://markmail.org/thread/b7ze2fyrqyr6fb7i I had to install the "Platform SDK" and was able to produce a 32-bit binary again. I'll have to rollback my VM and see if I can build with the SDK (which includes VS2010, evidently) only, to simplify things. Anyway, here's what the above tool says tcnative-1.dll requires in terms of direct dependencies: - USER32.dll - PSAPI.dll - SHLWAPI.dll - KERNEL32.dll - ADVAPI32.dll - WS2_32.dll - MSWSOCK.dll - MSVCR100.dll Is that last one the one you were concerned about? If so, what's the procedure for statically-linking that library into tcnative ... or, better yet, why is that library not necessary when using MSVS 2006 or whatever? I checked, and the openssl.exe binary that was built also requires that same library (specifically, MSVCR100.dll). Thanks, -chris
signature.asc
Description: OpenPGP digital signature
