Michael,
I suppose it would be possible to create an FPC compiler running on
ARM/Linux and creating ARM code.
FreePascal 2.2.2 had a ARM/Linux compiler release. I have a 922 KB
"Hello World" example (compiler and everything) minimal distribution on
this page:
http://www.turbocontrol.com/
Am 06.05.2010 12:46, schrieb Graeme Geldenhuys:
> On 6 May 2010 12:38, Michael Schnell wrote:
>>
>> was if Lazarus itself can successfully compile itself so that the
>> resulting Lazarus IDE runs with QT.
>
> Yes. Use the menu: "Tools > Configure Build Lazarus" and select Qt as
> the widgetset.
Great !
Thanks.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 05/06/2010 12:43 PM, Henry Vermaak wrote:
> Under the screenshots section of the qt wiki page, there are links to
> images of the ide compiled for qt running on linux and macosx.
> Perhaps you missed that?
>
So Lazarus might run on your Arm/Linux/QT.
Thanks !
-Michael
_
On 6 May 2010 12:38, Michael Schnell wrote:
>
> was if Lazarus itself can successfully compile itself so that the
> resulting Lazarus IDE runs with QT.
Yes. Use the menu: "Tools > Configure Build Lazarus" and select Qt as
the widgetset. You still need to install the Qt library, Qt developer
libr
On 6 May 2010 11:38, Michael Schnell wrote:
> On 05/06/2010 12:32 PM, Henry Vermaak wrote:
>> On 6 May 2010 11:23, Michael Schnell wrote:
>>
>>> Can Lazarus be built for QT ?
>>>
>> http://wiki.lazarus.freepascal.org/Qt_Interface
>>
> Of course Lazarus can create programs for the QT Interface. Th
On 05/06/2010 12:32 PM, Henry Vermaak wrote:
> On 6 May 2010 11:23, Michael Schnell wrote:
>
>> Can Lazarus be built for QT ?
>>
> http://wiki.lazarus.freepascal.org/Qt_Interface
>
Of course Lazarus can create programs for the QT Interface. The question
was if Lazarus itself can success
On 6 May 2010 11:23, Michael Schnell wrote:
> On 05/06/2010 10:37 AM, Henry Vermaak wrote:
>> This has been done by several people. ARM devices are usually not
>> that powerful (at least not the boards I have), so native building
>> takes very long.
>>
> Many ARM devices run at more than 500 MHz,
On 05/06/2010 10:37 AM, Henry Vermaak wrote:
> This has been done by several people. ARM devices are usually not
> that powerful (at least not the boards I have), so native building
> takes very long.
>
Many ARM devices run at more than 500 MHz, even about 1 GHz is not
uncommon nowadays.
Debian
Graeme Geldenhuys schrieb:
> Vincent Snijders het geskryf:
>> A cross compiler can create a runnable lazarus compiler, it just doesn't
>> actually run win64 code, when creating it, so it tests the win64
>> capabilities of the compiler less.
>
> Exactly what I wanted to say.
Believe me, I test
On 6 May 2010 09:08, Michael Schnell wrote:
> BTW.: (slightly off-topic)
>
> I suppose it would be possible to create an FPC compiler running on
> ARM/Linux and creating ARM code.
This has been done by several people. ARM devices are usually not
that powerful (at least not the boards I have), so
Vincent Snijders het geskryf:
>
> A cross compiler can create a runnable lazarus compiler, it just doesn't
> actually run win64 code, when creating it, so it tests the win64
> capabilities of the compiler less.
Exactly what I wanted to say.
[ Vincent, we actually agree on something! :-) ]
BTW.: (slightly off-topic)
I suppose it would be possible to create an FPC compiler running on
ARM/Linux and creating ARM code.
Do you think it could be possible to create a full featured completely
native ARM/Linux based Lazarus IDE including native debugging ?
If yes, a binary distribution of
Brad Campbell schreef:
Jonas Maebe wrote:
On 04 May 2010, at 19: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 because I think that to make sure it can compile Laza
Jonas Maebe schreef:
On 04 May 2010, at 19: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 because I
think that to make sure it can compile Lazarus correctly, it has
Jonas Maebe wrote:
On 04 May 2010, at 19: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 because I
think that to make sure it can compile Lazarus correctly, it has t
On 04 May 2010, at 19: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
> because I think that to make sure it can compile Lazarus correctly, it has to
> be able to
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
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:
> 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
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
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 -
___
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 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 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 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.
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
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
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.
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-
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
>
> 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
> 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
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
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 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
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, 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: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 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
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 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 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: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 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 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 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 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: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 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,
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, 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
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 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: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 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 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 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, 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 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
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
> @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
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
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 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
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: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
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 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
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 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:
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
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: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
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
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
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
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 contain both 32 & 64-bit versions),
or create a
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 contain both 32 & 64-bit versions),
> or create a new Win64 fold
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 contain both 32 & 64-bit versions),
or create a new Win64 folder for 64-bit versions.
--
Regards,
- Graeme -
80 matches
Mail list logo