It is probably my fault somewhere, since I do not know the exact procedure to be followed.....

BUT:

In a checkout of
http://svn.freepascal.org/svn/fpcbuild/trunk in C:/FPC/SVN/build_trunk/

PATH=C:/FPC/SVN/build_trunk/install\binw32
cd C:/FPC/SVN/build_trunk/fpsrc

// a starting native 2.6.2 ppc
make.exe   all   FPC=C:\otherplace\ppc386_2_6_2.exe   PPC_TARGET=arm

after a very short while

make[5]: Entering directory `C:/FPC/SVN/build_trunk/fpcsrc/rtl/win32' C:/FPC/SVN/build_trunk/fpcsrc/compiler/ppc.exe -Ur -Xs -O2 -n -Fi../inc -Fi../i386 -Fi../win -FE.
-FUC:/FPC/SVN/build_trunk/fpcsrc/rtl/units/i386-win32 -di386 - dRELEASE -Us -Sg system.pp -Fi../win
system.inc(231,4) Fatal: Can't open include file "armdefines.inc" Fatal: Compilation aborted
make[5]: *** [system.ppu] Error 1
make[5]: Leaving directory `C:/FPC/SVN/build_trunk/fpcsrc/rtl/win32' make[4]: *** [win32_all] Error 2
make[4]: Leaving directory `C:/FPC/SVN/build_trunk/fpcsrc/rtl' make[3]: *** [rtl] Error 2
make[3]: Leaving directory `C:/FPC/SVN/build_trunk/fpcsrc/compiler' make[2]: *** [cycle] Error 2
make[2]: Leaving directory `C:/FPC/SVN/build_trunk/fpcsrc/compiler' make[1]: *** [compiler_cycle] Error 2
make[1]: Leaving directory `C:/FPC/SVN/build_trunk/fpcsrc' make: *** [build-stamp.i386-win32] Error 2

It is probably my fault somewhere, since I do not know the exact procedure to be followed.....

BUT:

In a checkout of
http://svn.freepascal.org/svn/fpcbuild/trunk in C:/FPC/SVN/build_trunk/

PATH=C:/FPC/SVN/build_trunk/install\binw32
cd C:/FPC/SVN/build_trunk/fpsrc

// a starting native 2.6.2 ppc
make.exe   all   FPC=C:\otherplace\ppc386_2_6_2.exe   PPC_TARGET=arm

after a very short while

make[5]: Entering directory `C:/FPC/SVN/build_trunk/fpcsrc/rtl/win32' C:/FPC/SVN/build_trunk/fpcsrc/compiler/ppc.exe -Ur -Xs -O2 -n -Fi../inc -Fi../i386 -Fi../win -FE.
-FUC:/FPC/SVN/build_trunk/fpcsrc/rtl/units/i386-win32 -di386 - dRELEASE -Us -Sg system.pp -Fi../win
system.inc(231,4) Fatal: Can't open include file "armdefines.inc" Fatal: Compilation aborted
make[5]: *** [system.ppu] Error 1
make[5]: Leaving directory `C:/FPC/SVN/build_trunk/fpcsrc/rtl/win32' make[4]: *** [win32_all] Error 2
make[4]: Leaving directory `C:/FPC/SVN/build_trunk/fpcsrc/rtl' make[3]: *** [rtl] Error 2
make[3]: Leaving directory `C:/FPC/SVN/build_trunk/fpcsrc/compiler' make[2]: *** [cycle] Error 2
make[2]: Leaving directory `C:/FPC/SVN/build_trunk/fpcsrc/compiler' make[1]: *** [compiler_cycle] Error 2
make[1]: Leaving directory `C:/FPC/SVN/build_trunk/fpcsrc' make: *** [build-stamp.i386-win32] Error 2

Please try

make all FPC=C:\otherplace\ppc386_2_6_2.exe CPU_TARGET=arm

to be on the save side for comparison.

Regards,
Sven

On Linux it hasn't compiled since May. It crashes before the RTL stuff. The compiler itself does compile.

An error message would be nice.

If the error is that "bx r14" is not supported, then I've fixed this now in revision 25393.

Regards,
Sven

What we get is a bizarre error which gives little information as to why it barfs Compilation works perfectly if using snapshots from may. That is what I have on my funtoo odroid right now.

michel ~ # fpc
Free Pascal Compiler version 2.7.1 [2013/05/18] for arm Copyright (c) 1993-2013 by Florian Klaempfl and others

Here are the last messages of the compilation of the latest snapshots as of Sept 2nd. The result has been identical since may. Someone introduced a deadly bug that kills compilation on ARM devices. This was done on an Odroid U2.

The last successfull compile I had was using a fpc.zip that my funtoo had in a cache. So I think that the last non broken fpc was around the 15th of may or slightly before that. It would be nice to have better error message that just an Access violation. There is no way to figure out what happen when the error comes from the OS. Can't the compiler traps this kind of stuff and get us more informative clue as to what happened? The crash seems to be caused by the UnicodeString stuff, if that is the case why the Warning instead of an error?

/bin/rm -f fpcmade.arm-linux Package.fpc ./ppas.sh script.res link.res /bin/rm -f *.s *_ppas.sh
make[6] : on quitte le répertoire « /var/tmp/portage/dev-lang/fpc-2.7.1-r2/work/fpcbuild/fpcsrc/rtl/linux » make[5] : on quitte le répertoire « /var/tmp/portage/dev-lang/fpc-2.7.1-r2/work/fpcbuild/fpcsrc/rtl » make -C /var/tmp/portage/dev-lang/fpc-2.7.1-r2/work/fpcbuild/fpcsrc/rtl 'OPT=-dFPC_ARMHF ' all make[5] : on entre dans le répertoire « /var/tmp/portage/dev-lang/fpc-2.7.1-r2/work/fpcbuild/fpcsrc/rtl » make -C linux all
make[6] : on entre dans le répertoire « /var/tmp/portage/dev-lang/fpc-2.7.1-r2/work/fpcbuild/fpcsrc/rtl/linux » as -o /var/tmp/portage/dev-lang/fpc-2.7.1-r2/work/fpcbuild/fpcsrc/rtl/units/arm-linux/prt0.o arm/prt0.as as -o /var/tmp/portage/dev-lang/fpc-2.7.1-r2/work/fpcbuild/fpcsrc/rtl/units/arm-linux/dllprt0.o arm/dllprt0.as as -o /var/tmp/portage/dev-lang/fpc-2.7.1-r2/work/fpcbuild/fpcsrc/rtl/units/arm-linux/cprt0.o arm/cprt0.as as -o /var/tmp/portage/dev-lang/fpc-2.7.1-r2/work/fpcbuild/fpcsrc/rtl/units/arm-linux/gprt0.o arm/gprt0.as as -o /var/tmp/portage/dev-lang/fpc-2.7.1-r2/work/fpcbuild/fpcsrc/rtl/units/arm-linux/ucprt0.o arm/ucprt0.as /var/tmp/portage/dev-lang/fpc-2.7.1-r2/work/fpcbuild/fpcsrc/compiler/ppc1 -Ur -Ur -O2 -n -Fi../inc -Fi../arm -Fi../unix -Fiarm -FE. -FU/var/tmp/portage/dev-lang/fpc-2.7.1-r2/work/fpcbuild/fpcsrc/rtl/units/arm-linux -dFPC_ARMHF -darm -dRELEASE -Us -Sg system.pp
text.inc(2082,14) Warning: Implicit string type conversion from "AnsiString" to "UnicodeString" text.inc(2301,53) Warning: Implicit string type conversion with potential data loss from "UnicodeString" to "AnsiString" An unhandled exception occurred at $0000923C:
EAccessViolation: Access violation
$0000923C

An unhandled exception occurred at $0000923C:
EAccessViolation: Access violation
$0000923C

make[6]: *** [system.ppu] Erreur 217
make[6] : on quitte le répertoire « /var/tmp/portage/dev-lang/fpc-2.7.1-r2/work/fpcbuild/fpcsrc/rtl/linux » make[5]: *** [linux_all] Erreur 2
make[5] : on quitte le répertoire « /var/tmp/portage/dev-lang/fpc-2.7.1-r2/work/fpcbuild/fpcsrc/rtl » make[4]: *** [rtl] Erreur 2
make[4] : on quitte le répertoire « /var/tmp/portage/dev-lang/fpc-2.7.1-r2/work/fpcbuild/fpcsrc/compiler » make[3]: *** [next] Erreur 2
make[3] : on quitte le répertoire « /var/tmp/portage/dev-lang/fpc-2.7.1-r2/work/fpcbuild/fpcsrc/compiler » make[2]: *** [ppc2] Erreur 2
make[2] : on quitte le répertoire « /var/tmp/portage/dev-lang/fpc-2.7.1-r2/work/fpcbuild/fpcsrc/compiler » make[1]: *** [cycle] Erreur 2
make[1] : on quitte le répertoire « /var/tmp/portage/dev-lang/fpc-2.7.1-r2/work/fpcbuild/fpcsrc/compiler » make: *** [compiler_cycle] Erreur 2
* ERROR: dev-lang/fpc-2.7.1-r2 failed (compile phase):
* emake failed

Only use the last stable release (currently 2.6.2) or a compiler of the exact same SVN revision to compile a trunk (or fixes) compiler. Nothing else is supported and might break unexpectedly.

Regards,
Sven

Version 2.6.2 doesn't have all the latest for lazarus and has some issues with hard float on ARM. I have a working 2.6.2 on my ubuntu version on the odroid U2. The stuff that doesn't work on Lazarus with that version works perfectly on my funtoo on the odroid U2 where I use fpc 2.7.1 from way back in may.

You must not have read what I wrote or have no clue whatsoever about the subject. Read it again and if you do not have any idea about the problem, just go away and let people who know comment.

I have no interest whatsoever in using binaries that I do not compile myself. For one thing, except for a version on Debian, a good version doesn't exist or is soft float.

Development version of fpc worked perfectly for what I did with it back in may but has been broken since. I would prefer using the lastest SVN stuff but it is has been useless since may.

Michel

Every other developer of FPC will tell you the same: The only supported version for compiling a development (2.7.1) or fixes (2.6.3) version is either the last release (2.6.2) or a development/fixes version of the same revision and nothing else.

2.7.1 definitely is a development version and it sometimes happens that things will break in a way that a older revision is no longer able to build a newer one. We do not check for compatibility with older revisions and the only way we guarantee that works is a compilation with 2.6.2.

The softfloat 2.6.2 compiler should be able to compile a hard float one and as far as I've understood the softfloat discussion it should also work on hardfloat systems. Otherwise you could compile a hardfloat compiler on a Debian system (using a 2.6.2 as starting compiler), move that to your odroid U2 and build the compiler (of the same revision!) with that (the compiler does not use libc or any other library so you can freely move it between Linux systems).

Regards,
Sven

Sven Barth wrote

Every other developer of FPC will tell you the same: The only supported version for compiling a development (2.7.1) or fixes (2.6.3) version is either the last release (2.6.2) or a development/fixes version of the same revision and nothing else.

I am not sure that this is entirely true. I do understand that it is possible as you say that sometimes it won't compile, but that part doesn't fail to compile. What fails is when it is time to use the newly created compiler. Do you mean to say that the compiler created by the dev version is junk and that is the problem?

I allready have a hard float 2.6.2 compiler on my odroid ubuntu. I guess I should rename my ubuntu to something else because it is no longer a true ubuntu since it is very similar to mint. I took out unity and its companion snooping crap (kind of like a trojan) Before I had unity replaced with mate it tried to uninstall just about everything when I tried to remove zeitgeist. ssh was usefull to recover stuff after the first attempt to remove zeitgeist.

On ubuntu I can use alternative to switch between the two. I will try that. On funtoo I do not have it setup to use alternative, I will have to remove my current fpc and put the latest release. I still have the original source code that compiled correctly so I can always go back to it if your theory doesn't work. I will try your suggestion on ubuntu first.

Michel

"Michel Catudal" wrote

Le 2013-09-02 13:51, Sven Barth a écrit : > > Every other developer of FPC will tell you the same: The only supported

version for compiling a development (2.7.1) or fixes (2.6.3) version is either the last release (2.6.2) or a development/fixes version of the same revision and nothing else.

> I am not sure that this is entirely true. I do understand that it is

possible as you say that sometimes it won't compile, but that part doesn't fail to compile. What fails is when it is time to use the newly created compiler.

Do you mean to say that the compiler created by the dev version is junk

and that is the problem?

The ppc1 you see in the make output uses the RTL of its own revision compiled by your previous 2.7.1 compiler. Now some change inside the RTL and maybe the compiler results in your previous compiler to generate a non working RTL.
The problems that occur when you use an older dev version to compile a younger one can sometimes be very strange. I often had the problem myself when I forgot to switch back from the trunk compiler to the last release one.

> 2.7.1 definitely is a development version and it sometimes happens that

things will break in a way that a older revision is no longer able to build a newer one. We do not check for compatibility with older revisions and the only way we guarantee that

> works is a compilation with 2.6.2. > > The softfloat 2.6.2 compiler should be able to compile a hard float one

and as far as I've understood the softfloat discussion it should also work on hardfloat systems. Otherwise you could compile a hardfloat compiler on a Debian system (using a 2.6.2 as

> starting compiler), move that to your odroid U2 and build the compiler

(of the same revision!) with that (the compiler does not use libc or any other library so you can freely move it between Linux systems).

> I allready have a hard float 2.6.2 compiler on my odroid ubuntu. I guess

I should rename my ubuntu to something else because it is no longer a true ubuntu since it is very similar to mint. I took out unity and its companion snooping crap (kind of like a

trojan) Before I had unity replaced with mate it tried to uninstall just

about everything when I tried to remove zeitgeist. ssh was usefull to recover stuff after the first attempt to remove zeitgeist.

On ubuntu I can use alternative to switch between the two. I will try

that. On funtoo I do not have it setup to use alternative, I will have to remove my current fpc and put the latest release. I still have the original source code that compiled correctly

so I can always go back to it if your theory doesn't work. I will try

your suggestion on ubuntu first.

You should be able to take your 2.6.2 hardfloat ppcarm binary only from your Ubuntu and copy that to your funtoo. You can then invoke the compilation this way:

make clean all FPC=/path/to/2.6.2/ppcarm

You should nevertheless have your 2.7.1 bin directory in $PATH as a few other tools (e.g. data2inc) might be needed when installing (don't know whether we changed that already to use the freshly compiled one first...)

Regards,
Sven

.
.

The simplest case (which may make this restriction easier to understand) is like this:

- The compiler behaves in certain way in the last released version (e.g. 2.6.2).

- A change to the previous behaviour needs to be done in the trunk version (e.g. 2.7.1).

- The compiler reports the same version before the specific change and after that change (both is considered as 2.7.1).

- The change in the compiler behaviour results in a need to change something in the RTL (remember that the RTL sometimes needs to reflect low-level stuff impacted by internal behaviour of the compiler).

- In order to keep the RTL working with both the old and the new compiler behaviour, an IFDEF is added for the last released version (e.g. {$IFDEF VER2_6_2}implementation based on the old behaviour{$ELSE VER2_6_2}implementation based on the new behaviour{$ENDIF}).

- Since that point in time, RTL compiled with the trunk compiler created before that change will not work correctly (and that obviously also applies to programs using such compiled RTL). The incorrect working may have whatever effects - access violations, wrong behaviour, whatever.

I hope that this makes it a bit clearer.

Tomas

Your answer is to the point and right.
It is of ultimate importance, though, that the compiler options for armXX have changed considerably since 2.6.2/3.
For my Friday toys (Pi's) I use 2.7.1 with the new ARM options and bootstrap with OVERRIDEVERSIONCHECK=1
I think that is a perfectly viable option.
Maybe it is just a case of pointing out exactly that. There are still no public makefiles that support those options, afaik.

Thaddy wrote

For my Friday toys (Pi's) I use 2.7.1 with the new ARM options and bootstrap with OVERRIDEVERSIONCHECK=1 I think that is a perfectly viable option.

It is not, as evidenced by the fact that about 99% of this thread until now has been about trying to determine whether there is in fact something wrong with the current 2.7.1, or whether the problems are simply caused by not using the latest release to bootstrap.

Jonas

At least the current RaspBian releases (wheezy and Jessie) still bootstrap from 2.6.2, if that helps.
The point I was referring to is about the generated code. There were some fixes related to bx.
So I assumed wrong compiler settings.

In our previous episode, Thaddy said:

If that 2.7.1 was just bootstrapped using the same SVN starting with 2.6.2/3.

That's the only reason why OVERRIDE.. exists.

1. bootstrap native 2.7.1 from 2.6.2, then
2. use that to bootstrap something cross-arch that 2.6.x doesn't support.

But do both stages _every_ time (svn update)

Anything that builds 2.7.1 with an older 2.7.1 is not supported. If you're unlucky a single revision can cause problems.

I know.... Sometimes I learned something, Marco. Hence my comment.

These changes fix the compilation for older ARM CPUs which don't support BX and where its semantic needs to be implemented by a different instruction. So if it didn't compile before it will now compile, if it compiled before then nothing changed.

Regards,
Sven

I can put that in my ebuild, thanks for the info.

Michel