[Lazarus] Lazarus 0.9.30.4RC2 available for download

[Mark Morgan Lloyd]

Mark Morgan Lloyd wrote:
> Mattias Gaertner wrote:
>> On Wed, 07 Mar 2012 21:25:14 +0000
>> Mark Morgan Lloyd <markMLl.lazarus at telemetry.co.uk> wrote:
>>
>>> Vincent Snijders wrote:
>>>> Op 7 maart 2012 20:26 heeft Mark Morgan Lloyd
>>>> <markMLl.lazarus at telemetry.co.uk> het volgende geschreven:
>>>>> Vincent Snijders wrote:
>>>>> What's that from SVN? Some of the naming's beginning to look a bit 
>>>>> ragged.
>>>>>
>>>> The release has been build from this branch:
>>>>> branches/release_0_9_30_4/
>>>>> ..
>>>> The successful build has been tagged:
>>>>> tags/lazarus_0_9_30_4RC2/
>>> OK on x86 Linux. NOT OK on SPARC Linux, get this when attempting to 
>>> open a project:
>>
>> AFAIK no developer has a Sparc machine to test.
> 
> There has been one available here for years, Vincent has used it in the 
> past. However at the moment I'm a little suspicious of it- might have 
> suspect RAM.
> 
>> The patches users sent for Sparc were for 0.9.31 and were all applied.
>> Does 0.9.31 run on Sparc?
> 
> It did until recently ** , I'll check again.

0.9.31 at 35613 using 2.7.1 doesn't exhibit this problem, but it is 
unable to display some project forms (on any platform) for reasons which 
are yet to be resolved (I think I got as far as determining that it was 
specific to GTK2).

0.9.31 at 35818 using 2.7.1 is OK apart from the form problem.

0.9.30.4RC1 built from /tags/lazarus_0_9_30_4RC1 using 2.6.0 has the 
problem.

Which versions do you want me to try next?

> ** Except for a problem that I raised a few weeks ago, where some forms 
> were being mis-read. But that appeared to affect all platforms, and I 
> had to back out due to pressure of other work.
> 
>>> Program received signal SIGSEGV, Segmentation fault.
>>> [Switching to Thread 16384 (LWP 24359)]
>>> 0x006fb770 in SEARCH (ANUNITINFO=0xf673da20, ACOMPONENT=0xf6acabd0, 
>>> parentfp=0xff0adc20) at project.pp:4653
>>> 4653            if (PropInfo^.PropType^.Kind=tkClass) then begin
>>> (gdb) bt
>>> #0  0x006fb770 in SEARCH (ANUNITINFO=0xf673da20, 
>>> ACOMPONENT=0xf6acabd0, parentfp=0xff0adc20) at project.pp:4653
>>> #1  0x006fb2c8 in TPROJECT__UPDATEUNITCOMPONENTDEPENDENCIES 
>>> (this=0xf6c2a4d0) at project.pp:4731
>>> #2  0x000b5b30 in TMAINIDE__UNITCOMPONENTISUSED 
>>> (ANUNITINFO=0xf673da20, CHECKHASDESIGNER=false, this=0xf6e4c0e0)
>>>      at main.pp:7333
>>> #3  0x000b53a4 in TMAINIDE__CLOSEUNITCOMPONENT 
>>> (ANUNITINFO=0xf673da20, FLAGS=[], this=0xf6e4c0e0) at main.pp:7207
>>> #4  0x000bbf58 in TMAINIDE__DOCLOSEEDITORFILE (AEDITOR=0xf61a04a0, 
>>> FLAGS=[CFPROJECTCLOSING], this=0xf6e4c0e0)
>>>      at main.pp:8589
>>>
>>> Not tried other platforms yet.
>>
>> Mattias
>>
>> -- 
>> _______________________________________________
>> Lazarus mailing list
>> Lazarus at lists.lazarus.freepascal.org
>> http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
> 
> 


-- 
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]