Fri, Sep 4
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.
Tue, Aug 25
Mon, Aug 24
Sat, Aug 22
Aug 19 2020
For GNU/Linux, it's done.
Aug 17 2020
Aug 15 2020
Here's the patch:
Aug 14 2020
@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
firstname.lastname@example.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.
Aug 10 2020
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.
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.
Aug 5 2020
BTW, I learned that Fedora now uses pkgconfig (instead of pkg-config).
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).
Aug 3 2020
Aug 2 2020
Jul 29 2020
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.
Jul 9 2020
Jun 16 2020
You are very welcome, i'll let you know if i found more issues in the future, same goes to libgcrypt.
Jun 15 2020
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.