Bruno Haible <> writes:

>> Usually, I bump the required version when there is any change in the
>> dependent modules since the last release, using the scripts:
>> 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, 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:

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

Daiki Ueno

Reply via email to