On 11.07.2014 19:50, Christopher Schultz wrote:
Rainer,
On 7/10/14, 8:36 PM, Rainer Jung wrote:
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.
Something doesn't quite add up, here: we have been producing builds
against the "system" MSVCRT.dll library for .. ever, and the JVM has
probably been built against MSVCR100.dll for a while, but there have
been no reports of tcnative burning to the ground on Windows. Doesn't
that mean that "libs built with different MSVC versions in the same
process" aren't a problem.. at least .. not always? Maybe the deal is
that we use only simple calls from the library and therefore it doesn't
matter which one gets called at runtime.
Folklore says mixing msvcrt.dll and a single numbered one is fine,
mixing multiple numbered ones in the same binary not.
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.
It can still be done using the Windows Driver Development Kit, but most
people don't have the DDK sitting around for "normal" Windows development.
I can't comment, I never tried that way for any build.
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.
Any chance that MSVCR100.dll and friends are provided by recent OSs? On
my Windows 8 VM I can see these files in /windows/system32:
07/25/2012 11:06 PM 77,824 msvcirt.dll
07/11/2012 10:01 PM 613,840 msvcp110_clr0400.dll
07/25/2012 11:06 PM 572,416 msvcp60.dll
08/30/2012 08:52 PM 17,888 msvcr100_clr0400.dll
07/11/2012 10:01 PM 856,016 msvcr110_clr0400.dll
07/26/2012 01:26 AM 654,848 msvcrt.dll
Like Konstantin said, typically it is *not* provided.
In my particular case, would we need to bundle anything with tcnative?
I'd say if we ever switch to building using normal MSVC, it should
simply be documented, that tcnative has a dependency on msvcr100.dll
(with the number 100 adopted to the version of MSVC which was used for
the build) and that you can get that from MS (the redistributable
download). I'd expect, that as long as we stick to the same version,
that's used to build the JVM, tcnative would find the dll loaded already
by the JVM (but haven't tested that assumption). If that is true, we
could document that as well.
Currently since we only depend on msvcrt.dll everything is fine, except
that building that way is a bit more complicated and MS might stop that
possibility in the future.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
