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.

1.25 has been released.

ping

Distinguishing between 32 and 64 bit Windows in the same development package
works on Windows but only because 64 bit Windows also supports 32 bit Windows.
On most other platforms this is not the case. For a different ABI it is quite
common to require the installation of a platform specific development package.

You won't change the design to support sloppy build systems which would only
trigger hard to find bugs.

Fixed in 40e5ff0a0084c0d9521b401db4f38885bfdae233.

ping

This particular problem of assertion error, it was fixed in 1.22. So, I close this.
We also have T2378 for a possible change for Solaris/sparc. Please continue
there.

I believe that it's fixed in 1.22. Closing.

Closing, as I confirmed that -lrt is not needed any more in Solaris Userland
project:
https://hg.java.net/hg/solaris-userland~gate

IMHO, it's pretty uncommon from the packaging point of view to deliver
different generic header files for different platforms (one can meet
platform related ifdefs much often). It necessarily moves the platform
decision rules into the source code of the library consumer.

Yes, that is very likely the same bug. Feel free to reopen this report if yuo
can still reproduce it, in which case a backtrace would be very handy.

Fixed in 28fd0ab.

I can't find an explanation why gentoo inserts "-hardfloat". I doubt that this
is willy-nilly and as long as this has not been figured out, there is a
possibility of a different ABI and thus we can't simply alias it. Can you
please work with Kristian or someone else from gentoo to figure this out?

Thanks for binutils link.