Thu, Jun 16
Applied to 1.10 branch.
didn't seem to work with 1.9.x
Wed, Jun 15
Thanks! Interestingly didn't seem to work with 1.9.x but it does with 1.10x. Maybe I made some error when testing.
Wed, Jun 1
May 17 2022
Pushed the change.
May 16 2022
Thanks for your confirmation.
May 14 2022
Okay, confirmed: I was just wrong and the build failure was only ever with --disable-asm (i.e. the log in this bug is the only relevant one). Patch works.
May 13 2022
Thank you for your fast reply. My apologies - I should have thought to do that (share log with asm enabled)! But now I'm confused. I think the failure was only ever with asm disabled. I will check with somebody else tomorrow just to make sure though.
Could you please give us the build log with no --disable-asm?
Feb 24 2022
(note: -O2 is added only for compiling powerpc vector implementation files)
I added check to configure.ac for missing -O flag and tests with -O2. If adding -O2 does not help, then powerpc vector implementations wont be build at all.
Jan 26 2022
Thanks for report. Those powerpc vector implementations expect that compiler optimizations are enabled and here provided CFLAGS did not have '-Ox' parameter. This could be worked around by introducing -O2 always when building those files (confiugre.ac & cipher/Makefile.am change) or using 'optimize' attributes to required functions (cipher/*-ppc*.c change).
Jan 22 2022
Thanks for report. I got similar report earlier this week from gentoo user through email and made following patch for them to test. I'll push it to master soon.
Jan 20 2022
Jan 17 2022
sorry, I'm a bit confused now and probably everything I wrote above is incorrect.
thanks for approving account.
build error happens in automatic configuration (when --enable-ppc-crypto-support is omitted from ./configure) and -mcpu=powerpc64le, -mcpu=power8 or power9 or -mpower8-vector flags are not passed to compiler.
On behalf of @gyakovlev (pending approval for his account):
[03:05:23] <@gyakovlev> AC_DEFINE(HAVE_COMPATIBLE_CC_PPC_ALTIVEC,1, [03:05:23] <@gyakovlev> [Defined if underlying compiler supports PowerPC AltiVec/VSX/crypto intrinsics]) [03:05:34] <@gyakovlev> they should definitely check for __POWER8_VECTOR__ 1 [03:05:44] <@gyakovlev> it's not plain altivec [03:06:52] <@gyakovlev> that power check should check for __POWER8_VECTOR__ [03:06:52] <@gyakovlev> not only for what they check already. [03:08:59] <@gyakovlev> it probably should be checked after __powerpc64__ or instead of it.
Oct 29 2021
Sep 6 2021
Sep 5 2021
You could use --disable-keyboxd which should fix this. However, there will eventually be no more way to build w/o Sqlite and thus I would suggest not to allow disabling of sqlite.
Aug 13 2021
Feb 7 2020
Jan 2 2020
PS I forgot to say why movement to cmake will be the best way.
I totally disagree.
Please read libgpg-error's README. For each architecture we need to have a dedicated config file - this has nothing to do with autotools. Big and little endian variants are obviously different architectures. Here is an excerpt from the README
Jan 1 2020
Hello @wener, I want to say that libgpg-error is the only one (!) application that fails to cross compile using valid toolchains: "armeb-unknown-linux-gnueabi" and "aarch64_be-unknown-linux-gnu". It compiles and runs perfectly using "arm-unknown-linux-gnueabi" and "aarch64-unknown-linux-gnu", but fails with big endian. I see project are actually using "hton/ntoh" so we shouldn't see this error. What this problem is about?
Dec 6 2019
Apr 23 2019
For reference our downstream tracker of this is https://bugs.gentoo.org/683254 including patches
Mar 28 2019
Good that it works again for you.
This was most likely a (chipcard) hardware issue. It went away after polishing the contact pads for a bit. Possibly my laptop reader applies more force...
May 15 2018
Jul 13 2017
I am closing this, because this particular change was rejected. Eventually libtool might get updated on its own merits, so no need to track this here.