Please note that the result with --host="arm-unknown-linux-gnueabi" for linux-uclibcgnueabih machine is different to the one of correctly generated version by gen-posix-lock-obj.c with USE_POSIX_THREADS undefined on the host.

I found that the use of $CC -print-file-name=crt1.o won't work with some cross compiler.
For example, on my system of Debian bullseye for cross compiler ppc64el, while it's for multiarch configuration, crt1.o is under GNU cross style directory: /usr/powerpc64le-linux-gnu/lib

I would understand your workaorund of using artifical --host intentionally.

This won't work in the context of buildroot as we're passing --host="arm-unknown-linux-gnueabi" to avoid the following build failure:

We also need to support the use case of GNU cross style, like when we build with MinGW toolchain.

For other libraries, like libgcrypt, it is mostly OK with old gpg-error.m4, because those libraries don't depend on new libgpg-error features.

Fixed GnuPG in rGe1e3f1db4660: build: Update gpg-error.m4. and rG985e85dc0e6c: build: Update gpg-error.m4..

Fixed more in rEd7fd25bbfb83: build: Fix the previous change..

Thank you for the report. I had expected *-*-linux* matches only to GNU/Linux (Linux kernel with GNU C library).

They are mandatory for gnupg but not for Libgcrypt and Libgpg-error. I guess we can fix that.

Because, threads are optional on uclibc as threads are not supported by all embedded targets.
libgpg-error was building perfectly fine without threads until version 1.40 as all pthread calls were protected by USE_POSIX_THREADS.
Should I understand from your answer that threads are now mandatory?

How does it come that you have a Linux kernel without threads? Or maybe the better question is why does libc not support threads?

Considered again, I realized that (1) is no need to check.

POSIX says so (use printf instead).
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/echo.html

iirc the advise from the GNU coding standards is to use printf(1) instead of trying to figure out how echo(1) works.

Thank you. I'll fix. Perhaps, I'll ignore old UNIXen like AIX 6.1, which has no way to echo with no newlines.

See T5192 for an updated release.

I know these troubles.

In T3189#117959, @gniibe wrote:

Do we need to expose the secmem routines, as a public interface of gpgrt?

I would find it useful. For example I'm making a utility that gets a passphrase with GPGME and gpg-agent, and would like to copy it into a buffer that lives on after closing the context.

Winepath starts calls the full Wine engine just convert file names to DOS format. This is used by libtool but if winepath can't be executed, it doesn't care. So the given solution (using /etc/alternatives/winepath -> /bin/false) can be used.

Release done.

For GNU/Linux, it's done.

Thanks

Here's the patch:

@JW: @gniibe explained you the problem and provided a fix (i.e. use correct specifiction of the directory names). Changes to Makefile.in are a no-go because that is a built file and a real fix would need to go into libtool. However, for a couple of reasons we do not want to update libtool (e.g. too many breakages in the past, we have out own fixes in for Windows). Thus we consider this bug closed.

I understand your point, but your fix is not relevant

Thanks for your patch. I understand your point, but your fix is not relevant (for supporting all platforms). You can use that way in your build script, but we can't take that approach; The correct fix is fixing libtool.

I'm feeling difficulty to talk to you.

@JW, I'm feeling difficulty to talk to you.

... no-support of slash at the end of path and duplicated slash, we won't fix.

T5024: libtool problem for some platforms for 'make check' (program built with -no-install won't work without installation)

For the original problem of no-support of slash at the end of path and duplicated slash, we won't fix.

@JW, I'm afraid you are not able to read what I write here. This is not chat system at all. For chat system, please use XMPP on
gnupg-devel@chat.gnupg.org as written at https://gnupg.org/documentation/mailing-lists.html (if possible).

I wrote that "FAIL: gpg-error-config-test.sh" is because of your typo

I wrote that "FAIL: gpg-error-config-test.sh" is because of your typo, and I asked to fix your typo and test again.

... you are now describing another problem

@JW, you are now describing another problem, instead of the problem you reported.
I'm closing this one.

We currently already ship:

The problem appears to be the test framework is not setting a LD_LIBRARY_PATH (or DYNLD_LIBRARY_PATH on OS X).

As far as I know, the environment is set correctly. PKG_CONFIG_PATH, --prefix and --libdir are set. And runpaths are also set.

I meant:

If you can point me to a commit, I can patch the package and retest it.

If there is no other problem (than the issues of additional slash and double slash), I'll close this bug report.

BTW, I learned that Fedora now uses pkgconfig (instead of pkg-config).
https://github.com/pkgconf/pkgconf

Try with --prefix=/home/jwalton/tmp/pk2delete (with no slash at the end) and --libdir=/home/jwalton/tmp/pk2delete/lib64 (with no double slash between pk2delete and lib64, but a single slash).

We have had this in the past but it led to subtle build and, worse, runtime problems. Thus the decision to provide architecture dependent files and have configure complain for wrong files. Right, you sometimes get false warnings for non-matching cpu-vendor-os strings but I consider this less severe than the old problem.

I just saw that there is related discussion and a patch for this in T4994 so I will close again here.

This change broke for me the compilation of GPGME which I fixed with: 52f930c1ed7eee6336a41598c90ef3605b7ed02b I found that fix there OK because GPGME explicitly uses ws2_32.

You are very welcome, i'll let you know if i found more issues in the future, same goes to libgcrypt.

It's me who should say "thank you".

Yes, i always build it with PKG_CONFIG_SYSROOT_DIR but never had any issues with it until 1.38 version, your suggestion definitely fixed it. Thank you.

Or one liner patch would be enough:

IIUC, you build libgpg-error with setting PKG_CONFIG_SYSROOT_DIR.
It results errors, because while old gpg-error-config never supports PKG_CONFIG_SYSROOT_DIR, it compares result from old gpg-error-config and gpgrt-config gpg-error.

Please give us full build log here, so that we can investigate what's going on. You can upload log file by the "upload" button in comment edit dialog.

Confirm gpg-error-config works... no

• Please report to https://bugs.gnupg.org with gpg-error-config-test.log

Makefile:1667: recipe for target 'gpg-error-config' failed

No problem, in fact there's several issues with the cross build code, i'll report them later today.

Sorry for repeated mistake of mine.
I fixed it and tested with 'make distcheck' in the environment of cross-build for ppc64el host.

After this change:

Thanks for your report. I think it fails to generate src/lock-obj-pub.native.h.

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.