From: Luke Dunstan <coder_infidel@ho...> - 2002-11-12 06:25:28
>From: "Jonathan Brandmeyer" <jbrandmeyer@...>
>Reply-To: "Jonathan Brandmeyer" <jbrandmeyer@...>
>To: "[MinGW-msys]" <mingw-msys@...>,"Luke Dunstan"
>Subject: Re: [Mingw-msys] ./configure and /usr/local/lib(s)
>Well, the zlib issue has been fixed. My mistake with that is too
>embarrassing to repeat here.
>Here is another interesting line (a bugreport?)
> checking whether snprintf correctly terminates long strings... no
> configure: WARNING: ****** Your snprintf() function is broken,
>to your vendor
It is correct that snprintf() does not add a null terminator when the buffer
is filled, but this is not really a bug. Mingw snprintf() calls _vsnprintf()
in the MS C runtime library, which is documented as not adding the null
terminator. If the warning bothers you, you could always submit a patch that
makes the Mingw snprintf() work as expected :)
>OpenSSL is another story. Turns out that libcrypto.a has some undefined
>references in it that makes it dependant on libgdi32.a to build anything
>against OpenSSL in the MinGW system. Can these functions be imported into
>libcrypto.a when it is built? (worked around by adding the linker
>flag -lgdi32 to configure).
Linking to libgdi32.a is the normal way to do it, but I'm not sure if there
is an easier way. I know it is possible to put normal objects into an import
library, so you could probably extract the object files from libgdi32.a and
add them to libcrypto.a, but I hardly think it is worth the trouble.
Add photos to your e-mail with MSN 8. Get 2 months FREE*.