Den 02-01-2015 kl. 15:07 skrev Jonas Maebe:
On 02/01/15 14:55, Bart wrote:
On 1/2/15, Jonas Maebe jonas.ma...@elis.ugent.be 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
On 02/01/15 14:55, Bart wrote:
On 1/2/15, Jonas Maebe jonas.ma...@elis.ugent.be 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
On Fri, 02 Jan 2015 15:39:39 +0100
Jonas Maebe jonas.ma...@elis.ugent.be 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
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
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 linking.
On Fri, 2 Jan 2015, Jonas Maebe wrote:
On 02/01/15 14:55, Bart wrote:
On 1/2/15, Jonas Maebe jonas.ma...@elis.ugent.be 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
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
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 faster
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
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.
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 not
On 1/2/15, Jonas Maebe jonas.ma...@elis.ugent.be 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.
On Fri, 2 Jan 2015 16:13:26 +0100
Krzysztof dib...@wp.pl wrote:
2015-01-02 15:51 GMT+01:00 Mattias Gaertner nc-gaert...@netcologne.de:
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
2015-01-02 15:51 GMT+01:00 Mattias Gaertner nc-gaert...@netcologne.de:
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
___
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
___
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
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
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.
In
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 bigger data
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
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
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 register as
23 matches
Mail list logo
