On 11/07/2014 01:36, Rainer Jung wrote: > 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.
As long as all versions of Java depend on the same msvcrXXX.dll then we'd only need to ship one version of tc-native. As soon as there are multiple dependencies we'd need to build and ship multiple versions. > 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. Right now the prudent thing to do appears to ensure that multiple committers have a built environment (preferably on a VM) for the current build process. > 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. Indeed. Most systems will probably have it installed already. If we opted to depend on the version that shipped with Java we'd know it was present. That said, it still makes me uncomfortable. My preference is to stick to the current dependencies for as long as we can. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
