GNU gettext - Bugs: bug #65346, Five test failures in...
You are not allowed to post comments on this tracker with your current authentication level.
bug #65346: Five test failures in gettext-0.22.5
Submitter: | Xi Ruoyao <xry111> | ||
Submitted: | Thu 22 Feb 2024 12:16:49 PM UTC | ||
Category: | Build | Severity: | 2 - Minor |
Item Group: | None | Status: | Answer Provided |
Privacy: | Public | Assigned to: | haible |
Open/Closed: | Closed |
Jump to the original submission
Sat 24 Feb 2024 10:25:08 PM UTC, comment #6: |
Bruno Haible <haible> |
Sat 24 Feb 2024 05:03:50 PM UTC, comment #5:
|
Xi Ruoyao <xry111> |
Sat 24 Feb 2024 04:49:21 PM UTC, comment #4: The test failures will probably go away after you install GNU libunistring 1.2 (in place of the older version that you currently have installed). |
Bruno Haible <haible> |
Thu 22 Feb 2024 02:15:14 PM UTC, comment #3:
|
Xi Ruoyao <xry111> |
Thu 22 Feb 2024 02:07:48 PM UTC, comment #2:
|
Xi Ruoyao <xry111> |
Thu 22 Feb 2024 02:04:27 PM UTC, comment #1: On which operating system?
|
Bruno Haible <haible> |
Thu 22 Feb 2024 12:16:49 PM UTC, original submission:
FAIL: test-ctype_alnum
|
Xi Ruoyao <xry111> |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follow 4 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2024-02-24 | haible | Status | None | Answer Provided | |
Assigned to | None | haible | |||
Open/Closed | Open | Closed | |||
2024-02-22 | haible | Severity | 3 - Normal | 2 - Minor |
Powered by Savane 3.13-bb6a.
Corresponding source code
Usually the gl_LIBUNISTRING_MODULE and libunistring-optional.m4 logic determines correctly whether to use the installed libunistring or not. But it can produce a wrong decision in complex situations:
In FreeBSD 14.0, I had a libunistring 1.1 installed in /usr/local and a libunistring 1.2 installed in /some/prefix. Due to the way the -I options got accumulated, /some/prefix/include came before /usr/local/include; and due to the way the linker searches for libraries, /usr/local/lib came before /some/prefix/lib. So, at configure time, when <unistring/version.h> was tested, it found libunistring 1.2, i.e. LIBUNISTRING_VERSION_MAJOR=1 and LIBUNISTRING_VERSION_MINOR=2. The test from modules/unictype/ctype-alnum
thus set the LIBUNISTRING_COMPILE_UNICTYPE_CTYPE_ALNUM conditional to false. The source file gettext-tools/gnulib-lib/unictype/ctype_alnum.c was thus not being compiled. Thus libgnu.a did not contain a definition of the symbol uc_is_alnum. Then, when linking the program test-ctype_alnum, since this symbol was not found in libgnu.a, the linker took it from libunistring.so. But this happened to be /usr/local/lib/libunistring.so. And so, at runtime, the combination of a unit test for Unicode 15.1.0 with a uc_is_alnum function at the Unicode 15.0.0 level caused a test failure.
Basically, the build system did do the right thing when confronted with an include file that says "this is libunistring 1.2" together with a libunistring 1.1 library.
In order to do the right thing, it should have looked at the value of the _libunistring_version constant (when not cross-compiling). Just an idea in case this gets reported more often...