Adal Chiriliuc wrote:
>
> Hello,
>
>
> I have a big problem making https calls using libcurl 7.20.0 in a 32
> bit application on CentOS 5.4 64 bit.
>
>
> I'm making a dynamic library which uses libcurl for both http and
> https requests. libcurl is statically built and linked into the .so.

Are you building the static code appropriately for a .so on CentOS 5.4
x86 64-bit?

I thought that these days, all code in a .so had to be compiled with
-fPIC to behave correctly on x86 GNU/Linux.

> When I try to make a https request, I get the "libcurl was built with
> SSL disabled, https: not supported!" error message. BUT, if I call
> curl_version_info and look at the returned structure, CURL_VERSION_SSL
> is on, and "https:" is in the list of supported protocols. However,
> and this is where it gets weird, ssl_version is NOT NULL, but it is
> pointing to an empty string ("").
>
> If I switch the build traget of the exact same project from "Dynamic
> Library" to "Application" and include a main() function in which I try
> to make a https: call, everything works fine. In this case,
> ssl_version does not point to an empty string, but to the expected
> result - "OpenSSL/0.9.8m".
>
> I though that maybe I'm building libcurl the wrong way,

That's my thought too.

> so I removed
> libcurl 7.20.0 from my project and relied on the CentOS supplied one
> (7.15.2).

Are you statically linking the CentOS supplied on into your .so, or
having the main application link to both your .so and the CentOS
dynamic libcurl.so?

> The same thing happens. CURL_VERSION_SSL is present, but
> ssl_version points is not NULL and points to an empty string.
>
> I tried breaking into the code just before the curl_version_info call,
> to see how ssl_version could end up empty (since looking at the code
> shows that this should not be possible), but unfortunately I couldn't
> attach to the process hosting my dynamic library.

Adding print statements sometimes does the trick. Or open/write/close
to a debugging log, if you can't print things.

If it is truly "impossible" to have ssl_version pointing to an empty
string, and not merely a coding or API error, that suggests to me a
problem with the dynamic/static linking combination, resulting in
multiple instances of some variables with the same name (so the one
you see isn't the one libcurl sees), or other weird variations on that
theme.

If you are linking libcurl.a statically into your .so, I can imagine
obscure problems due to lack of -fPIC in libcurl.a's code. But more
likely, if you're doing that, perhaps the main application or some
other library used by the main application links to libcurl.so as
well, making multiple instances of libcurl in the same application?

Of course it could just be a coding or API error :-)

-- Jamie
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2010-04-15