Contrary to what written in docs, DefaultFormatSettings aren't adjusted to the current locale in Linux at the startup of an application both on fpc 2.6.4 and on fpc 2.7.1.
One is forced to explicitly add "clocale" in the uses section of the application, in order to get the proper locale settings. Did someone forget to add cloclale to the uses section of /rtl/unix/sysutils.pp or there's another reason for this?

Giuliano

Giuliano Colla wrote

Contrary to what written in docs, DefaultFormatSettings aren't adjusted to the current locale in Linux at the startup of an application both on fpc 2.6.4 and on fpc 2.7.1.

Where is this written? At least
http://www.freepascal.org/docs-html/rtl/sysutils/defaultformatsettings.html doesn't say anything like that.

One is forced to explicitly add "clocale" in the uses section of the application, in order to get the proper locale settings. Did someone forget to add cloclale to the uses section of /rtl/unix/sysutils.pp or there's another reason for this?

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.

Jonas

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

Bart

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

Den 02-01-2015 kl. 15:07 skrev Jonas Maebe:

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.

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.

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

Il 02/01/2015 13:47, Jonas Maebe ha scritto:

See here:

http://www.freepascal.org/docs-html/rtl/sysutils/shortdaynames.html

Giuliano

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

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

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.

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

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

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.

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.

In our previous episode, Jonas Maebe said:

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 do like the object writers mostly from a support viewpoint. The FPC as-a-system is a lot more equal and deterministic across installations, and one or several dimensions from versioning matrix disappear. Moreover there is hope to avoid having long time unfixable issues like:

http://www.freepascal.org/faq.var#unix-ld219

The libc discussion is IMHO different. Last week, the FPC_USE_LIBC became 11 years old. There are hardly user experiences on Linux. (admitted, usually some bugs have accumulated causing a first movers disadvantage).

Frankly, I guess nobody is really that interested, and the current solution works fine enough.

Noting that I asked about something related to this in fpc-devel the other day, I assure you that I feel your pain.

It's not just that. Some of the GNU/C crowd make the confident assertion that a bug-free compiler /cannot/ generate code that breaks alignment, despite the fact that the majority whine if they can't pack their data structures exactly how they want.

I'm trying to wean my colleagues off SPARC, I'm no longer convinced that the pain is worth it.

========================================================================

Does anybody have any Debian/multiarch issues that they want to air? I seem to have caught the attention of one of the admins.

-----8<-----

> Multiarch obviously introduces its own problems.

Could you provide some examples? Multiarch seems unrelated to the portability of Debian. In fact I think it has a more positive impact on portability, since for less portable software you can workaround that by installing binaries from another architecture and running them directly where possible or use qemu-user to emulate them where not possible.
----->8-----