On 08.07.2014 18:14, Mark Thomas wrote:
On 08/07/2014 16:39, Christopher Schultz wrote:
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?
Yes.
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?
Using VS6 or Mladen's toolkit, it builds against msvcrt.dll which is
part of the base OS.
For reasons I haven't dug into, later versions of Visual Studio build
upon a newer version of that library and despite quite a lot of
searching I haven't found a way to make later versions of Visual
Studio build against the older dll.
The dependency on the modern (versioned) msvcrXXX.dll only gets
problematic when you need to mix binaries and libs build with different
MSVC versions in the same process.
For instance building modules for the Apache web server and the server
itself with different MSVC versions can get you in trouble, because the
msvcrXXX.dll version depends 1:1 on the MSVC version and different
versions of the lib are not expected to interact nicely in the same process.
In the tcnative case, this would only happen, if either the jvm itself
or another native agent or library loaded into the jvm would be linked
against a different msvcrXXX.dll. Concerning agents we can't be safe
because we can't control what users load. Concerning the jvm I did a
quick check with 1.7.0_51 64 bit on Windows 7 and depends.exe show the
dependency to msvcr100.dll in bin/server/jvm.dll. The same for Java 8.
So to me it looks one can only either use the old way of building
against the old msvcrt.dll without version - which seems to be no longer
really supported and might vanish - or sync on the msvc version that is
used to build the jvm and hope they keep it stable per jvm major version.
For end users the dependency on the dll is not a big problem, because
Microsoft provides it for redistribution or download. Of course we can't
bundle it due to license incompatibility.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
