[gnutls-devel] Automatic library initialization

Nikos Mavrogiannopoulos nmav at gnutls.org
Mon Nov 16 16:23:31 CET 2015


On Mon, Nov 16, 2015 at 3:17 PM, Nikos Mavrogiannopoulos
<nmav at gnutls.org> wrote:
>>> > IMO, you should revert your decision and should not automatic initialize.
>>> > For someone who badly needs that (beyond my imagination right now), a
>>> > ./configure flag and GNUTLS_NO_EXPLICIT_INIT should do it. Maybe it
>>> > should be
>>> > GNUTLS_AUTOMATIC_INIT, defaulting to 0.
>>> That is too late now as it would be an ABI break. However a configure
>>> flag is certainly an easy thing to be added, but it would only solve
>>> your problem if you target some specific systems. What is the use case
>>> you are trying to address?
>> A ./configure flag would be enough. I'll ask the Debian maintainer(s) to apply
>> such a flag. As long as there are no packages/projects that *rely* on
>> automatic init, there should be no problem. If there are, these packages
>> should be fixed.
> That is hardly a solution. An API is not distribution specific, and if
> the gnutls' API doesn't require gnutls_global_init(), that should be
> for any distribution including debian. We need to find something
> better to prevent the constructor being run for specific applications

Something like the following. Have each program not wishing to use
global initialization to define a symbol which overrides a weak one
from gnutls. In practice that would mean setting:
GNUTLS_SKIP_GLOBAL_INIT

in some global section in your program. That can also be easily
backported in 3.3.x and you can check for that feature with an ifdef.
Would that be acceptable?

regards,
Nikos
-------------- next part --------------
A non-text attachment was scrubbed...
Name: skip-global-init.patch
Type: text/x-diff
Size: 1741 bytes
Desc: not available
URL: </pipermail/attachments/20151116/380570cc/attachment-0001.patch>


More information about the Gnutls-devel mailing list