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

Bug#615513: release.debian.org: armhf inclusion into the archive



On Wed, Jan 4, 2012 at 12:24 AM, peter green <plugwash@p10link.net> wrote:
> Luke Kenneth Casson Leighton wrote:
>>
>> On Tue, Jan 3, 2012 at 10:54 PM, Adam D. Barratt
>> <adam@adam-barratt.org.uk> wrote:
>>
>>
>>>
>>> (fwiw, the not-yet-built list includes webkit and ruby1.9.1, each of
>>> which have a number of other packages directly or indirectly stuck
>>> behind them).
>>>
>>
>>
>>  ahh... webkit.  do you have a system anywhere that has 2gb of RAM?
>> if not, i strongly strongly advise skipping the debug builds on any
>> webkit library.
>>
>>  as webkit is mostly c++ and as pretty much everything goes into one
>> massive library with hundreds of object files that are very closely
>> inter-dependent, linking the library requires a whopping 1.5gb of
>> *resident* memory in order to complete within a reasonable amount of
>> time.
>>
>>  anything outside of that - even by a marginal amount - will result in
>> the build machine absolutely thrashing its nuts off.
>>
>>  1gb is not enough (tried it...).  1.5gb will not be enough.  2gb is
>> the bare minimum for the link stage
>
> Well anthiel built the armel webkit package (including debug packages)
> successfully and according to the machines database it only has 1.5Gb of
> ram.
> OTOH the build DID take 33 hours.

 :)  90% of that will have been absolute thrashing the nuts off the
hard drive during the link phase.

 increase that RAM to a mere 2gb and it'll drop drastically to about 3
hours, with the link phase taking only about... *guesses* 20 mins
instead of 30 hours.


> Furthermore the failure on armhf didn't look like a timeout to me, the error
> was "ERROR: can't resolve libraries to shared libraries:
> javascriptcoregtk-3.0, webkitgtk-3.0".

 hmmm... those are internal libraries which are private to webkit.
they get linked into libwebkitXYZgtk-N.N which is the public library
but the symbols in those two libraries must *not* be made publicly
accessible (nor the header files made available either).

 so if the build tries to do anything fancy/special by moving those
out of the location they're supposed to be in to stop them being
public... just speculation but something to watch out for.

 l.



Reply to: