[fpc-pascal] FormatSettings not updated in Linux
Jeppe Græsdal Johansen
jeppe at j-software.dk
Fri Jan 2 15:59:52 CET 2015
Den 02-01-2015 kl. 15:07 skrev Jonas Maebe:
> 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 pretty much disagree on all points. Maybe it's nice if you sit on some
popular flavour Linux, but relying on GNU tools and libraries is a pain
point on Windows and for crosscompiling in general.
For library components such as cthreads, cwstring, clocale, etc. it's
nice to have a choice whether you want libc provided units. We have
those already, and they mostly seem to work(?). But I think it would be
nice to have both, so you could at least have a choice whether you would
want to skip right over building a bunch of C.
For object writers and assemblers, sure. There are probably lots of
problems, but I haven't had any big issues on Windows with FPC for soon
a decade. I hope that can become the case for ARM/Linux/Embedded too soon :)
It just need some testing on a wider scale for all the bumps to be
More information about the fpc-pascal