Re: [bug-gettext] activate --enable-relocatable by default for some platforms

[Daiki Ueno]

Hi Keith,

Keith Marshall <address@hidden> writes:

>> If I understand correctly, the 'relocate' function merely replaces
>> the original installation prefix with the given installation prefix.
>
> Currently, it appears that its only effect is to wrap the LOCALEDIR
> argument to 'bindtextdomain()' within a 'relocate()' call, in the
> caller's scope,

Yes, it is the use-case illustrated in the manual:
https://gnu.org/software/gnulib/manual/html_node/Supporting-Relocation.html#Supporting-Relocation
and indeed it works as documented, since 'bindtextdomain' doesn't do
relocation by itself.

> and this occurs only for the tools which are included in the gettext
> package itself; it has no effect in the general case of any other
> libintl client.

FWIW, there are a couple of other places using 'relocate' in libintl:
locating 'locale.alias' and 'charset.alias' files.  If the client
defines DEPENDS_ON_LIBINTL=1 and calls 'set_program_name' as described
in the above manual, libintl should look for the files in the given
installation prefix.

>> I see dcigettext.c directly uses LOCALEDIR (without 'relocate') as a
>> fallback catalog directory, but it shouldn't be a problem if you call
>> bindtextdomain properly.
>
> But, what does it mean to "call bindtextdomain properly"?  GCC, for
> example, will not wrap the LOCALEDIR argument in a 'relocate()' call,
> (unless we maintain a locally patched fork, which we _really_ want to
> avoid), even though that would be desirable behaviour.

I see.

>> So, what is the actual problem?
>
> That you have a hard coded path embedded in the libintl binary at all
> is, IMHO, a serious design failing; that this path seems to be probed,
> even when there is no language selection environment variable defined,
> and without which the probe is useless anyway, merely compounds the
> problem.  It might be useful if the probe is suppressed, in the absence
> of any language selection environment variable, and to have an analogue
> for the NLSPATH environment variable, (as it applies to 'catopen()'),
> for 'bindtextdomain()'; (yes, I do realize that a fully qualified path
> can be specified for LC_MESSAGES, or other such variable, which may
> already provide such a capability).

Yeah, that should be possible.  Maybe we could reuse the GNULOCALEDIR
envvar used in the OS/2 compat code.

> It would also be good if we had some mechanism for LOCALEDIR relocation,
> such as that provided by Erwin Waterlander's patch:
> https://sourceforge.net/p/mingw/bugs/1808/
>
> so that _any_ libintl client would _automatically_ perform the
> relocation.

Perhaps we could do some special treatment of the pathname resolution
for MinGW using 'GetModulePathName()', independently of the
'relocatable' stuff, so not to break the current calling convention that
the 'relocatable' Gnulib module offers.

Regards,
--
Daiki Ueno