[fpc-pascal] FormatSettings not updated in Linux

[Jonas Maebe]

On 02/01/15 15:59, Jeppe Græsdal Johansen wrote:
> Den 02-01-2015 kl. 15:07 skrev Jonas Maebe:
>> 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,

Our basic "manager" units are independent of Linux flavours and should
not introduce any dependencies on a particular flavour or version of Linux.

> but relying on GNU tools and libraries is a pain
> point on Windows and for crosscompiling in general.

We have never relied on GNU libraries on Windows, and I didn't mean to
imply that we should. On Windows, we do however rely on standard OS
library functionality for threading, localisation etc rather than
implementing it ourselves. That's what I'm in favour of.

As to assemblers/linkers: in the compiler, the internal assemblers and
linkers are optional, so there it doesn't really bother me.

> 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.

You don't have to build a bunch of C. You copy over the libraries from
the Unix system you want to deploy on. If you don't have access to such
a system, then you can't test your program either and you have bigger
problems than a lack of libraries.

> 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 :)

I've had major problems with the integrated object writer of fcl-res
both with the AIX port in the past and now with the Darwin/AArch64 port.
It's not because its architecture is bad (it's not), but because it's a
lot of fiddling with low level stuff for which barely any debugging
tools exist, and for some details also documentation. It's just
completely wasted time and effort on my part that I could have spent on
doing useful things.

And to top it off, you'll still need the libraries and cross-binutils
(to the extent that they exist) for both targets, because neither Apple
nor IBM supports syscall compatibility across OS versions (libc is their
"system call interface"), and maintaining a binary writer and linker for
Apple's ever changing stuff would be more or less a full time job by
itself (maybe for AIX it would be more doable).

> It just need some testing on a wider scale for all the bumps to be
> ironed out.

If you never add new targets and your existing targets stay completely
static, maybe. Otherwise you keep encountering new bumps because things
change slightly, or you have to implement support for new targets, which
in turn also adds new bumps.


Jonas