I have a trunk source tree for FPC, which I checked out a few weeks ago and built fpc 3.1.1 using fpc 2.6.4 then installed it etc. Now I wanted to get to the latest revision and did an svn update in the source dir. But when I then issue 'make all' I get this message:

Makefile:2873: *** The only supported starting compiler version is 2.6.4. You are trying to build with 3.1.1.. Stop.

How am I supposed to update fpc 3.1.1?

Web sources only describe how to get it in the first place but not how to keep it updated. Do I have to adjust all the fpc related symlinks first or what?

Bo Berglund wrote

How am I supposed to update fpc 3.1.1?

Forgot to say that I am doing this on an ARM device (Raspberry Pi2).

You must always start with a released (currently 2.6.4) compiler. That is normal.

To do this, you can e.g. make a symlink to the 2.6.4 compiler (name it ppcarm-2.6.4) and use that when calling make:

make all PP=ppcarm-2.6.4

or, if you want to avoid the symlink, you can directly refer to the 2.6.4 compiler:

make all PP=/usr/local/lib/fpc/2.6.4/ppcarm

(change the path to suit your setup, obviously)

I have always done the former.

Michael.

Good suggestion!
I did this and fpc is now being built:
time make all PP=ppcarm-2.6.4

Unfortunately it ends with an error:

/usr/local/fpc/source/rtl/units/arm-linux/cprt0.o: In function `_haltproc_eabi':
(.text+0x88): undefined reference to `_fini'
/usr/local/fpc/source/rtl/units/arm-linux/cprt0.o: In function `_haltproc_eabi':
(.text+0x90): undefined reference to `_init'
fpmake.pp(49) Error: Error while linking
fpmake.pp(49) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted
Makefile:1698: recipe for target 'fpmake' failed
make[2]: *** [fpmake] Error 1
make[2]: Leaving directory '/usr/local/fpc/source/packages' Makefile:2699: recipe for target 'packages_smart' failed make[1]: *** [packages_smart] Error 2
make[1]: Leaving directory '/usr/local/fpc/source' Makefile:2895: recipe for target 'build-stamp.arm-linux' failed make: *** [build-stamp.arm-linux] Error 2

real 12m33.806s
user 11m6.580s
sys 1m8.590s

If this can be solved:

Next question:
--------------
Do I need to also run the following commands afterwards:

make install OPT=-dFPC_ARMHF PREFIX=/usr/local
make install sourceinstall OPT=-dFPC_ARMHF PREFIX=/usr/local

and do these also need the PP=ppcarm-2.6.4 parameter?

Except that that won't work on the RPi, where you need to start off with a specially-built compiler.

Bo, look for the error message in Makefile and you'll also see reference to OVERRIDEVERSIONCHECK which allows you to build from your current compiler, i.e. something like

make OVERRIDEVERSIONCHECK=1 all

I'd not normally recommend this, but I think in the current case it's necessary and safe. TO EMPHASISE: UNDER NORMAL CIRCUMSTANCES USE THE LAST-RELEASED COMPILER.

In haste,

I think my 2.6.4 is OK because I got it as follows (from my notes): wget
http://sourceforge.net/projects/freepascal/files/Linux/2.6.4/fpc-2.6.4.arm-linux.tar tar xvf fpc-2.6.4.arm-linux.tar
cd fpc-2.6.4.arm-linux
./install.sh (Reply /usr/local to the first question)

I am seroiusluy considering scrapping my current installation (FPC 3.1.1 and Lazarus 1.5) in favour of the released versions. But I don't know how to go about it, i.e. how does one get rid of old (newer) versions in favour of release versions?
In Windows one would do an uninstall, but here on Linux everything is built from sources and might interact in unknown ways.... I don't want to scrap my whole Raspbian installation this time around, just get the released version for the Linux ARM platform.

BTW, I saw that the released Lazarus is 1.4.4, and I think that FPC 2.6.4 is the latest release. So since I have 2.6.4 installed it might just be about changing the symlink inside /usr/local/bin to point pparm to that versionon the FPC side?

I thought we'd already been through this loop once? You need a custom binary tailored for the RPi.

Mark, thanks for hanging in and advicing me!
Most appreciated!

Right now I am getting dizzy by all the webpages, newsgroups, emails and how-tos I have read the last week....
And still I seem not to completely understand how this works... But I hope I am getting closer.

The tar file above does work on my RPi2 in order to build FPC from svn trunk, so in what way is it not a valid ARM binary for the Pi? Surely if it works on the Pi to build the bleeding edge trunk fpc itself it should work in all other respects too??

Or do I need to check out fpc svn sources from the 2.6.4 tag and build the 2.6.4 compiler itself on the Pi hardware in order to get it working correctly? If that is the case then fpc from tar seems not to have something that an fpc from the same sources but compiled locally will contain. And this something is not needed for compiling FPC?

My previous tests with svn versions were based on svn trunk sources and FPC was compiled with this tar binary into the 3.1.1 version, then this fpc 3.1.1 was used to compile Lazarus itself.

Anyway, I decided to try to go the apt-get route instead irrespective of the webpage notes I found in several places stating that it does not work for getting fpc and lazarus installed on an RPi2.

So sudo apt-get install fpc lazarus gave me fpc 2.6.4 (again but in a different location) and Lazarus 1.2.4 (pretty old but OK for now). No error messages. :)

It also gave me a dialog when starting Lazarus (1.2.4) indicating that in order to use multiple versions of Lazarus I had to add a command line parameter --pcp <directory> in order to direct it to where the user configuration should be saved.
So I did this and created a new command line program, again based on TCustomApplication, into which I copied the code from my previous test with lnet. I also used the GetTickCount64 call as I had done before in order to time the program operations.

Surprise! GetTickCount64() (and GetTickCount() for that matter) are flagged as "Identifier not found" when I try to compile the test.

But after adding LCLBase to project required packages and adding LclIntf to uses it solved the GetTickCount problem. Now the test program compiles and runs. :)

So as far as I can see now I could move forward using the apt-get versions.

Only problem is how to safely remove all of the various builds and compiles and tar versions that are now scattered around my disk and potentially will cause conflicts down the line.
IOW: How does one uninstall stuff that has been installed by make install scripts?
Maybe I should make a clean start now that I know how to proceed, i.e. scrap the SDcard and start over with a fresh operating system on a card...

Last note:
Since I got Lazarus 1.2.4 off apt-get and it is pretty old now, could I check out lazarus_1_4_4 and then build it using the fpc I have from apt-get and thus have a newer Lazarus still using fpc 2.6.4? Or does Lazarus 1.4.4 release need stuff that is in newer fpc versions?

Sorry but I've got other things that I've got to do so this is brief and might overlook points.

Right now I am getting dizzy by all the webpages, newsgroups, emails and how-tos I have read the last week.... And still I seem not to completely understand how this works... But I hope I am getting closer.

You really should not be in a position where you have a working configuration and then can't get back to it. To be quite frank, you should be keeping (the equivalent of) an engineering notebook.

The tar file above does work on my RPi2 in order to build FPC from svn trunk, so in what way is it not a valid ARM binary for the Pi? Surely if it works on the Pi to build the bleeding edge trunk fpc itself it should work in all other respects too??

Building the compiler does not exercise all aspects of the compiler, RTL and FCL. As a gross example, it does not exercise the graphical and database interface units which are referred to by Lazarus.

Here's what I do. For any given architecture or- in the case of the RPi- variant of an architecture, try to find a binary that is tailored to it. In some cases that might be older (or newer) than the official stable release. Either get the fpcbuild bundle corresponding to that and build it, or in some cases you'll need to check a specified revision (etc.) out of svn. Compile that, noting any instructions you're given (e.g. if I remember correctly, for some early versions you had to warn the compiler etc. that it was to build the hardware float variant). Where feasible build other versions using the fpcbuild sources, except that trunk obviously needs to be built from svn; note that at present there's an fpcbuild for v3 RCx.

As I've noted in some detail in the Lazarus conf over the last few days, there's a preferred version of FPC for each Lazarus version, i.e. you can check out a tagged Lazarus release from svn and build it with a specific FPC. If running multiple versions you'll make life much easier for yourself if you make sure that Lazarus is always started off with a --pcp option.

Martin has gone to the trouble of making a binary available for the RPi. As I've discussed in this ML, there are problems with that on Raspbian Wheezy 2014 but these are just about fixed on 2015, much thanks to Jonas and others for setting me right on details relating to paths etc. I can't remember where I've got to with Jessie.

So. I'd suggest that you start off with Martin's binary, build the matching 2.6.4, then build v3 RCx. On a PC, I've found Lazarus 1.4.2 OK with FPC v3 (RCwhatever), as I've said I can't remember where I've got to with Jessie.

You decided based on whose advice exactly? Martin, myself and others have been telling you how to get things working... /repeatedly/ telling you how to get things working, then you go off on a tangent and complain that you've spent a day fruitlessly.

And to make it worse, you're complaining about fruitless work attempts on the Sabbath :-)

[I'm Welsh. We have plenty of jokes about people working on the Sabbath.]

Mark Morgan Lloyd wrote

So. I'd suggest that you start off with Martin's binary, build the matching 2.6.4,

FPC 2.6.4 has no support for EABIHF AFAIK. I have a patched 2.6.4 version with EABIHF support but I suggest to use FPC 3.0 or fixes_3_0 instead. I am sure Bo knows where to get it. ;-)

Martin

Sources yes, I have checked out something like 4 different source trees by now.
But the binaries are another deal...
What is EABIHF?
So you think that fixes_3_0 would be a better fpc on my RPi2?

I fear you do not read my mails.
http://sourceforge.net/projects/mseide-msegui/files/fpcarm/

What is EABIHF?

The application binary interface of RaspberryPi.

So you think that fixes_3_0 would be a better fpc on my RPi2?

Yes. And I recommend to use cross compiling and debugging from a X86 Linux PC: http://www.mail-archive.com/lazarus%40lists.lazarus.freepascal.org/msg50406.html

Martin

Agreed, best place to start.

> What is EABIHF? The application binary interface of RaspberryPi.

HF variant of the ARM (E)ABI.

> So you think that fixes_3_0 would be a better fpc on my RPi2? Yes. And I recommend to use cross compiling and debugging from a X86 Linux PC: http://www.mail-archive.com/lazarus%40lists.lazarus.freepascal.org/msg50406.html

On that we'll have to disagree. The RPi, particularly the 2, is an entirely adequate computer in its own right.

Sure but the accustomed development environment (tools, documentation, version control, useful links, mail and mailinglists...) must first be installed and maintained separately.
I find it much more convenient to use a single "every day" development environment for all tasks.

Martin

On the balance, particularly when one has something as capable as the RPi2, I don't. What I do find useful is being able to cut-and-paste between (programs running on) different hosts, which in practice either means running the IDE over SSH or having something running on each computer to implement a shared clipboard.

I had to leave the RPi pascal/Lazarus stuff for a while, but now I am checking the messages on the list again...

I agree on the tools side after trying to work on the RPi via TinyVNC for a while...

- Version control
We use CVS at our company since 14-15 years, so I installed cvsnt on the RPi in order to use that against our company server. I had done this on a Linux Mint 13 virtual machine earlier.
Problem: With the Pi I did not manage to set up the VPN connection to the company so I would be able to use it.
This is a showstopper.

- Copy/Paste
When asking about things here I wanted to copy code off the Pi and paste it on my PC. But TinyVNC and Lazarus do not work well together so if I Copy in Lazarus I have to first paste inside the VNC window into a text editor, only then is it possible to also paste in the PC. Inconvenient.

With a VMWare virtual machine it is possible to:
1) Share the host's VPN channel to the company so CVS works.
2) Copy/Paste in both directions
3) Drag-Drop files between the systems

So I think I will re-visit the Linux on x86 with cross-compilation again. This I think was my path when I asked here first... But I thought the cross-compile looked difficult to set up. Maybe not now any longer.

If one goes Linux Mint, what version is the one I should choose to get FPC/Lazarus working in the easiest way with cross compilation for ARMHF?
I don't want to be on an unstable/unsupported distribution.

[...]

I use 32 bit OpenSUSE 13.1. And I strongly suggest to drop CVS and to use git instead. ;-)
There is even a git client GUI written in Free Pascal: http://sourceforge.net/projects/mseuniverse/

Martin

Not so easy, since the company version control uses CVS since many years. Switching to something else is a major engagement... Of course I could use something newer myself locally, but the idea is to have everything in the company version control system.

It is probably possible to use git locally by an import of the CSV history https://git-scm.com/docs/gitcvs-migration
and to fetch/push the changed files from/to the CSV server.

Martin

Martin Schreiber wrote

It is probably possible to use git locally by an import of the CSV history https://git-scm.com/docs/gitcvs-migration and to fetch/push the changed files from/to the CSV server.

http://www.oak.homeunix.org/~marcel/blog/2009/06/03/tracking-cvs-with-git-using-cvs2git Please continue the thread on mseide-msegui-task if you like:

https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

http://dir.gmane.org/gmane.comp.ide.mseide.user

It is less strict regarding subject matter than fpc-pascal.

Martin

That's unfortunate but I don't have sufficient VPN experience to be able to offer a fix (and this isn't the right place to try to thrash it out). However I don't see why it should be happening, the RPi- particularly the RPi2- is basically "just a computer" and stuff that runs on a PC should run happily on it- /unless/ Raspbian has fouled up NetworkManager (which I normally disable since it breaks various networking things that I want to run) or systemd configuration.

I notice that there is now a pukka Debian for the RPi2 (/not/ for the original RPi) and intend to investigate it because there are far too many services exposed by Raspbian to make it a viable platform for e.g. a firewall or mailserver.

http://sjoerd.luon.net/posts/2015/02/debian-jessie-on-rpi2/

As I've said repeatedly, sort out your SSH so that you can tunnel an X session over it. That will fix your C&P problems.

Hello everybody,

Could we please stick to FPC related topics on this list? I don't think that VPN connectivity and discussion about version control systems fit this definition. Feel free to continue these discussions in the mailing list fpc-other.

Thank you

Tomas
(one of FPC mailing list moderators)