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.ma...@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.
Jonas
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
ironed out.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
