My patches on the topic branch: https://dev.gnupg.org/source/libgpg-error/history/gniibe%252Fdisable-new-dtags/

My tentative conclusion: When (GNU) ld supports --disable-new-dtags, add it to LDADD in tests/Makefile.am.

Reading this discussion: http://lists.gnu.org/archive/html/bug-libtool/2018-01/msg00014.html
It seems that it could be fixed if we care about the order of libraries.
And it's not the issue for libgpg-error, which doesn't require external libraries.

For binutils, in Stretch, Debian specific patch was introduced.
Then, upstream introduced --enable-new-dtags option for configure to build binutils.
Now, Debian uses --enable-new-dtags option (at build time).

NEWS for 1.33:

I don't think this works for me in that way.

Use that function as early as possible. The gpg-error tool has also be enahnced on Windows:

Thanks. In the meantime GpgOL takes it's language from the Outlook configured display language setting. I'll add support for override locale to gpgol so that the locale is set accordingly

So far, so good.

To avoid the drawback, we can put the logic of locating possible libdir in gpg-error.m4, instead of putting in the script.

It builds for me now. I had a mismatch with a to old gpgrt-config and did not properly set PKG_CONFIG_PATH

libassuan master fails to compile for windows against libgpg-error master http://paste.debian.net/1049534/ I think gpg-error.m4 ignores both sysroot and --with-gpg-error-prefix

We need more testing.

I decided to change gpgrt-config to have --libdir option.
By supplying libdir directly, it's no need anymore to detect the directory by CC variable.
gpg-error.m4 is also updated.

I need more information:

• where is pkg-config path for <host_alias>? How is it determined?
  • 32-bit: /lib or /lib32?
  • 64-bit: /lib or /lib64?
  • something like x32: where???

I consider:

• Single gpgrt-config is better (and simpler)
• new option --for-host=<host_alias>? (--host is already used for query for host)
• update *.m4 using this new option to provide host information to determine the path

yat2m updated. Thanks.

secmem routines are installed into gniibe/secmem branch.
Please note that it's only secmem routines, not malloc_secure.

I created gniibe/secmem branch for this.
https://dev.gnupg.org/source/libgpg-error/history/gniibe%252Fsecmem/

We are moving to use the yat2m from gpgrt (libgpg-error); thus the additional tag.

IMO this can be closed. At least the problem for which I intended this ticket is fixed.

Printing "(null)" is just coincidence because NULL is stored at the respective stack address on one platform.

Well I'm pretty sure the reason is that valuetable_buffer is not inialized in _gpgrt_estream_format. But the resulting behavior confused me. It would not crash. But it would also not print "gpg: Entschlüsselung als fehlgeschlagen angesehen: (null)" It would just print nothing instead of that string.

It's manually written one in Debian:
https://salsa.debian.org/debian/gnupg2/blob/debian/master/debian/gpg-check-pattern.1

Thanks for forwarding.

It is in 1.30 which I released a few minutes ago. Only minor other changes.

Argh. I missed that. Probably because I searched for libgpg-error but I myself renamed the tag recently :-(.

Put the check in configure.

I close this bug as wontfix. If you can provide the requested changes for libtool please re-open this bug.

I merely said, that we won't replace libtool by the upstream version because that lacks other important changes we need. Upstream was not willing to integrate our changes for Windows support and also introduced a lot of other regressions as well as dropping support for some platforms. Thus we need to maintain our version.

I know exactly what you mean, but werner disagrees so that's not going to happen.

Forgive me. I was biting my tongue.

No response.

Maybe ask on a mailing list for help to find out why your environment is broken.

I tried on a fresh installation of Ubuntu 14.04.5 and could not reproduce the problem. Apparentlcy your test suite tries to link against an installed version of the library, which is very odd.

Can you provide a patch for our version of the libtool macros that only adds support for illumos?

libgpg-error is a placeholder project for the master version of our libtool, but all other packages are likely to be affected as well.

The platform is illumos, a fork of OpenSolaris.

No response.

and the platform is ...

The version of libtool that you ship does not have the necessary patches required to support my platform. Normally this isn't a problem because autogen.sh (or autoreconf) will update it.

You may not run your own version of libtool or libtoolize. Only the maintainer updates the autotools related files including libtool. This is to avoid bugs stemming from different or broken versions of autotools. This makes it much easier to reproduce bugs.

No reply to my question, thus it seems not to be important. Closing.
Note that replying to this will re-open the bug.

ping (see T2370 (wk on Nov 18 2016, 08:44 AM / Roundup))

What you describe is a standard requirement for many low level libraries and
tool when cross-compiling.

Please do not use the bug tracker for discussions but use gnupg-devel instead.
Thanks.

sorry, but it is not acceptable to copy executables via ssh to native computers
and execute them there and copy the result back to the build machine during
crosscompilation.
the whole arch-specific stuff is unnecessary when you just use pthread_mutex_t
directly and be done with it. patch attached.
in case there's a system that doesnt use pthreads, fine, then you can do the
arch-specific dance there, but please do not ruin the buildprocess for anyone
using a POSIX conforming system for this madness.

D399: 921_0001-fix-libgpg-error-lock-madness.patch

Sorry, this is not a bug but clearly documented in the README in the section
"Cross-Compiling". Your log shows that you are dojng just that:

checking whether we are cross compiling... yes

Please search the gnupg-devel ML for a discussion on why this is the Right Thing
to do for this library.

Yes, I have seen that URL but what I like to get an answer to my question here
or on gnupg-devel. I do not want to follow a possible long thread of some Linux
distribution.

There was a long drawn out discussion as to the validity of "-hardfloat" in the
triplet name. You can peruse at https://bugs.gentoo.org/show_bug.cgi?id=584052 .

I am not a dev and have pretty much given up. The Gentoo devs are adamant that this
is an upstream problem.