On Thu, Jul 03, 2014 at 10:19:46AM -0400, Daniel Kahn Gillmor wrote:
> It sounds like upstream is willing to include these headers for whatever
> architecture we want, and it looks like it should be pretty
> straightforward to add headers as a stopgap to new debian releases of
> libgpg-error should we need to do that.
I do not think that this is a good solution, because it is hard to
maintain. These headers may need changes with updated versions of glibc
(or with a different libc) and for new ports the header will always be
missing. Ultimately, this is not a good solution.
> Helmut, can you try doing that for some of our more obscure
> architectures, or for ones you're trying to cross-build? I'm happy to
> forward any platform-specific generated header files upstream.
I'm sorry, I cannot do that for two reasons:
* The list of Debian architectures I am trying to crossbuild for is:
alpha, arm, arm64, armel, armhf, hppa, i386, ia64, m68k, mips,
mips64el, mipsel, or1k, powerpc, powerpcspe, ppc64, ppc64el, s390,
s390x, sh4, sparc, sparc64, x32.
I hope you agree with me that this is simply infeasible for me to do.
* For many of these architectures executing code is non-trivial. For
example, it is still hard to obtain hardware access for arm64, or1k,
and ppc64el. Also the qemu emulation is lacking (segfaults etc) for
some architectures.
On Thu, 03 Jul 2014 08:46:00 +0200, Werner Koch wrote:
> By means of configure's AC_CHECK_SIZEOF - pretty standard for
> cross-compiling.
I'd much prefer a solution based on AC_CHECK_SIZEOF (which works without
executing binaries for the host), but I am not an autofoo expert. It
seems that gen-posix-lock-obj examines the following aspects:
* sizeof(pthread_mutex_t)
* sizeof(_gpgrt_lock_t)
* Assumes that reordering a long in a struct retains size. I am not
sure why this assumption should be safe. (_gpgrt_lock_t vs. dummyobj)
Explanation welcome.
* Assumes that sizeof(long) <= sizeof(long*). I am not sure why this
assumption should be safe. (_gpgrt_lock_t vs. gpgrt_lock_t)
Explanation welcome.
* Explicitly assumes that a union of long long* has the same alignment
as pthread_mutex_t (see comment).
* The contents that PTHREAD_MUTEX_INITIALIZER assigns to a
pthread_mutex_t.
Can someone explain to me why gpgrt_lock_t cannot be redefined to be
a typedef to _gpgrt_lock_t and GPGRT_LOCK_INITIALIZER cannot be changed
from
{ <<hardcoded value of LOCK_ABI_VERSION>> ,{{ \
<<sequence of char values>> }}
to
{LOCK_ABI_VERSION,{PTHREAD_MUTEX_INITIALIZER}}?
That'd help me better understand why we need this dance. I didn't find
answers to these questions in either READMEs.
Please keep CCing me.
Helmut
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
