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
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/sysutil
On 1/2/15, 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
On 02/01/15 14:55, Bart wrote:
> On 1/2/15, 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
>> > thre
Hi,
One of my project just started fail on compilation. Other projects compile
fine. In lazarus message window I get only "Error: Error while linking".
Normally in that case, more details were printed like "missing -lib" etc
but here I get only "error while linking". Tried cleanup output dir but n
On 02/01/15 15:31, Krzysztof wrote:
> One of my project just started fail on compilation. Other projects
> compile fine. In lazarus message window I get only "Error: Error while
> linking". Normally in that case, more details were printed like "missing
> -lib" etc but here I get only "error while l
On Fri, 02 Jan 2015 15:39:39 +0100
Jonas Maebe wrote:
> On 02/01/15 15:31, Krzysztof wrote:
> > One of my project just started fail on compilation. Other projects
> > compile fine. In lazarus message window I get only "Error: Error while
> > linking". Normally in that case, more details were prin
Den 02-01-2015 kl. 15:07 skrev Jonas Maebe:
On 02/01/15 14:55, Bart wrote:
On 1/2/15, 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
2015-01-02 15:51 GMT+01:00 Mattias Gaertner :
>
> To see all messages in Lazarus use the popup menu of the
> Messages window (right click).
>
Thank you Mattias! lgmime-2.6 was hidden in lazarus message window. Problem
solved
___
fpc-pascal maillist -
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 stren
On Fri, 2 Jan 2015 16:13:26 +0100
Krzysztof wrote:
> 2015-01-02 15:51 GMT+01:00 Mattias Gaertner :
>
> >
> > To see all messages in Lazarus use the popup menu of the
> > Messages window (right click).
> >
>
> Thank you Mattias! lgmime-2.6 was hidden in lazarus message window. Problem
> solved
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:
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
>>> reimplementin
On Fri, 2 Jan 2015, Jonas Maebe wrote:
On 02/01/15 14:55, Bart wrote:
On 1/2/15, 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
Does it make sense to use PtrInt instead of Integer for optimization or
code size reasons?
In other words, does the compiler generate faster or smaller code in 64-bit
CPUs for the native integer size?
Does it depend on architecture?
Regards,
Juha
___
fpc
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
Am 02.01.2015 um 19:31 schrieb Juha Manninen:
> Does it make sense to use PtrInt instead of Integer for optimization or code
> size reasons?
Hard to say, but I wouldn't expect a benefit because bigger data types means
also more cache pollution.
> In other words, does the compiler generate faste
On 02/01/15 21:16, Florian Klämpfl wrote:
> Am 02.01.2015 um 19:31 schrieb Juha Manninen:
>> Does it make sense to use PtrInt instead of Integer for optimization or code
>> size reasons?
>
> Hard to say, but I wouldn't expect a benefit because bigger data types means
> also more cache pollution.
Am 02.01.2015 um 21:34 schrieb Jonas Maebe:
> On 02/01/15 21:16, Florian Klämpfl wrote:
>> Am 02.01.2015 um 19:31 schrieb Juha Manninen:
>>> Does it make sense to use PtrInt instead of Integer for optimization or
>>> code size reasons?
>>
>> Hard to say, but I wouldn't expect a benefit because big
On 02/01/15 22:12, Florian Klämpfl wrote:
> Am 02.01.2015 um 21:34 schrieb Jonas Maebe:
>> > And except for AArch64, where 32 bit will, in principle, also be more
>> > efficient than 64 bit in all cases. It can even use the lower 8/16/32
>> > bit of a register as index in a memory references and si
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
re
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
Am 02.01.2015 um 23:02 schrieb Jonas Maebe:
> On 02/01/15 22:12, Florian Klämpfl wrote:
>> Am 02.01.2015 um 21:34 schrieb Jonas Maebe:
And except for AArch64, where 32 bit will, in principle, also be more
efficient than 64 bit in all cases. It can even use the lower 8/16/32
bit of a
23 matches
Mail list logo
