Page MenuHome GnuPG

libgpg-error 1.25 fails to build
Closed, ResolvedPublic


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 ./ \

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

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

full log attached



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
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.

werner claimed this task.