That may be true, but takes tricks. The compiler from me WILL build
trunk, because it is a trunk. I do not have much time but as I stated
before i WILL update it. It just takes a bit longer. Also, I won't do a
full .deb for it, unless some helps with that. I wasn't able to do that
yet and do
Jonas,
In that case I would advice people to use my version of 2.7.1 for the
Raspberry Pi and let me deal with any build difficulties. I am fully
aware you removed the OVERRIDEVERSIONCHECK from the documentation.
The most recently published build by me takes full advantage of most of
the
At the moment, there is not a good, publicly available, starting
compiler other than my unofficial builds.
The real starting compiler has never been public AFAIK.
Maybe the guy(s) or/and girl(s) who have done the original build for the
Raspberry Pi can shed a light on that one...
On
On 23/10/14 10:55, Thaddy de Koning wrote:
The most recently published build by me takes full advantage of most of
the features for ARMV6 EABIHF.
Plz advice on how to progress,
By never saying that people should build trunk with trunk.
Jonas
___
Which means you shut out the platform.
Which is a teaching platform.
On 10/23/2014 11:04 AM, Jonas Maebe wrote:
On 23/10/14 10:55, Thaddy de Koning wrote:
The most recently published build by me takes full advantage of most of
the features for ARMV6 EABIHF.
Plz advice on how to progress,
By
On 23/10/14 11:00, Thaddy de Koning wrote:
At the moment, there is not a good, publicly available, starting
compiler other than my unofficial builds.
The real starting compiler has never been public AFAIK.
The real starting compiler is a cross-compiler. You always have to start
using a
I know it is a cross- compiler. My builds include a (actually 2)
cross-compiler(based on my own builds 2.7.1) The original is NOT a
2.6.X build that is publicly available. That's the point.
Where is the dogfood?
Where is the starting compiler for Raspian/Debian?
Point me at that and I
On 23/10/14 11:09, Thaddy de Koning wrote:
On 10/23/2014 11:04 AM, Jonas Maebe wrote:
On 23/10/14 10:55, Thaddy de Koning wrote:
Plz advice on how to progress,
By never saying that people should build trunk with trunk.
Which means you shut out the platform.
I'm not saying you can't
On 23/10/14 11:16, Thaddy de Koning wrote:
I know it is a cross- compiler. My builds include a (actually 2)
cross-compiler(based on my own builds 2.7.1) The original is NOT a
2.6.X build that is publicly available. That's the point.
Where is the dogfood?
Where is the starting
Not for ARMV6 EABIHF
On 10/23/2014 11:23 AM, Jonas Maebe wrote:
On 23/10/14 11:16, Thaddy de Koning wrote:
I know it is a cross- compiler. My builds include a (actually 2)
cross-compiler(based on my own builds 2.7.1) The original is NOT a
2.6.X build that is publicly available. That's the
Bad practise is the only practise if knowledge about good practise is
not available.
I am fully prepared to accept you are right. In fact, in my professional
settings I would not do otherwise.
But this is a special case, for a huge platform, and somebody, somehow,
forgot about the license
On 23/10/14 11:28, Thaddy de Koning wrote:
The starting compiler is any official FPC 2.6.4 compiler that can be
downloaded from our website. With any of those compilers, you can build
both cross and native trunk compiler for any of the targets supported
only by trunk. That's how all targets
Thaddy de Koning wrote:
Not for ARMV6 EABIHF
Building for ARMV6+vfpv2 armhf is indeed a bit of a messs.
Afaict it's not possible to build a cross compiler that defaults to
armv6 ARMHF without modifying the source. With the right flags you
should be able to create a cross-compiler that is
On 10/23/2014 11:49 AM, Jonas Maebe wrote:
On 23/10/14 11:28, Thaddy de Koning wrote:
The starting compiler is any official FPC 2.6.4 compiler that can be
downloaded from our website. With any of those compilers, you can build
both cross and native trunk compiler for any of the targets
ok, but can we now please return this thread to the original subject re
2.7.1 (and 2.6.4) for rpi. TIA John
On 23 October 2014 13:41, Joost van der Sluis jo...@cnoc.nl wrote:
On 10/23/2014 11:49 AM, Jonas Maebe wrote:
On 23/10/14 11:28, Thaddy de Koning wrote:
The starting compiler is any
With this in mind, how is one supposed to go about implementing a brand
new target? Should I build a compiler from modified release branch, then
use that to compile the modified trunk?
On 10/23/2014 5:04 AM, Jonas Maebe wrote:
By never saying that people should build trunk with trunk.
In our previous episode, Thaddy de Koning said:
Bad practise is the only practise if knowledge about good practise is
not available.
Should I change cursive to bold here then?
http://www.stack.nl/~marcov/buildfaq/#toc-Section-2.2
___
fpc-devel
On 23/10/14 16:21, Vsevolod Alekseyev wrote:
With this in mind, how is one supposed to go about implementing a brand
new target? Should I build a compiler from modified release branch, then
use that to compile the modified trunk?
You build a cross-compiler for your brand new target from the
If you follow the steps in that post, you'll get the following:
makefile:197: *** The Makefile doesn't support target i386-winphonesim,
please r
un fpcmake first. Stop.
If you run fpcmake -Tall -w first, you'll get the same. Looks like the
first step should be rebuilding fpcmake itself with
On 23/10/14 17:06, Vsevolod Alekseyev wrote:
If you follow the steps in that post, you'll get the following:
makefile:197: *** The Makefile doesn't support target i386-winphonesim,
please r
un fpcmake first. Stop.
If you run fpcmake -Tall -w first, you'll get the same. Looks like the
There's no separate makefile for fpcmake alone, is there?
On 10/23/2014 11:12 AM, Jonas Maebe wrote:
On 23/10/14 17:06, Vsevolod Alekseyev wrote:
If you follow the steps in that post, you'll get the following:
makefile:197: *** The Makefile doesn't support target i386-winphonesim,
please r
un
On 10/23/2014 08:41 AM, Joost van der Sluis wrote:
On 10/23/2014 11:49 AM, Jonas Maebe wrote:
On 23/10/14 11:28, Thaddy de Koning wrote:
The starting compiler is any official FPC 2.6.4 compiler that can be
downloaded from our website. With any of those compilers, you can build
both cross and
Gennadiy Poryev wrote:
thank you,
but my question was more about where to put fpc.cfg so that both
versions can use it properly, or, if that is not possible, where to
stuff different fpc.cfg's for the same purpose?
and what would be the basepath in either case?
execute ppx64 -vut
the last
In our previous episode, Vsevolod Alekseyev said:
There's no separate makefile for fpcmake alone, is there?
No. There are more such cases, and while there are tricks for advanced
users, like with the starting compiler version, I suggest you stick to
the official requirement of having the full
On second look, no, the -vp tree is not sufficient. It doesn't have
datatype definitions, doesn't have interface definitions...
On 10/22/2014 4:44 AM, Nikolay Nikolov wrote:
On 10/22/2014 12:23 AM, Vsevolod Alekseyev wrote:
Hi all,
I wonder where in the FPC compilation flow would be a good
On 23.10.2014 г. 18:59, Vsevolod Alekseyev wrote:
On second look, no, the -vp tree is not sufficient. It doesn't have
datatype definitions, doesn't have interface definitions...
True. I guess, you can try to use ppudump in order to dump these
definitions. It'll only work for units though, but I
I don't see local variable definitions there, either...
On 10/23/2014 12:15 PM, Nikolay Nikolov wrote:
On 23.10.2014 г. 18:59, Vsevolod Alekseyev wrote:
On second look, no, the -vp tree is not sufficient. It doesn't have
datatype definitions, doesn't have interface definitions...
True. I
Lazarus has a Pascal tokenizer unit under components\mpaslex\mpaslex.pp. It
seems old and doesn't look like it supports the full FPC syntax, but it
might be a starting point since most likely you can convert the code to C++
with GNU GCC extensions (nested functions, etc) straightforward.
On Thu,
Hello,
I am trying to get the embedded version of fpc for arm to work.
Currently i try it for the lpc1768 from NXP using the lpcxpresso board.
The example compiles, but doesn't run on the target...
I created a simple example and it seems that the code it generates is NOT
thumb2 code.
I
Are you sure those are the precise steps you took? Because that should
work as you expected it unless you have a broken binutils version. It's
normally very quick to complain about incompatible ARM versions
Try to disassemble the objects in the source directory at
rtl/units/arm-embedded
I remember seeing the problem that gdb does not correctly disassemble
code...
Please do a
arm-none-eabi-readelf -A xxx.elf
you should see:
File Attributes
Tag_CPU_name: 7-M
Tag_CPU_arch: v7
Tag_CPU_arch_profile: Microcontroller
Tag_THUMB_ISA_use: *Thumb-2*
Compiling, linking and
One more thing:
Did you try to run the code directly on the device after uploading it or
did you use a debugger to start the program?
When I remember correcly all LPCxxx devices need a magic checksum so
that they are started on the device. The creation of this checksum is in
trunk, but I am
On 10/23/2014 08:38 PM, Jeppe Græsdal Johansen wrote:
Are you sure those are the precise steps you took? Because that should work as
you expected it unless you have a broken binutils version. It's normally very
quick to complain about incompatible ARM versions
Try to disassemble the objects
This smells like some system.o left over from an old build or from an
incorrect setting in fpc.cfg. Please use the switch -vu when you compile
your program to find out where this file is in your filesystem.
If you do not get the correct path then please add the parameter -sh to
your
On 10/23/2014 09:16 PM, Michael Ring wrote:
This smells like some system.o left over from an old build or from an incorrect
setting in fpc.cfg. Please use the switch -vu when you compile your program to
find out where this file is in your filesystem.
I redid the creation of the compiler,
You had better use the fcl-passrc units. They dump a complete syntax tree.
It is used to generate (a currently limited version of) javascript, and
used to create documentation.
so it should be usable to generate C code...
The test program re-dumps a pascal program.
Presumably you can
What test program, please? Where?
On 10/23/2014 4:12 PM, Michael Van Canneyt wrote:
You had better use the fcl-passrc units. They dump a complete syntax
tree.
It is used to generate (a currently limited version of) javascript,
and used to create documentation.
so it should be usable to
See the FPC sources:
packages/fcl-passrc/examples/test_parser.pp
Michael.
On Thu, 23 Oct 2014, Vsevolod Alekseyev wrote:
What test program, please? Where?
On 10/23/2014 4:12 PM, Michael Van Canneyt wrote:
You had better use the fcl-passrc units. They dump a complete syntax tree.
It is
On 23/10/14 17:16, Vsevolod Alekseyev wrote:
There's no separate makefile for fpcmake alone, is there?
It used to be as simple as going into utils/fpcm and performing a make
all, but with the new FPC-based build system I think that is
unfortunately no longer possible.
Jonas
On 23/10/14 17:43, Marco van de Voort wrote:
In our previous episode, Vsevolod Alekseyev said:
There's no separate makefile for fpcmake alone, is there?
No. There are more such cases, and while there are tricks for advanced
users, like with the starting compiler version, I suggest you stick
40 matches
Mail list logo
