On Fri, Nov 09, 2007, Jeff Johnson wrote:

> On Nov 9, 2007, at 2:08 AM, Ralf S. Engelschall wrote:
>>>
>>> What's the best way to get rid of these leaks? I understand perfectly
>>> why a neon library cannot eliminate the leaks, see the comments in
>>> ne_sock_init.
>>
>> Can't RPM just call OpenSSL's ERR_free_strings() explicitly itself in
>> case it knows it is using NEON (we provide "WITH_NEON") and NEON is
>> using SSL (<ne_utils.h> provides "NE_FEATURE_SSL")?
>
> But doesn't that force rpm to also be explicitly (rather than implicitly)
> linked with openssl?

Not really linked, but compiled: RPM needs to include an OpenSSL header
in order to get the prototype for ERR_free_strings() or we have to
cheat and provide an own prototype. But under link-time the indirect
dependency librpmmisc->libneon->libcrypto should work just fine.

> I can't justify linking openssl to get rid of a valgrind message ...

Yes, it is a little bit strange, of course. But the only possibility
would be to cheat the following way, I think:

| #if defined(WITH_NEON)
| #include <ne_utils.h>
| #if !defined(HEADER_ERR_H)
| /* cheat to avoid having to explicitly build against OpenSSL */
| extern void ERR_free_strings(void);
| #endif
| #endif
|
| [...]
|
| #if defined(WITH_NEON)
| if (ne_has_support(NE_FEATURE_SSL))
|     ERR_free_strings();
| #endif

But the call to ERR_free_strings() should be in the RPM code which
already calls the NEON functions just to make sure that only the
librpmXXX which has already the symbol references to NEON also has this
additional OpenSSL reference.

                                       Ralf S. Engelschall
                                       rse@engelschall.com
                                       www.engelschall.com