on theory it would be possible to do an 'inline update' of glibc and
binutils (as an updated glibc clearly expects a newer binutils than the
one in rPL toolchain); current gcc _may_ be able to be enough.
the isn't the core issue. Albeit we diverge more and more from rPL each
day, on the ultra low level stuff (toolchain) we keep consistent with
them, so that our bugs are theirs, and vice-versa.
IMHO it could turn playing Russian roulette to arbitrarily bump parts of
the toolchain, as we do not have any insurance of how things would
behave. (also, rPL/FL current structure doesn't made to turn this things
easy). This is why i want to get into f3 as soon as possible.
Regarding what features from glibc we miss - the 1st ones that come to
my mind are the hooks to interfaces from recent kernels
-eventfd(2.7+)/*notify - that newer udev{,-extras}, and friends, need
and expect.
All the best,
António
On 09/30/2009 02:45 PM, Matt Wilson wrote:
> On Tue, Sep 29, 2009 at 03:28:17PM +0200, Martin Bähr wrote:
>
>> On Mon, Sep 28, 2009 at 02:30:57PM +0100, António Meireles wrote:
>>
>>> we are locked in glibc-2.5 from rPL
>>>
>> could you explain why that is the case?
>> what prevents us from upgrading?
>> is it just the amount of work involved?
>>
> <aol>me too</>
>
>
_______________________________________________
Foresight-devel mailing list
Foresight-devel@lists.rpath.org
http://lists.rpath.org/mailman/listinfo/foresight-devel
