Page MenuHome GnuPG

libgpg-error 1.25 fails to build
Closed, ResolvedPublic

Description

it seems latest libgpg-error has a hardcoded list of all supported system using
some kind of lock header and fails for all unknown systems instead of having a
portable fallback. this seems like a very Bad Idea(tm).

        libgpg-error-1.25 prepared for make

        Revision: 6d834f8  (28035)
        Platform: powerpc-unknown-linux-musl

if test -f lock-obj-pub.native.h; then rm lock-obj-pub.native.h; fi
./mkheader linux-musl powerpc-unknown-linux-musl ./gpg-error.h.in \

../config.h 1.25 0x011900 >gpg-error.h

./gpg-error.h.in:435: error including `./syscfg/lock-obj-pub.linux-musl.h': No
such file or directory
make[2]: *** [gpg-error.h]

full log attached

Details

Version
1.25

Event Timeline

werner lowered the priority of this task from Unbreak Now! to Normal.
werner removed a project: Bug Report.
werner added a subscriber: werner.

Sorry, this is not a bug but clearly documented in the README in the section
"Cross-Compiling". Your log shows that you are dojng just that:

checking whether we are cross compiling... yes

Please search the gnupg-devel ML for a discussion on why this is the Right Thing
to do for this library.

musluser raised the priority of this task from Normal to High.Nov 26 2016, 4:02 PM

sorry, but it is not acceptable to copy executables via ssh to native computers
and execute them there and copy the result back to the build machine during
crosscompilation.
the whole arch-specific stuff is unnecessary when you just use pthread_mutex_t
directly and be done with it. patch attached.
in case there's a system that doesnt use pthreads, fine, then you can do the
arch-specific dance there, but please do not ruin the buildprocess for anyone
using a POSIX conforming system for this madness.

What you describe is a standard requirement for many low level libraries and
tool when cross-compiling.

Please do not use the bug tracker for discussions but use gnupg-devel instead.
Thanks.

werner claimed this task.