[bug-libunistring] [PATCH] unicase: Add missing prefix/suffix-context modules

[Bruno Haible]

Hi,

- u{8,16,32}_casing_{prefix,suffix}_context
- u{8,16,32}_casing_{prefix,suffix}es_context
As it stands, these functions were exposed in the header files, but were
not available in the shared object. Of course, this resulted in linker
errors.

Thanks for the report. Part of the fix goes into gnulib:


2018-04-07 Bruno Haible <***@clisp.org>

unicase/u*-context: Fix link errors with libunistring <= 0.9.9.
Reported by Genki Sky <***@genki.is>.
* modules/unicase/u8-prefix-context (configure.ac): Require libunistring
version 0.9.10 or newer.
* modules/unicase/u8-suffix-context (configure.ac): Likewise.
* modules/unicase/u16-prefix-context (configure.ac): Likewise.
* modules/unicase/u16-suffix-context (configure.ac): Likewise.
* modules/unicase/u32-prefix-context (configure.ac): Likewise.

diff --git a/modules/unicase/u16-prefix-context b/modules/unicase/u16-prefix-context
index 11939cf..355f7a3 100644
--- a/modules/unicase/u16-prefix-context
+++ b/modules/unicase/u16-prefix-context
@@ -15,7 +15,7 @@ unistr/u16-mbtouc-unsafe
unistr/u16-prev

configure.ac:
-gl_LIBUNISTRING_MODULE([0.9.8], [unicase/u16-prefix-context])
+gl_LIBUNISTRING_MODULE([0.9.10], [unicase/u16-prefix-context])

Makefile.am:
if LIBUNISTRING_COMPILE_UNICASE_U16_PREFIX_CONTEXT
diff --git a/modules/unicase/u16-suffix-context b/modules/unicase/u16-suffix-context
index 7acbf7f..c4c5cbd 100644
--- a/modules/unicase/u16-suffix-context
+++ b/modules/unicase/u16-suffix-context
@@ -14,7 +14,7 @@ unictype/combining-class
unistr/u16-mbtouc-unsafe

configure.ac:
-gl_LIBUNISTRING_MODULE([0.9.8], [unicase/u16-suffix-context])
+gl_LIBUNISTRING_MODULE([0.9.10], [unicase/u16-suffix-context])

Makefile.am:
if LIBUNISTRING_COMPILE_UNICASE_U16_SUFFIX_CONTEXT
diff --git a/modules/unicase/u32-prefix-context b/modules/unicase/u32-prefix-context
index 9785ad8..32968a5 100644
--- a/modules/unicase/u32-prefix-context
+++ b/modules/unicase/u32-prefix-context
@@ -15,7 +15,7 @@ unistr/u32-mbtouc-unsafe
unistr/u32-prev

configure.ac:
-gl_LIBUNISTRING_MODULE([0.9.8], [unicase/u32-prefix-context])
+gl_LIBUNISTRING_MODULE([0.9.10], [unicase/u32-prefix-context])

Makefile.am:
if LIBUNISTRING_COMPILE_UNICASE_U32_PREFIX_CONTEXT
diff --git a/modules/unicase/u32-suffix-context b/modules/unicase/u32-suffix-context
index de7ba3f..f6c165f 100644
--- a/modules/unicase/u32-suffix-context
+++ b/modules/unicase/u32-suffix-context
@@ -14,7 +14,7 @@ unictype/combining-class
unistr/u32-mbtouc-unsafe

configure.ac:
-gl_LIBUNISTRING_MODULE([0.9.8], [unicase/u32-suffix-context])
+gl_LIBUNISTRING_MODULE([0.9.10], [unicase/u32-suffix-context])

Makefile.am:
if LIBUNISTRING_COMPILE_UNICASE_U32_SUFFIX_CONTEXT
diff --git a/modules/unicase/u8-prefix-context b/modules/unicase/u8-prefix-context
index da5641c..8d55fbc 100644
--- a/modules/unicase/u8-prefix-context
+++ b/modules/unicase/u8-prefix-context
@@ -15,7 +15,7 @@ unistr/u8-mbtouc-unsafe
unistr/u8-prev

configure.ac:
-gl_LIBUNISTRING_MODULE([0.9.8], [unicase/u8-prefix-context])
+gl_LIBUNISTRING_MODULE([0.9.10], [unicase/u8-prefix-context])

Makefile.am:
if LIBUNISTRING_COMPILE_UNICASE_U8_PREFIX_CONTEXT
diff --git a/modules/unicase/u8-suffix-context b/modules/unicase/u8-suffix-context
index adde7e2..16214df 100644
--- a/modules/unicase/u8-suffix-context
+++ b/modules/unicase/u8-suffix-context
@@ -14,7 +14,7 @@ unictype/combining-class
unistr/u8-mbtouc-unsafe

configure.ac:
-gl_LIBUNISTRING_MODULE([0.9.8], [unicase/u8-suffix-context])
+gl_LIBUNISTRING_MODULE([0.9.10], [unicase/u8-suffix-context])

Makefile.am:
if LIBUNISTRING_COMPILE_UNICASE_U8_SUFFIX_CONTEXT

[Daiki Ueno]

Hello Bruno,

Post by Bruno Haible

- u{8,16,32}_casing_{prefix,suffix}_context
- u{8,16,32}_casing_{prefix,suffix}es_context
As it stands, these functions were exposed in the header files, but were
not available in the shared object. Of course, this resulted in linker
errors.

unicase/u*-context: Fix link errors with libunistring <= 0.9.9.
* modules/unicase/u8-prefix-context (configure.ac): Require libunistring
version 0.9.10 or newer.
* modules/unicase/u8-suffix-context (configure.ac): Likewise.
* modules/unicase/u16-prefix-context (configure.ac): Likewise.
* modules/unicase/u16-suffix-context (configure.ac): Likewise.
* modules/unicase/u32-prefix-context (configure.ac): Likewise.

While I am glad to see this has been fixed, I now wonder when we should
increase the version number and whether the above list is complete.

Usually, I bump the required version when there is any change in the
dependent modules since the last release, using the scripts:

https://git.savannah.gnu.org/gitweb/?p=libunistring.git;a=blob;f=Admin/README.update;h=76c9925c2cb63b86b6bbdc62037706c95ac399ed;hb=HEAD#l45

However, I don't see such changes since 0.9.8. Could you elaborate why
this change is appropriate, for future improvements of the release
process?

Regards,

[Bruno Haible]

Hi Daiki,

Post by Daiki Ueno
whether the above list is complete.

I did not check whether every function/variable/macro described in the
documentation is actually defined in the header files and in the library.
I just _hope_ it is the case.

It would probably be possible to check that every function/variable/macro
declared in the header files is actually defined in the library, by use
of SWIG.

Post by Daiki Ueno
Usually, I bump the required version when there is any change in the
https://git.savannah.gnu.org/gitweb/?p=libunistring.git;a=blob;f=Admin/README.update;h=76c9925c2cb63b86b6bbdc62037706c95ac399ed;hb=HEAD#l45
However, I don't see such changes since 0.9.8. Could you elaborate why
this change is appropriate, for future improvements of the release
process?

Between 0.9.8 and 0.9.9 we did not change anything, because the only
relevant change was the multithread-safety fix of 'malloca'. Hmm, I don't
know whether a malloca() from before the change and a freea() from after
the change (or vice versa) (one coming from the libunistring.so, one
from the executable) will work well together...

Between 0.9.9 and 0.9.10 we added a couple of modules to libunistring,
that were already included in gnulib.
Why the change is needed? When a program requests a module such as
'unicase/u8-prefix-context' and the module description has

gl_LIBUNISTRING_MODULE([0.9.8], [unicase/u8-prefix-context])

the autoconfiguration (when it finds a preinstalled libunistring
version 0.9.8 or 0.9.9) will not compile the module locally for the
executable, but reference the installed libunistring - thus leading
to a link error. Whereas with

gl_LIBUNISTRING_MODULE([0.9.10], [unicase/u8-prefix-context])

the autoconfiguration will compile the module locally - thus filling
the "hole" in the installed libunistring.

Your recipe
(cd $GNULIB_SRCDIR && git show --oneline --name-only $COMMIT | tail -n+2) \
| ./containing | LC_ALL=C sort | uniq \
| ./dependent | LC_ALL=C sort | uniq
looks only at gnulib, but ignores the libunistring/autogen.sh.

I don't think it is worth to change this recipe, because here we have a
very special case, that ought to not occur any more in the future.

Bruno

[Daiki Ueno]

Post by Bruno Haible

Post by Daiki Ueno
Usually, I bump the required version when there is any change in the
https://git.savannah.gnu.org/gitweb/?p=libunistring.git;a=blob;f=Admin/README.update;h=76c9925c2cb63b86b6bbdc62037706c95ac399ed;hb=HEAD#l45
However, I don't see such changes since 0.9.8. Could you elaborate why
this change is appropriate, for future improvements of the release
process?

Between 0.9.8 and 0.9.9 we did not change anything, because the only
relevant change was the multithread-safety fix of 'malloca'. Hmm, I don't
know whether a malloca() from before the change and a freea() from after
the change (or vice versa) (one coming from the libunistring.so, one
from the executable) will work well together...
Between 0.9.9 and 0.9.10 we added a couple of modules to libunistring,
that were already included in gnulib.
Why the change is needed? When a program requests a module such as
'unicase/u8-prefix-context' and the module description has
gl_LIBUNISTRING_MODULE([0.9.8], [unicase/u8-prefix-context])
the autoconfiguration (when it finds a preinstalled libunistring
version 0.9.8 or 0.9.9) will not compile the module locally for the
executable, but reference the installed libunistring - thus leading
to a link error. Whereas with
gl_LIBUNISTRING_MODULE([0.9.10], [unicase/u8-prefix-context])
the autoconfiguration will compile the module locally - thus filling
the "hole" in the installed libunistring.

So, is my understanding correct that this only affects unreleased
version of libunistring (0.9.10 is not released)?

I was confused because you urged a new release for this:
https://lists.gnu.org/archive/html/bug-libunistring/2018-04/msg00003.html

And if it is the case, my answer again would be "not this time", because
the fix in the Gnulib git should be sufficient.

Regards,

[Bruno Haible]

Hi Daiki,

Post by Daiki Ueno

Post by Bruno Haible
Whereas with
gl_LIBUNISTRING_MODULE([0.9.10], [unicase/u8-prefix-context])
the autoconfiguration will compile the module locally - thus filling
the "hole" in the installed libunistring.

So, is my understanding correct that this only affects unreleased
version of libunistring (0.9.10 is not released)?

No, I don't think it can be stated like this.

There are three kinds of packages that use GNU libunistring:

a) Those that use gnulib modules 'uni*/*', without module
'libunistring-optional'.

These packages don't link with libunistring, therefore they
have not experienced said bug, and they are not impacted by the changes
of this week.

b) Those that use gnulib modules 'uni*/*', with module
'libunistring-optional'.

These package got link errors when they attempted to use said *context
functions. These link errors will go away once
- the package updates its gnulib infrastructure (to get the modified
gl_LIBUNISTRING_MODULE invocations), or
- libunistring 0.9.10 or newer gets installed on the target system.

c) Those that use gnulib module 'libunistring', or don't use gnulib at all.

These package got link errors when they attempted to use said *context
functions. These link errors will go away once libunistring 0.9.10 or
newer gets installed on the target system.

Hope this clarifies.

Bruno