serf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: SCons considered terminally broken
Date Sat, 23 Jun 2018 17:53:11 GMT
I think you have suggested CMake in the past? ... I would support any build
system that does Unix and Windows (which obviates autoconf)

On Sat, Jun 23, 2018, 05:59 Branko ─îibej <> wrote:

> I've been working on getting Serf built on Windows x64 with OpenSSL
> 1.1.0. I noticed that the function checks in SCons (Config.CheckFunc)
> that we use to find OpenSSL features were not working correctly. After
> some digging around in OpenSSL import libraries, SCons sources and the
> config.log file, I found the following:
> 1. Behaviour of Config.CheckFunc(function[, header]):
> SCons generates a test program that contains a call to 'function()'.
> This turns out to be quite problematic.
> 2. CheckFunc without the optional header parameter:
> When the test program is built, the compiler issues a warning about a
> missing prototype for 'function', assumes it's an "extern returning
> int". However, linking fails because the linker looks for the decorated
> function name '_function', but the names exported from the OpenSSL
> libraries (static or DLL import lib) are not decorated, so, just
> 'function'. The names don't match, the link fails and SCons happily
> assumes that the function does not exist.
> 3. CheckFunc /with/ the optional header parameter:
> The compiler now sees the function prototype and, since most functions
> require parameters, errors out because the call to 'function()' as
> generated by SCons is invalid. Again, SCons happily assumes that the
> function does not exist.
> 4. Conclusion:
> I do have an opinion about Windows name decoration that's not for public
> consumption. But in this case, I think that SCons is simply doing the
> wrong thing by blindly generating the function call. For comparison,
> autoconf does the same *but* also generates a prototype that overrides
> any compiler builtins, and doesn't include any headers in the test program.
> Finally, has anyone successfully built 64-bit Serf with OpenSSL 1.1.0 on
> Windows? If yes, how? Because I can't think of how this could be
> possible with SCons failing the way it does.
> FWIW: a 32-bit build of Serf and OpenSSL works.
> -- Brane

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message