Fedora 32 and FAIL: gpg-error-config-test.sh
Closed, WontfixPublic

Description

I'm trying to build GnuPG for Fedora 32. libgpg-error-1.38 is having trouble.

$ make check V=1
Making check in m4
make[1]: Entering directory '/home/jwalton/Build-Scripts/libgpg-error-1.38/m4'
make[1]: Nothing to be done for 'check'.
make[1]: Leaving directory '/home/jwalton/Build-Scripts/libgpg-error-1.38/m4'
Making check in src
make[1]: Entering directory '/home/jwalton/Build-Scripts/libgpg-error-1.38/src'
make  check-am
make[2]: Entering directory '/home/jwalton/Build-Scripts/libgpg-error-1.38/src'
make  check-TESTS
make[3]: Entering directory '/home/jwalton/Build-Scripts/libgpg-error-1.38/src'
pkg-config: --version specified with other options or module names, assuming --modversion.
pkg-config: --version specified with other options or module names, assuming --modversion.
FAIL: gpg-error-config-test.sh
=======================================
1 of 1 test failed
Please report to https://bugs.gnupg.org
=======================================
make[3]: *** [Makefile:1326: check-TESTS] Error 1
make[3]: Leaving directory '/home/jwalton/Build-Scripts/libgpg-error-1.38/src'
make[2]: *** [Makefile:1452: check-am] Error 2
make[2]: Leaving directory '/home/jwalton/Build-Scripts/libgpg-error-1.38/src'
make[1]: *** [Makefile:1454: check] Error 2
make[1]: Leaving directory '/home/jwalton/Build-Scripts/libgpg-error-1.38/src'
make: *** [Makefile:511: check-recursive] Error 1

And:

$ cat src/gpg-error-config-test.log
Test result: --libs
====================: pkg-config gpg-error
-L/var/example-target/home/jwalton/tmp/ok2delete/lib64 -lgpg-error
====================: gpgrt-config
-L/var/example-target/home/jwalton/tmp/ok2delete//lib64 -lgpg-error
====================
Test result: --cflags --libs
====================: pkg-config gpg-error
-I/var/example-target/home/jwalton/tmp/ok2delete/include -L/var/example-target/home/jwalton/tmp/ok2delete/lib64 -lgpg-error
====================: gpgrt-config
-I/var/example-target/home/jwalton/tmp/ok2delete/include -L/var/example-target/home/jwalton/tmp/ok2delete//lib64 -lgpg-error
====================
Test result: --version
====================: pkg-config gpg-error
1.38
====================: gpgrt-config
1.38
====================

And:

$ command -v pkg-config 
/bin/pkg-config
$ pkg-config --version
1.6.3

Here is config.log:

Details

Version
1.38
JW created this task.Aug 2 2020, 12:11 AM
JW updated the task description. (Show Details)Aug 2 2020, 12:14 AM
gniibe added a subscriber: gniibe.EditedAug 5 2020, 3:20 AM

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.

gniibe claimed this task.Aug 5 2020, 3:21 AM
gniibe triaged this task as Low priority.
gniibe added a comment.Aug 5 2020, 3:51 AM

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.

JW added a comment.Aug 10 2020, 7:19 AM

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
JW added a comment.Aug 10 2020, 3:40 PM

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.

JW added a comment.Aug 10 2020, 4:12 PM

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.

JW added a comment.EditedAug 14 2020, 5:30 AM

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

JW added a comment.Aug 14 2020, 5:39 AM

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)

gniibe closed this task as Wontfix.Aug 14 2020, 5:52 AM

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

JW added a comment.EditedAug 14 2020, 5:56 AM

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.

JW added a comment.Aug 14 2020, 6:20 AM

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

JW added a comment.Aug 14 2020, 7:54 AM

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.

JW added a comment.EditedAug 14 2020, 8:06 AM
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.

werner added a subscriber: werner.Aug 14 2020, 9:09 AM

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