Fri, May 22
Thu, May 21
libgpg-error used to be blamed because of this kind of architectural support in earlier stage of building operating system.
T4774 is my try to fix the problem.
Thank you for your work. Please go ahead.
Wed, May 20
If there's no objection to this in a few days, i'll go ahead and merge it to master.
Tue, May 19
branch dkg/fix-4952 contains this fix in an easily applicable form
Thu, May 14
Apr 9 2020
Push the change to master.
Apr 6 2020
I'm testing this as an initial start:
Apr 2 2020
werner closed this task as Spite.
Apr 1 2020
See my comments on the other bugs you posted today.
Please see my other comments; we need proper bug reports and not just arbitrary snippets.
Mar 12 2020
Feb 27 2020
Feb 18 2020
Fixed in master, using Libs.private support.
Feb 10 2020
Note that we have a small pactch in the queue which should be applied by distributions to 1.37unless they want to wait for 1.38. See rEd72c1ddfde09ffa69745ec2439c5a16d15e2202f
Feb 7 2020
Feb 6 2020
Thanks. Fix goes into 1.37.
It has been fixed in the repo for nearly a year, see T4459. A new release is urgently required and will follow in the next days. I close this as a duplicate.
Jan 29 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?