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. > 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. > 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 In my particular case, would we need to bundle anything with tcnative? Thanks, -chris
signature.asc
Description: OpenPGP digital signature
