[pkg-gnupg-maint] Bug#869609: Bug#869609: libgpg-error is unecessarily hard to bootstrap for new architectures/ABIs

[Daniel Kahn Gillmor]

Hi all--

over on https://bugs.debian.org/869609, Wookey and Steven Capper kicked
off this discussion about making libgpg-error less painful to bootstrap
for a new architecture (Steven's contribution is included below).

I note that there is additional discussion about cross-compilation of
things *based* on gpg-error over at https://bugs.debian.org/643341 -- i
think that's a different issue, though it seems related: we haven't made
ease of cross-compilation or bootstrapping a specific goal of the
library, afaict.

On Mon 2017-07-24 22:07:49 +0100, Steven Capper wrote:

> So going through this my understanding is that for Linux this library
> creates weak references to the pthread_mutex_ functions as well as
> simulates the size of the pthread_mutex_t type. IIUC this obviates the
> need to cross-compile against pthreads. When one loads the library,
> the weak references will be overridden by the C library and, providing
> the data type is the same as simulated, should operate as one is using
> pthreads.
>
> If the simulated data type does not match the system implementation, I
> am not sure what behaviour will manifest.
>
> I don't understand why one cannot cross-compile a library that makes
> use of pthreads directly though? Was this weak function/type
> simulation workaround needed for a bug in the past that has since been
> fixed?
>
> Have we missed something obvious?

I don't know the history of this part of libgpg-error, though i know
that cross-platform portability (as well as support on historic
architectures) has generally been a goal of the GnuPG project.  It might
be an irony of this focus that it's actually *harder* to do more common
modern cross-compilation/bootstrapping as a result.

But maybe Werner or some other GnuPG upstream folks with more knowledge
can weigh in on the backstory here?

fwiw, i generally agree that it'd be great to be able to make gpg-error
more closely conform to modern cross-compilation and bootstrapping
processes, since it tends to be in the core of a tight group of
dependencies on many systems.

Regards,

      --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/attachments/20170727/3097ca23/attachment-0001.sig>