-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Rainer,

On 8/25/15 11:49 AM, Rainer Jung wrote:
> Am 24.08.2015 um 21:23 schrieb Mark Thomas:
>> On 24/08/2015 16:40, Alten, Jessica-Aileen wrote:
> 
>>>> We'd love to provide Windows binaries for mod_jk, but they
>>>> are a real pain in the neck to actually build: they require
>>>> very specific build environment, and the library must be
>>>> built in such a way that it's compatible with the web server
>>>> in which it's running (e.g. httpd 1.3/2.2/2.4 or IIS
>>>> 5/6/7/8/9, proper architecture (32/63) and chipset 
>>>> (x86/x86-64/itanium/alpha). It's gotten to the point where
>>>> it's tough to provide all of those combinations with any
>>>> regularity.
>>> 
>>> I understand that it is difficult - perhaps too difficult for
>>> the developers of this module, but the average Windows admin or
>>> Java programmer should do this? ;) There were binaries of this
>>> module at least for the last 10 years! I'm very disappointed on
>>> this attitude. You are closing out the whole Windows/IIS
>>> world.
>> 
>> Yes, we (the Tomcat community) has a problem here.
>> 
>> We needed a jk release to address a security issue that had been
>> made public before we were ready. The developers that normally
>> work on jk have been quiet lately so one of the other Tomcat
>> developers stepped up to do the release. The source code side of
>> things is relatively simple but the binaries are not and the
>> document build process is not sufficient to generate a binary
>> release.
>> 
> 
>> This is the documented build process for ISAPI: 
>> http://svn.apache.org/viewvc/tomcat/jk/trunk/native/iis/README?view=a
nnotate
>>
>>
>>
>> 
We don't have the equivalent 'How to build a release' documentation.
>> 
>> It is not at all clear how release builds (which options have
>> been used, what have they been compiled with / against?) have
>> been built in the past so it is next to impossible to reproduce a
>> similar build.
>> 
>>>> Unfortunately, I don't believe they provide builds for the
>>>> ISAPI redirector for IIS. If that's what you need... umm...
>>> 
>>> Umm - yes - this is what I need.
>> 
>> There are a couple of options:
>> 
>> Hope the jk committers provide enough information to document
>> the release process so anyone can run it.
>> 
>> Figure out how to build something that works for you and share
>> that with the Tomcat community so anyone can build it. Then one
>> of the active Tomcat committers will be able to include the
>> binary in the next release (and provide an official binary for
>> this release).
> 
> I just tried the isapi_redirector build using VC 2010 and the 
> Makefile.amd64. No additional flags, just setting up the compiler
> with "setenv /Release /x64" (as usual for MSVC) before running it.
> Then changing into the iis src directory and running "nmake -f 
> Makefile.amd64" which results in Release_amd64/isapi_redirect.dll
> (the IIS plugin) and Release_amd64/isapi_redirect.pdb (the symbol
> file needed for debugging). The build was done on Windows 7 64 Bits
> Professional, but I think that is less important then the MSVC
> version used.
> 
> Since I'm using the 2010 compiler, the produced binary has a
> dependency on the MSVCR100.dll runtime library, which must be
> installed independently on the system if not yet available, but at
> least there are redistributables for it provided by Microsoft, see 
> https://www.microsoft.com/en-US/download/details.aspx?id=5555. I
> have checked the dependency using the "depends.exe" dependency
> walker (similar to Unix/Linux ldd), see
> http://www.dependencywalker.com/.
> 
> I'd hope that the usual runtime library compatibility issues are
> not the problematic for the ISAPI redirector as for mod_jk on
> Windows. Maybe IIS can cope better with plugins using different
> versions of the runtime libs. I definitely don't have a version 6
> compiler to prevent using the newer runtime libs.

I believe we go through great pains with tcnative to build against
MSVCRT.DLL because, evidently, that is guaranteed to be available on
any modern Windows system (I think that means win2k/NT4.0+... possibly
back to win95). This reduces the installation complexity for the end
user, but requires lots of work on the part of the packager.

I'd like to know what the community thinks about building against
MSVCRT100.DLL, which is essentially the same thing and I would imagine
that everyone has that DLL these days. (The issue, of course, is that
we can't bundle it ourselves due to licensing restrictions.)

Can we statically-link instead of using the DLL? Would that be very
stupid? Seems like it would solve everything.

Thanks,
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJV3LbzAAoJEBzwKT+lPKRYZJAP/jcbABmW39urbWUDQ6OYIJHB
jXLhOyb4ibH9fGesEeNL/ye/i29WbX+uxp3TJWbQ2eKK5Lraom5TRzqm0zjJFgYR
MEjuk7djBWX0TgnC2S2YlAnfxkzUCC4D2+1S9olPlX8J/mDmvbwS3ei4k+6QLjMO
IvJ/fBYdga1dAhE8cnT4yIxj5MRzZk9GCQkwKrknksoTzU1J+UNbaVUomTAnDcqe
akkvq0m/C8ubXRuq7bRLcYWBlgbYy22GxJClczMgmKTfIHoHnkG/nONgpvLxtq+i
CDPt3B2ULoYsjz0xTWo94NtNdl8BceNWfsd8JBSF2YFW35Bd1SDVsNQHQV6J3gU3
iIhtbyaiApyBwBm0c/1hiz7toCG1jMZ2yXgb2RInr/X7nqibauab7s7B8j1WMwRL
yjMeXtSYaqibTGok5DH8v184m6mSit/RL/9BU7V/holx+8kcVI956/OG+9eIBWpg
RdQ4QR63UGf2do1kU6Bo1qG7RIfWXdC2D0TtX5PgsbpMfyKWiuDjfKgiL0iLJ0hB
M7AAsRUfArBlPtZTm7JDDWRDajrhYoEgwW0UXB2fVrkabkAxODEWlxZeX6wxH5xR
g7VQcwO11CvsKb9di9h2WiW8cGoffWfXQSEubbSrvCivAcLVBOStdpbo6MjOElXv
36oZEj6hxAqMpwdHbOnG
=ZRj0
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to