I'm experimenting with building fpc from source in various combinations and a couple of issues have come up which could be bugs or just me not knowing which environment variables to set.

The build environment is a clean install of Linux Mint 17.2 Cinnamon (64 bit) with fpc 2.6.4 installed from the binary distribution. fpc-build-3.0.0.tar.gz is then expanded into my home directory and I start off by cd-ing into the directory and starting the build with:

make all NOGDB=1

This seems to happily build the compiler and libraries for the default environment. I then do a test install with:

make install NOGDB=1 INSTALL_PREFIX=/tmp/fpc

All seems to be installed fine expect for two things:

1. Missing softlink.
==============

The make install does not add the softlink:

ln -s /tmp/fpc/lib/3.0.0/ppcx86 /tmp/bin/ppcx86

I originally came across this problem when installing over 2.6.4 when everything was OK expect that the old softlink /usr/bin/ppcx86 had been left in place with the result that the new compiler was being ignored when I call "fpc -iV" (i.e. 2.6.4 was still the active compiler).

2. Package.fpc is not installed
=======================

This seems to affect all packages. The problem comes up when compiling the lazarus sources. For example:

I now install fpc 3.0.0 with

make install NOGDB=1 INSTALL_PREFIX=/usr

and fix the softlink.

extract a copy of lazarus 1.6.0rc2, cd to its directory and then run:

fpcmake

it fails with "Error: Target "linux", package "regexpr" not found".

I can maually create regexpr's "Package.fpc" and copy it to "/usr/lib/fpc/3.0.0/units/x86_64-linux/regexpr". Repeating the above then results in the error "Error: Target "linux", package "fpmkunit" not found" and so on.

For some reason the package Package.fpc files are not being generated by the fpc build install process.

So, are these bugs or am I just missing something?

Tony

"Tony Whyman" wrote

I'm experimenting with building fpc from source in various combinations

and a couple of issues have come up which could be bugs or just me not knowing which environment variables to set.

The build environment is a clean install of Linux Mint 17.2 Cinnamon (64

bit) with fpc 2.6.4 installed from the binary distribution. fpc-build-3.0.0.tar.gz is then expanded into my home directory and I start off by cd-ing into the directory and starting the build with:

You should use fpc-src-3.0.0. fpc-build is for building a release installer.

Regards,
Sven

This is as designed.

The symlink is only installed with the installsymlink make target in the compiler directory.

Michael.

OK, done that - with the same result. Both issues are still present.

Michael Van Canneyt wrote

This is as designed. The symlink is only installed with the installsymlink make target in the compiler directory.

Why? This means that "make install" is effectively broken as the symlink is essential for the compiler to work.

Tony Whyman wrote on Fri, 29 Jan 2016:

Because "make install" is often used to install development versions of FPC, and the you don't necessarily want it to change the default compiler version at the same time.

This means that "make install" is effectively broken as the symlink is essential for the compiler to work.

It is not essential, you can always call it explicitly via e.g. /usr/local/lib/fpc/3.0.0/ppc386

Jonas

I am not convinced that it is a good idea for the default install to result in a broken system.

Wouldn't it be better to have a "NOSYMLINK" environment variable instead to handle the developer versions? Failing that a "README" file giving basic build instructions could be useful or a final message on install completion saying something like "Now run make -C complier installsymlink to complete the installation".

BTW, the most up-to-date instructions I have been able to find on building fpc from source is buried in the wiki under a page titled "Installing Lazarus", and that suggests creating the symlink manually.

Tony Whyman wrote on Fri, 29 Jan 2016:

It just does not make the newly installed compiler the default compiler. The newly installed compiler is available and fully functional. Resorting to hyperbole is not useful. Besides, there is another thing that a "make install" does not do, namely updating the fpc.cfg configuration file to the newest version. It just installs the compiler, utilities and units.

BTW, the most up-to-date instructions I have been able to find on building fpc from source is buried in the wiki under a page titled "Installing Lazarus", and that suggests creating the symlink manually.

The wiki is in fact probably the best case to collect this information, because otherwise there are always scenarios not covered by the readme that some people will need, such as cross-compiling under platform X or for platform Y. A readme pointing to a wiki page would probably be a good idea though.

Jonas

Tony Whyman wrote

I am not convinced that it is a good idea for the default install to result in a broken system.

It's not broken.

As jonas said, make install is used a lot to install a new version, but that doesn't mean you want to make it the default version.

Do not forget that using makefiles implies that you already have a working version.

But maybe we can add a

make distinstall

target (target name debatable) on the FPC root directory that calls

make -C compiler installsymlink

which would then proceed to do what you want on unix systems. If the make info or help mentions this, it should be OK.

Michael.

I wonder whether a useful compromise would be to install a sufficient symlink that fpc -V reaches a plausible binary. After all, I'm sure I'm not the only person who has a symlink layer like ppcx86-3.0.0 and having ppcx86 forcibly overwritten before I was ready for it might not be what I wanted.

I think that my concern is that I fell into a simple trap. Now I know it's there I probably won't do it again - but I want to report it so that others don't do the same thing.

The problem is that intuitively "make install" should install a working program or bring an existing one up-to-date. Clearly, in FPC, that is not true and it installs a program suitable for testing with a separate action needed to make it the live version. Ideally, there should be a separate "make testinstall" for a test system and with "make install" having its usual semantic. However, it seems to late to change that.

A message emitted at the end of "make install" along the lines of "now enter make -C compiler installsymlink" would have probably stopped me falling into the trap and I think that would be a good thing to add to always remind the user about the extra step to make the compiler the live version.

However, it may also be worth adding a warning message to the fpc binary to warn when the selected symlink points to a binary with a different version number to fpc. That could also be useful diagnosing broken or partly updated installations.

Tony