You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Christopher Schultz <ch...@christopherschultz.net> on 2014/06/19 21:21:42 UTC
Re: Building tcnative on win32 [x86_64, failing]
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.
Any ideas?
Thanks,
-chris
cl -c -nologo -DWIN32 -D_WIN32 -D_WINDOWS -DWINNT -D_WINNT
-D_WIN32_WINN
T=0x0501 -DWINVER=0x0501 -D_WIN32_IE=0x0600 -W3 -EHsc -D_MBCS -DMBCS
-D_AMD64_=1
-DWIN64 -D_WIN64 -O2 -Ob2 -Zi -DNDEBUG -D_MT -MD -DAPR_DECLARE_STATIC
-DZLIB_WI
NAPI -DNO_IDEA -DNO_RC5 -DNO_MDC2 -DOPENSSL_NO_IDEA -DOPENSSL_NO_RC5
-DOPENSSL_
NO_MDC2 -DHAVE_OPENSSL -DHAVE_SSL_SET_STATE=1 -I.\include -I "C:\Program
Files\J
ava\jdk1.7.0_60\include" -I "C:\Program
Files\Java\jdk1.7.0_60\include\win32" -I
C:\Users\IEUser\AppData\Local\Temp\build-tcnative\build\apr\include
-IC:\Users\I
EUser\AppData\Local\Temp\build-tcnative\build\apr\include\arch\win32
-IC:\Users\
IEUser\AppData\Local\Temp\build-tcnative\build\openssl\include
-FoWINXP_X64_DLL_
RELEASE\ -FdWINXP_X64_DLL_RELEASE\tcnative-1-src .\os\win32\system.c
system.c
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.
link.exe /NOLOGO /DLL /SUBSYSTEM:WINDOWS /MACHINE:AMD64 /OPT:REF
/version:1.1 user32.lib psapi.lib gdi32.lib shlwapi.lib wldap32.lib
ole32.lib apr-1.lib
libeay32.lib ssleay32.lib WINXP_X64_DLL_RELEASE\address.obj
WINXP_X64_DLL_RELE
ASE\bb.obj WINXP_X64_DLL_RELEASE\dir.obj
WINXP_X64_DLL_RELEASE\error.obj WINX
P_X64_DLL_RELEASE\file.obj WINXP_X64_DLL_RELEASE\info.obj
WINXP_X64_DLL_RELEAS
E\jnilib.obj WINXP_X64_DLL_RELEASE\lock.obj
WINXP_X64_DLL_RELEASE\misc.obj WI
NXP_X64_DLL_RELEASE\mmap.obj WINXP_X64_DLL_RELEASE\multicast.obj
WINXP_X64_DLL
_RELEASE\network.obj WINXP_X64_DLL_RELEASE\os.obj
WINXP_X64_DLL_RELEASE\poll.o
bj WINXP_X64_DLL_RELEASE\pool.obj WINXP_X64_DLL_RELEASE\proc.obj
WINXP_X64_DL
L_RELEASE\shm.obj WINXP_X64_DLL_RELEASE\ssl.obj
WINXP_X64_DLL_RELEASE\sslconte
xt.obj WINXP_X64_DLL_RELEASE\sslinfo.obj
WINXP_X64_DLL_RELEASE\sslnetwork.obj
WINXP_X64_DLL_RELEASE\sslutils.obj WINXP_X64_DLL_RELEASE\stdlib.obj
WINXP_X64
_DLL_RELEASE\user.obj WINXP_X64_DLL_RELEASE\thread.obj
WINXP_X64_DLL_RELEASE\n
tpipe.obj WINXP_X64_DLL_RELEASE\registry.obj
WINXP_X64_DLL_RELEASE\system.obj
WINXP_X64_DLL_RELEASE\tcnative-1.res kernel32.lib advapi32.lib
ws2_32.lib mswsock.lib ole32.lib shell32.lib rpcrt4.lib
/libpath:"C:\Users\IEUser\AppData\Local\Temp\build-tcnative\build\apr\lib"
/libpath:"C:\Users\IEUser\AppData\Local\Temp\build-tcnative\build\openssl\lib"
/pdb:WINXP_X64_DLL_RELEASE\tcnative-1.pdb /out:
WINXP_X64_DLL_RELEASE\tcnative-1.dll
WINXP_X64_DLL_RELEASE\address.obj : fatal error LNK1112: module machine
type 'X86' conflicts with target machine type 'x64'
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio
10.0\VC\Bin\link.exe"' : return code '0x458'
Stop.
Re: Building tcnative on win32 [x86_64, failing]
Posted by Mark Thomas <ma...@apache.org>.
On 01/07/2014 17:24, Christopher Schultz wrote:
> On 7/1/14, 12:18 PM, Mark Thomas wrote:
<snip/>
>>> The IA64 build of OpenSSL *did* complete, but I'm not sure how
>>> to check its architecture, etc. What is the "depends" tool you
>>> guys have been talking about?
>>
>> The depends tool ships with various tools including Visual
>> Studio and the platform SDK.
>
> Okay, but where is it? What is it called? Tapping the "windows"
> key and searching for it doesn't find it, and there are tools
> literally everywhere related to VC++. With a filename I might have
> a chance of finding it.
Try looking in the start menu -> Platform SDK -> tools. It is called
"depends".
If you want to search for the file name try looking for "depends.exe"
On my build system it is located at:
"C:\Program Files\Microsoft Platform SDK for Windows Server 2003
R2\Bin\Depends.Exe"
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Building tcnative on win32 [x86_64, failing]
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Mark,
On 7/1/14, 12:18 PM, Mark Thomas wrote:
> On 01/07/2014 16:40, Christopher Schultz wrote:
>
>> My script seemed a bit cleaner than what you are documenting on
>> the wiki, plus you can get the tools for free (MS VS 12).
>
> None of the tools documented on the Wiki are paid for.
>
>> I was able to build a complete 32-bit statically-linked
>> libtcnative.dll plus the openssl.exe utility using the process I
>> knocked-up from scratch.
>
> Depending on which version of the MSVCRT DLL?
I'll check once I can run that depends tool.
>> Note that I have been compiling without using the nasm assembler.
>> I figured I'd try to get things working without it, then add that
>> component later once the build process was working.
>
> Back when I was working with VS6, I needed to use nasm as the
> assembler that shipped with VS6 didn't understand the syntax. I'm
> assuming that Mladen hasn't been using it.
>
>> I have been having trouble building pretty much any 64-bit stuff.
>> I happen to be running a 32-bit Windows 8.1 OS, but that shouldn't
>> really be a problem (should it?).
>
> In theory, that should be fine.
>
>> I started with OpenSSL and there are a couple of weird things:
>>
>> 1. Even when configuring for x86-64, the C flags still clearly say
>> WIN32. Maybe that just means "windows" and not necessarily 32-bit.
>> The "configure" Perl script does declare it's configuring for
>> x84-64 so hopefully that's right.
>
> No idea.
>
>> 2. OpenSSL's build script calls ml64 which can't be found in the
>> path. It's probably not good that the command fails, and the build
>> script doesn't even check to see if it succeeded.
>
> That suggests that you haven't got your paths set right to pick up the
> right versions of the build tools and/or libraries.
>
>> 3. The linker fails at the last step for me: link /nologo
>> /subsystem:console /opt:ref /debug /out:out32\md4test.exe @
>> C:\Users\IEUser\AppData\Local\Temp\nmC7C.tmp LINK : fatal error
>> LNK1207: incompatible PDB format in
>> 'C:\Users\IEUser\AppData\Local\Temp\build-tcnative\build\openssl-1.0.1h\out3\md4test.pdb';
>>
>>
> delete and rebuild
>> NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual
>> Studio 12.0\VC\BIN\link.EXE"' : return code '0x4b7' Stop.
>
> That might be a 32-bit vs 64-bit error but that is only a guess on my
> part.
>
>> Installing both MS VS 2013 (v12.0) and the SDK separately seems to
>> have set up a bunch of shortcuts for CLI development. I'm not sure
>> what is what anymore, but switching to the "VS2013 x64 Cross Tools
>> Command Prompt" and building OpenSSL in 64-bit mode seems to have
>> produced a set of binary files (e.g. openssl.exe) that I can't run
>> on my 32-bit version. That indicates to me that I've successfully
>> built OpenSSL in 64-bit mode. I have no idea why it will build
>> under that environment and not in my "other" invocation of
>> cmd.exe.
>
> Different environment settings for the various paths would be my guess.
>
>> The IA64 build of OpenSSL *did* complete, but I'm not sure how to
>> check its architecture, etc. What is the "depends" tool you guys
>> have been talking about?
>
> The depends tool ships with various tools including Visual Studio and
> the platform SDK.
Okay, but where is it? What is it called? Tapping the "windows" key and
searching for it doesn't find it, and there are tools literally
everywhere related to VC++. With a filename I might have a chance of
finding it.
-chris
Re: Building tcnative on win32 [x86_64, failing]
Posted by Mark Thomas <ma...@apache.org>.
On 01/07/2014 16:40, Christopher Schultz wrote:
> My script seemed a bit cleaner than what you are documenting on
> the wiki, plus you can get the tools for free (MS VS 12).
None of the tools documented on the Wiki are paid for.
> I was able to build a complete 32-bit statically-linked
> libtcnative.dll plus the openssl.exe utility using the process I
> knocked-up from scratch.
Depending on which version of the MSVCRT DLL?
> Note that I have been compiling without using the nasm assembler.
> I figured I'd try to get things working without it, then add that
> component later once the build process was working.
Back when I was working with VS6, I needed to use nasm as the
assembler that shipped with VS6 didn't understand the syntax. I'm
assuming that Mladen hasn't been using it.
> I have been having trouble building pretty much any 64-bit stuff.
> I happen to be running a 32-bit Windows 8.1 OS, but that shouldn't
> really be a problem (should it?).
In theory, that should be fine.
> I started with OpenSSL and there are a couple of weird things:
>
> 1. Even when configuring for x86-64, the C flags still clearly say
> WIN32. Maybe that just means "windows" and not necessarily 32-bit.
> The "configure" Perl script does declare it's configuring for
> x84-64 so hopefully that's right.
No idea.
> 2. OpenSSL's build script calls ml64 which can't be found in the
> path. It's probably not good that the command fails, and the build
> script doesn't even check to see if it succeeded.
That suggests that you haven't got your paths set right to pick up the
right versions of the build tools and/or libraries.
> 3. The linker fails at the last step for me: link /nologo
> /subsystem:console /opt:ref /debug /out:out32\md4test.exe @
> C:\Users\IEUser\AppData\Local\Temp\nmC7C.tmp LINK : fatal error
> LNK1207: incompatible PDB format in
> 'C:\Users\IEUser\AppData\Local\Temp\build-tcnative\build\openssl-1.0.1h\out3\md4test.pdb';
>
>
delete and rebuild
> NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual
> Studio 12.0\VC\BIN\link.EXE"' : return code '0x4b7' Stop.
That might be a 32-bit vs 64-bit error but that is only a guess on my
part.
> Installing both MS VS 2013 (v12.0) and the SDK separately seems to
> have set up a bunch of shortcuts for CLI development. I'm not sure
> what is what anymore, but switching to the "VS2013 x64 Cross Tools
> Command Prompt" and building OpenSSL in 64-bit mode seems to have
> produced a set of binary files (e.g. openssl.exe) that I can't run
> on my 32-bit version. That indicates to me that I've successfully
> built OpenSSL in 64-bit mode. I have no idea why it will build
> under that environment and not in my "other" invocation of
> cmd.exe.
Different environment settings for the various paths would be my guess.
> The IA64 build of OpenSSL *did* complete, but I'm not sure how to
> check its architecture, etc. What is the "depends" tool you guys
> have been talking about?
The depends tool ships with various tools including Visual Studio and
the platform SDK.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Building tcnative on win32 [x86_64, failing]
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Mark,
On 6/30/14, 4:23 PM, Mark Thomas wrote:
> On 30/06/2014 14:45, Mark Thomas wrote:
>> 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.
>
> OK. I think I have a working build for tc-native statically linked to
> OpenSSL and APR and dynamically linked to the MS runtime DLLs.
>
> As far as I can tell Mladen has been building with Visual Studio 6.
>
> I need to clean up my build process, script a few things etc and then
> test the result (at least on 32-bit and AMD 64-bit).
My script seemed a bit cleaner than what you are documenting on the
wiki, plus you can get the tools for free (MS VS 12). I was able to
build a complete 32-bit statically-linked libtcnative.dll plus the
openssl.exe utility using the process I knocked-up from scratch.
Note that I have been compiling without using the nasm assembler. I
figured I'd try to get things working without it, then add that
component later once the build process was working.
I have been having trouble building pretty much any 64-bit stuff. I
happen to be running a 32-bit Windows 8.1 OS, but that shouldn't really
be a problem (should it?). I started with OpenSSL and there are a couple
of weird things:
1. Even when configuring for x86-64, the C flags still clearly say
WIN32. Maybe that just means "windows" and not necessarily 32-bit. The
"configure" Perl script does declare it's configuring for x84-64 so
hopefully that's right.
2. OpenSSL's build script calls ml64 which can't be found in the path.
It's probably not good that the command fails, and the build script
doesn't even check to see if it succeeded.
3. The linker fails at the last step for me:
link /nologo /subsystem:console /opt:ref /debug
/out:out32\md4test.exe @
C:\Users\IEUser\AppData\Local\Temp\nmC7C.tmp
LINK : fatal error LNK1207: incompatible PDB format in
'C:\Users\IEUser\AppData\Local\Temp\build-tcnative\build\openssl-1.0.1h\out3\md4test.pdb';
delete and rebuild
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio
12.0\VC\BIN\link.EXE"' : return code '0x4b7'
Stop.
Installing both MS VS 2013 (v12.0) and the SDK separately seems to have
set up a bunch of shortcuts for CLI development. I'm not sure what is
what anymore, but switching to the "VS2013 x64 Cross Tools Command
Prompt" and building OpenSSL in 64-bit mode seems to have produced a set
of binary files (e.g. openssl.exe) that I can't run on my 32-bit
version. That indicates to me that I've successfully built OpenSSL in
64-bit mode. I have no idea why it will build under that environment and
not in my "other" invocation of cmd.exe.
The IA64 build of OpenSSL *did* complete, but I'm not sure how to check
its architecture, etc. What is the "depends" tool you guys have been
talking about?
Thanks,
-chris
Re: Building tcnative on win32 [x86_64, failing]
Posted by Mark Thomas <ma...@apache.org>.
On 30/06/2014 21:32, Mladen Turk wrote:
> On 06/30/2014 10:23 PM, Mark Thomas wrote:
>> On 30/06/2014 14:45, Mark Thomas wrote:
>>> 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.
>>
>> OK. I think I have a working build for tc-native statically linked to
>> OpenSSL and APR and dynamically linked to the MS runtime DLLs.
>>
>> As far as I can tell Mladen has been building with Visual Studio 6.
>
> Nope.
> I'm building with Windows7 DDK, and some other tools:
> https://github.com/mturk/cmsc
Ah. Interesting. What OS are you running that little lot on?
> Think I'm gonna change that because Microsoft drop that
> in favor of standard Visual Studio.
Change to what? Whenever I have tried to use a newer version of Visual
Studio I have ended up with a dependency on a later version of the MS
runtime DLLs.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Building tcnative on win32 [x86_64, failing]
Posted by Mladen Turk <mt...@apache.org>.
On 06/30/2014 10:23 PM, Mark Thomas wrote:
> On 30/06/2014 14:45, Mark Thomas wrote:
>> 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.
>
> OK. I think I have a working build for tc-native statically linked to
> OpenSSL and APR and dynamically linked to the MS runtime DLLs.
>
> As far as I can tell Mladen has been building with Visual Studio 6.
Nope.
I'm building with Windows7 DDK, and some other tools:
https://github.com/mturk/cmsc
Think I'm gonna change that because Microsoft drop that
in favor of standard Visual Studio.
Regards
--
^TM
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Building tcnative on win32 [x86_64, failing]
Posted by Mark Thomas <ma...@apache.org>.
On 30/06/2014 14:45, Mark Thomas wrote:
> 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.
OK. I think I have a working build for tc-native statically linked to
OpenSSL and APR and dynamically linked to the MS runtime DLLs.
As far as I can tell Mladen has been building with Visual Studio 6.
I need to clean up my build process, script a few things etc and then
test the result (at least on 32-bit and AMD 64-bit).
I also want to put together a step-by-step guide for creating the
necessary build environment from scratch.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Building tcnative on win32 [x86_64, failing]
Posted by Mark Thomas <ma...@apache.org>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Building tcnative on win32 [x86_64, failing]
Posted by Mark Thomas <ma...@apache.org>.
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.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Building tcnative on win32 [x86_64, failing]
Posted by Christopher Schultz <ch...@christopherschultz.net>.
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.
Thanks,
-chris
Re: Building tcnative on win32 [x86_64, failing]
Posted by Konstantin Kolinko <kn...@gmail.com>.
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).
Several notes on previous mails in this thread
1. Please stick to some %Subject%. Changing %Subject% I causes GMail
to break the thread.
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?
BTW, there exists paste.apache.org, but I have never used it.
https://blogs.apache.org/infra/entry/paste_apache_org_sees_the
3. The syntax for using double quotes with SET command is
SET "FOO=BAR BAZ"
or
SET FOO=BAR BAZ
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.
[1] https://www.modern.ie/en-us/virtualization-tools
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org