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

Okay, I see the problem. The microsoft toolchain is more picky about de-facto standard use patterns with common blocks and the author of that code was not ware of this. Thanks for reporting, will be fixed in the next release.

This is not about a function, but about the variable _gpgrt_functions_w32_pollable. And this is not about exporting the variable from the library, but about declaring it as extern in gpgrt-int.h, so that gpgrt-int.h can be included in multiple translation units without defining the variable in each.

This function is not exported on purposes. Even the name of the header file indicates that tis is internal. External, that is public functions of the API, are defined gpgrt.h and only made externally visible by including them in the .def file. This has not been done and so I don't understand your bug report.

Applied.

News for 1.34:

Topic branch of libgpg-error is not good to show changes (for other libraries).
So, I made D473: Introducing LDADD_FOR_TESTS_KLUDGE to enable 'make check' with LD_LIBRARY_PATH.
Appliying to libgpg-error.

For other distros, it seems it's quite old issue: https://sourceware.org/ml/binutils/2012-05/msg00037.html

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.