[fpc-devel] Unix internationalization patch

[Michael Van Canneyt]

On Tue, 8 Apr 2008, petr.kristan at epos.cz wrote:

> On Tue, Apr 08, 2008 at 05:19:34PM +0200, Jonas Maebe wrote:
> > 
> > On 08 Apr 2008, at 17:03, petr.kristan at epos.cz wrote:
> > >On Tue, Apr 08, 2008 at 04:29:51PM +0200, Michael Van Canneyt wrote:
> > >>
> > >
> > >>This is not correct, it makes sysutils dependent on (g)libc and  
> > >>that is not
> > >>allowed. The correct way of doing this is to make it a separate unit
> > >>that links to libc, and fills all variables in it's initialization  
> > >>section.
> > >Ok. But where in rtl place this unit in the uses clause?
> > 
> > Nowhere. You'll have to manually add it to the uses-clause of your  
> > programs, like the cwstring (widestring support for unix) and cthreads  
> > (threading support for unix) units.
> Here is attached separated clocale.pp. I think that it should be placed into rtl/unix directory.
> Unit is tested only in Linux environment, but I assume that on other unices
> will be necessary to add some $IFDEFs.
> 
> Finally a little question. I'am here new, do not know context and my
> english is bad. But why rtl/win/sysutils.pp can depend on windows and
> rtl/unix/sysutils.pp cannot depend on libc?

Because on windows you know what is there and what not. Microsoft keeps
everything reasonly stable and backwards compatible. There is also only 1
architecture to support (well, now it is 2)

On Linux (or other unixes), libc is commonly glibc, but sometimes not, 
it is different on all CPU platforms, and often breaks backwards 
compatibility. We would be continuously play catch-up with the libc team.

So the rule is that we only rely on direct Kernel calls, which does stay
reasonably backwards (or forwards, whatever you want to call it) compatible.

Michael.