Hi everyone,
GPC version 20011222, the release candidate #2 for GPC 2.1, has been uploaded to the usual places, CVS and FTP:
ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/current/gpc-20011222.tar.gz
The main changes made since RC 1 are in the searching of unit source and GPI files (thanks to a bug report by The Chief), the handling of packed arrays (thanks to a bug report by Emil Jerabek) and set constructors (due to some bugs found by myself). If you use any of these things, you might want to check if the changes didn't break any of your code.
There is also one new "feature", the Intl (internationalization) unit by Eike Lange. (I know that normally one should not do major additions so short before a release, but the unit is completely separate from the rest of the compiler and run time system, so even a very unlikely fatal bug would not affect the stability of the whole system.)
Again, I've tested it on some systems, test reports from other systems are welcome, and if you find new or especially important bugs, or very important missing features, please report them.
Merry Xmas, Frank
Frank Heckenbach wrote:
Hi everyone,
GPC version 20011222, the release candidate #2 for GPC 2.1, has been uploaded to the usual places, CVS and FTP:
ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/current/gpc-20011222.tar.gz
There is also one new "feature", the Intl (internationalization) unit by Eike Lange. (I know that normally one should not do major additions so short before a release, but the unit is completely separate from the rest of the compiler and run time system, so even a very unlikely fatal bug would not affect the stability of the whole system.)
No problem to compile for djgpp, uploaded as usual to agnes under the link: ftp://agnes.dida.physik.uni-essen.de/home/maurice/gpc2953b.zip
DJGPP has only partial support for intl: namely setlocale understands only 'C', 'POSIX' and '' but the translations are allowed by environment variables LANG and LANGUAGE (may be in djgpp.env file) Furthermore it needs -liconv in addition to -lintl because the .mo files are coded as usual in ISO (8859-1 for french), which needs to be recoded to DOS codepage (CP850 foir french).
In the zip uploaded I have changed intl.pas and gettextdemo.pas which give a djgpp working example.
Maurice
Maurice Lombardi wrote:
DJGPP has only partial support for intl: namely setlocale understands only 'C', 'POSIX' and '' but the translations are allowed by environment variables LANG and LANGUAGE (may be in djgpp.env file) Furthermore it needs -liconv in addition to -lintl because the .mo files are coded as usual in ISO (8859-1 for french), which needs to be recoded to DOS codepage (CP850 foir french).
In the zip uploaded I have changed intl.pas and gettextdemo.pas which give a djgpp working example.
Actually I've just added an autoconf check for -lintl to link it automatically from intl.pas when present. Should I do the same for -liconv? It will probably not be needed on most platforms, but shouldn't hurt, either. Or should I do it conditionally on __OS_DOS__?
Frank
Frank Heckenbach wrote:
Maurice Lombardi wrote:
DJGPP has only partial support for intl: namely setlocale understands only 'C', 'POSIX' and '' but the translations are allowed by environment variables LANG and LANGUAGE (may be in djgpp.env file) Furthermore it needs -liconv in addition to -lintl because the .mo files are coded as usual in ISO (8859-1 for french), which needs to be recoded to DOS codepage (CP850 foir french).
In the zip uploaded I have changed intl.pas and gettextdemo.pas which give a djgpp working example.
Actually I've just added an autoconf check for -lintl to link it automatically from intl.pas when present. Should I do the same for -liconv? It will probably not be needed on most platforms, but shouldn't hurt, either.
Would be useful for djgpp at least.
Or should I do it conditionally on
__OS_DOS__?
No, mingw32 defines __OS_DOS__, presumably for line ends and may be drive letters,
but being windows it uses (nearly) ISO-8859-1. EMX, when used with rsxwin as extender uses also windows codepage, (and presumably CP437/CP850 when in plain dos with rsx or emx as extender, I used it some years ago that way with emtex/texshell)
Do you suppose that gpc/gcc should be configured with --enable-nls ? I have not done it in the binaries uploaded, and when I tried, it triggers a bug, djgpp-related, on stage 1: I suppose that nobody has ever tried to compile gcc-2.95.3 natively for djgpp with intl support.
Maurice
Maurice Lombardi wrote:
Frank Heckenbach wrote:
Actually I've just added an autoconf check for -lintl to link it automatically from intl.pas when present. Should I do the same for -liconv? It will probably not be needed on most platforms, but shouldn't hurt, either.
Would be useful for djgpp at least.
Or should I do it conditionally on
__OS_DOS__?
No, mingw32 defines __OS_DOS__, presumably for line ends and may be drive letters,
Yes, and so do Cygwin and EMX.
but being windows it uses (nearly) ISO-8859-1.
Yeah, nearly but not completely the same, so maybe they also need a (slight) conversion.
Anyway, checking for and linking -liconv does not mean that any conversion will be done automatically. It only means that -liconv will be "offered" to the linker in case -lintl actually uses any of its routines. So I think it's still safe to do it on all __OS_DOS__ systems, isn't it?
Do you suppose that gpc/gcc should be configured with --enable-nls ? I have not done it in the binaries uploaded, and when I tried, it triggers a bug, djgpp-related, on stage 1: I suppose that nobody has ever tried to compile gcc-2.95.3 natively for djgpp with intl support.
I have no idea. But if anything, this will only influence the compiler itself (and AFAIK there are no non-English messages for GPC -- don't know about GCC, so it would seem pointless). The RTS doesn't use this setting (it should be up to the configuration of a GPC compiled program whether or not to include NLS, but that's up to the author and/or user of the Pascal program then).
Frank
Frank Heckenbach wrote:
Maurice Lombardi wrote:
Anyway, checking for and linking -liconv does not mean that any conversion will be done automatically. It only means that -liconv will be "offered" to the linker in case -lintl actually uses any of its routines. So I think it's still safe to do it on all __OS_DOS__ systems, isn't it?
OK I see no problem.
-
Frank Heckenbach -
Maurice Lombardi