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).

It would be good to have complete compatibility supporting these kinds of typos, but I'm afraid we can't.

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

I found this:
https://dev.gentoo.org/~mgorny/pkg-config-spec.html

And I leaned that pkg-config development has been stopped.
https://cgit.freedesktop.org/pkg-config

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

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

I meant:

• From the point of mine, it is YOUR problem to specify correct prefix and libdir
• Please fix your script for prefix and libdir
• If it works, I'd like to close this problem as wontfix

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

Also see build-gpgerror.sh script.

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

My runpath is $ORIGIN/../lib64:/home/jwalton/tmp/ok2delete/lib64, but the library is not yet installed. So there is nothing in /home/jwalton/tmp/ok2delete/lib64 at the moment. The library is located at libgpg-error-1.38/.lib (or whatever Autotools uses).

$ find . -name t-version
./libgpg-error-1.38/tests/t-version

And my runpath:

$ readelf -d libgpg-error-1.38/tests/t-version | grep -E 'RPATH|RUNPATH'
 0x000000000000001d (RUNPATH)            Library runpath: [$ORIGIN/../lib64:/home/jwalton/tmp/ok2delete/lib64]

But:

$ ldd libgpg-error-1.38/tests/t-version
        linux-vdso.so.1 (0x00007ffd0a197000)
        libgpg-error.so.0 => /lib64/libgpg-error.so.0 (0x00007fb7df788000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007fb7df781000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fb7df75f000)
        libc.so.6 => /lib64/libc.so.6 (0x00007fb7df595000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fb7df7c9000)

And:

$ LD_LIBRARY_PATH="libgpg-error-1.38/src/.libs" ldd libgpg-error-1.38/tests/t-version
        linux-vdso.so.1 (0x00007f13d651e000)
        libgpg-error.so.0 => libgpg-error-1.38/src/.libs/libgpg-error.so.0 (0x00007f13d64f3000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f13d64d1000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f13d64af000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f13d62e5000)
        libintl.so.8 => /home/jwalton/tmp/ok2delete/lib64/libintl.so.8 (0x00007f13d62d8000)
        libiconv.so.2 => /home/jwalton/tmp/ok2delete/lib64/libiconv.so.2 (0x00007f13d61ec000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f13d6520000)

If the test scripts set LD_LIBRARY_PATH then that should fix the problem.

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

Please continue your libtool problem on macOS at T5009: OS X 10.12 and FAIL: random.

... you are now describing another problem

I'm not sure what you mean. If you look at the output in the initial report, it says "FAIL: gpg-error-config-test.sh".

The analysis I provided shows why it failed. The analysis was a courtesy. Apparently, no one on the team could be bothered to test it or duplicate it.

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

I don't think that your analysis of LD_LIBRARY_PATH is relevant for the error of gpg-error-config-test.sh, since it is a shell script.

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

What typo?

@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).

Anyway, please continue at where I am creating new issue: T5024: libtool problem for some platforms for 'make check' (program built with -no-install won't work without installation)

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

No, I'm not using libtool's -no-install. That's a different problem. I'm not experiencing that problem.

To be clear, my workflow is shown below. As far as I know this is a standard workflow practiced by most users. There's nothing special about it.

1. configure
2. make
3. make check
4. sudo make install

If any step fails, then the process stops.

The problem here is, GnuPG is not putting .libs/ on-path for testing.

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

That's not a problem. That's standard Posix behavior.

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

What I meant in T5024 is: on your platform (because of what I wrote in T5024), you need to do:

1. configure
2. make
3. sudo make install
4. make check

to run the test programs correctly. (-no-install is used in our Makefile, I am sure you are using that feature.)

I'm feeling difficulty to talk to you.

That's because I am politely ignoring the questionable advice.

Regarding the advice, it will only happen in the reign of Queen Dick. Its an English saying that means, it will only happen when Queen Elizabeth grows a pecker between her legs. This is wrong, and it will not happen:

1. configure
2. make
3. sudo make install
4. make check

You never run make install until make check passes. If make check does not pass, then you cannot run make install.

I seem to recall GnuPG has some certifications. Any auditor worth their salt will not certify the program until make check passes as expected. If an auditor approves the procedure, then he/she is not worth a shit. You don't install defective software.

Here's the patch you need to fix the libgpg-error self tests.

--- tests/Makefile.in
+++ tests/Makefile.in
@@ -646,6 +646,10 @@
 check-TESTS: $(TESTS)
 	@failed=0; all=0; xfail=0; xpass=0; skip=0; \
 	srcdir=$(srcdir); export srcdir; \
+	gpgerror_libdir=`dirname $$PWD`/src/.libs; \
+	LD_LIBRARY_PATH=`echo "$$gpgerror_libdir:$$LD_LIBRARY_PATH" | $(SED) 's/:*$$//g'`; \
+	DYLD_LIBRARY_PATH=`echo "$$gpgerror_libdir:$$DYLD_LIBRARY_PATH" | $(SED) 's/:*$$//g'`; \
+	export LD_LIBRARY_PATH; export DYLD_LIBRARY_PATH; \
 	list=' $(TESTS) '; \
 	$(am__tty_colors); \
 	if test -n "$$list"; then \

The $(SED) 's/:*$$//g at the end removes trailing semi-colons. That will happen if LD_LIBRARY_PATH or DYLD_LIBRARY_PATH is empty before running the script. It is needed because some BSDs choke when there's a trailing semi-colon. Linux and OS X are fine.

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 understand your point, but your fix is not relevant

That's called "throwing the baby out with the bathwater". The patch fixes AIX, BSDs, Linux, OS X, Solaris and nearly all other Unix knock-offs. It covers nearly all of your use cases.

You are welcome to update the patch for Windows. I don't do the "Linux on Windows" thing, so I don't care about the use case.

And if you do nothing, then 100% of your use cases are broken.

@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.

You also raised a different problem for which @gniibe asked you to leap to T5024. Please do not mix different issues - that is too confusing for everyone.