[fpc-pascal] FormatSettings not updated in Linux

Michael Van Canneyt michael at freepascal.org
Fri Jan 2 19:29:07 CET 2015



On Fri, 2 Jan 2015, Jonas Maebe wrote:

> On 02/01/15 14:55, Bart wrote:
>> On 1/2/15, Jonas Maebe <jonas.maebe at elis.ugent.be> wrote:
>>
>>>> The reason is that by design, FPC-compiled programs for Linux do not
>>>> depend on libc and clocale introduces a dependency on libc. It's the
>>>> same reason why you have to use the cthreads unit to get a functional
>>>> thread manager under Linux.
>> We need fplocale unit maybe?
>> I tried long time ago, but failed miserably.
>
> It would probably also significantly increase the size of the binary. We
> now have an fpwidestring unit, but if you want to have the same
> functionality as with cwstring (including support for Japanese and
> Chinese character sets), it increases the size of your binary by several
> megabytes (or you have to supply several megabytes of code page
> conversion tables). As a result, I doubt it will be very popular.
>
> After just having spent 2 days debugging an issue in fcl-res that could
> have been avoided by just using the assembler instead of by
> reimplementing object writers from scratch, I'm even more strengthened
> in my conviction that it is a mistake trying to implement and
> reimplement everything just to make cross-compiling somewhat easier, or
> to avoid libc version compatibility problems on Linux that were common
> 15 years ago.

I will not argue about the linker and assembler, but
I am not sure your libc argument is quite correct.

It is about binary compatibility. If gnu C lib devs change the alignment of some struct, 
they just do it. All C programs can be recompiled, relinked, and that is it.
Some client libs make this problem even bigger (apache, mysql, probably others).

Pascal programmers are in a bigger predicament.
A Free Pascal programmer would need to wait till we update our import headers 
of libc, make a new release and so on. It creates a bigger maintenance problem 
and ties us to the libc release cycle.

By contrast, like Microsoft with the Windows API, the Linux kernel people maintain 
a much stricter backward compatibility for userland tools.

So, from my point of view, not relying on Libc and using direct kernel access 
on Linux is the best option.

That you miss out on some userland functionality of Libc such as localization, 
and for this need to rely on glue code units, is something that I take into the 
bargain.

Michael.



More information about the fpc-pascal mailing list