Hi Florian and other friends

I am involved in porting existing C code to Arm Linux for AT91SAM9263 Ek board with 340x220 display. I need to write lots of console kinda apps.

I am using a "qemu-system-arm" emulated Armel Debian machine on a

Debian x86 Lenny distro for writing code. I installed fpc-2.2.0.arm-linux.tar on the emulated linux.
Which compiling a simple helloworld.pas , i get the classic error of System.o being EABI 0 while target is EABI 4.

I have got the svn download of fpc, and trying to compile it in the emulated machine for ARM for the past 2 days. I have given :-

make clean all ARCH=arm OPT="-CfSoft".

Its compiling for quite long and finally comes to rest endlessly while

compiling system.pp.

Let me remind you that i am dont use a Cross compiler, but an emulated Arm machine.

My boss and colleagues are 'C only' programmers . Doing all kinda harware access for embedded devices using C. They have developed pretty

good & successful apps using pure C without an OS. What i have been trying is to convice them to use Freepascal for the Application part, which is presently console Apps. The next stage is to develop X apps

using Lazarus. But for these I need to get FPC working.

Please help.

regards

Nataraj

sorry if this comes thru twice, I think I used the wrong email address before.

this might help a little bit...
http://www.klc.net.nz/linux/?page_id=13

I am still to complete it, there are some tricks to svn for arm that I haven't documented yet but it should give you a heads up.

Terry

also I noted afterwards you aren't crosscompiling... but its an option anyways, and lazarus / qt crosscompiles no probs (mostly).

trick from clean svn (from memory) is to run fpcmake -Tall (2.2.0 version only - 2.3.1 doesn't work)) and when compiling fails on ffpkg or similar when installing to zip change into that folder and do the same.

also although it creates an EABI 4 executable correctly there is a problem with fpc-svn/compiler/systems/t_linux.pas that sticks the wrong dynamic linker name in the file. I fixed it with this...

{$ifdef arm}
    {$ifdef FPC_ARMEL}
         defdynlinker:='/lib/ld-linux.so.3';
    {$else}
         defdynlinker:='/lib/ld-linux.so.2';
    {$endif}
{$endif arm}

probably wrong but IWFM.

En/na Terry Kemp ha escrit:

this might help a little bit... http://www.klc.net.nz/linux/?page_id=13

That looks cool, though I'm right now trying a different route for my nokia n800: I downloaded a 2.2.0 native arm release to compile a native arm eabi compiler under scratchbox, with
make zipinstall OPT='-CfSOFT -dFPC-ARMEL -gl'

Next I'll try to compile a native arm lazarus (however I'm a complete scratchbox newbie, so I don't have the slightest idea on how to access the display to run lazarus).

I also noticed that under scratchbox I only have /lib/ld-linux.so.3, as well as on the tablet.
Any reason why this fix isn't added to svn?

Bye

En/na Luca Olivetti ha escrit:

Mmh, it doesn't seem to work: ppc1 generated ppc2 but ppc2 has been spinning the cpu at 100% for the last 10 minutes and I don't think it'll finish.

It's currently doing this:

/home/luca/fpc-svn/compiler/ppc2 -Ur -Ur -Xs -O2 -n -Fi../inc -Fi../arm -Fi../unix -Fiarm -FE. -FU/home/luca/fpc-svn/rtl/units/arm-linux -CfSOFT -dFPC-ARMEL -gl -darm -dRELEASE -Us -Sg system.pp

I don't think that fpc svn is broken, since an i386 make all worked.

Any hint?
(note that running either ppc1 or ppc2 with no arguments I get the fpc help message, so at least they both seem to run)

Bye

En/na Luca Olivetti ha escrit:

Mmh, it doesn't seem to work: ppc1 generated ppc2 but ppc2 has been spinning the cpu at 100% for the last 10 minutes and I don't think it'll finish.

Duh, that's also the op problem.

Try with OPT=-O-

En/na Florian Klaempfl ha escrit:

That did the trick, however the resulting compiler is huge (compared to the 2.2.0 one):

$ ls -l ../fpc/lib/fpc/2.2.0/ppcarm compiler/ppcarm -rwxrwxr-x 1 luca luca 8809137 mai 31 22:32 compiler/ppcarm* -rwxr-xr-x 1 luca luca 1657400 set 8 2007 ../fpc/lib/fpc/2.2.0/ppcarm*

Or is it due to the '-gl'?

(currently building the rtl...)

Bye

Yes.

Jonas

En/na Florian Klaempfl ha escrit:

Ok, now I have a supposedly eabi compiler working under scratchbox.

I added

-CfSOFT
-dFPC-ARMEL

to /etc/fpc.cfg.

A simple hello world works, both under the emulated arm in scratchbox and in the tablet.

But I tried to compile a couple of examples in the gtk2 package and I see this:

[sbox-CHINOOK_ARMEL: ~/fpc-svn/packages/gtk2/examples/helloworld] > ./helloworld
/lib/ld-linux.so.2: No such file or directory

As per Terry's instructions I changed t_linux.pas to use ld-linux.so.3 if compiled with -dFPC-ARMEL.

My guess is that the rtl/packages were compiled without the '-dFPC-ARMEL' when I made the compiler with

make zipinstall OPT='-CfSOFT -dFPC-ARMEL -O-'

(I didn't pay too much attention but I'm sure that at least it didn't pass the '-O-' while compiling the rtl).

Hints?

Bye

As per Terry's instructions I changed t_linux.pas to use ld-linux.so.3 if compiled with -dFPC-ARMEL.

That's not necessary, a -FD in the fpc.cfg works too without changing + recompiling.

It should work like this. However most makefile commands that involve a bootstrapping step ignore fpc.cfg, that is afaik documented.

En/na Marco van de Voort ha escrit:

"-FD<x> sets the directory where to search for compiler utilities"

How do I use it to define the default dynamic linker?

I'm not sure I understand correctly.
I added the '-dFPC-ARMEL' *after* making the compiler+rtl, if I put it in *before*, will be taken into account while building the rtl/packages or will it be ignored?
If the latter, how do I make sure the rtl/packages are built with 'dFPC-ARMEL'?

Thanks.

You should need only FPC_ARMEL.

The compiler takes care of this now in trunk.

It's -dFPC_ARMEL

If the latter, how do I make sure the rtl/packages are built with 'dFPC-ARMEL'?

cd fpc && make clean all OPT=-dFPC_ARMEL

En/na Florian Klaempfl ha escrit:

> > make zipinstall OPT='-CfSOFT -dFPC-ARMEL -O-' It's -dFPC_ARMEL

/me smacks head into nearby wall

Thanks, I'll try

Bye

En/na Luca Olivetti ha escrit:

/home/luca/fpc-svn/compiler/ppc1 -Ur -Xs -O2 -n -Fuarm -Fusystems -Fu/home/luca/fpc-svn/rtl/units/arm-linux -Fiarm -FE. -FUarm/units/arm-linux -dRELEASE -CfSOFT -dFPC_ARMEL -O- -darm -dGDB -dBROWSERLOG pp.pas
/scratchbox/compilers/cs2005q3.2-glibc2.5-arm/bin/sbox-arm-linux-ld:./link.res: file format not recognized; treating as linker script /scratchbox/compilers/cs2005q3.2-glibc2.5-arm/bin/sbox-arm-linux-ld:./link.res:281: syntax error
pp.pas(209,27) Error: Error while linking
pp.pas(209,27) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted

The content of link.res around line 281:

279 /* Adjust the address for the data segment. We want to adjust up to
280 the same address within the page on the next page up. */ 281 . = ALIGN(CONSTANT (MAXPAGESIZE)) + (. & (CONSTANT (MAXPAGESIZE) - 1));

Bye

En/na Luca Olivetti ha escrit:

Without "-dFPC_ARMEL" it gets past this stage, but that's not what I want.

Bye

Please mail me the output (write in one line) of

/scratchbox/compilers/cs2005q3.2-glibc2.5-arm/bin/sbox-arm-linux-ld --verbose

En/na Florian Klaempfl ha escrit:

I sent that privately.
FWIW I also tried on real arm hardware running oabi debian/etch (I wasn't courageous enough to migrate my home server to lenny/armel, but the kernel supports eabi) with the same result.

Bye