[gnutls-devel] Automatic library initialization

Tim Ruehsen tim.ruehsen at gmx.de
Mon Nov 16 16:54:18 CET 2015

On Monday 16 November 2015 16:23:31 Nikos Mavrogiannopoulos wrote:
> 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:
> 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?

Brilliant idea. I'll use it for my projects... but other projects won't 
benefit immediately (they first have to know).

Regards, Tim

More information about the Gnutls-devel mailing list