[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: winff fails to build on Armel: unit path of lazarus points to 0.9.30 i.s.o.

Hi Abou and debian-arm readers,

Thanks for the responses.

On 16-01-12 16:09, Abou Al Montacir wrote:
> Unless you precise a path in your project, this is taken from
> ~/.lazarus/environmentoptions.xml and if not found from
> /etc/lazarus/environmentoptions.xml which is handled using alternatives
> system

In my project:

This would be one of the two location where I believe it possible to
"work around" the issue. The other one would be on the build command line:
lazbuild --lazarusdir=something
but it seems to me that the build system should be able to find
everything out by itself. I would hate to maintain the logic here.

>> Abou: 2) Do you have any idea how to solve this problem (in Lazarus, or
>> in Winff)?
> Probably we need to check is the machine have an old /etc/lazarus
> configuration

Does anybody on the debian-arm list have access to the build machine to
take a look for us? To me it seems that something like this must be the
case. If really needs be, I could try to "cat" it in my next upload, but
that seems really ugly.

>> All: 3) Do you have any debugging hints as I don't have access to an
>> armel machine yet, but I did get a response on the mentors list that
>> said he could not reproduce the problem on a QEMUed armel chroot [3].
> Yes, add in your rules file the above command (update-alternatives
> --display lazarus)

If no response comes I will do that, although (as you note below
yourself) I don't believe this is really the problem.

> From what I can see, the installation process was OK and was
> configured as the default LCL.
> Setting up lcl-utils- ( ...
> update-alternatives: using /usr/lib/lazarus/ to provide /usr/lib/lazarus/default (lazarus) in auto mode.
> So on this machine, I want to say that the default LCL that will be used
> is However clearly here something forces using the 0.9.30 as I
> can see in your build log.
> Can this be stored in winff.lpi? But in this cas it will fail on other
> systems (chroot in the above message).

I can not find it (I put the text higher in this mail) and I don't
believe so as winff has build without problems on all other
architectures AND on an other armel buildd, so I really believe it is
something specific to that buildd. Also other people have not been able
to reproduce this problem in their armel environments.


Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: