[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: svn commit: r1748461 - in /httpd/httpd/branches/2.2.x: ./ CHANGES support/ab.c

On Sat, Oct 13, 2018 at 2:06 PM Ivan Zhakov <ivan@xxxxxxxxxxxxx> wrote:
On Sat, 13 Oct 2018 at 20:00, Gregg Smith <gls@xxxxxxxx> wrote:
On 10/13/2018 8:32 AM, William A Rowe Jr wrote:
> Sorry, I don't understand.
> Gregg, can you shed some insight here? For both, applink.c is helpful if
> the OpenSSL .dll files are created with a different VC compiler than
> abs.exe was compiled with.

Not true, OSSL 1.0.2 I know from experience if applink.c is not included
it will still err even if both ab.c & OSSL are compiled with the same VC
version (14 & 15). I never tested 1.1.0.

That's true: since OpenSSL 1.0.2 applink.c is required even if OpenSSL и application uses same VC toolchain.

That's very interesting, not observed here. Second request... pointers please? I'm strongly suspecting an /MD /MT mismatch. I only build the 'ntdll' style of OpenSSL, and never bother to mix linkage models or build abs.c static against openssl etc. Or perhaps this speaks to specific, buggy releases of 1.0.2?

[Something for the audience; applink.c redirects all of the "standard c library" API's used by OpenSSL into the flavor in use by the version of the MSVC runtime linked to the primary .exe file. And in it's absence, the flavor OpenSSL was built against. Why we almost never care? These apply to basic input/output, the BIO layer of OpenSSL, which mod_ssl hardly touches. But apps using classic C stdio functionality like ab.c care a great deal. Which leads us to Ivan's comment;]
Alternative solution to including applink.c could stop using OpenSSL APIs that uses stdio and provide APR based BIO implementation. In this case OpenSSL will never use stdio functions.

Indeed! That's a complete solution. But a lot of effort if Boring/Libre/etc "just work" and only OpenSSL falls down on doing the simplest BIO functions. I'd have to fault OpenSSL, and not promote workarounds. Again I need some citations about the "defect" which makes zero sense here.

It would also support building mod_ssl with OpenSSL compiled with option --no-stdio.
Indeed, I'm shocked if we can't build mod_ssl with --no-stdio today! Those would be some odd quirks in mod_ssl/openssl (discounting ab.c)... but that's certainly another thread. It seems like a worthwhile goal, nothing should speak stdio within mod_ssl's structure.