"2018-03-07 16:46 GMT+01:00 Graham Inggs <gin...@debian.org>: > On Tue, 23 Jan 2018 08:46:09 +0200 Adrian Bunk <b...@debian.org> wrote: >> >> This problem is unfortunately still present with fpc 3.0.4+dfsg-14: >> >> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/transgui.html > > > This can be worked around by the following change in debian/rules: > > -export FPCDIR=/usr/lib/fpc/${FPCDIR} > +export FPCDIR=/usr/lib/$(DEB_HOST_MULTIARCH)/fpc/default > > However, it was my understanding that this was supposed to be fixed in FPC, > so forwarding to the Pascal list for comment. >
The recent fix in the Debian package of FPC was for the FpMake build system, http://wiki.freepascal.org/FPMake . It tries to auto-detect the standard units location, but can be overridden by $FPCDIR environment variable. The auto-detection was fixed in this case, removing the need for $FPCDIR. It seems that transgui is using an older "fpcmake" system (depending on Makefile which is auto-generated based on "Makefile.fpc" contents). The auto-detection is in a different place then, although it is also overridden by $FPCDIR environment variable. You can see how this works in case of transgui : - This is the source file: https://github.com/transmission-remote-gui/transgui/blob/master/Makefile.fpc - And developer calls "fpcmake" to generate a Makefile like this: https://github.com/transmission-remote-gui/transgui/blob/master/Makefile Searching the generated Makefile, there is a line that tries to auto-guess the FPC library location: https://github.com/transmission-remote-gui/transgui/blob/master/Makefile#L226 . So possibly it can be fixed in FPC package in Debian too. Regards, Michalis
