Bug#662814: [fp-utils-2.6.0] fpcmake has internal FPCDIR=/etc/alternatives

[Lutz Lehmann]

Package: fp-utils-2.6.0
Version: 2.6.0
Severity: important


Steps to reproduce:

cp -r /usr/share/doc/fp-compiler/2.6.0/graph /tmp
cd /tmp/graph
fpcmake -v -w

results in

FPCMake Version 2.0.0 [2012/01/13]
Processing Makefile.fpc
Targets: "i386-linux"
Globals:
FPCDIR = "/etc/alternatives"
PACKAGESDIR = "$(FPCDIR)/packages $(FPCDIR)/packages/base
$(FPCDIR)/packages/extra $(FPCDIR)/packages"
UNITSDIR = "$(FPCDIR)/units/$(FULLTARGET)"
BASEDIR = "/tmp/graph"
Required packages for linux-i386: rtl
Package "rtl": Looking for Makefile.fpc:
"/etc/alternatives/rtl/Makefile.fpc
/etc/alternatives/packages/rtl/Makefile.fpc
/etc/alternatives/packages/base/rtl/Makefile.fpc
/etc/alternatives/packages/extra/rtl/Makefile.fpc
/etc/alternatives/packages/rtl/Makefile.fpc "
Package "rtl": Looking for Package.fpc:
"/etc/alternatives/rtl/Package.fpc
/etc/alternatives/units/i386-linux/rtl/Package.fpc "
Error: Target "linux", package "rtl" not found


Obviously, the FPCDIR path is totally wrong, resulting in a useless
search path for the rtl units.
Setting it explicitely by

export FPCDIR=/usr/lib/fpc

has no effect. I found no configuration file responsible for this, so I
assume it is part of the binary file.

Please check if there is something like a reference to the path of
args[0] hard-coded in the sources or build script.

With kind regards, Lutz Lehmann

--- System information. ---
Architecture: i386
Kernel: Linux 3.2.0-1-amd64

Debian Release: wheezy/sid
700 testing ftp.de.debian.org
600 stable security.debian.org
600 stable ftp.uni-kl.de
600 stable ftp.de.debian.org
200 unstable ftp.spline.de

--- Package information. ---
Package: fp-utils-2.6.0
State: installed
Automatically installed: yes
Version: 2.6.0-1
Priority: optional
Section: devel
Maintainer: Carlos Laviola <clav...@debian.org>
Uncompressed Size: 12.4 M
Recommends: fp-compiler-2.6.0 (= 2.6.0-1)
Breaks: fp-compiler (<= 2.4.0-3), fp-units-gfx (<= 2.4.2-2),
fp-units-gfx-2.4.2 (<= 2.4.2-2), fp-utils (<= 2.4.0-3)
Replaces: fp-compiler (<= 2.4.0-3), fp-utils (<= 2.4.0-3)
Provides: fp-utils





--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

[Abou Al Montacir]

On Tue, 2012-03-06 at 16:21 +0100, Lutz Lehmann wrote:

> Steps to reproduce:
>
> cp -r /usr/share/doc/fp-compiler/2.6.0/graph /tmp
> cd /tmp/graph
> fpcmake -v -w
>
> results in
>
> FPCMake Version 2.0.0 [2012/01/13]
> Processing Makefile.fpc
> Targets: "i386-linux"
> Globals:
> FPCDIR = "/etc/alternatives"
> PACKAGESDIR = "$(FPCDIR)/packages $(FPCDIR)/packages/base

...

> Error: Target "linux", package "rtl" not found
>
>
> Obviously, the FPCDIR path is totally wrong, resulting in a useless
> search path for the rtl units.
> Setting it explicitely by
>
> export FPCDIR=/usr/lib/fpc
>
> has no effect. I found no configuration file responsible for this, so I
> assume it is part of the binary file.

This is because /usr/lib/fpc is not a valid FPCDIR path

> Please check if there is something like a reference to the path of
> args[0] hard-coded in the sources or build script.

I'll have a look to that soon. For now I have a quick workaround that I
tested is working:
FPCDIR=/usr/lib/fpc/ fpcmake-2.6.0 -v -w

Cheers,

[Lutz Lehmann]

Am 06.03.2012 17:15, schrieb Abou Al Montacir:
> On Tue, 2012-03-06 at 16:21 +0100, Lutz Lehmann wrote:
>
> This is because /usr/lib/fpc is not a valid FPCDIR path
>

How is that, since it is used below?

>> Please check if there is something like a reference to the path of
>> args[0] hard-coded in the sources or build script.
> I'll have a look to that soon. For now I have a quick workaround that I
> tested is working:
> FPCDIR=/usr/lib/fpc/ fpcmake-2.6.0 -v -w

Sorry, didn't work in my installation. Same error.

2.4.4 was freshly installed, already with this problem, then recently
updated to 2.6.0. Is there something that could
be cleaned up or reconfigured?

Some lazarus bugs seem to have the same problem, rtl not found by
fpcmake. Their workaround was to remove fpcmake from the compilation chain.

Regards, Lutz Lehmann

[Abou Al Montacir]

On Tue, 2012-03-06 at 17:44 +0100, Lutz Lehmann wrote:
> Am 06.03.2012 17:15, schrieb Abou Al Montacir:
> > On Tue, 2012-03-06 at 16:21 +0100, Lutz Lehmann wrote:
> >
> > This is because /usr/lib/fpc is not a valid FPCDIR path
> >
>
> How is that, since it is used below?
> >> Please check if there is something like a reference to the path of
> >> args[0] hard-coded in the sources or build script.
> > I'll have a look to that soon. For now I have a quick workaround that I
> > tested is working:
> > FPCDIR=/usr/lib/fpc/ fpcmake-2.6.0 -v -w
> Sorry, didn't work in my installation. Same error.

Sorry, but I've copyed the wrong line :(
FPCDIR=/usr/lib/fpc/2.6.0 fpcmake -v -w
Indeed, the FPCDIR is versioned to allow multiple tool chains to coexist

> 2.4.4 was freshly installed, already with this problem, then recently
> updated to 2.6.0. Is there something that could
> be cleaned up or reconfigured?
> Some lazarus bugs seem to have the same problem, rtl not found by
> fpcmake. Their workaround was to remove fpcmake from the compilation chain.

Anyway fpcmake is becoming obsolete, upstream is now pushing fpmake.

Cheers,

[Lutz Lehmann]

Am 06.03.2012 18:10, schrieb Abou Al Montacir:

On Tue, 2012-03-06 at 17:44 +0100, Lutz Lehmann wrote:
> Am 06.03.2012 17:15, schrieb Abou Al Montacir:
> > On Tue, 2012-03-06 at 16:21 +0100, Lutz Lehmann wrote:
> > FPCDIR=/usr/lib/fpc/ fpcmake-2.6.0 -v -w
> Sorry, didn't work in my installation. Same error.
Sorry, but I've copyed the wrong line :(
FPCDIR=/usr/lib/fpc/2.6.0 fpcmake -v -w

Indeed, that works. Thank you.

Indeed, the FPCDIR is versioned to allow multiple tool chains to coexist

And at the same time, that seems to be the root of the problem. From educated
speculation I would assume that the FPCDIR is determined such that the binary
"ppc386" resides therein. If this fails for the given environment variable or it is
not given at all, "/usr/bin/ppc386" is assumed to be a link to the library directory
and resolved, but only once, and not recursively.

But since the introduction of the alternatives mechanism "to allow multiple tool chains to coexist",
the destination of "/usr/bin/ppc386" is "/etc/alternatives/ppc386". For some reason, probably
because it was not necessary before, this is not checked to be a link as well, so the wrong path "/etc/alternatives" results. The proper way would be to resolve the links repeatedly
until the destination is not a link.

Anyway fpcmake is becoming obsolete, upstream is now pushing fpmake.

Hopefully, this acts more intelligently for the library path determination.

Regards, Lutz Lehmann