libgpg-error: Replace syscfg

Jörg Krause joerg.krause at
Sat Apr 16 09:42:56 CEST 2016

Dear Werner Koch,

sorry for my late reply and many thanks for your feedback!

On Di, 2016-03-29 at 12:22 +0200, Werner Koch wrote:
> On Mon, 21 Mar 2016 12:43, joerg.krause at said:
> > All the information gen-posix-lock-obj provides are available at
> > compile-time, so I do not see the necessity for a runtime tool to
> > fetch
> It is a compile time tool and not a runtime tool

Yes, the detection of the platform specific properties is done during
build time. However, the README states that "the detection can't be
done when cross-compiling", which is not true as the cross-toolchain
knows all platform specific properties. Or do I miss something?

> > > an internal change to libgpg-error does not introduce a long
> > > chain of
> > > required ABI changes to all software dependent on libgpg-error.
> > 
> > I understand! However, as I said, there is no difference in the end
> > between using gen-posix-lock-obj/syscfg/mkheader generating the
> > lock
> > part of gpg-error.h and defining the lock object directly in gpg-
> > error.h. Both produces the same compilation unit.
> That is true for the current implementaion.  However, this defines a
> specific ABI which independent of the actual implementation.  Thus we
> can add any time change the internal implementation without affecting
> the ABI.

Sorry for my ignorance, but I'm not sure I understand the ABI part

I know that {posix,w32}-lock-obj.h defines a LOCK_ABI_VERSION. Do you
mean this by "specific ABI"? If so, the lock-obj is part of that ABI,
and the implementation might change in the future, right?

Is the problem here that I replaced in 'src/' the '@inclu
de:lock-obj@' by the gpgrt_lock_t definition which might change in
future implementations?

However, I do not understand: "Thus we can add any time change the
internal implementation without affecting the ABI." What do you mean by
changing the internal implementation? And how does a change does not
affect the ABI?

Best regards
Jörg Krause

More information about the Gnupg-devel mailing list