peter green wrote

On armel the problem seems to be that freepascal can't find crti.o in the new multiarch path. Confusingly if freepascal can't find crti.o then rather than throwing an error it simply omits it from link.res. Manually pointing freepascal at the multiarch path by using -Fl/usr/lib/arm-linux-gnueabi (for armel) allows the test program to be built successfully. I presume the problem is the same on powerpc and sparc but I have no way of testing those. So it would seem that the multiarch library path for the relavent architecture needs to be added to the default freepascal search path either through adding it to the default configuration file or adding it to the hardcoded list in fpcsrc/compiler/systems/t_linux.pas .

Is there a standard for multiarch library path locations and names? If not, that sounds like configuration option that should be added by distribution-specific patches. At least when looking at tool chains I've seen everything from 'arm-unknown-eabi" to 'arm-linux-eabi' to 'arm-linux-gnueabi'. That kind of variation is not something we can or should build into the compiler or in the standard configuration files.

Jonas

tags 636802 +patch
thanks

Note: jonas's reply was only posted to fpc-devel, not to the debian bug report , a copy can be found at
http://lists.freepascal.org/lists/fpc-devel/2011-August/025444.html

Jonas Maebe wrote

Is there a standard for multiarch library path locations and names?

Multiarch seems to be a debian/ubuntu creation. Debian and ubuntu seem to be consistent at least on i386 and amd64. I'm not sure what the situation is with arm ports of ubuntu (note that multiarch triplets are supposed to represent an ABI so two arm ports with incompatible ABIs are supposed to have different multiarch triplets).

If not, that sounds like configuration option that should be added by distribution-specific patches.

I've attatched a patch to debian/rules to add the multiarch path to the configuration installed by the debian package.