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

[Keith Marshall]

Hi Daiki, Roumen,

On 22/04/14 09:49, Daiki Ueno wrote:
> Roumen Petrov <address@hidden> writes:
> 
>> In this thread
>> http://comments.gmane.org/gmane.comp.gnu.mingw.devel/5366 is posted
>> that libintl contain some absolute paths with drive letter (woe
>> platform) .
>>
>> If configuration option --enable-relocatable is not set would libintl
>> contain paths with drive letter ?
>>
>> If so what about "relocation" to be activated by default for woe platforms ?
> 
> Keith also opened a issue on the tracker:
> 
> https://savannah.gnu.org/support/?108469
> (sorry I missed it, actually)
> 
> I still haven't had a chance to try it on Windows, but I'm confused why
> 'relocatable' matters here.

As currently implemented, it seems to be ineffective in the scenario to
which my ticket relates.

> If I understand correctly, the 'relocate' function merely replaces
> the original installation prefix with the given installation prefix.

My question relates not to what the 'relocate()' function does, but
rather to the anticipated effect of the '--enable-relocation' option, at
'configure' time.  Currently, it appears that its only effect is to wrap
the LOCALEDIR argument to 'bindtextdomain()' within a 'relocate()' call,
in the caller's scope, 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.  This seems like a missed design
opportunity, especially in the case of clients on Woe32 or Woe64 hosts,
which could derive significant benefit from relocation being performed
within the scope of 'bindtextdomain()' itself, relative to the
installation directory of the client application, (as returned by
'GetModulePathName()' with a NULL module handle).

> That way, it should work either with or without a drive letter.

The drive letter issue, which was the subject of the MinGW bug report,
is a consequence of one of those exceedingly annoying nuisances on
MS-Windows, coupled with a rash configuration choice by the developer
who created the binary release of gettext-0.18.3.1 for MinGW.org -- he
had mapped '${localedir}' to

    I:/some/arcane/path/share/locale

which may have been a persistently valid drive mapping on his host, but
has a high probability of mapping to a device with removable media on
other users' hosts.  When this the case, and there is no medium in the
drive, then Windows throws an exception which 'bindtextdomain()' cannot
silently ignore, (as it would for an otherwise non-existent directory);
rather, Windows itself interrupts process flow, and nags the user to
insert some medium into the drive, before it can continue.

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

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

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.  However, I rejected that patch myself, for the following
reasons:

1) It was offered as a MinGW.org specific patch, which would have
created a gettext project fork; this is an option which we would prefer
not to entertain.

2) The offered patch ignores the 'relocate()' function which is already
present within the gettext sources, in favour of an entirely disparate
implementation; I would like to see the concept of the patch accepted
upstream, and might expect more favourable consideration if it were
based on the already existing 'relocate()' function.

-- 
Regards,
Keith.