Thank you also for the reply, the environment / build host is Ubuntu 18.04 LTS x86-x64 GNU/Linux and target host systems are MIPS and ARM.

Thanks for the report. It would be helpful if you can tell us your environment; in particular your build and target(host ) system.

Let's wait with this until we ship a libgpgrt. I am not sure what the best way to migrate to another library name. By current idea is start with some release installing two libraries using the two names but with identical code. Some releases later we could require a configure option to install libgpg-error in addition to libgpgrt.

FYIL This is delayed because there are some dependencies to internals of gnupg.

Merged. Thanks.

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.

If there's no objection to this in a few days, i'll go ahead and merge it to master.

branch dkg/fix-4952 contains this fix in an easily applicable form as 0db8c768843db3e85935b972f1ed9d1b98159c46

Push the change to master.

Clever idea.

I'm testing this as an initial start:

ac_ext=c
ac_objext=o

werner closed this task as Spite.

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.

Fixed in master, using Libs.private support.

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

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.

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

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?

For argparse.c, it can be only stopped with nonnull attribute for the API, I suppose.

I take this so that libgpg-error can be released soon.

@stm -- thank you for this!

Thank you. Merged.

I've just pushed rE732855a483709345a5c0f49504f45cb8da3f883a to dkg-fix-T4643 in the gpg-error git repository. I don't know why it is not yet visible here.

Thanks for the feedback. I'll go ahead and close any tickets that come in via debian that expect to be able to cross compile without having at least once had a native compiler on the platform to generate the appropriate lock-obj-pub-*.h.

In fact this specific scheme of indirect access to pthread objects is there to minimize dependencies of libgpg-error. It makes cross-compiling a bit harder but that is anyway the case because you need to check a lot of things for a new platform.

It is on on my private todo list but thanks for opening a public issue for tracking.

Current situation of *.pc: static linking is not supported (yet).
It has never supported, actually, by *-config.

Fix pushed.

I think that detecting strerror_s by configure is better, because it's a new feature on Windows.

I think that when using GNU autoconf's configure, you should have the ${prefix}/bin in your PATH.

I guess we can do that. Thanks for the hint.

Thanks for your report.
Let me handle issue by issue.

We update condig.{guess,sub} only when needed. In the past we had cases with regressions on some rare platforms.

It is because you don't have ${prefix}/bin in your PATH.
Please build having /var/tmp/bin in your PATH.

Without -no-undefined, libtool refuses to create the shared library (dll) on Cygwin, because libtool knows that creating a shared library (dll) on Cygwin does require all symbols to be defined.
Unfortunately but traditionally, by default libtool has to assume a library being created will have undefined symbols.
Hence, if the library to be created is designed to have all symbols defined, libtool needs to be informed about this fact using the -no-undefined flag.
This flag does allow libtool to create a shared library even on platforms known to require all symbols to be defined for shared libraries.

Please explain in more detail what the problem with Cygwin is.

For reference our downstream tracker of this is https://bugs.gentoo.org/683254 including patches

Added a fix to GnuPG, too (master and stable 2.2).

I keep this ticket open, since it is also problem for other packages.

Similar issue with ntbtls:

FWIW:
The first config.log is from a gnutls build.
The second for libassuan 2.5.3 and has been configured:

./configure --enable-shared --prefix=/var/tmp --libdir=/var/tmp/lib64