Mike Frysinger wrote:
>> clean trunk branch is the way to go.
>> Do whatever you guys want and I will deal with it.
>
> this isnt exactly a helpful stance to take ...
>
Sorry for the shortness of the response, but with my 2 year old son
screaming next to me to play chase, I could not get much mor
On Sun, 6 May 2007, Mike Frysinger wrote:
> seems like it'd be sane to bring at least Joseph and Carmelo on board ?
Note that Jim Blandy and Paul Brook did much more of the ARM work than I
did, so they would probably be better placed for this merging. I don't
think any of us have SVN write acc
Em Domingo 06 Maio 2007 08:20, Mike Frysinger escreveu:
> first, the status of linuxthreads ... when i first introduced the latest
> version of linuxthreads, the upstream status was fully maintained and no
> plans for this to end ... nptl wasnt even being considered. the idea was
> that the versio
On Sunday 06 May 2007, Steven J. Hill wrote:
> Daniel Jacobowitz wrote:
> > I don't think revisiting the unfortunate circumstances is going to get
> > us anywhere. Is there some way we can move on, and end up with a
> > unified port? I don't care how we end up with an up-to-date branch as
> > lon
On Sunday 06 May 2007, rafael2k wrote:
> but one thing I'd really like to ask for is to not remove linuxthreads at
> all (nor in any near future), just like glibc did in 2.5 - so, w/ no
> linuxthreads support, no kernel 2.4 support, wich is very important for old
> pcs (486s)...
there are no plans
woot, and congrats
On 5/6/07, Mike Frysinger <[EMAIL PROTECTED]> wrote:
> tagged, branched, and posted ... 0.9.29 is up
> -mike
>
> ___
> uClibc mailing list
> uClibc@uclibc.org
> http://busybox.net/cgi-bin/mailman/listinfo/uclibc
>
>
--
Christian
___
Daniel Jacobowitz wrote:
>
> I don't think revisiting the unfortunate circumstances is going to get
> us anywhere. Is there some way we can move on, and end up with a
> unified port? I don't care how we end up with an up-to-date branch as
> long as we do; from my experience with long-running bra
Dear David, Mike, Kevin, etc
Thank you all for quick responses. Mike and David were right, it is a
wrapper in rdesktop.c, thanks for pointing it out. Some of the code used
Malloc, some used Xmalloc. So I've made it consistently use xmalloc as it
has error checking
Stil getting segmentation fa
On Sun, May 06, 2007 at 08:53:31AM -0500, Steven J. Hill wrote:
> > The ARM NPTL work was based on trunk at that time (and subsequently merged
> > from newer trunk) precisely because the incomplete and undocumented merges
> > made it infeasible to work based on the NPTL branch without getting
>
On Sun, 6 May 2007, Steven J. Hill wrote:
> > The ARM NPTL work was based on trunk at that time (and subsequently merged
> > from newer trunk) precisely because the incomplete and undocumented merges
> > made it infeasible to work based on the NPTL branch without getting
> > regressions relativ
> I'm still concerned about the incomplete and undocumented status of merges
> from trunk into this branch. If I diff libc/sysdeps/linux/arm/, say,
> between trunk and branch, I see several changes that are reversions of
> patches made on trunk months ago, despite the last "Merge from trunk"
>
On Sun, 6 May 2007, Mike Frysinger wrote:
> the plan for NPTL is to get the extraneous ports and patchsets (like arm and
> sh) floating around merged into the uClibc-nptl branch. then we need to get
I'm still concerned about the incomplete and undocumented status of merges
from trunk into thi
first, the status of linuxthreads ... when i first introduced the latest
version of linuxthreads, the upstream status was fully maintained and no
plans for this to end ... nptl wasnt even being considered. the idea was
that the version of linuxthreads we had in our tree was pretty outdated and
tagged, branched, and posted ... 0.9.29 is up
-mike
signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
On Wednesday 02 May 2007, Nickolai Zeldovich wrote:
> Having a bad patch day apparently. Attached is a version that compiles.
thanks, should be fixed in svn now
-mike
signature.asc
Description: This is a digitally signed message part.
___
uClibc maili
On Thursday 03 May 2007, Harald Krammer wrote:
> I have a question about LD_PRELOAD. Is it possible to use pthread
> functions for preloaded libs or exists any restriction for that?
there should be no such restriction on libraries with LD_PRELOAD
-mike
signature.asc
Description: This is a digita
16 matches
Mail list logo
