[fpc-pascal] FormatSettings not updated in Linux

[Florian Klämpfl]

Am 02.01.2015 um 16:43 schrieb 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.

I still doubt that it is possible to build a glibc-linked linux binary like the compiler which runs
on all linux flavours still being in support. Just look at the pain with the IDE on linux. Bottom
line in the bug tracker and on the mailing lists: if the provided IDE binary does not work for you,
just do not use it, we cannot help you (I know, in this case we could switch to an external gdb and
get rid of glibc but this proves only the point).

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

Yes, because Windows offers an reasonable OS interface for this functionality.

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

It sounds simple like this, yes, but as far as I remember I never succeeded to build any fpc program
depending on glibc for arm linux by cross compiling from windows. I guess scamp and masta can tell
stories about this.

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

At least on Windows the internal assembler/linker are still time safers.

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

Actually having a Apple binary writer would FPC enable finally to cross-compile to Mac OS X ;)

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

For me, I do not want to miss the assembler/linker for i386/x86-64 for windows, especially because I
can fix bugs easily in them which is not the case for binutils.