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. Thanks, -chris
signature.asc
Description: OpenPGP digital signature
