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: <OtherUnitFiles Value="$(LazarusDir)/components/codetools/units/$(TargetCPU)-$(TargetOS)"/> <SrcPath Value="$(LazarusDir)/lcl;$(LazarusDir)/lcl/interfaces/$(LCLWidgetType)"/> 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 0.9.30.2 was > configured as the default LCL. > > Setting up lcl-utils-0.9.30.2 (0.9.30.2-1) ... > update-alternatives: using /usr/lib/lazarus/0.9.30.2 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 0.9.30.2. 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. Paul
signature.asc
Description: OpenPGP digital signature
