Carmelo AMOROSO wrote:
Denys Vlasenko wrote:
On Wednesday 10 December 2008 10:06, Carmelo AMOROSO wrote:
Carmelo AMOROSO wrote:
Hi Khem,
I'm seeing similar problem on sh4-nptl as happened to you as you told me
yesterday.. Something recently merged is causing issues.
I'm doing investigation
Khem Raj wrote:
On (10/12/08 17:52), Carmelo AMOROSO wrote:
Carmelo AMOROSO wrote:
Carmelo AMOROSO wrote:
Hi Khem,
I'm seeing similar problem on sh4-nptl as happened to you as you told
me yesterday.. Something recently merged is causing issues.
I'm doing investigation and keep you all
Denys Vlasenko wrote:
On Wednesday 10 December 2008 10:06, Carmelo AMOROSO wrote:
Carmelo AMOROSO wrote:
Hi Khem,
I'm seeing similar problem on sh4-nptl as happened to you as you told me
yesterday.. Something recently merged is causing issues.
I'm doing investigation and keep you all
Carmelo AMOROSO wrote:
Hi Khem,
I'm seeing similar problem on sh4-nptl as happened to you as you told me
yesterday.. Something recently merged is causing issues.
I'm doing investigation and keep you all informed.
Further I'm just writing a detailed report on current status of merge
On 07/12/2008, Ricard Wanderlof [EMAIL PROTECTED] wrote:
On Sat, 6 Dec 2008, Hiroshi Shinji wrote:
Hi Khem,
Thanks for your comment.
2008/12/6 Khem Raj [EMAIL PROTECTED]:
Getting NULL for ifa_addr means that the interface has no address. Do
you know in what cases does this happen. Patch
Bernhard Reutner-Fischer wrote:
On Mon, Dec 08, 2008 at 10:35:50AM +0100, Carmelo Amoroso wrote:
On 07/12/2008, Ricard Wanderlof [EMAIL PROTECTED] wrote:
On Sat, 6 Dec 2008, Hiroshi Shinji wrote:
Hi Khem,
Thanks for your comment.
2008/12/6 Khem Raj [EMAIL PROTECTED]:
Getting NULL
Khem Raj wrote:
On (08/12/08 10:35), Carmelo Amoroso wrote:
On 07/12/2008, Ricard Wanderlof [EMAIL PROTECTED] wrote:
On Sat, 6 Dec 2008, Hiroshi Shinji wrote:
Hi Khem,
Thanks for your comment.
2008/12/6 Khem Raj [EMAIL PROTECTED]:
Getting NULL for ifa_addr means that the interface has
Hi Khem,
I'm seeing similar problem on sh4-nptl as happened to you as you told me
yesterday.. Something recently merged is causing issues.
I'm doing investigation and keep you all informed.
Further I'm just writing a detailed report on current status of merge,
that I can say is almost complete
Bernhard Reutner-Fischer wrote:
On Wed, Dec 03, 2008 at 09:53:18AM -0800, [EMAIL PROTECTED] wrote:
Author: carmelo
Date: 2008-12-03 09:53:17 -0800 (Wed, 03 Dec 2008)
New Revision: 24246
Log:
Rework nptl build system for cleaning headers and objects
to be compliant with all other Makefile.
[EMAIL PROTECTED] wrote:
Author: kraj
Date: 2008-12-01 19:11:25 -0800 (Mon, 01 Dec 2008)
New Revision: 24225
Log:
signed-off-by: Khem Raj [EMAIL PROTECTED]
More merges from trunk to get nptl compiling for arm. Also fix some
errno related linking problems.
Added:
Carmelo AMOROSO wrote:
[EMAIL PROTECTED] wrote:
Author: kraj
Date: 2008-12-01 19:11:25 -0800 (Mon, 01 Dec 2008)
New Revision: 24225
Log:
signed-off-by: Khem Raj [EMAIL PROTECTED]
More merges from trunk to get nptl compiling for arm. Also fix some
errno related linking problems.
Added
Filippo ARCIDIACONO wrote:
-Original Message-
From: Carmelo Amoroso [mailto:[EMAIL PROTECTED]
Sent: Saturday, November 29, 2008 3:25 PM
To: Tobias Poschwatta
Cc: Filippo ARCIDIACONO; 'Carmelo AMOROSO'; uclibc@uclibc.org
Subject: Re: testsuite: wcsxfrm
Tobias Poschwatta wrote
Arvind Kumar wrote:
Hello!
Any clue will be appreciated.
I am running my application on target machine which contain uclibc
version 0.2.29. http://0.2.29. In my application connect system call
is called.
On my Linux host machine, connect system call is failed and errno is
set to
Denys Vlasenko wrote:
Hi Bernhard, folks,
Can you indicate what coding style you prefer
in uclibc?
Hi Denys,
my preferred style is kernel's one, I don't think uclibc has
a preferred one, even if, yesy, a Coding style rules could be useful.
Curretly we have a mixture of all kinds,
GNU
Khem Raj wrote:
On Thu, Nov 27, 2008 at 6:57 AM, Carmelo AMOROSO [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
Author: carmelo
Date: 2008-11-27 06:52:15 -0800 (Thu, 27 Nov 2008)
New Revision: 24165
Log:
Make __UCLIBC_HAVE_ASM_CFI_DIRECTIVES__ visible in case the arch
supports
Tobias Poschwatta wrote:
On Thu, Nov 27, 2008 at 08:45:18AM +0100, Carmelo Amoroso wrote:
Thanks Filippo. Please TObia may you give a try ?
Thanks, works much better now. There are only two failing tests
remaining in locale-mbwc: tst_iswctype and tst_wcswidth. Output
attached.
Thanks
concerns on this.
It will simplify my work a lot.
TIA,
Carmelo
Signed-off-by: Carmelo Amoroso [EMAIL PROTECTED]
Modified:
trunk/uClibc/include/libc-symbols.h
trunk/uClibc/libc/sysdeps/linux/sh/bits/uClibc_arch_features.h
Changeset:
Modified: trunk/uClibc/include/libc-symbols.h
Hi Denys,
among a lot of other stuff, I'm merging into nptl branch your changes
for hidden proto removal. I'd like to test it on nptl.
I've seen that you are commenting out and not removing... I can
understand and that's fine for me... as well as if you are going to
remove other parts, I'll
Tobias Poschwatta wrote:
Hi,
in libc/strings/Makefile.in, it seems that wcsxfrm is included only if
UCLIBC_HAS_LOCALE is selected.
But the test case test/locale-mbwc/tst_wcsxfrm.c is run if
UCLIBC_HAS_WCHAR is selected.
So, if WCHAR is enabled, but LOCALE disabled, the testsuite fails:
Tobias Poschwatta wrote:
On Tue, Nov 25, 2008 at 03:39:08PM +0100, Carmelo AMOROSO wrote:
Fixed in rev 24147.
Please give it a try.
That particular test case works now. Thanks.
Still, because locale is disabled, a lots of tests fail in
test/locale-mbwc with 'can't set locale' messages
Tobias Poschwatta wrote:
On Tue, Nov 25, 2008 at 04:47:11PM +0100, Carmelo AMOROSO wrote:
do you mean at runtime, or while compiling ?
at runtime. All tests compile, now. E.g.:
Ok.
Well firstly locale support is not totally completed
even if recently we did a lot of progresses on this.
My
Tobias Poschwatta wrote:
On Tue, Nov 25, 2008 at 05:19:35PM +0100, Carmelo AMOROSO wrote:
It seems that you don't have these locales built-in.
Are you using pre-generated locale headers ? or are you building
locales data at build time ?
Well, actually, locale is disabled
Denys Vlasenko wrote:
On Friday 21 November 2008 06:22, [EMAIL PROTECTED] wrote:
Author: kraj
Date: 2008-11-20 21:22:12 -0800 (Thu, 20 Nov 2008)
New Revision: 24107
Log:
Add _res_init.c to resolv_CSRC.
Please also add a comment why it is necessary.
Hi Denys,
I erroneously removed it in
×èíêîâ Àíäðåé wrote:
Hi.
I can not build JFFS2 image using buildroot.
My build attempts always crashes with different errors in
.../project_build_mipsel/uclibc/linux-2.6.26.3:
errors are like smth unresolved symbol in object file or unknown type in
C source file..
if you don't
Carmelo AMOROSO wrote:
Peter Kjellerstedt wrote:
Can anyone explain to me why kernel-features.h is placed in
libpthread/linuxthreads/sysdeps/pthread? As far as I can tell
there is nothing pthread related in that file.
Hi Peter,
probably because it has been simply copied from glibc... your
Rob Landley wrote:
On Monday 27 October 2008 15:02:19 Rob Landley wrote:
On Monday 27 October 2008 12:50:13 Carmelo AMOROSO wrote:
Sorry for having confused with multiple patches/proposal and emails.
Currently the dl_iterate_phdr symbols is defined in ld-uClibc.so.0 and
libdl.a. The idea
Bernhard Reutner-Fischer wrote:
On Mon, Nov 17, 2008 at 04:57:41AM +0100, Denys Vlasenko wrote:
Sometime ago I removed string.h related libc_hidden_proto's.
There were a few bumps, but nothing tragic.
So now it sits half-done, something like:
...
/* Experimentally off -
Matt Fleming wrote:
Hi,
the attached patch contains some fixes from linuxthreads HEAD. The patch
should apply against trunk. This patch was initially proposed by Will Newton
on Aug 27, I've just brought it up to date. Amongst other things it fixes a
bug that a customer was seeing with mutex
Rob Landley wrote:
While debugging why the dynamic loader is just not working for me on sparc, I
stumbled across this little gem:
Near the end of ldso/ldso/dl-startup.c we have the only user of the START()
macro:
#ifndef START
return _dl_elf_main;
#else
START();
the constructors.
Signed-off-by: Filippo Arcidiacono [EMAIL PROTECTED]
Signed-off-by: Carmelo Amoroso [EMAIL PROTECTED]
Index: test/tls/Makefile
===
--- test/tls/Makefile (revision 24035)
+++ test/tls/Makefile (working copy)
@@ -3,7
Bernhard Reutner-Fischer wrote:
On Sun, Jul 13, 2008 at 09:08:01AM +0200, Carmelo Amoroso wrote:
Denys Vlasenko wrote:
On Wednesday 09 July 2008 18:59, Carmelo AMOROSO wrote:
Hi Steve, Khem, Mike, all ...
well just an update on the NPTL branch synchmerge work.
Seeing you doing all this, I
Hans-Christian Egtvedt wrote:
On Mon, 3 Nov 2008 17:35:47 -0500
Rob Landley [EMAIL PROTECTED] wrote:
[SNIP]
There are more defines to be cleaned up I think, places where #if is
used when I think it should really have been #ifdef.
It depends on how this is used.
In a simple case just
Rob Landley wrote:
On Monday 27 October 2008 12:50:13 Carmelo AMOROSO wrote:
Sorry for having confused with multiple patches/proposal and emails.
Currently the dl_iterate_phdr symbols is defined in ld-uClibc.so.0 and
libdl.a. The idea is to move into libc.so.0 and libc.a (exactly as glibc
Kevin Day wrote:
On Tue, Oct 28, 2008 at 3:31 PM, Bernhard Reutner-Fischer
[EMAIL PROTECTED] wrote:
Hi,
uClibc-0.9.30-rc3 is out of the door. Please refer to
$ svn log -r23683:23835 svn://uClibc.org/trunk/uClibc
for the ChangeLog between the -rc2 and -rc3.
The tarballs can be downloaded
Carmelo AMOROSO wrote:
Hi,
__syscall_rt_sigaction should accept kernel_sigaction instead on
sigaction, as declared into the bit/kernel_sigaction.h header.
Indeed, each libc function that invoke it, are passing a
kernel_sigaction pointer.
Attached patch tries to fix it.
Cheers,
Carmelo
ganesh sahu wrote:
Hi
Does uClibc is having an system call to get stack information. In
glibc we can print the stack trace through backtrace() function but it
doesn't work in uClibc. So how we can get stack trace information inside
our C code using uClibc.
Thanks
Ganesh
Backtrace
Rob Landley wrote:
On Saturday 11 October 2008 04:00:07 Bernhard Reutner-Fischer wrote:
On Sat, Oct 11, 2008 at 01:38:08AM -0500, Rob Landley wrote:
Just wondering...
Thanks to khem for testing and applying the 4994 patch.
There is a depency problem in locales, i'll fix this during the
that links successfully, but I can't figure out how
to get the crt[ni].o to build otherwise :(
--
Cheers
Kieran
2008/10/6 Carmelo Amoroso [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
Kieran Bingham wrote:
Hi Guys,
I'm currently trying to build uClibc-0.9.30-rc1
Kieran Bingham wrote:
Hi Guys,
I'm currently trying to build uClibc-0.9.30-rc1 for SH2aeb and found an
issue when building which I fixed with the attached patches.
make[2]: Entering directory `/opt/sh/2a/build/src/test-apps-0.1'
sh2aeb-linux-uclibc-gcc -Wl,-EB test.c -o test
test.c: In
Corinna Schultz wrote:
These changes are based on the glibc code that handles ppc32. This
probably shouldn't be in the common dir, but I am unfamiliar with how
to add code into the arch-specific dir. I am also unsure about the
proper symbol to use in the #ifdef; however, this patch worked for
Bernhard Reutner-Fischer wrote:
On Tue, Sep 30, 2008 at 11:29:46PM -0500, Rob Landley wrote:
libc/libc_so.a(memcpy.os): In function `memcpy':
memcpy.c:(.text+0x6e): undefined reference to `WORD_COPY_FWD'
likely something I broke with a recent commit. I'll check it(but cannot
test).
Carmelo AMOROSO wrote:
Bernhard Reutner-Fischer wrote:
On Tue, Sep 30, 2008 at 11:29:46PM -0500, Rob Landley wrote:
libc/libc_so.a(memcpy.os): In function `memcpy':
memcpy.c:(.text+0x6e): undefined reference to `WORD_COPY_FWD'
likely something I broke with a recent commit. I'll check
Bernhard Reutner-Fischer wrote:
Hi,
To be gentle to c89 bootstrap-compilers the attached patch does
basically s/\/\/\(.*\)/\/*\1 *\//g
The corresponding issue is
http://bugs.uclibc.org/view.php?id=5194
The reporter sees this with gcc-4.2.4 without passing -std=c89 to
the compiler
Hi,
__syscall_rt_sigaction should accept kernel_sigaction instead on
sigaction, as declared into the bit/kernel_sigaction.h header.
Indeed, each libc function that invoke it, are passing a
kernel_sigaction pointer.
Attached patch tries to fix it.
Cheers,
Carmelo
Index:
Corinna Schultz wrote:
Quoting Carmelo AMOROSO [EMAIL PROTECTED]:
Does anybody (other than sh4) tried posix_fadvise tests?
Carmelo, I was finally able to test this today. The tests are still
failing for me (I'm on ppc32), though for different reasons than before
:-) . I have not tried
Paul Mundt wrote:
On Mon, Sep 15, 2008 at 01:55:56PM +0200, Carmelo AMOROSO wrote:
Index: libc/sysdeps/linux/sh/bits/syscalls.h
===
--- libc/sysdeps/linux/sh/bits/syscalls.h(revision 23401)
+++ libc/sysdeps/linux/sh/bits
Hi Paul,
please find attached a patch to make SYSCALL_INST_STR macros working on
SH2 too. I've built trunk for sh4 and objdumped some object using
INLINE_SYSCALL, and it looks fine.
Let me know, so I can commit.
Carmelo
Index: libc/sysdeps/linux/sh/bits/syscalls.h
Bernhard Reutner-Fischer wrote:
On Wed, Sep 24, 2008 at 10:53:59PM +0900, Paul Mundt wrote:
uClibc has no equivalent of __stringify()? This should probably be in a
generic header somewhere.
Agree. We only have STRINGIFY in libpthread internals.
Moving to libc-symbols.h (alway included)
I'll look at these two issues soon.
Thanks,
Carmelo
Vallevand, Mark K wrote:
Wow. I just ran into this problem. Or, something very similar. I
reported a memory leak in dlopen() dlclose() last week. I've got a fix
for that problem, and my program doesn't leak any more. But, now its
Fathi Boudra wrote:
On Thu, Sep 18, 2008 at 5:05 PM, Carmelo AMOROSO [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Bernhard Reutner-Fischer wrote:
On Thu, Sep 18, 2008 at 03:29:09PM +0200, Carmelo AMOROSO wrote:
Absolutely agreed. IIRC I should now use
Fathi Boudra wrote:
fails to build on my config.
LD libuClibc-0.9.29.so http://libuClibc-0.9.29.so
http://libuClibc-0.9.29.so
libc/libc_so.a(posix_fadvise64.os): In function `posix_fadvise64':
posix_fadvise64.c:(.text+0x18): undefined reference
yogesh marathe wrote:
I'm trying to execute system( ) call (the one from stdlib.h) in an
application that requires uclibc5 and pthread lib both. System hangs up
when i do so.
Please help me out. Issue is resolves when I do not use pthread library.
Same function is working with uclibc4 with
Carmelo AMOROSO wrote:
Khem Raj wrote:
On Mon, Sep 15, 2008 at 4:55 AM, Carmelo AMOROSO [EMAIL PROTECTED] wrote:
Corinna Schultz wrote:
Quoting Carmelo AMOROSO [EMAIL PROTECTED]:
a colleague of mine is right now working to produce a patch for
posix_fadvise to fix all LTP tests using
AMOROSO wrote:
Bob Wilson wrote:
Carmelo AMOROSO wrote:
Hi Bob,
I don't see any problems in committing this on behalf
of you, but proper signed-off-by should be added
to these set of patches, as a general rule of thumbs.
Possibly Acked-by Xtensa Maintainer (Chris Zankel)
It looks like Chris
Bernhard Reutner-Fischer wrote:
On Mon, Sep 15, 2008 at 01:55:56PM +0200, Carmelo AMOROSO wrote:
Corinna Schultz wrote:
Quoting Carmelo AMOROSO [EMAIL PROTECTED]:
a colleague of mine is right now working to produce a patch for
posix_fadvise to fix all LTP tests using posix_fadvise[64
Search in the list for similar issues. I sugegsted a work-around in the
past. I've got also a complete fix for uclibc, but up to now, never
committed.
Carmelo
P.S.
Please send emails in text/plain, not html
Flemming Madsen wrote:
Hello
First of all: Thank you for all this wonderful stuff!
Khem Raj wrote:
On Mon, Sep 15, 2008 at 4:55 AM, Carmelo AMOROSO [EMAIL PROTECTED] wrote:
Corinna Schultz wrote:
Quoting Carmelo AMOROSO [EMAIL PROTECTED]:
a colleague of mine is right now working to produce a patch for
posix_fadvise to fix all LTP tests using posix_fadvise[64].
Indeed LTP
Rob Landley wrote:
On Tuesday 16 September 2008 01:23:37 Carmelo AMOROSO wrote:
1) How platform specific is it?
Fully, TLS relocations are different from one arch to another.
Ok.
2) Does it actually have anything to do with nptl?
Nothing, just dynamic linker, and obviously your compiler
Will Newton wrote:
On Tue, Sep 16, 2008 at 7:23 AM, Carmelo AMOROSO [EMAIL PROTECTED] wrote:
1) How platform specific is it?
Fully, TLS relocations are different from one arch to another.
2) Does it actually have anything to do with nptl?
Nothing, just dynamic linker, and obviously your
Bernhard Reutner-Fischer wrote:
On Tue, Sep 16, 2008 at 12:28:19PM +0200, Carmelo AMOROSO wrote:
Well, we could ship now with a -rc1. Adding bug fixes as someone have
Consider trunk the RC. bugs.uclibc.org has quite some stuff that
currently does not work and also there were reports
Hans-Christian Egtvedt wrote:
Hi,
I see web is up again, but the mail server seems to be down :/
PS! This email is more or less a check to see if the mail server is
back up again.
Indeed I've sent some messages hours ago and my smtp server could not
reach uclibc.org.
Now I can see your
Rob Landley wrote:
Would anyone like to speculate why make clean and even make distclean
leave tons of .o and .so files in libm and such?
$ find . -name *.o | wc
10861086 30230
Rob
___
uClibc mailing list
uClibc@uclibc.org
Rob Landley wrote:
On Thursday 28 August 2008 09:25:32 Carmelo AMOROSO wrote:
Looking at what we have into the nptl branch is useful.
Walk trough ldso directory and look for USE_TLS to see where you should
put your hands to add TLS support. Working code is a good guide.
Feel free to ask
Corinna Schultz wrote:
Quoting Carmelo AMOROSO [EMAIL PROTECTED]:
a colleague of mine is right now working to produce a patch for
posix_fadvise to fix all LTP tests using posix_fadvise[64].
Indeed LTP tests expect that, when posix_fadvise[64] fails,
it should return as return value an error
Denys Vlasenko wrote:
On Friday 12 September 2008 13:10, Bernhard Reutner-Fischer wrote:
On Tue, Jul 08, 2008 at 08:57:40AM +0200, Carmelo AMOROSO wrote:
Denys Vlasenko wrote:
Hi,
Seems like removal of libc_hidden_proto's for functions
from string.h went without major catastrophes.
I
Bob Wilson wrote:
Carmelo AMOROSO wrote:
Hi Bob,
I don't see any problems in committing this on behalf
of you, but proper signed-off-by should be added
to these set of patches, as a general rule of thumbs.
Possibly Acked-by Xtensa Maintainer (Chris Zankel)
It looks like Chris already
Corinna Schultz wrote:
Quoting Carmelo AMOROSO [EMAIL PROTECTED]:
a colleague of mine is right now working to produce a patch for
posix_fadvise to fix all LTP tests using posix_fadvise[64].
Indeed LTP tests expect that, when posix_fadvise[64] fails,
it should return as return value an error
Bernhard Reutner-Fischer wrote:
On Thu, Sep 11, 2008 at 07:32:09PM +0800, JACOB BENJAMIN-VGH684 wrote:
Hello ppl,
and ran the resultant a.out on a monta vista box
I got an error saying something to the effect of Can't modify text
section. Use GCC option -fPIC for shared objects, please.
I
Bernhard Reutner-Fischer wrote:
Hi,
On Mon, Sep 08, 2008 at 05:35:24PM -0400, Corinna Schultz wrote:
I noticed this difference between glibc and uclibc, in the fadvise
code (I'm trying to track down a bug on a ppc32 machine).
Why the difference in the number of arguments? I don't know
Carmelo AMOROSO wrote:
Carmelo AMOROSO wrote:
[EMAIL PROTECTED] wrote:
Author: vda
Date: 2008-04-09 12:51:18 -0700 (Wed, 09 Apr 2008)
New Revision: 21683
Log:
Factor out the core of vprintf() into separate function
vprintf_internal, so that:
* vprintf() does locking
Carmelo Amoroso wrote:
Bernhard Reutner-Fischer wrote:
On Fri, Jul 11, 2008 at 02:12:51PM +0200, Carmelo AMOROSO wrote:
Filippo ARCIDIACONO wrote:
Hi all,
The following patch solve several locale multibyte tests failures.
It has been tested and works fine.
The patch applies to the latest
Bernhard Reutner-Fischer wrote:
On Tue, Sep 09, 2008 at 05:06:58AM -0700, [EMAIL PROTECTED] wrote:
Author: carmelo
Date: 2008-09-09 05:06:58 -0700 (Tue, 09 Sep 2008)
New Revision: 23365
Log:
Hush compiler for extern inline warnings by using
__extern_inline macro, this also makes gcc 4.3
gargs wrote:
Hi
I am cross compiling a program that is known to work on various other
uClinux platforms, to target blackfin.
When I compile using the blackfin-toolchain-uclibc-default
([EMAIL PROTECTED]), and debug the code using gdb, before the segmentation
fault, I get numerous
Paul Mundt wrote:
On Mon, May 28, 2007 at 02:44:47PM +0200, Carmelo Amoroso wrote:
I've updated the previous patch to keep into account both suggestions
made by Mike and Paul.
A brief explanation of the changes follows:
did you have time to look at this ?
If accepted, may reduce a bit
Rob Landley wrote:
On Sunday 07 September 2008 02:47:49 Carmelo Amoroso wrote:
Rob Landley wrote:
On Wednesday 27 August 2008 05:41:14 Bernhard Reutner-Fischer wrote:
On Wed, Aug 27, 2008 at 11:32:30AM +0200, Natanael Copa wrote:
Hi,
Were there any plans for a 0.9.30 release before the NPTL
Corinna Schultz wrote:
Hello, all.
I'm trying to track down a bug in the fadvise functions. I'm seeing a
failure in the LTP tests for posix_fadvise and posix_fadvise64, on a
ppc 32 machine. The specific failures are:
* in the posix_fadvise64 tests, the function call is still returning
Bernhard Reutner-Fischer wrote:
On Fri, Jul 11, 2008 at 02:12:51PM +0200, Carmelo AMOROSO wrote:
Filippo ARCIDIACONO wrote:
Hi all,
The following patch solve several locale multibyte tests failures.
It has been tested and works fine.
The patch applies to the latest trunk revision.
Any
Rob Landley wrote:
On Wednesday 27 August 2008 05:41:14 Bernhard Reutner-Fischer wrote:
On Wed, Aug 27, 2008 at 11:32:30AM +0200, Natanael Copa wrote:
Hi,
Were there any plans for a 0.9.30 release before the NPTL merge?
What is the status of the 0.9.30 release?
vapier would know, ISTR that
Carmelo Amoroso wrote:
Rob Landley wrote:
On Wednesday 27 August 2008 05:41:14 Bernhard Reutner-Fischer wrote:
On Wed, Aug 27, 2008 at 11:32:30AM +0200, Natanael Copa wrote:
Hi,
Were there any plans for a 0.9.30 release before the NPTL merge?
What is the status of the 0.9.30 release
Carmelo AMOROSO wrote:
Chris Metcalf wrote:
On 9/2/2008 10:25 AM, Chris Metcalf wrote:
On 9/2/2008 10:06 AM, Carmelo AMOROSO wrote:
I had to read it more carefully.. you are right, and yes, probably the
issue you were referring to about static link and pthread was raised
by me
Bernd Schmidt wrote:
Carmelo Amoroso wrote:
When libpthread is included in the link, __pthread_mutex_init will do
the initialization. So, what's going on?
likely you're right ... but this is not true for the nptl branch.
I've almost completed to port a lot of changes from th trunk
Paul Mundt wrote:
On Tue, Sep 02, 2008 at 02:09:20PM +0200, Carmelo AMOROSO wrote:
I did not success to create a test that could fail.
application ctor/dtor defined by gcc attribute ((__contructor__)) on
((__destructor__)) are correctly invoked.
Indeed, if I put the ctor/dtor in a separate
Paul Mundt wrote:
On Thu, Aug 28, 2008 at 07:58:15AM +0200, Carmelo AMOROSO wrote:
Paul Mundt wrote:
On Tue, Aug 26, 2008 at 03:53:18PM +0200, Carmelo AMOROSO wrote:
Takashi Yoshii wrote:
For SH, init/fini function prologue is defined in
libc/sysdeps/linux/sh/crti.S
as follows.
| (frame
Chris Metcalf wrote:
On 9/2/2008 10:06 AM, Carmelo AMOROSO wrote:
I had to read it more carefully.. you are right, and yes, probably the
issue you were referring to about static link and pthread was raised
by me in the past.
It was related to opendir function that is the only function within
Paul Mundt wrote:
On Thu, Aug 28, 2008 at 07:56:03AM +0200, Carmelo AMOROSO wrote:
Carmelo AMOROSO wrote:
Hi Paul, All
attached a little fix in clone asm code for SH to use a delayed branch
instead of a normal branch.
Let me know so I can commit it.
Regards,
Carmelo
Please hold
Paul Mundt wrote:
On Tue, Aug 26, 2008 at 03:53:18PM +0200, Carmelo AMOROSO wrote:
Takashi Yoshii wrote:
For SH, init/fini function prologue is defined in
libc/sysdeps/linux/sh/crti.S
as follows.
| (frame entry)
|#ifndef __HAVE_SHARED__
| (GOT pointer initialization)
|#endif
I think
Bernhard Reutner-Fischer wrote:
On Wed, Aug 27, 2008 at 12:58:50PM +0300, Cristi Magherusan wrote:
Said that, I don't think addign TLS support for i386 is difficult, but
we need someone having time to spend on it.
Do you mean adding TLS support for the old linuxthreads branch on x86?
Carmelo AMOROSO wrote:
Hi Paul, All
attached a little fix in clone asm code for SH to use a delayed branch
instead of a normal branch.
Let me know so I can commit it.
Regards,
Carmelo
Please hold on. After a discussion with a colleague of mine, really sh4
architectural expert, we
argument (hold on r5) is done into the delay slot.
Signed-off-by: Carmelo Amoroso [EMAIL PROTECTED]
Index: libc/sysdeps/linux/sh/clone.S
===
--- libc/sysdeps/linux/sh/clone.S (revision 23105)
+++ libc/sysdeps/linux/sh/clone.S
Takashi Yoshii wrote:
Hi,
For SH, init/fini function prologue is defined in libc/sysdeps/linux/sh/crti.S
as follows.
| (frame entry)
|#ifndef __HAVE_SHARED__
| (GOT pointer initialization)
|#endif
I think this should be ifdef, but ifndef.
Or, are there any reason that GOT should be
Chris Metcalf wrote:
On 7/29/2008 10:50 AM, Carmelo AMOROSO wrote:
Carmelo AMOROSO wrote:
[...]
libc/misc/utmp/utent.c:38: warning: braces around scalar initializer
libc/misc/utmp/utent.c:38: warning: (near initialization for
'utmplock.__data.__spins')
any idea ? I'm not sure it's
Cristi Magherusan wrote:
Hello,
On Fri, 2008-08-08 at 12:15 +0200, Carmelo AMOROSO wrote:
Cristi Magherusan wrote:
Hello,
I noticed that the gentoo uclibc ebuild[1] applies a considerable amount
of patches[2]. Has anyone investigated how many of them worth including
in the main uclibc
Mandeep Ahuja wrote:
Hi everyone,
I have a buildroot which builds uclibc tool chain with busybox1.2.2.1.
When I telnet into my board it says
uclibc login: root
Password:
username is root,
I dont know what the password is? I have tried nothing, blank, root,
rootmenothing worked.
Takashi Yoshii wrote:
Hi,
Hum... I think that we are lucky because _dl_fini is defined in ldso.c
that includes dl-startup.c that includes dl-startup.h... but if
_dl_fini were defined in another compilation units ? does it work ? am
I correct ?
Well, that strange structure of the source
Takashi Yoshii wrote:
Thank you for your review.
I've found some of architectures other than SH set a pointer to _dl_fini()
to rtld_fini in ldso/ldso/*/dl-startup.h, which apparently SH should
have, too.
Yes, we need. please look at my previous reply, where I've a patch
to solve it in a
Takashi Yoshii wrote:
Hi,
As a comment in libc/sysdeps/linux/sh/crt1.S says
/* __uClibc_main (main, argc, argv, init, fini) */
, something wrong here. There should be two more args.
7th arg stack_end seems to be missing.
6th one is not listed, but the original code pushed register
Carmelo AMOROSO wrote:
Takashi Yoshii wrote:
Hi,
As a comment in libc/sysdeps/linux/sh/crt1.S says
/* __uClibc_main (main, argc, argv, init, fini) */
, something wrong here. There should be two more args.
7th arg stack_end seems to be missing.
6th one is not listed, but the original
[EMAIL PROTECTED] wrote:
Author: vda
Date: 2008-04-09 12:51:18 -0700 (Wed, 09 Apr 2008)
New Revision: 21683
Log:
Factor out the core of vprintf() into separate function
vprintf_internal, so that:
* vprintf() does locking and __STDIO_STREAM_TRANS_TO_WRITE thing,
then calls
Carmelo AMOROSO wrote:
[EMAIL PROTECTED] wrote:
Author: vda
Date: 2008-04-09 12:51:18 -0700 (Wed, 09 Apr 2008)
New Revision: 21683
Log:
Factor out the core of vprintf() into separate function
vprintf_internal, so that:
* vprintf() does locking and __STDIO_STREAM_TRANS_TO_WRITE thing
Khem Raj wrote:
On (27/07/08 16:31), [EMAIL PROTECTED] wrote:
Hello!
I am pretty new to this mailing list and the whole uclibc thing and I ave a
question:
I downloaded the pre-installed buildroot toolchain, mounted the image,
copied my sources in it and chrooted in the toolchain.
I am
501 - 600 of 762 matches
Mail list logo
