Re: [fpc-devel] fpc fails to link against libc on some architectures due to multiarch
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.
--- fpc-2.4.4/debian/rules 2011-07-04 22:41:08.0 +0100
+++ fpc-2.4.4.new/debian/rules 2011-08-18 08:35:48.0 +0100
@@ -62,6 +62,7 @@
DEB_UPSTREAM_VERSION:=$(shell echo $(DEB_VERSION) | cut -f 1 -d -)
DEB_UPSTREAM_MAIN_VERSION:=$(shell echo ${DEB_UPSTREAM_VERSION} | sed -e 's/^\([0-9\.]*\).*/\1/')
DEB_BUILD=$(lastword $(subst -, ,${DEB_VERSION}))
+DEB_BUILD_MULTIARCH:=$(shell dpkg-architecture -qDEB_BUILD_MULTIARCH)
ifndef PACKAGESUFFIX
export PACKAGESUFFIX=-${DEB_UPSTREAM_MAIN_VERSION}
endif
@@ -205,6 +206,9 @@
# Install configuration files
/bin/bash fpcsrc/compiler/utils/samplecfg \
/usr/lib/fpc/${DEB_UPSTREAM_VERSION} ${INSTALL_DIR}/etc
+ # Add multiarch path to /etc/fpc.cfg so executables linked against libc can be corectly linked
+ echo # multiarch library search path ${INSTALL_DIR}/etc/fpc.cfg
+ echo -Fl/usr/lib/$(DEB_BUILD_MULTIARCH) ${INSTALL_DIR}/etc/fpc.cfg
${MV} ${INSTALL_DIR}/etc/fpc.cfg ${INSTALL_DIR}/etc/fpc-${DEB_UPSTREAM_MAIN_VERSION}.cfg
# Install RTL demos
$(MAKE) -C demo sourceinstall $(INSTALLOPTS) INSTALL_SOURCEDIR=$(DOC_DIR)/fp-compiler/${DEB_UPSTREAM_MAIN_VERSION}
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpc fails to link against libc on some architectures due to multiarch
On 12 Aug 2011, at 22:33, 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___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] fpc fails to link against libc on some architectures due to multiarch
reassign 636802 fpc thanks From my testing on armel I now belive that the issue causing the lazarus build failures is a problem with freepascal and multiarch. I haven't tried to troubleshoot the issue on powerpc or sparc as I don't have access to them but I presume it is the same issue. 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 . ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
