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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
