bug-gnu-utils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Patches for OS/2 (2)


From: Bruno Haible
Subject: Re: Patches for OS/2 (2)
Date: Mon, 11 Nov 2002 21:33:33 +0100 (CET)

Andreas Buening writes:

> I added a __DEBUG__ macro that causes some extra info to
> be printed to stderr at runtime. It helped me a lot.

You could just as well have used a .gdbinit with a few breakpoints. No
need to modify the source for extra info for a single person.  And if
you want Joe User profit from your extra info then it is wrong make it
conditional on __DEBUG__.

> The main problem with libintl is that it is not easy to
> provide precompiled executables that work on all systems
> because every user may have its stuff on another drive.

You can compile the binaries for a fixed virtual
drive, say U:, and expect the users to ASSIGN/JOIN/SUBST
U: to where they have installed emx.

> If the precompiled binaries use prefix=e:/usr/local then
> libintl can't find the locale files in f:/usr/local etc.
> If the precompiled binaries use prefix=/usr/local then libintl
> can find the files in f:/usr/local only if f: is the current
> drive which means that the program result depends on the
> choosen current directory.
> The solution is the following: If a directory name doesn't
> contain a drive letter x: then the $UNIXROOT drive letter
> is assumed. If UNIXROOT is not set nothing happens.

DOS and OS/2 maintain a notion of "current drive". The
effect that you achieve through UNIXROOT=f: is the same
as the user would obtain through the command "cd f:".
The handling of pathnames without drive letters is
already handled inside EMX. I see no reason to duplicate
it in the software above it.

> loadmsgcat.c:
> Initialize _nl_msg_cat_cntr with 0. It's a bad programming style
> not to do so

We've already discussed this. BSS allocated variables are ISO C compliant.

> and under some circumstances it can lead to problems
> with the OS/2 linker.

If these "circumstances" can occur with libintl, then you'd better ask
EM to fix the OS/2 linker.

> localcharset.c:
> Moved most of the OS/2 specific code to os2compat.c.

Nope. localcharset.c is used in other GNU packages as well, and they
don't have and don't want to have an os2compat.c.

> Try to find out the current OS/2 charset. If that's not possible
> use the default code for non Win32 systems.
> Use a more general function to strcmp() the codeset with the
> existing aliases. In this case e.g. "de_DE" (the usual LANG
> for Germany) is identical with the first string that contains
> "de_DE" (which is "de_DE.ISO-8859-1"). Otherwise no correct
> codeset is selected due to the entries in charset.alias.

If charset.alias does not contain a given locale name, then the first
thing to consider is: a user error. On a system without built-in
locales, tell the user to set LANG=de_DE.ISO-8859-1. If FreeBSD users
can do that, OS/2 users can do it as well.  If you don't agree with
this, then add the missing locale names to config.charset - in the
OS/2 specific part, of course.

Bruno




reply via email to

[Prev in Thread] Current Thread [Next in Thread]