[Top][All Lists]
[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