[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: SHA384_Update symbol clash with libgs
Edgar Fuß <ef%math.uni-bonn.de@localhost> writes:
> I'm not sure at which level this needs to be dealt with.
> libgs, in its infinite wisdom, exports SHA384_Update, which of course clashes
> with OpenSSL's well known symbol of the same name. Which means that as soon as
> you pull in libgs, your TLS may fail in mysterious ways.
> [In my case, it was php-ldap failing to StartTLS because OpenSSL's
> tls1_setup_key_block() failed. It took three working days (including two
> stepping through OpenSSL code) to pinpoint that. libgs was pulled in via
> Apart from a GS rendering library exporting symbol with the name of a
> well-known crypto function being a strange idea, who is at fault? Why does
> libssl's reference to SHA384_Update gets resolved to libgs's symbol and not
> Any workaround to make the code work?
I don't think there are any real definitions of which package is allowed
to do what.
In this case, though, it seems clear that libgs shouldn't use that name.
I would suggest renaming it in the sources and APIs to gs_SHA384_Update,
but I would suggest filing a bug upstream first to try to shed light on
what's happening and why.
Main Index |
Thread Index |