Vincent Snijders schrieb:
> Henry Vermaak schreef:
>> On 3 May 2010 23:49, Graeme Geldenhuys wrote:
>>> Hi,
>>>
>>> Going to SourceForge to download the Win64 version of FPC, you have to
>>> navigate into the Win32 folder?! Surely it would make more sense to
>>> rename Win32 to Windows (so it can
Florian Klaempfl het geskryf:
>
> Even more: the win64 package is an add on to the win32 installer.
Why is there no native Win64 version? See comments from the following URL.
You need i386-win32, to use the win64 version. It seems there is only a
cross compiler available, no native win64 execut
Graeme Geldenhuys schrieb:
> Florian Klaempfl het geskryf:
>> Even more: the win64 package is an add on to the win32 installer.
>
>
> Why is there no native Win64 version?
Because it has no advantage over a win32 executable (it is very unlikely
that the compiler needs more than 2 or 3 GB and a
Hi,
Michael announced on 6 Mar that the FPC 2.4.0 docs have been update
due to the new docs for the DB unit. Well, looking on SourceForge
(link found from Free Pascal website), the last docs updated was from
2009-12-30. So they are still the old docs from original FPC 2.4.0
release date. Could som
On 4 May 2010 10:11, Florian Klaempfl wrote:
>
> Because it has no advantage over a win32 executable (it is very unlikely
> that the compiler needs more than 2 or 3 GB and a native win64 compiler
> is slower due to bigger memoy footprint) and because it would require
> additional release preparati
On 4 May 2010 10:19, Graeme Geldenhuys wrote:
>
> http://www.freepascal.org/down/docs/docs-ftp.freepascal.org.var
Also the .zip PDF download link says 6.1MB download, when in fact it
is 6.8 MB (7100651 bytes). ;-)
ftp://ftp.freepascal.org/pub/fpc/dist/2.4.0/docs/doc-pdf.zip
--
Regards,
On 4 May 2010 10:11, Florian Klaempfl wrote:
>
> Because it has no advantage over a win32 executable (it is very unlikely
> that the compiler needs more than 2 or 3 GB and a native win64 compiler
> is slower due to bigger memoy footprint) and because it would require
> additional release preparati
On Tue, 4 May 2010, Graeme Geldenhuys wrote:
On 4 May 2010 10:11, Florian Klaempfl wrote:
Because it has no advantage over a win32 executable (it is very unlikely
that the compiler needs more than 2 or 3 GB and a native win64 compiler
is slower due to bigger memoy footprint) and because it
Hi Michael,
ftp://ftp.freepascal.org/pub/fpc/dist/2.4.0/docs/
The FCL documentation for the DB unit has some formatting mistakes (pdf
version of docs). In the PDF document, some code examples do not wrap, and
simply go of the edge of the page. This happens onscreen and when printed.
I used Adob
On 04 May 2010, at 09:46, Michael Van Canneyt wrote:
> Cross-compiling is OK for small mobile devices, but not for mature platforms
> and
> daily development.
Why not?
Jonas___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freep
On Tue, 4 May 2010, Graeme Geldenhuys wrote:
Hi Michael,
ftp://ftp.freepascal.org/pub/fpc/dist/2.4.0/docs/
The FCL documentation for the DB unit has some formatting mistakes (pdf
version of docs). In the PDF document, some code examples do not wrap, and
simply go of the edge of the page. Th
Jonas Maebe het geskryf:
>
>> Cross-compiling is OK for small mobile devices, but not for mature platforms
>> and
>> daily development.
>
> Why not?
Because it doesn't always work.
I run 64-bit FPC under Linux. I have cross-compiled 32-bit Linux and 32-bit
Windows executables. The compilation
On Tue, 4 May 2010, Jonas Maebe wrote:
On 04 May 2010, at 09:46, Michael Van Canneyt wrote:
Cross-compiling is OK for small mobile devices, but not for mature platforms and
daily development.
Why not?
Because of 2 reasons:
1. you can't debug properly. And with that I mean an efficient
Michael Van Canneyt het geskryf:
>
> Installing 32-bit apps on 64-bit linux is asking for problems,
Simply running apps, I haven't experienced any problems. Cross-compiling
32-bit (linux and windows) apps, I have had issues.
> Personally, I would simply recompile a 64-bit FPC for windows
> if I
On 04 May 2010, at 10:16, Graeme Geldenhuys wrote:
> Jonas Maebe het geskryf:
>>
>>> Cross-compiling is OK for small mobile devices, but not for mature
>>> platforms and
>>> daily development.
>>
>> Why not?
>
> Because it doesn't always work.
>
> I run 64-bit FPC under Linux. I have cross-c
On Tue, 4 May 2010, Jonas Maebe wrote:
On 04 May 2010, at 10:16, Graeme Geldenhuys wrote:
Jonas Maebe het geskryf:
Cross-compiling is OK for small mobile devices, but not for mature platforms and
daily development.
Why not?
Because it doesn't always work.
I run 64-bit FPC under Linu
On 04 May 2010, at 10:44, Michael Van Canneyt wrote:
> I had the same experience as Graeme. Admittedly, a couple of years ago.
> I never found out why the generated binaries did not work. They simply
> refused to run, and immediatly exited. (both from explorer and command-line
> prompt)
Again: I
Jonas Maebe het geskryf:
>
> Again: I've never seen a previous post or bug report about this.
For me, it occurred with the 2.4.0 compiler (my issue was back in January).
I'll try the cross-compiling again, after all, if it works, it will save me
a huge amount of time when we do release builds of
On Tue, 4 May 2010, Jonas Maebe wrote:
On 04 May 2010, at 10:44, Michael Van Canneyt wrote:
I had the same experience as Graeme. Admittedly, a couple of years ago.
I never found out why the generated binaries did not work. They simply
refused to run, and immediatly exited. (both from explor
> @Florian
> I believe you develop mostly under Windows. Maybe the FPC slowness should
> be resolved before Delphi releases a 64-bit compiler?
This cannot be resolved. A 64-Bit compiler has a bigger memory footprint
because FPC uses a lot of pointers and pointers simply double in size on
a 64 bit
Graeme Geldenhuys schrieb:
> On 4 May 2010 10:11, Florian Klaempfl wrote:
>> Because it has no advantage over a win32 executable (it is very unlikely
>> that the compiler needs more than 2 or 3 GB and a native win64 compiler
>> is slower due to bigger memoy footprint) and because it would require
On Tue, 4 May 2010, Florian Klaempfl wrote:
@Florian
I believe you develop mostly under Windows. Maybe the FPC slowness should
be resolved before Delphi releases a 64-bit compiler?
This cannot be resolved. A 64-Bit compiler has a bigger memory footprint
because FPC uses a lot of pointers and
On Tue, May 4, 2010 at 6:40 AM, Florian Klaempfl wrote:
>> @Florian
>> I believe you develop mostly under Windows. Maybe the FPC slowness should
>> be resolved before Delphi releases a 64-bit compiler?
>
> This cannot be resolved. A 64-Bit compiler has a bigger memory footprint
> because FPC uses
On 04 May 2010, at 12:51, Michael Van Canneyt wrote:
> The i386 version of the compiler is simply much more optimized as the 64-bit
> version (as are all FPC-generated binaries).
That was true pre-2.4.0, but as of 2.4.0 the assembler optimiser is no longer
enabled by default on i386 (and it did
On Tue, 4 May 2010, Jonas Maebe wrote:
On 04 May 2010, at 12:51, Michael Van Canneyt wrote:
The i386 version of the compiler is simply much more optimized as the 64-bit
version (as are all FPC-generated binaries).
That was true pre-2.4.0, but as of 2.4.0 the assembler optimiser is no long
On 04 May 2010, at 13:56, Jonas Maebe wrote:
> i386->i386 compiler compiling itself:
> user 0m8.180s
> sys 0m0.694s
>
> x86-64->i386 compiler compiling itself:
> user 0m8.096s
> sys 0m0.736s
>
> So at least on Mac OS X there is no real speed difference between the two.
... on my Core 2 D
On 04 May 2010, at 13:58, Michael Van Canneyt wrote:
> On Linux, there was a major difference between i386 and x64_64
> compilers when running a "make cycle'. But I admit that my last test was
> definitely from before 2.4.0.
"make cycle" not only tests the speed of the compiler code, but also o
On 04 May 2010, at 14:05, Jonas Maebe wrote:
> On 04 May 2010, at 13:58, Michael Van Canneyt wrote:
>
>> On Linux, there was a major difference between i386 and x64_64
>> compilers when running a "make cycle'. But I admit that my last test was
>> definitely from before 2.4.0.
>
> "make cycle"
On 04 May 2010, at 13:56, Jonas Maebe wrote:
> i386->i386 compiler compiling itself:
> user 0m8.180s
> sys 0m0.694s
>
> x86-64->i386 compiler compiling itself:
> user 0m8.096s
> sys 0m0.736s
And i386->i386 compiler compiling itself (again using the same options), but
with the starting co
On Tue, 4 May 2010, Jonas Maebe wrote:
On 04 May 2010, at 13:56, Jonas Maebe wrote:
i386->i386 compiler compiling itself:
user0m8.180s
sys 0m0.694s
x86-64->i386 compiler compiling itself:
user0m8.096s
sys 0m0.736s
And i386->i386 compiler compiling itself (again using the
Florian Klaempfl het geskryf:
>
> No. It actually proves that using 32 bit executables (and installer
> packages!) on 64 bit linux is a pain. On windows, we can cover with two
> installers Win2k (no idea about Win98) up to Win7 regardless if 32 or 64
> bit, on linux things are much more compilcate
On Tue, 4 May 2010, Graeme Geldenhuys wrote:
Florian Klaempfl het geskryf:
No. It actually proves that using 32 bit executables (and installer
packages!) on 64 bit linux is a pain. On windows, we can cover with two
installers Win2k (no idea about Win98) up to Win7 regardless if 32 or 64
bit,
On 4 May 2010 14:12, Andrew Brunner wrote:
>
> How is it possible that under *nix I'm able to live with the memory
> performance of 64bit FPC but cannot with Windows?
This is the exact question I asked Florian, but he side-tracked the
answer. [or I haven't read a new reply yet].
--
Regards,
On 04 May 2010, at 14:52, Michael Van Canneyt wrote:
> Summarizing we can state that code execution is not significantly different
> between 32/64 bit, but the binary and memory sizes make the apps load/start
> slower.
>
> Correct ?
Not from my experience with the compiler binary on Mac OS X.
On 4 May 2010 14:55, Graeme Geldenhuys wrote:
>
> It's just the stupid .RPM and .DEB packages that prevent installation, due
> to other external dependencies (eg: pulling in MySQL or Firebird database
> libraries etc). I'm pretty confident a binary FPC executable can run on
> much older Linux dist
On 4 May 2010 16:04, Michael Van Canneyt wrote:
>
> We offer a .tar.gz for download, so what is the problem ?
> No-one is forced to use rpm or .deb files ?
I don't have a problem, but it sounded like Florian has (or I
misunderstood him). From what I understood, he stated that deployment
is easier
On 04 May 2010, at 15:07, Graeme Geldenhuys wrote:
> On 4 May 2010 14:12, Andrew Brunner wrote:
>>
>> How is it possible that under *nix I'm able to live with the memory
>> performance of 64bit FPC but cannot with Windows?
>
> This is the exact question I asked Florian, but he side-tracked the
On 04 May 2010, at 15:14, Jonas Maebe wrote:
> The above is a correct and full answer to the question why we distribute a
> native x86-64 compiler for Linux even if it is believed to be slower than an
> i386->x86-64 cross-compiler, and why we do not do this for Linux.
... and why we do not do
On 4 May 2010 16:14, Jonas Maebe wrote:
> b) we only distribute an i386->x86-64 cross-compiler because on Windows the
> problem that exists under Linux does not exist, and there is no advantage to
> having a native x86-64 Windows compiler (at best it will be just as fast as a
> i386->x86-64 cro
On 04 May 2010, at 15:29, Graeme Geldenhuys wrote:
> So to be able to compile Win64 apps, we need two installations. The
> Win64 download (17MB) and the i386 download (35MB).
>
> * now installation is more complex than it needs to be. It now
> requires two FPC versions.
I have not yet seen bug
On Tue, May 4, 2010 at 9:17 AM, Jonas Maebe wrote:
> ... and why we do not do this *for Windows*.
I disagree. I think some thought should go into having a
multi-threaded system for building projects. If we had a dependency
tree worker threads could transverse the tree and compile near
instant
On 04 May 2010, at 16:01, Andrew Brunner wrote:
> On Tue, May 4, 2010 at 9:17 AM, Jonas Maebe wrote:
>
>> ... and why we do not do this *for Windows*.
>
> I disagree. I think some thought should go into having a
> multi-threaded system for building projects. If we had a dependency
> tree work
Graeme Geldenhuys schrieb:
> On 4 May 2010 16:14, Jonas Maebe wrote:
>> b) we only distribute an i386->x86-64 cross-compiler because on Windows the
>> problem that exists under Linux does not exist, and there is no advantage to
>> having a native x86-64 Windows compiler (at best it will be just
On Tue, May 4, 2010 at 10:09 AM, Jonas Maebe wrote:
> Cross-compilers can be just as multi-threaded as "native" ones. This is a
> completely orthogonal feature.
>
True statement but I fear does not address the issue at hand. You
guys really need to tap talent - there's gotta be somebody here th
Graeme Geldenhuys schrieb:
> On 4 May 2010 16:04, Michael Van Canneyt wrote:
>> We offer a .tar.gz for download, so what is the problem ?
>> No-one is forced to use rpm or .deb files ?
>
> I don't have a problem, but it sounded like Florian has (or I
> misunderstood him). From what I understood,
On Tue, 4 May 2010, Andrew Brunner wrote:
On Tue, May 4, 2010 at 10:09 AM, Jonas Maebe wrote:
Cross-compilers can be just as multi-threaded as "native" ones. This is a
completely orthogonal feature.
True statement but I fear does not address the issue at hand. You
guys really need to ta
On Tue, 4 May 2010, Florian Klaempfl wrote:
Graeme Geldenhuys schrieb:
On 4 May 2010 16:04, Michael Van Canneyt wrote:
We offer a .tar.gz for download, so what is the problem ?
No-one is forced to use rpm or .deb files ?
I don't have a problem, but it sounded like Florian has (or I
misund
On 04 May 2010, at 16:17, Andrew Brunner wrote:
> On Tue, May 4, 2010 at 10:09 AM, Jonas Maebe
> wrote:
>
>> Cross-compilers can be just as multi-threaded as "native" ones. This is a
>> completely orthogonal feature.
>>
> True statement but I fear does not address the issue at hand.
"The is
> Speeding up compilation is always nice (and if anyone wants to dive into the
> unit loading logic, solve its existing problems and make it multi-threading
> safe, I'd be delighted -- I already spent several weeks on trying, and
> largely failing, to merely solve particular bugs in it), but I f
>
> IMO: Native debugging under x64 would be the number 1 reason or
> justification for doing the work.
There is a native gdb for win64. However, I never got a working win64
textmode ide with integrated debugger, so this is no reason.
> The second would be for
> distribution.
Yes, it increas
On 4 May 2010 18:33, Florian Klaempfl wrote:
>
> If anybody builds win64 installers he should also take care of people
> installing the native win32 and native win64 installer and a wince cross
> installer, nice nasty problem to solve :)
Contradicting your self. :-) And here I thought you said a
On 04 May 2010, at 16:47, Andrew Brunner wrote:
> Native debugging under x64 would be the number 1 reason or
> justification for doing the work.
A cross-compiler or native compiler has absolutely nothing to do with debugging
(unless you debug the compiler itself). Binaries generated by a cross-
Graeme Geldenhuys schrieb:
> On 4 May 2010 18:33, Florian Klaempfl wrote:
>> If anybody builds win64 installers he should also take care of people
>> installing the native win32 and native win64 installer and a wince cross
>> installer, nice nasty problem to solve :)
>
> Contradicting your self.
Hi!
On 04.05.2010 16:14, Graeme Geldenhuys wrote:
On 4 May 2010 16:04, Michael Van Canneyt wrote:
We offer a .tar.gz for download, so what is the problem ?
No-one is forced to use rpm or .deb files ?
I don't have a problem, but it sounded like Florian has (or I
misunderstood him). From what
Jonas Maebe schreef:
On 04 May 2010, at 15:29, Graeme Geldenhuys wrote:
So to be able to compile Win64 apps, we need two installations. The
Win64 download (17MB) and the i386 download (35MB).
* now installation is more complex than it needs to be. It now
requires two FPC versions.
I don't
On 5/4/2010 11:40, Vincent Snijders wrote:
Jonas Maebe schreef:
On 04 May 2010, at 15:29, Graeme Geldenhuys wrote:
So to be able to compile Win64 apps, we need two installations. The
Win64 download (17MB) and the i386 download (35MB).
* now installation is more complex than it needs to be.
On 4 May 2010 17:27, Michael Van Canneyt wrote:
>> fpGUI probably depends as well as the fp text mode ide on glibc etc. so
>> running on older systems is pure luck.
>
> This is correct. I did some tests for this when still running SuSE.
> Only binaries that do not depend on LibC will run on old li
On 4 May 2010 19:38, Florian Klaempfl wrote:
>
> Ever tried to install the 32 bit and 64 bit native linux tar
> installer on one system?
Yes, I have both on my 64-bit Ubuntu 8.04.2 system at work. It was
easier to setup that cross-compiling (at least it was for me), but
installing native FPC's i
On 4 May 2010 20:18, Sven Barth wrote:
> Microsoft hadn't done this). Thus there is no real need to ship a 64 bit
> version of the compiler.
This still seems a bit short-sighted to me. It now simply places the
burden on the developer to compile there own 64-bit version of FPC -
but I guess that's
On 4 May 2010 20:40, Vincent Snijders wrote:
>
> I don't know where to add this exactly in this thread, but the win64 version
> of Lazarus includes a native win64 version of the compiler. It is done
Kudos to the Lazarus team! :-)
--
Regards,
- Graeme -
___
Graeme Geldenhuys schrieb:
> On 4 May 2010 19:38, Florian Klaempfl wrote:
>> Ever tried to install the 32 bit and 64 bit native linux tar
>> installer on one system?
>
> Yes, I have both on my 64-bit Ubuntu 8.04.2 system at work. It was
> easier to setup that cross-compiling (at least it was for
Graeme Geldenhuys schrieb:
> So Florian and Michael, I would safely say a new binary
> created with FPC (non-gui or fpGUI based) would run perfectly fine on
> rather old Linux distros.
>
Well, even more FPC itself. This is also why we ship .tar.gzs ;) I'am
the first one to agree to ship only .tar
On 4 May 2010 22:05, Florian Klaempfl wrote:
>
> We don't ship any .tar.gz containing 2.4.1?
With my various build scrips and the 'git archive' command, I have
been creating my own "fixes" versions for months. Our "fixes" builds
created via our scripts use the latest stable release as starting
co
Graeme Geldenhuys schrieb:
> On 4 May 2010 22:05, Florian Klaempfl wrote:
>> We don't ship any .tar.gz containing 2.4.1?
>
> With my various build scrips and the 'git archive' command, I have
> been creating my own "fixes" versions for months.
I wanted only to point out that your setup is not si
You know, I had this idea and I was wondering if this is already done
or do-able...
Periodic (every hundred+milliseconds) writing of a stats file. When
fpc compiles Lazarus projects the dialog does not reflect lines until
the unit is complete. I have a project that is heavy on include files
and
65 matches
Mail list logo
