[fpc-devel] Re: Accepted fpc 2.6.2-1 (source amd64 all)
peter green
plugwash at p10link.net
Thu May 30 00:53:36 CEST 2013
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.
> /usr/bin/make -C fastcgi smart
> make[3]: Entering directory `/«PKGBUILDDIR»/fpcsrc/packages/fastcgi'
> /«PKGBUILDDIR»/fpcsrc/compiler/ppcppc fpmake.pp -n -Fu/«PKGBUILDDIR»/fpcsrc/rtl/units/powerpc-linux -Fu/«PKGBUILDDIR»/fpcsrc/packages/hash/units/powerpc-linux -Fu/«PKGBUILDDIR»/fpcsrc/packages/paszlib/units/powerpc-linux -Fu/«PKGBUILDDIR»/fpcsrc/packages/fcl-process/units/powerpc-linux -Fu/«PKGBUILDDIR»/fpcsrc/packages/fpmkunit/units/powerpc-linux
> /usr/bin/ld: warning: link.res contains output sections; did you forget -T?
> /usr/lib/powerpc-linux-gnu/libc_nonshared.a(elf-init.oS): In function `__libc_csu_init':
> (.text+0x48): undefined reference to `_init'
> fpmake.pp(30,38) Error: Error while linking
> fpmake.pp(30,38) Fatal: There were 1 errors compiling module, stopping
> Fatal: Compilation aborted
> make[3]: *** [fpmake] Error 1
> make[3]: Leaving directory `/«PKGBUILDDIR»/fpcsrc/packages/fastcgi'
> make[2]: *** [fastcgi_smart] Error 2
> make[2]: Leaving directory `/«PKGBUILDDIR»/fpcsrc/packages'
> make[1]: *** [packages_smart] Error 2
> make[1]: Leaving directory `/«PKGBUILDDIR»/fpcsrc'
> make: *** [build-arch-stamp] Error 2
> dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2
>
> At a first look, it seems related to a particular component (fastcgi),
> but deeper look shows that this is the first package being compiled
> using fpmake (new FP make like utility). The error itself happens while
> compiling fpmake at link stage.
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.
More information about the fpc-devel
mailing list