Need password updated on 'uclibc.org' server...

[Steven J. Hill]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello.

I can still login to the 'uclibc.org' server via SSH with my private/public
keypair. However, I need to have my password reset on that machine. Could
someone please reset for me? Thanks.

Steve
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkzQ8JQACgkQgyK5H2Ic36cDGACeLi6SOr54B6hIthSJ7CS7XWUO
rngAnRcud4TQwhe8O/rMa+dE1a8ZQWF8
=Cp6P
-END PGP SIGNATURE-
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Status of uClibc NPTL and C++ on ARM

[Steven J. Hill]

> As I understand it, NPTL has been ported to uClibc and there is support
> for ARM, but it's currently living on a branch at
> http://uclibc.org/cgi-bin/viewcvs.cgi/branches/uClibc-nptl.  Right?
> 
No, the ARM NPTL support is in patch form and has been posted to the
list. MIPS and SuperH NPTL support are in the branch. I am finishing the
merge and testing to then move both of those architectures to the trunk.
After that, then the ARM support will be brought in. For now, if you
want ARM NPTL support, go grab the patches.

> In general, POSIX thread cancellation does not work well with C++ as
> destructors are not called during cancellation.  In glibc+NPTL,
> however, destructors are called (though code in catch blocks might not
> be?) as the cancellation handler unwinds the stack.  Can anyone confirm
> whether this feature has or hasn't been included in the uClibc port of
> NPTL?  Has anyone tested it?  I guess that there may be some
> architecture-specific stuff in the stack unwinding, so maybe I also
> need to add "...for ARM" to the question.
> 
I know how to spell 'C' '+' '+' and that's about it. Someone else can
answer your question on that.

-Steve
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc

Re: svn commit: branches/uClibc-nptl/libpthread/nptl/sysdeps/generic

[Steven J. Hill]

On Mon, Jan 21, 2008 at 09:25:41AM +0100, Carmelo AMOROSO wrote:
>
> this has broken build on sh4. C_LABEL is used into ENTRY macro defined
> into libpthred/nptl/sysdeps/sh.
> Likely you forgot to add it into another place ? I'm not going to fix it 
> into nptl branch waiting
> your feedback.
> 
Carmelo,

Very sorry about that. I was certain I did a 'grep -r' which would have
caught that. Please revert my change or I can do it this afternoon.
Thanks.

-Steve
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc

NPTL merge status...

[Steven J. Hill]

I just wanted people to know that NPTL merging is not standing still. I
have Carmelo's latest changes and am integrating and testing a lot with
MIPS to make sure nothing breaks for that architecture. I am spending
time on this every evening right now, so I am really trying to get the
merge wrapped up. Thanks for your patience.

-Steve
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc

Re: Ping Re: Text relocations in PIEs

[Steven J. Hill]

> > (Might not apply when objects are PIC by default as on MIPS; tested on 
> > ARM.)
> > 
> yes. I can confirm that on ARM.
> 
Please confirm that the patch works and then commit. Thanks Khem.

-Steve
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc

Re: Ping Re: Text relocations in PIEs

[Steven J. Hill]

> Ping.  This patch 
>  is pending 
> review.
> 
Do you have a test case to show how it fails and then it passes when
the patch is applied? Thanks.

-Steve
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc

NPTL development and merging.

[Steven J. Hill]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello.

I have very much desired to get back to working on NPTL and merging everything
into the trunk from my branch. This evening the first of those went in. I am
going to merge the SuperH port into the NPTL branch first and then examine the
NPTL fpr ARM. SuperH is first since it was based from my branch and ARM will be
a bit more work to get merged in. I have had many private emails asking about
NPTL, so consider this an answer to all of them. Personally, I would like to see
another uClibc release before bringing in the NPTL changes which will hammer the
crap out of the codebase in trunk. Regardless, thank you all for your immense
patience. After MIPS, SuperH, and ARM NPTL support is in I would like to see the
PowerPC architecture get NPTL. Yes, I have some work done on NPTL PowerPC. No,
you can't see it...yet. Stay tuned.

- -Steve
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHOTGQgyK5H2Ic36cRAlTNAJ9WPv2KK+9xsH/mqZZjNHqO1Pdn+ACZAX75
xmMDjjMcugHeHhVqU1iDHIU=
=EwsC
-END PGP SIGNATURE-
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc

Re: Now I'm curious...

[Steven J. Hill]

> 
> Have you built nptl for arm7 no-mmu?   I'm woried that I may be making
> the effort to integrate it into our build for a big let down and
> debugging effort in the end. 
> 
It will not work. Using NPTL on a no-MMU system is going to be pretty
worthless IMHO. You should stick with linuxthreads. Not only does it
make doing TLS difficult, the performance is going to suck. Also, the
stuff from CodeSourcery will not support no-MMU.

-Steve
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc

Re: Now I'm curious...

[Steven J. Hill]

On Wed, Sep 05, 2007 at 02:52:11PM +0200, Christian MICHON wrote:
> 
> so, the "NPTL stuff" is ready...
> 
My branch contains a fully working NPTL for the MIPS architecture only.
I have patches from CodeSourcery for ARM and ST Microelectronics for
SuperH 4. Those are the only three architectures supported at this time.

> is it fully available somewhere now or it cannot be released ?
> 
The MIPS stuff is the 'uClibc-NPTL' branch. ARM and SH4 are in my mail
folders somewhere if you are interested.

-Steve
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc

Re: Now I'm curious...

[Steven J. Hill]

> 
> As I see it, there are basically these possible courses of action:
> 
> * Change nothing; or
> 
Which is bad.

> * Ask current uclibc maintainers and Peter whether they are interested
>   in applying his work to svn, having him continue to work on svn head and
>   him putting out releases, at which point further stabilization
>   of release branch is done by current uclibc maintainers
>   and/or Rob Landley; or
> 
I would be interested in applying Peter's work to svn. I either forgot
or was unaware that he maintained his own repository. After finishing
the NPTL stuff, I dropped off on uClibc maintenance and keeping up with
the mailing list. I will take a patch set that fixes a certain bug or
adds a specific feature, but please do not submit a big huge patch that
fixes twenty different things. Also, if you have a reference to a bug
in Bugzilla, let me know that too so we can update its status.

> * Ask Peter to start putting out his own releases _somewhere else_ than
>   http://www.uclibc.org/, and see how good it will be in the long run.
> 
Not a good idea. Let's see what stuff Peter has lurking in his
repository.

-Steve
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc

Re: Now I'm curious...

[Steven J. Hill]

On Tue, Sep 04, 2007 at 01:08:53AM -0700, Nitin Gupta wrote:
> 
> I agree that Peter was a valuable and aggressive contributor. It's sad that 
> instead of communicating
> each other's concerns, "high-profile" committer(s) snatched psm's commit 
> rights.
> 
Your facts are incorrect. Peter voluntarily removed himself and asked
for his account to be deactivated. However, it is still active and he
is welcome to check in changes.

> IIRC, Peter got into trouble as his changes were huge, hard to review and 
> some time broke the build and/or compatability.
> 
This is correct.

-Steve
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc

Re: [PATCH] uClibc/buildroot for Sparc32

[Steven J. Hill]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Your 'uclibc-fix-ulong_t.diff' is rejected because your uClibc repository
is out of date. Your other patch has been applied. Thanks!

- -Steve
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGnYR3gyK5H2Ic36cRAmcmAJwIHs86e0SFgoKsyc35+k9FNSQLPACfVFAm
8B1j9AWGrhv43y9gm3aRFZk=
=iNeP
-END PGP SIGNATURE-
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc

Re: Time based releases for open source projects (a google video)

[Steven J. Hill]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Carmelo Amoroso wrote:
>
> I provided with Steve, some weeks ago, all the patch for the nptl port over 
> SH4.
> He should have had defined a strategy for the merge as he told me...
> probably he is vry busy at this time, anyway I haven't pinged him any more.
>
Guilty as charged. I am actually going to get a chance to work on this while I
am at OLS this upcoming week. I have not forgotten. My 5-week old has been
consuming all of my resources as of late. Thanks for your patience Carmelo!

- -Steve
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGfK2ogyK5H2Ic36cRAtVXAJ984XhvyP1cD8u7eXoNKnaXrUFSgwCeP5JO
90bTkhHKep5CZZ7lTkdzK8Q=
=H8BF
-END PGP SIGNATURE-
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc

Re: Compiling bluez-utils on uclibc gives errors

[Steven J. Hill]

On Thu, Jun 14, 2007 at 03:33:54PM +0800, [EMAIL PROTECTED] wrote:
>
> After taking a look at termios.h, I see that these are commented for
> uclibc.
> 
> #define  B57600   0010001
> #define  B115200  0010002
> #if 0 /* limited on uClibc, keep in sync w/ cfsetspeed.c */
> #define  B230400  0010003
> #define  B460800  0010004
> #define  B50  0010005
> #define  B576000  0010006
> #define  B921600  0010007
> #define  B100 0010010
> #define  B1152000 0010011
> #define  B150 0010012
> #define  B200 0010013
> #define  B250 0010014
> #define  B300 0010015
> #define  B350 0010016
> #define  B400 0010017
> #define __MAX_BAUD B400
> #else
> #define __MAX_BAUD B115200
> #endif
> #ifdef __USE_MISC
> 
> Any reason as to why this is done. Is is ok if I uncomment them and
> compile my source. Any pointers will be very helpful.
> 
I just verified that the file 'libc/termios/cfsetspeed.c' in uClibc
does provide for the usage of the above baud rates. You should be able
to remove the 'if 0' or replace it with 'if 1' and recompile your entire
root file system. Also, if there are no objections, I will check in the
change to remove the 'if 0' since those values are clearly supported.

-Steve
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc

Re: [PATCH-NPTL] environ heeds to be a weak_alias

[Steven J. Hill]

Carmelo Amoroso wrote:
> Hi Steve,
> this patch to fix a problem into nptl branch related to strong_alias
> used for data. Any code linked with the uCLibc-nptl trying to dereference
> the 'environ' variable will segfault.
> This has been already solved in trunk, and there are a lot of posts
> into libc-alpha related to the wrong usage of strong_alias with data.
> 
> I caught a SIGSEV using busybox (env and awk applets). With this patch
> it works fine.
>
Cool. Thank you much.

-Steve
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc

Re: NPTL plans?

[Steven J. Hill]

On Mon, May 28, 2007 at 11:23:58AM +0200, Joakim Tjernlund wrote:
> 
> uhh, I thought that using current trunk was the way to go?
> 
Correct. If there are no objections, I will proceed with placing
NPTL code into trunk.

-Steve
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc

Re: MIPS syscall function

[Steven J. Hill]

Committed. Thank you.
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc

Re: Fix ARM EABI signal unwinding

[Steven J. Hill]

Committed. Thank you.
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc

Re: posix threading plans

[Steven J. Hill]

> For what it is worth, I prefer Carmelos changes to the _dl_find_hash()
> function. 
>
Agreed. Mine is a hack right now and I had not gotten around to using
Carmelos'.

> I would like to see the common changes for NTPL integrated first.
> Also, since this is THE feature for the next release, why not work in
> trunk?
> 
I'm assuming that nightly builds are still being done from trunk? If so,
then I have no problem with this. Nightly builds using linuxthreads will
need to be mandatory.

-Steve
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc

Re: posix threading plans

[Steven J. Hill]

On Tue, May 08, 2007 at 05:27:40PM +0200, Carmelo AMOROSO wrote:
>
> Hi Steve, no problem to distribute the SuperH patches... I've asked my 
> Sys Admin if we can put them
> somewhere on our STLinux website, or simply emailing them to you (and 
> uClibc ML).. I'll notify when done.
> It's up to you to deciding if the changes are too sever or not, and 
> eventually you are free to commit them
> on the nptl branch but my opinion is to start from a new branch from 
> now and avoid double merges
> (for a lot of reasons as in my reply to Mike).
> 
Agreed. Don't worry about sending me patches. I'll go ahead and create a
branch called 'uClibc-NPTL-merge' and we can get going on this.

Mike, can you create write access for Carmelo. For the ARM side, which
person from CodeSourcery is going to do commits?

-Steve
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc

Re: posix threading plans

[Steven J. Hill]

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 more typed.
My stance is to do what is best for the community at large. I am more
than happy resolve the different branches. Carmelo's SuperH stuff is
against the uClibc-NPTL branch last I knew.

My NPTL thread code is from glibc 20050823, clearly older code. Joseph,
what glibc version did you reference for the ARM port?

> so what i'm hearing is:
>  - mips/nptl only exists in branches/uClibc-nptl/
>  - the uClibc-nptl branch is in an unrecoverable state compared to trunk
>  - arm/nptl exists against trunk
>  - sjhill's work and codesourcery's work have some design decisions that need 
> to be reconciled
> 
I would like to have Carmelo's latest patch against uClibc-NPTL branch. If the
changes are not severe, then I would like to get SuperH into the current NPTL
branch first. If there are too many changes, then let's go ahead and create a
new branch and start merging.

Mike, I can create the branch so you can focus on trunk. Carmelo and Joseph,
after I hear back on the glibc reference version for ARM and what state the
SuperH port is in, we can proceed.

-Steve
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc

Re: posix threading plans

[Steven J. Hill]

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 branch development
> I tend to think that Joseph is right and that rebasing on top of a
> clean trunk branch is the way to go.
> 
Do whatever you guys want and I will deal with it.

-Steve
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc

Re: posix threading plans

[Steven J. Hill]

> 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" 
> commit being on 2007-04-21.  This is the issue I explained at 
> : unless every 
> single merge commit (a) merges every change in the relevant range of trunk 
> revisions and (b) states in the log message what those revisions are, it 
> becomes pretty much impossible afterwards to work out what isn't merged, 
> and so which diffs are real changes on the branch (and should be merged to 
> trunk) and which are reversions of changes not merged from trunk (and such 
> reversions mustn't be merged to trunk).
> 
Agreed, I am a little behind right now doing customer releases. I will
gladly type up a status of things if people are interested.

> For this reason, I still think a separate branch based on current trunk, 
> getting only individual logical patches that have be checked line-by-line 
> applied to it, and with no partial merges from trunk made to it, is the 
> way to go.
> 
See below.

> 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 relative to trunk.
> 
No, when I began the NPTL work there was no one from Code Sourcery that
even hinted another architecture was being worked on. There was no
initial collaboration and you guys went your own way. The SuperH people
actually did their work against the NPTL branch and kept me abreast of
the work and made patches and development against the branch.

-Steve
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc