FormatSettings not updated in Linux

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

FormatSettings not updated in Linux

Giuliano Colla
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

Project planning question: when it's 90% done, are we halfway or not yet?

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: FormatSettings not updated in Linux

Jonas Maebe-2
On 02/01/15 13:35, 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
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: FormatSettings not updated in Linux

Bart-48
On 1/2/15, Jonas Maebe <[hidden email]> 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
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: FormatSettings not updated in Linux

Jonas Maebe-2
On 02/01/15 14:55, Bart wrote:
> On 1/2/15, Jonas Maebe <[hidden email]> 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
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: FormatSettings not updated in Linux

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

> On 02/01/15 14:55, Bart wrote:
>> On 1/2/15, Jonas Maebe <[hidden email]> 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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: FormatSettings not updated in Linux

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

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: FormatSettings not updated in Linux

Giuliano Colla
In reply to this post by Jonas Maebe-2
Il 02/01/2015 13:47, Jonas Maebe ha scritto:
> On 02/01/15 13:35, 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.

See here:

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

Giuliano

--
Giuliano Colla

Project planning question: when it's 90% done, are we halfway or not yet?

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: FormatSettings not updated in Linux

Florian Klämpfl
In reply to this post by Jonas Maebe-2
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.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: FormatSettings not updated in Linux

Michael Van Canneyt
In reply to this post by Jonas Maebe-2


On Fri, 2 Jan 2015, Jonas Maebe wrote:

> On 02/01/15 14:55, Bart wrote:
>> On 1/2/15, Jonas Maebe <[hidden email]> 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 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.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: FormatSettings not updated in Linux

Marco van de Voort
In reply to this post by Jonas Maebe-2
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

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

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.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: FormatSettings not updated in Linux

Mark Morgan Lloyd-5
In reply to this post by Florian Klämpfl
Florian Klämpfl wrote:

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

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

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: FormatSettings not updated in Linux

Mark Morgan Lloyd-5
In reply to this post by Michael Van Canneyt
Michael Van Canneyt wrote:
> On Fri, 2 Jan 2015, Jonas Maebe wrote:

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

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

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal