For those reading this on fpc-devel the context is that the upload of fpc 2.6.2 to debian failed on most architectures and I would like upstream input on sorting it out.

Abou Al Montacir wrote

Many targets are broken: powerpc, sparc, armel, armhf. The error message looks very similar on 3 targets (powerpc, sparc and armel) but not for armhf.

I've sorted the armhf specific issue. As expected it just required some tweaking of ifdefs so that the code in question wasn't used when building the rtl with 2.6.0. After sorting that issue it failed with much the same linker problem with fpmake as other architectures.

I figured out the cause of this one. To successfully link against libc on many platforms (but NOT i386 and amd64) fpc needs to find certain libraries (/usr/lib/crt?.o iirc). To make things more confusing if it doesn't find them it silently leaves them out of the linker script and the build fails with missing symbol errors. This was discovered some time ago. On debian versions that support multiarch the libraries in question can be found in /usr/lib/<multiarch triplet>

For programs that users build we got arround this some time ago by adding a line to fpc.cfg but that doesn't work for stuff that is built as part of the build process itself like fpmake because the fpc build process (deliberately) ignores fpc.cfg. So the option to make it look int the right place needs to be passed in explicitly. Unfortunately I haven't managed to make the fpc build process pass that in. I vaugely remember an option called something like FPMAKEOPT but I can't seem to find any evidence of it in the 2.6.2 source tree.

Another way of solving the problem would be to add /usr/lib/<multiarch triplet> to the paths that are baked into the compiler (as is done for gcc in debian). IMO this is the best soloution but last time I mentioned this to upstream they didn't seem to keen on the idea.

Yet another option would be to disable threading support in fpmake but i'd rather not go down that road.

In our previous episode, peter green said:

I've sorted the armhf specific issue. As expected it just required some tweaking of ifdefs so that the code in question wasn't used when building the rtl with 2.6.0. After sorting that issue it failed with much the same linker problem with fpmake as other architectures.

After some discussion, something to try:

try adding -dNO_THREADING to CROSSOPT (for target) and maybe also to OPT (for host)

It will disable threading inside fpmake by not USESing cthreads, eliminating the need for cross-linking to being said, I don't like FPC simply silently dropping those objectfiles. That should be improved, please file a bug (but I think that is more something long term for trunk, not 2.6.2)

Unfortunately it seems that at least when building natively (note: debian is and always has been natively built) neither OPT or CROSSOPT is passed to the build of fpmake. I asked about this in the past ( http://bugs.freepascal.org/view.php?id=21547 ) and was told it was by design.

It will disable threading inside fpmake by not USESing cthreads, eliminating the need for cross-linking to work at all.

Disabling threading is the last resort option but really I just want to pass the path to the compiler, I know where it should be looking. The bug report I mentioned above claims there is a FPMAKEOPT variable but I couldn't find any evidence of it in the 2.6.2 source tree. Maybe it appeared after the 2.6 series was branched (last time I ran into this issue I was dealing with trunk)

The good news is I found out I can pass the setting in through the "FPCFPMAKE" variable. fpmake was then built successfully.

I then ran into the same link problem building fpdoc. I was able to work arround that one through the "OPT" variable.

While i've managed to get the debian 2.6.2 package to build I still feel that the best soloution long term is to add the multiarch library paths to the compiler itself. Debian/ubuntu are two of the biggest linux distros, their use of multiarch paths isn't going to go away and while we distro packagers can work arround the fact that the compiler looks there by default end users who use the upstream release directly are likely to be somewhat phased by it (especially because of the way the compiler fails in a non-obvious way). I got a fairly negative response to that last time I suggested it to you guys (don't remember if it was on irc or the mailing list) but since then I notice someone has gone ahead and added the multiarch paths for armel and armhf to the default search path in trunk.

grep -r arm-linux-gnu *
compiler/systems/t_linux.pas:
LibrarySearchPath.AddPath(sysrootpath,'/usr/lib/arm-linux-gnueabihf',true); compiler/systems/t_linux.pas:
LibrarySearchPath.AddPath(sysrootpath,'/usr/lib/arm-linux-gnueabi',true); Binary file tests/test/cg/obj/linux/arm-eabi/tcext6.o matches

If they are going to be added for armel and armhf shouldn't they be added for other ports too?

That being said, I don't like FPC simply silently dropping those objectfiles. That should be improved, please file a bug (but I think that is more something long term for trunk, not 2.6.2

http://bugs.freepascal.org/view.php?id=24518

Hi Peter,

I was about committing new changes to fix build issue and saw that you already have fix that.

If you don't mind I'd like to change your patch slightly as follow (cf attached patch)
Please note that fpmake is a build tool which is compiled and ran on host while building the compiler (unless I'm confusing DEB_HOST_TARGET and DEB_BUILD_TARGET). But in any case, doc and fpmake should build for the same target I assume.

Cheers,