[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: fixing python-gpg package, need help
From: |
Efraim Flashner |
Subject: |
Re: fixing python-gpg package, need help |
Date: |
Mon, 9 Jan 2017 12:14:29 +0200 |
User-agent: |
Mutt/1.7.2 (2016-11-26) |
On Sun, Jan 08, 2017 at 04:09:17PM -0500, Troy Sankey wrote:
> I'm trying to fix the python-gpg package. Latest build [0] was a
> failure because gpgme.h claims gpgme was compiled with _FILE_OFFSET_BITS
> = 64, implying the current build (python-gpg) doesn't define any
> _FILE_OFFSET_BITS (it should also be set to 64, I think).
>
> Relevant build log snippet:
>
> ---- cut here / start ----
> swigging gpgme.i to gpgme_wrap.c
> swig -python -py3 -builtin -threads -outdir gpg -o gpgme_wrap.c gpgme.i
> gpgme.h:104: Error: CPP #error "GPGME was compiled with _FILE_OFFSET_BITS =
> 64, please see the section "Largefile support (LFS)" in the GPGME
> manual.". Use the -cpperraswarn option to continue swig processing.
> error: command 'swig' failed with exit status 1
> ---- cut here / end ----
>
> Attached is a patch which forces _FILE_OFFSET_BITS = 64 and
> _LARGEFILE_SOURCE = 1, as per the gpgme documentation [1]. This fixes
> the build on my laptop (i686), but I'm quite sure this is a bad hack.
>
Since your laptop is actually 32-bit, does python-gpg build without the
patch? If it does build without the patch, then it means that the
64-bit-ness of the build-machine on hydra is leaking into the build
environment, and it should be set to the 32/64-bit-ness of the
%target-system.
> Seeking help!
>
> Troy
>
> [0] http://hydra.gnu.org/build/1749143
> [1]
> https://www.gnupg.org/documentation/manuals/gpgme/Largefile-Support-_0028LFS_0029.html
--
Efraim Flashner <address@hidden> אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
signature.asc
Description: PGP signature