Subject: Re: detect linkage against openssl or gcrypt

Re: detect linkage against openssl or gcrypt

From: Peter Stuge <>
Date: Tue, 30 Jul 2013 16:28:31 +0200

Guenter wrote:
>>> But I could also imagine a run-time API so that an application can
>>> figure this out on its own...
>> It can't be runtime, or applications must depend on every single
>> crypto lib supported by libssh2, in order to have all symbols
>> available.
> perhaps something as simple like this would do already?

I was refering to the next step; what will your application code look
like which uses the return value from libssh2_buildinfo()?

Daniel Stenberg wrote:
>>> Is it? How would you build your makefile / build scripts with pkg-config
>>> to figure this out?
>> Run:
>> pkg-config --print-requires libssh2
>> pkg-config --print-requires-private libssh2
>> If the output is empty then that is a libssh2 bug.
> "pkg-config --print-requires libssh2" is completely blank for me on Debian,
> but so is "pkg-config --print-requires libcurl" as well, and both are
> listed with pkg-config --list-all... In fact, I couldn't find any package
> showing something in --print-requires on my Debian box when I tried a bunch
> of others as well.
> Clearly not a very reliable method up until now at least!

So there are lots of buggy packages. No big surprise.

It's really unfortunate that pkg-config is not as well-understood
as many other, much more complicated, tools. It *really* solves all
these problems as long as it is being used correctly.

It's easy for us to fix libssh2.pc and you can probably fix libcurl.pc
in a similar way. As long as all dependencies install a .pc file it's
super simple for applications to compile and link against the correct

That said, it seems silly to push the burden of dealing with this to
application code.

I think it would be much better to allow applications to ask libssh2
to deal with this on its own. Doing so would be optional.

For the case when the application in fact does want to do this on its
own I would suggest that libssh2.h simply defines a macro to be the
correct respective function for each crypto library rather than
making something more complicated.

> I can think of cases where detecting the underlying crypto lib at
> run-time can be useful or at least helpful.

Please mention some?

Received on 2013-07-30