Re: [PATCH] remove duplicate interp from lib-so-y

[Carmelo AMOROSO]

Bernhard Fischer wrote:
> [I've already sent this some time ago and got no response]
> Hi,
>
>   LD libuClibc-0.9.29.so
> ./lib/interp.os:(.interp+0x0): multiple definition of `__dl_ldso__'
> lib/interp.os:(.interp+0x0): first defined here
>
> - interp comes in via LIBs, remove erroneous duplicate prerequisite.
>
> I will apply this patch in a week from now unless somebody objects.
> thanks,
>
> Index: Makerules
> ===
> --- Makerules (revision 22286)
> +++ Makerules (working copy)
> @@ -9,7 +9,7 @@ PHONY := FORCE
>  ifeq ($(HAVE_SHARED),y)
>  .LIBPATTERNS: "lib%.so"
>  libs: $(lib-so-y) $(lib-a-y)
> -$(lib-so-y): $(interp)
> +$(lib-so-y):
>  else
>  .LIBPATTERNS: "lib%.a"
>  ifeq ($(UCLIBC_FORMAT_SHARED_FLAT),y)
>
> ___
> uClibc mailing list
> uClibc@uclibc.org
> http://busybox.net/cgi-bin/mailman/listinfo/uclibc
>   
Hi,
I don't have this problem... instead I'm seeing the the ld.so is linked 
twice
as below

[EMAIL PROTECTED] ~/uClibc-work/SVN/trunk]make -C ldso
make: Entering directory `/home/work/uClibc-work/SVN/trunk/ldso'
  CC ldso/ldso/ldso.oS
In file included from ../ldso/include/dl-syscall.h:12,
 from ../ldso/include/ldso.h:36,
 from ../ldso/ldso/ldso.c:33:
../ldso/ldso/sh/dl-syscalls.h:9:2: warning: #warning !!! gcc 4.1 and 
later have problems with __always_inline so redefined as inline
  AS ldso/ldso/sh/resolve.oS
  AR cr ../ldso/ldso/ld-uClibc_so.a
  STRIP -x -R .note -R .comment ../ldso/ldso/ld-uClibc_so.a
  LD ld-uClibc-0.9.29.so
  CC ldso/ldso/ldso.oS
In file included from ./ldso/include/dl-syscall.h:12,
 from ./ldso/include/ldso.h:36,
 from ldso/ldso/ldso.c:33:
./ldso/ldso/sh/dl-syscalls.h:9:2: warning: #warning !!! gcc 4.1 and 
later have problems with __always_inline so redefined as inline
  AS ldso/ldso/sh/resolve.oS
  AR cr ldso/ldso/ld-uClibc_so.a
  STRIP -x -R .note -R .comment ldso/ldso/ld-uClibc_so.a
  LD ld-uClibc-0.9.29.so
  CC ldso/libdl/libdl.oS


This doesn't happen on nptl branch that doesn' t include recent chanegs 
on build system !

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

Re: Test build failed due to UCLIBC_INTERNAL header rework

[Carmelo AMOROSO]

Denys Vlasenko wrote:
> On Tuesday 10 June 2008 16:27, Carmelo AMOROSO wrote:
>   
>> Hello,
>> recent change on libc_hidden_proto brakes test and utils build.
>> 
>
> Please send your .config
>
> I never did "make utils" before, possibly because I usually do static 
> builds...
> --
> vda
>   
but you should build test at least.. hopefully.
So now that string.h has been changed again, how is UCLIBC_INTERNALS 
maco used ?
is it still required ? please my you explain ?

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

*.dep file not cleaned

[Carmelo AMOROSO]

Should be new *.dep files be cleaned when running 'make clean' ?
I'd expect yes.. or am I wrong ?

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

make realclean does clean twice

[Carmelo AMOROSO]

Hi,
I've seen that *.dep will be removed with 'realclean' target,
but when running it I've seen that make tries to clean files twice
as in the attached log.

Cheers,
Carmelo
rm -f ./ldso/ldso/*.{o,os,oS,a} ./ldso/ldso/*/*.{o,os,oS}
rm -f ./ldso/libdl/*.{o,os,a,oS}
rm -f ./libcrypt/*.{o,os,oS,a}
rm -f ./libintl/*.{o,os,a}
rm -f ./libm/{,*/,*/*/}*.{o,os,oS,a}
rm -f ./libnsl/*.{o,os,a}
rm -f ./libresolv/*.{o,os,a}
rm -f ./libutil/*.{o,os,oS,a}
rm -f ./libpthread/linuxthreads.old/*.{o,os,oS,a}
rm -f ./libpthread/linuxthreads.old_db/*.{o,os,oS,a}
rm -f ./librt/*.{o,os,a}
rm -f ./extra/locale/gen_collate ./extra/locale/gen_wc8bit 
./extra/locale/gen_wctype ./extra/locale/locale_data.c 
./extra/locale/{*.{o,os,txt},gen_locale,gen_ldc}
rm -f 
./extra/locale/{uClibc_locale_data,lt_defines,c8tables,wctables,locale_tables,locale_collate}.h
rm -f ./extra/locale/{lmmtolso,gen_mmap,locale.mmap}
rm -f ./libc/sysdeps/linux/sh/*.{o,os} ./lib/crti.o ./lib/crtn.o ./lib/crt1.o 
./lib/Scrt1.o
rm -f ./libc/sysdeps/linux/common/*.{o,os,oS}
rm -f ./libc/misc/assert/*.{o,os}
rm -f ./libc/misc/ctype/*.{o,os}
rm -f ./libc/misc/dirent/*.{o,os}
rm -f ./libc/misc/error/*.{o,os}
rm -f ./libc/misc/file/*.{o,os,oS}
rm -f ./libc/misc/fnmatch/*.{o,os}
rm -f ./libc/misc/ftw/*.{o,os}
rm -f ./libc/misc/glob/*.{o,os}
rm -f ./libc/misc/gnu/*.{o,os}
rm -f ./libc/misc/internals/*.{o,os,oS}
rm -f ./libc/misc/locale/*.{o,os}
rm -f ./libc/misc/mntent/*.{o,os}
rm -f ./libc/misc/regex/*.{o,os}
rm -f ./libc/misc/search/*.{o,os}
rm -f ./libc/misc/statfs/*.{o,os,oS}
rm -f ./libc/misc/syslog/*.{o,os}
rm -f ./libc/misc/sysvipc/*.{o,os}
rm -f ./libc/misc/time/*.{o,os}
rm -f ./libc/misc/ttyent/*.{o,os}
rm -f ./libc/misc/utmp/*.{o,os}
rm -f ./libc/misc/wchar/*.{o,os}
rm -f ./libc/misc/wctype/*.{o,os}
rm -f ./libc/misc/wordexp/*.{o,os}
rm -f ./libc/pwd_grp/*.{o,os}
rm -f ./libc/stdio/*.{o,os,oS}
rm -f ./libc/string/{,*/}*.{o,os}
rm -f ./libc/termios/*.{o,os}
rm -f ./libc/inet/rpc/*.{o,os,oS}
rm -f ./libc/inet/*.{o,os}
rm -f ./libc/signal/*.{o,os}
rm -f ./libc/stdlib/malloc/*.{o,os}
rm -f ./libc/stdlib/malloc-simple/*.{o,os}
rm -f ./libc/stdlib/malloc-standard/*.{o,os}
rm -f ./libc/stdlib/*.{o,os,oS}
rm -f ./libc/unistd/*.{o,os}
rm -f ./libc/*.{o,os,oS,a}
rm -f ./include/pthread.h \
./include/semaphore.h \
./include/bits/pthreadtypes.h
rm -f ./include/thread_db.h
rm -f include/fpu_control.h include/dl-osinfo.h include/hp-timing.h
rm -f -r lib include/bits
rm -f ldso/*/*.a libpthread/*/*.a libc/*.a libcrypt/*.a libintl/*.a \
libm/*.a libnsl/*.a libpthread/*.a libresolv/*.a librt/*.a \
libutil/*.a lib/*.a
make objclean-y headers_clean-y
rm -f ./ldso/ldso/*.{o,os,oS,a} ./ldso/ldso/*/*.{o,os,oS}
rm -f ./ldso/libdl/*.{o,os,a,oS}
rm -f ./libcrypt/*.{o,os,oS,a}
rm -f ./libintl/*.{o,os,a}
rm -f ./libm/{,*/,*/*/}*.{o,os,oS,a}
rm -f ./libnsl/*.{o,os,a}
rm -f ./libresolv/*.{o,os,a}
rm -f ./libutil/*.{o,os,oS,a}
rm -f ./libpthread/linuxthreads.old/*.{o,os,oS,a}
rm -f ./libpthread/linuxthreads.old_db/*.{o,os,oS,a}
rm -f ./librt/*.{o,os,a}
rm -f ./extra/locale/gen_collate ./extra/locale/gen_wc8bit 
./extra/locale/gen_wctype ./extra/locale/locale_data.c 
./extra/locale/{*.{o,os,txt},gen_locale,gen_ldc}
rm -f 
./extra/locale/{uClibc_locale_data,lt_defines,c8tables,wctables,locale_tables,locale_collate}.h
rm -f ./extra/locale/{lmmtolso,gen_mmap,locale.mmap}
rm -f ./libc/sysdeps/linux/sh/*.{o,os} ./lib/crti.o ./lib/crtn.o ./lib/crt1.o 
./lib/Scrt1.o
rm -f ./libc/sysdeps/linux/common/*.{o,os,oS}
rm -f ./libc/misc/assert/*.{o,os}
rm -f ./libc/misc/ctype/*.{o,os}
rm -f ./libc/misc/dirent/*.{o,os}
rm -f ./libc/misc/error/*.{o,os}
rm -f ./libc/misc/file/*.{o,os,oS}
rm -f ./libc/misc/fnmatch/*.{o,os}
rm -f ./libc/misc/ftw/*.{o,os}
rm -f ./libc/misc/glob/*.{o,os}
rm -f ./libc/misc/gnu/*.{o,os}
rm -f ./libc/misc/internals/*.{o,os,oS}
rm -f ./libc/misc/locale/*.{o,os}
rm -f ./libc/misc/mntent/*.{o,os}
rm -f ./libc/misc/regex/*.{o,os}
rm -f ./libc/misc/search/*.{o,os}
rm -f ./libc/misc/statfs/*.{o,os,oS}
rm -f ./libc/misc/syslog/*.{o,os}
rm -f ./libc/misc/sysvipc/*.{o,os}
rm -f ./libc/misc/time/*.{o,os}
rm -f ./libc/misc/ttyent/*.{o,os}
rm -f ./libc/misc/utmp/*.{o,os}
rm -f ./libc/misc/wchar/*.{o,os}
rm -f ./libc/misc/wctype/*.{o,os}
rm -f ./libc/misc/wordexp/*.{o,os}
rm -f ./libc/pwd_grp/*.{o,os}
rm -f ./libc/stdio/*.{o,os,oS}
rm -f ./libc/string/{,*/}*.{o,os}
rm -f ./libc/termios/*.{o,os}
rm -f ./libc/inet/rpc/*.{o,os,oS}
rm -f ./libc/inet/*.{o,os}
rm -f ./libc/signal/*.{o,os}
rm -f ./libc/stdlib/malloc/*.{o,os}
rm -f ./libc/stdlib/malloc-simple/*.{o,os}
rm -f ./libc/stdlib/malloc-standard/*.{o,os}
rm -f ./libc/stdlib/*.{o,os,oS}
rm -f ./libc/unistd/*.{o,os}
rm -f ./libc/*.{o,os,oS,a}
rm -f ./include/pthread.h \
./include/semaphore.h \
./include/bits/pthreadtypes.h
rm -f ./include/thread_db.h
rm -f include/fpu_control.h include/dl-osinfo.h include/hp-timing.h
make -s -C test clean
make -C uti

Re: *.dep file not cleaned

[Carmelo AMOROSO]

Bernhard Fischer wrote:
> On Wed, Jun 11, 2008 at 09:33:17AM +0200, Carmelo AMOROSO wrote:
>   
>> Should be new *.dep files be cleaned when running 'make clean' ?
>> I'd expect yes.. or am I wrong ?
>> 
>
> I think they should not be cleaned in clean. They are cleaned in realclean
> and distclean.
>   
yes sorry, you're about realclean/distclean... anyway see my other post 
on realclean issue.

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

Re: [PATCH] remove duplicate interp from lib-so-y

[Carmelo AMOROSO]

Bernhard Fischer wrote:
> On Wed, Jun 11, 2008 at 09:28:07AM +0200, Carmelo AMOROSO wrote:
>
>   
>> Hi,
>> I don't have this problem... instead I'm seeing the the ld.so is linked  
>> 
>
> You have to turn on domulti to see it.
>
>   
I'll try it.
>> twice
>> as below
>> 
>
> odd. I'll have a look.
>   
thanks Bernard
>   
>> This doesn't happen on nptl branch that doesn' t include recent chanegs  
>> on build system !
>> 
>
> Do you also see this without -C ?
>   
No, without -C it works fine as below
..
AS lib/Scrt1.o
  AS lib/crti.o
  AS lib/crtn.o
  CC ldso/ldso/ldso.oS
In file included from ./ldso/include/dl-syscall.h:12,
 from ./ldso/include/ldso.h:36,
 from ldso/ldso/ldso.c:33:
./ldso/ldso/sh/dl-syscalls.h:9:2: warning: #warning !!! gcc 4.1 and 
later have problems with __always_inline so redefined as inline
  AS ldso/ldso/sh/resolve.oS
  AR cr ldso/ldso/ld-uClibc_so.a
  STRIP -x -R .note -R .comment ldso/ldso/ld-uClibc_so.a
  LD ld-uClibc-0.9.29.so
  CC lib/interp.os
make[1]: `lib/ld-uClibc.so' is up to date.
  CC ldso/libdl/libdl.oS
In file included from ./ldso/include/dl-syscall.h:12,
 from ./ldso/include/ldso.h:36,
 from ldso/libdl/libdl.c:33:
./ldso/ldso/sh/dl-syscalls.h:9:2: warning: #warning !!! gcc 4.1 and 
later have problems with __always_inline so redefined as inline
  AR cr ldso/libdl/libdl_so.a
  STRIP -x -R .note -R .comment ldso/libdl/libdl_so.a
  CC libc/sysdeps/linux/sh/mmap.os
  CC libc/sysdeps/linux/sh/pipe.os
.
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc

[PATCH] update bits/errno.h to include kernel header errno.h instead of errno_values.h

[Carmelo AMOROSO]

Hi,
I've found some problem while building bluez-utils for uclibc due to 
missing

ENOKEY errno, that is properly defined in linux/asm-generic/errno.h
that uclibc doesn't include from include/bits/errno.h.
We use instead bits/errno_values.h.

I think it should be worth to be always aligned with errno as defined by 
the kernel headers

we link against. So I suggest this patch and to remove the errno_values.h.
(note that glibc does the same)

Does it make sense for you ?

Thanks,
Carmelo
Index: libc/sysdeps/linux/common/bits/errno.h
===
--- libc/sysdeps/linux/common/bits/errno.h  (revision 22288)
+++ libc/sysdeps/linux/common/bits/errno.h  (working copy)
@@ -22,7 +22,7 @@
 # undef EDOM
 # undef EILSEQ
 # undef ERANGE
-# include 
+# include 
 
 /* Linux has no ENOTSUP error code.  */
 # define ENOTSUP EOPNOTSUPP
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc

Re: Test build failed due to UCLIBC_INTERNAL header rework

[Carmelo AMOROSO]

Bernd Schmidt wrote:
> Daniel Jacobowitz wrote:
>
>> I have no comment on the patch itself, but I like the approach - I've
>> concluded before that this is the only sane way to test toolchain
>> pieces, especially compiler or C library.  We do all of our testing
>> after installation here.
>
> My patch doesn't really create a full installation tree that looks 
> identical to the one created by 'make install'; that might require 
> somewhat more effort (unless we want to just $(MAKE) install 
> DESTDIR=somewhere/in/tree for every make test).
>
>
> Bernd
Hi Bernd,
I like it too... and I prefer your easier approach instead of having a 
full installation of headers.
Indeed what we need now is to able to build the test-suite from the 
working tree.

Carmelo

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

Re: [PATCH] remove duplicate interp from lib-so-y

[Carmelo AMOROSO]

Bernhard Fischer wrote:
> On Wed, Jun 11, 2008 at 10:02:33AM +0200, Bernhard Fischer wrote:
>   
>> On Wed, Jun 11, 2008 at 09:50:21AM +0200, Carmelo AMOROSO wrote:
>>
>> 
>>>>> This doesn't happen on nptl branch that doesn' t include recent 
>>>>> chanegs  on build system !
>>>>> 
>>>>>   
>>>> Do you also see this without -C ?
>>>>   
>>>> 
>>> No, without -C it works fine as below
>>>   
>> Great. I didn't think about -C. I'll keep it in mind and will have a
>> look ASAP, please refrain from -C for now then -- although it does no
>> real harm but building certain stuff twice.
>>
>> Thanks for the heads-up!
>> 
>
> Please retry with r22293.
>   
Yeah.. now that's fine ;-)
>   
>> PS: Does somebody know, by chance, why everything except crtbeginT.o:
>> uses $(objext)? This crtbeginT.o: is the only (wrongly, i assume)
>> hardcoded user of ".o" in libgcc/Makefile.in
>> 
>
> cruft, as is vis_hide in static-objects.mk. Fixed locally.
>   

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

Re: [PATCH] update bits/errno.h to include kernel header errno.h instead of errno_values.h

[Carmelo AMOROSO]

Denys Vlasenko wrote:
> On Wednesday 11 June 2008 11:00, Carmelo AMOROSO wrote:
>   
>> Hi,
>> I've found some problem while building bluez-utils for uclibc due to 
>> missing
>> ENOKEY errno, that is properly defined in linux/asm-generic/errno.h
>> that uclibc doesn't include from include/bits/errno.h.
>> We use instead bits/errno_values.h.
>>
>> I think it should be worth to be always aligned with errno as defined by 
>> the kernel headers
>> we link against. So I suggest this patch and to remove the errno_values.h.
>> (note that glibc does the same)
>>
>> Does it make sense for you ?
>> 
>
> Yes.
>
> BTW, the reference you are removing is the only one
> that exists in the tree:
>
> # grep -Fr bits/errno_values.h .
> ./libc/sysdeps/linux/common/bits/errno.h:# include 
>
> After your patch these four files seems to be not referenced
> from anywhere:
>
> # find -name errno_values.h
> ./libc/sysdeps/linux/mips/bits/errno_values.h
> ./libc/sysdeps/linux/alpha/bits/errno_values.h
> ./libc/sysdeps/linux/sparc/bits/errno_values.h
> ./libc/sysdeps/linux/common/bits/errno_values.h
> --
> vda
>   
yes, I intend to remove all of them... they seems to be now useless.
I think errno values should be correctly defined within kernel headers
and correctly managed by kernel.
Indeed, following the headers inclusion chain it should work

linux/errno.h -> asm-/errno.h -> asm-generic/errno.h -> 
asm-generic/errno-base.h

Ciao,
Carmelo

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

Re: Test build failed due to UCLIBC_INTERNAL header rework

[Carmelo AMOROSO]

Denys Vlasenko wrote:
> On Wednesday 11 June 2008 09:29, Carmelo AMOROSO wrote:
>   
>> Denys Vlasenko wrote:
>> 
>>> On Tuesday 10 June 2008 16:27, Carmelo AMOROSO wrote:
>>>   
>>>   
>>>> Hello,
>>>> recent change on libc_hidden_proto brakes test and utils build.
>>>> 
>>>> 
>>> Please send your .config
>>>
>>> I never did "make utils" before, possibly because I usually do static 
>>> builds...
>>> --
>>> vda
>>>   
>>>   
>> but you should build test at least.. hopefully.
>> 
>
> Yes, I do this. It progresses farther than your failure
> point (TEST_LINK crypt/ md5c-test), and eventually fails
> in TEST_EXEC inet/ tst-network_glibc:
>
>   
strange.. it should fail when referring to __GI_strcmp...
> ...
>
>   
>> So now that string.h has been changed again, how is UCLIBC_INTERNALS 
>> maco used ?
>> 
>
> It is used whenever you want to have something in a header file to be there
> only when you build the library, but want to physically remove it
> in installed headers (not just logically by #ifdef'ing it out).
>   
ok
> The implementation was stolen from linux kernel's "header sanitization step".
>
> libc_hidden_proto was projected to be a big user of it, but then Bernd
> came up with even more maintainable way to deal with that one.
>   
yes I've seen
> Now UCLIBC_INTERNALS is used for printf.h (there existed an ad-hoc solution
> which was doing basically the same, but only for this file) and other places.
> --
> vda
>   
Thanks for explanation.

Carmelo

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

[PATCH] fix 'make headers' when LOCALE is enabled

[Carmelo AMOROSO]

Hi,
when running 'make headers" with LOCALE enabled there is a problem
caused by a dependencies of extra/locale/gen_locale against sysnum.h
that is generated by the pregen target
So this patch solve it by moving the make -C locale_headers into the 
pregen target


Cheers,
Carmelo
  MKDIR include/bits
  GEN include/bits/uClibc_config.h
  LN include/pthread.h
  LN include/semaphore.h
  LN include/bits/mman.h
...  
  LN include/bits/wordsize.h
  LN include/sys/acct.h
  LN include/sys/ucontext.h
  LN include/sys/user.h
make[1]: *** No rule to make target `../../include/bits/sysnum.h', needed by 
`../../extra/locale/gen_locale'.  Stop.
make: *** [headers] Error 2
Index: Makefile.in
===
--- Makefile.in (revision 22296)
+++ Makefile.in (working copy)
@@ -134,9 +134,9 @@
 headers-y += $(target-headers-sysdep)
 
 headers: include/bits/uClibc_config.h
-   $(Q)$(if $(UCLIBC_HAS_LOCALE),$(MAKE) -C extra/locale locale_headers)
 
 pregen: include/bits/sysnum.h headers
+   $(Q)$(if $(UCLIBC_HAS_LOCALE),$(MAKE) -C extra/locale locale_headers)
 
 include/bits/sysnum.h: $(top_srcdir)extra/scripts/gen_bits_syscall_h.sh
$(Q)$(INSTALL) -d $(@D)
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc

Re: [PATCH] fix 'make headers' when LOCALE is enabled

[Carmelo AMOROSO]

Bernhard Fischer wrote:
> On Wed, Jun 11, 2008 at 07:01:27PM +0200, Carmelo AMOROSO wrote:
>   
>> Hi,
>> when running 'make headers" with LOCALE enabled there is a problem
>> caused by a dependencies of extra/locale/gen_locale against sysnum.h
>> that is generated by the pregen target
>> So this patch solve it by moving the make -C locale_headers into the  
>> pregen target
>> 
>
> pregen is ment to generate the needed headers and only that. Can you
> instead try to remove the headers dep from pregen and make headers
> depend on pregen, i.e. exactly the other way around?
>   
Hi,
if I make headers depending on pregen, that depends on sysnum.h,
then 'make headers' will require the cross-compiler available.
Doing so it will not be possible to run make install_headers
that are required to build the cross-gcc by scratch.

My fix doesn't change this behaviour.
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc

Re: [PATCH] fix 'make headers' when LOCALE is enabled

[Carmelo AMOROSO]

Bernhard Fischer wrote:
> On Wed, Jun 11, 2008 at 07:51:09PM +0200, Carmelo AMOROSO wrote:
>   
>> Bernhard Fischer wrote:
>> 
>>> On Wed, Jun 11, 2008 at 07:01:27PM +0200, Carmelo AMOROSO wrote:
>>>   
>>>   
>>>> Hi,
>>>> when running 'make headers" with LOCALE enabled there is a problem
>>>> caused by a dependencies of extra/locale/gen_locale against sysnum.h
>>>> that is generated by the pregen target
>>>> So this patch solve it by moving the make -C locale_headers into the  
>>>> pregen target
>>>> 
>>>> 
>>> pregen is ment to generate the needed headers and only that. Can you
>>> instead try to remove the headers dep from pregen and make headers
>>> depend on pregen, i.e. exactly the other way around?
>>>   
>>>   
>> Hi,
>> if I make headers depending on pregen, that depends on sysnum.h,
>> then 'make headers' will require the cross-compiler available.
>> Doing so it will not be possible to run make install_headers
>> that are required to build the cross-gcc by scratch.
>> 
>
> You need a cross-compiler to generate sysnum.h anyway. This is nothing
> new, really.
>   
yes, exactly.
> ok, install_dev (to build a stage1 cross-compiler) just needs headers
> (and no locale stuff, at least in my setup).
> If you have a working cross-compiler you can pregen, so your patch is
> ok.
>
> Please install and accept my apologies for breaking it in the first
> place :)
>   
:-) I'll do

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

Re: [PATCH] update bits/errno.h to include kernel header errno.h instead of errno_values.h

[Carmelo Amoroso]

Hello,
any concerns on this changes ?

2008/6/11 Carmelo AMOROSO <[EMAIL PROTECTED]>:
> Denys Vlasenko wrote:
>> On Wednesday 11 June 2008 11:00, Carmelo AMOROSO wrote:
>>
>>> Hi,
>>> I've found some problem while building bluez-utils for uclibc due to
>>> missing
>>> ENOKEY errno, that is properly defined in linux/asm-generic/errno.h
>>> that uclibc doesn't include from include/bits/errno.h.
>>> We use instead bits/errno_values.h.
>>>
>>> I think it should be worth to be always aligned with errno as defined by
>>> the kernel headers
>>> we link against. So I suggest this patch and to remove the errno_values.h.
>>> (note that glibc does the same)
>>>
>>> Does it make sense for you ?
>>>
>>
>> Yes.
>>
>> BTW, the reference you are removing is the only one
>> that exists in the tree:
>>
>> # grep -Fr bits/errno_values.h .
>> ./libc/sysdeps/linux/common/bits/errno.h:# include 
>>
>> After your patch these four files seems to be not referenced
>> from anywhere:
>>
>> # find -name errno_values.h
>> ./libc/sysdeps/linux/mips/bits/errno_values.h
>> ./libc/sysdeps/linux/alpha/bits/errno_values.h
>> ./libc/sysdeps/linux/sparc/bits/errno_values.h
>> ./libc/sysdeps/linux/common/bits/errno_values.h
>> --
>> vda
>>
> yes, I intend to remove all of them... they seems to be now useless.
> I think errno values should be correctly defined within kernel headers
> and correctly managed by kernel.
> Indeed, following the headers inclusion chain it should work
>
> linux/errno.h -> asm-/errno.h -> asm-generic/errno.h ->
> asm-generic/errno-base.h
>
> Ciao,
> Carmelo
>
> ___
> uClibc mailing list
> uClibc@uclibc.org
> http://busybox.net/cgi-bin/mailman/listinfo/uclibc
>
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc

Re: patch to add “width” function for out putting integers to uClibc++

[Carmelo AMOROSO]

Peter Nixon wrote:
> On Tue 10 Jun 2008, Peter Nixon wrote:
>   
>> The attached patch teaches uCLibc++ about the “width” function for
>> outputting integers, so if you had a value of 3 and wanted the output
>> “003”, we previously just got “3”.
>>
>> This is required for PTLib and OPAL to work correctly
>> (http://www.opalvoip.org/)
>> 
>
> Is anyone actually maintaining uClibc++ ? What do I have to do to get patches 
> applied? This is the second patch I have posted to this list after I 
> unsuccessfully tried to get in contact with the uClibc++ author privately, 
> but no-one has replied..
>
> Regards
>
>   
Hello,
I don't maintain uClibc++ but should have (as uClibc developer) right to 
commit it,
neither I have enough knowledge on uClibc+ internal, so I rely on your 
knowledge.
I'll see what I can do.

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

Re: patch to add “width” function for outputting integers to uClibc++

[Carmelo Amoroso]

I'm sorry... I cannot to commit to this. Ping maintainer again.

Carmelo

2008/6/17 Carmelo AMOROSO <[EMAIL PROTECTED]>:
> Peter Nixon wrote:
>> On Tue 10 Jun 2008, Peter Nixon wrote:
>>
>>> The attached patch teaches uCLibc++ about the "width" function for
>>> outputting integers, so if you had a value of 3 and wanted the output
>>> "003", we previously just got "3".
>>>
>>> This is required for PTLib and OPAL to work correctly
>>> (http://www.opalvoip.org/)
>>>
>>
>> Is anyone actually maintaining uClibc++ ? What do I have to do to get patches
>> applied? This is the second patch I have posted to this list after I
>> unsuccessfully tried to get in contact with the uClibc++ author privately,
>> but no-one has replied..
>>
>> Regards
>>
>>
> Hello,
> I don't maintain uClibc++ but should have (as uClibc developer) right to
> commit it,
> neither I have enough knowledge on uClibc+ internal, so I rely on your
> knowledge.
> I'll see what I can do.
>
> Cheers,
> Carmelo
> ___
> uClibc mailing list
> uClibc@uclibc.org
> http://busybox.net/cgi-bin/mailman/listinfo/uclibc
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc

Re: compile error when trying to use uClibc snapshots

[Carmelo AMOROSO]

Gaye Abdoulaye Walsimou wrote:
> Hello list,
> I'm trying to compile uClibc snapshots and have the following errors.
> Any suggestions?
> Thanks
> Regards
>
> ###Error output when trying to compile uClibc 
> snapshots ###
> make -C /opt/LDE/user/buildroot-20060919-1/toolchain_build_mipsel/uClibc \
> PREFIX= \
> DEVEL_PREFIX=/ \
> RUNTIME_PREFIX=/ \
> HOSTCC="gcc" \
> all
>   CC ldso/ldso/ldso.oS
> In file included from ./ldso/include/ldso.h:36,
>  from ldso/ldso/ldso.c:33:
> ./ldso/include/dl-syscall.h: In function `_dl_exit':
> ./ldso/include/dl-syscall.h:62: error: `__NR_exit' undeclared (first use 
> in this function)
>   
I think you don't have properly installed kernel headers and/or properly 
set the KERNEL_HEADERS config option
pointing to the right folder.


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

Re: Test build failed due to UCLIBC_INTERNAL header rework

[Carmelo AMOROSO]

Bernhard Fischer wrote:
> On Wed, Jun 11, 2008 at 04:10:23PM +0200, Bernd Schmidt wrote:
>   
>> Daniel Jacobowitz wrote:
>>
>> 
>>> I have no comment on the patch itself, but I like the approach - I've
>>> concluded before that this is the only sane way to test toolchain
>>> pieces, especially compiler or C library.  We do all of our testing
>>> after installation here.
>>>   
>> My patch doesn't really create a full installation tree that looks 
>> identical to the one created by 'make install'; that might require 
>> somewhat more effort (unless we want to just $(MAKE) install 
>> DESTDIR=somewhere/in/tree for every make test).
>> 
>
> A better approach would be to just
>
> test-includes: test/include/bits/uClibc_config.h
>   $(make) -C $(top_builddir) PREFIX=test/ RUNTIME_PREFIX=test/ \
>   DEVEL_PREFIX=/ \
>   HOSTCC="$(HOSTCC)" \
>   eventual_flags_passing_here \
>   install_dev
>
> i.e. do a real, full install an no fakery.
>   
Hi,
I've hacked Makefile based on your both inputs and tested a working 
solution.
Moreover I think this approach should be used for building the utils 
too, this why
I think dev files (headers/lib*.a and linker script lib*.so) should be 
installed in a dir
(let's say 'install_dir') undert the builddir instead of the test folder.

I'll came soon with a complete patch for you wider review.

Cheers,
Carmelo
> ___
> uClibc mailing list
> uClibc@uclibc.org
> http://busybox.net/cgi-bin/mailman/listinfo/uclibc
>
>   

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

Re: patch to add “width” function for outputting integers to uClibc++

[Carmelo Amoroso]

Peter Nixon wrote:
> The attached patch teaches uCLibc++ about the “width” function for outputting 
> integers, so if you had a value of 3 and wanted the output “003”, we 
> previously just got “3”.
> 
> This is required for PTLib and OPAL to work correctly 
> (http://www.opalvoip.org/)
> 
> Regards
> 
> 
> 
> 
> 
> ___
> uClibc mailing list
> uClibc@uclibc.org
> http://busybox.net/cgi-bin/mailman/listinfo/uclibc
applied. Thanks.

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

Update on NPTL status

[Carmelo Amoroso]

Hi All,
as you can see I'm committing new stuf on NPTL branch.
This because I've locally merged a lot of latest changes done recently on trunk
and I want to keep nptl branch as mush as possibible aligned with trunk
before the final merge,

Recent changes on trunk include (not availbale on NPTL):
- use of UCLIBC_MUTEX_xxx macros
- build system rework (better dependency checking)
- new way to make and install headers
- smallint stuff
- string.h, libc_hidden_proto and related changes
- other cleanups, warning reduction, cosmetic fixes
- other recent work by vda, aldot, myself and others.

There some other pending works I'll posr for inclusion to trunk
that will be included into nptl too

- rework of _dl_iterate_phdr (a my old patch never included)
- optimized memcpy for sh4
- recent changes on test build system due to hidden_proto change in string.h
- integration of futexes with UCLIBC_MUTEX_xxx macros for IO locking

The NPTL branch is compiling fine again (please wait until my last commit)
and it is under testing on sh4 heavily.
I'd expect some regressions due this huge set of changes.

Just to ensure all the NPTL is alive :-)
I'll be back with other updates (after my next week holiday :-) )

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

Re: Fwd: patch to make OPAL/PTLIB build with uClibc++

[Carmelo Amoroso]

Peter Nixon wrote:
> Hi Carmelo
> 
> Can you also please apply this patch (Sent to the list last month with no 
> reply..)
> 
> Regards
> 
> Peter
Applied as is. Thanks

Carmelo


--  Forwarded Message  --
> 
> Subject: patch to make OPAL/PTLIB build with uClibc++
> Date: Thu 29 May 2008
> From: Peter Nixon <[EMAIL PROTECTED]>
> To: uclibc@uclibc.org
> 
> The attached patch (2nd time around) is required to make OPAL/PTLIB 
> (http://www.opalvoip.org/) build with uclibc++
> 
> I previously sent it directly y-to the uClibc++ contact mail address listed 
> on the website but did not receive any reply so I thought I would try the 
> uclibc list..
> 
> All other changes required to make OPAL and PTLIB compile with uClibc++ have 
> been committed OPAL SVN so they should fully support uclibc++ once you 
> commit this patch. There are  currently still warning when building with 
> uclibc++ and we haven't yet done extensive testing but I will ping the list 
> again if we have any more patches.
> 
> Regards
> 
> 

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

Re: uClibc aio support

[Carmelo AMOROSO]

Cristi Magherusan wrote:
> On Mon, 2008-06-30 at 15:06 +0300, Cristi Magherusan wrote:
>   
>> Are there any plans to include aio support in uClibc soon or should I do
>> it myself? If so, which difficulty do you estimate for this task?
>> 
>
> I took a look at the code of uClibc and glibc and it seems trivial. 
> I'll soon make a patch for inclusion of aio in the official uClibc tree.
>
> Best regards,
> Cristi
>
>
>
>   
this will be appreciated. Please be sure that you will not get
code from glibc licensed under GPLv3.

Carmelo

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

Re: Update on NPTL status

[Carmelo AMOROSO]

Denys Vlasenko wrote:
> Hi Carmelo, Mike,
>
> On Wednesday 18 June 2008 17:39, Carmelo Amoroso wrote:
>   
>> Hi All,
>> as you can see I'm committing new stuf on NPTL branch.
>> This because I've locally merged a lot of latest changes done recently on 
>> trunk
>> and I want to keep nptl branch as mush as possibible aligned with trunk
>> before the final merge,
>>
>> Recent changes on trunk include (not availbale on NPTL):
>> - use of UCLIBC_MUTEX_xxx macros
>> - build system rework (better dependency checking)
>> - new way to make and install headers
>> - smallint stuff
>> - string.h, libc_hidden_proto and related changes
>> - other cleanups, warning reduction, cosmetic fixes
>> - other recent work by vda, aldot, myself and others.
>>
>> There some other pending works I'll posr for inclusion to trunk
>> that will be included into nptl too
>>
>> - rework of _dl_iterate_phdr (a my old patch never included)
>> - optimized memcpy for sh4
>> - recent changes on test build system due to hidden_proto change in string.h
>> - integration of futexes with UCLIBC_MUTEX_xxx macros for IO locking
>>
>> The NPTL branch is compiling fine again (please wait until my last commit)
>> and it is under testing on sh4 heavily.
>> I'd expect some regressions due this huge set of changes.
>>
>> Just to ensure all the NPTL is alive :-)
>> I'll be back with other updates (after my next week holiday :-) )
>> 
>
> I propose creating 0.9.30 branch shortly after NPTL merge.
> Call it 0.9.30_rc1 or 0.9.30.0 or whatever, announce it on http://uclibc.org/
> and let people iron out bugs.
>
> Mike, what would you say?
> --
> vda
>   
probably it's better just before NPTL merge. Anyway I need still more 
time, but I'm in a good point
with merging trunk->branch before.
In parallel Khem is working for the ARM part.

Cheers,
Carmelo
> ___
> uClibc mailing list
> uClibc@uclibc.org
> http://busybox.net/cgi-bin/mailman/listinfo/uclibc
>
>   

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

Re: Test build failed due to UCLIBC_INTERNAL header rework

[Carmelo AMOROSO]

Bernhard Fischer wrote:

On Wed, Jun 11, 2008 at 04:10:23PM +0200, Bernd Schmidt wrote:
  

Daniel Jacobowitz wrote:



I have no comment on the patch itself, but I like the approach - I've
concluded before that this is the only sane way to test toolchain
pieces, especially compiler or C library.  We do all of our testing
after installation here.
  
My patch doesn't really create a full installation tree that looks 
identical to the one created by 'make install'; that might require 
somewhat more effort (unless we want to just $(MAKE) install 
DESTDIR=somewhere/in/tree for every make test).



A better approach would be to just

test-includes: test/include/bits/uClibc_config.h
$(make) -C $(top_builddir) PREFIX=test/ RUNTIME_PREFIX=test/ \
DEVEL_PREFIX=/ \
HOSTCC="$(HOSTCC)" \
eventual_flags_passing_here \
install_dev

i.e. do a real, full install an no fakery.
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc

  

Hi All,
as I told few week ago, here there is a complete patch based on your inputs.
Just to summarize, the idea is to install the headers and kernel headers 
(required by some tests)
into a local directory. I prefer not under test dir, but in the top 
directory to be used

by utils too (not yet fixed).
Tests will be built using only as include dir the local install dir 
(with -nostdinc ).

This allows by-passing teh issue caused the hidden_proto.

I fixed a bit the clean target too.

Also added a new target in top Rules.mak "test_compile" to build the 
tests instead

of directly calling make -C test compile.

There some issues to build nptl and tls tests that need some internal 
header files, but this is

another story we are working on.

Comments are welcome.

Carmelo
Fix the test build system by installing headers on a local folder
instead of using internal headers.

Index: test/Rules.mak
===
--- test/Rules.mak  (revision 22609)
+++ test/Rules.mak  (working copy)
@@ -79,7 +79,11 @@
 XWARNINGS  := $(subst ",, $(strip $(WARNINGS))) -Wstrict-prototypes
 XARCH_CFLAGS   := $(subst ",, $(strip $(ARCH_CFLAGS))) $(CPU_CFLAGS)
 XCOMMON_CFLAGS := -D_GNU_SOURCE -I$(top_builddir)test
-CFLAGS += $(XWARNINGS) $(OPTIMIZATION) $(XCOMMON_CFLAGS) 
$(XARCH_CFLAGS) -I$(top_builddir)include $(PTINC)
+CFLAGS := $(XWARNINGS) $(OPTIMIZATION) $(XCOMMON_CFLAGS) 
$(XARCH_CFLAGS) -nostdinc -I$(top_builddir)$(LOCAL_INSTALL_PATH)/usr/include
+
+CC_IPREFIX:=$(shell $(CC) --print-file-name=include)
+CFLAGS += -I$(CC_IPREFIX)
+
 HOST_CFLAGS+= $(XWARNINGS) $(OPTIMIZATION) $(XCOMMON_CFLAGS)
 
 LDFLAGS:= $(CPU_LDFLAGS)
@@ -97,11 +101,12 @@
LDFLAGS   += -static
HOST_LDFLAGS  += -static
 endif
+
 LDFLAGS += -B$(top_builddir)lib -Wl,-rpath,$(top_builddir)lib 
-Wl,-rpath-link,$(top_builddir)lib
 UCLIBC_LDSO_ABSPATH=$(shell pwd)
 ifdef TEST_INSTALLED_UCLIBC
 LDFLAGS += -Wl,-rpath,./
-UCLIBC_LDSO_ABSPATH=/lib
+UCLIBC_LDSO_ABSPATH=$(SHARED_LIB_LOADER_PREFIX)
 endif
 
 ifeq ($(findstring -static,$(LDFLAGS)),)
Index: Rules.mak
===
--- Rules.mak   (revision 22609)
+++ Rules.mak   (working copy)
@@ -632,3 +632,5 @@
 SHARED_START_FILES:=$(top_builddir)lib/crti.o $(LIBGCC_DIR)crtbeginS.o
 SHARED_END_FILES:=$(LIBGCC_DIR)crtendS.o $(top_builddir)lib/crtn.o
 endif
+
+LOCAL_INSTALL_PATH := install_dir
Index: Makefile.in
===
--- Makefile.in (revision 22609)
+++ Makefile.in (working copy)
@@ -66,7 +66,7 @@
 ifneq ($(TARGET_SUBARCH),)
 HEADERS_BITS_SUBARCH := $(notdir $(wildcard 
$(top_srcdir)libc/sysdeps/linux/$(TARGET_ARCH)/bits/$(TARGET_SUBARCH)/*.h))
 endif
-HEADERS_BITS_COMMON := $(filter-out $(HEADERS_BITS_ARCH) 
$(HEADERS_BITS_SUBARCH),$(HEADERS_BITS_COMMON))
+HEADERS_BITS_COMMON := $(filter-out $(HEADERS_BITS_ARCH) 
$(HEADERS_BITS_SUBARCH) $(HEADERS_BITS_PTHREAD),$(HEADERS_BITS_COMMON))
 
 HEADERS_SYS_COMMON := $(notdir $(wildcard 
$(top_srcdir)libc/sysdeps/linux/common/sys/*.h))
 HEADERS_SYS_ARCH := $(notdir $(wildcard 
$(top_srcdir)libc/sysdeps/linux/$(TARGET_ARCH)/sys/*.h))
@@ -152,6 +152,15 @@
mv -f $$tmp include/bits/sysnum.h; \
fi
 
+$(LOCAL_INSTALL_PATH):
+   $(Q)$(MAKE) PREFIX=$(shell pwd)/ RUNTIME_PREFIX=./ \
+   DEVEL_PREFIX=$(LOCAL_INSTALL_PATH)/usr/ \
+   HOSTCC="$(HOSTCC)" \
+   install_kernel_headers
+   $(Q)$(MAKE) PREFIX=$(shell pwd)/ RUNTIME_PREFIX=./ \
+   DEVEL_PREFIX=$(LOCAL_INSTALL_PATH)/usr/ \
+   HOSTCC="$(HOSTCC)" \
+   install_dev
 
 install: install_runtime install_dev
 
@@ -451,7 +460,8 @@
$(Q)$(RM) -r lib include/bits
$(RM) ldso/*/*.a libpthread/*/*.a libc/*.a libcrypt/*.a libintl/*.a \
libm/*.a libnsl/*.a libpthread/*.a libresolv/*.a librt/*

Re: [PATCH] update bits/errno.h to include kernel header errno.h instead of errno_values.h

[Carmelo AMOROSO]

Carmelo Amoroso wrote:
> Hello,
> any concerns on this changes ?
> 
merged ;-)

Carmelo
> 2008/6/11 Carmelo AMOROSO <[EMAIL PROTECTED]>:
>> Denys Vlasenko wrote:
>>> On Wednesday 11 June 2008 11:00, Carmelo AMOROSO wrote:
>>>
>>>> Hi,
>>>> I've found some problem while building bluez-utils for uclibc due to
>>>> missing
>>>> ENOKEY errno, that is properly defined in linux/asm-generic/errno.h
>>>> that uclibc doesn't include from include/bits/errno.h.
>>>> We use instead bits/errno_values.h.
>>>>
>>>> I think it should be worth to be always aligned with errno as defined by
>>>> the kernel headers
>>>> we link against. So I suggest this patch and to remove the errno_values.h.
>>>> (note that glibc does the same)
>>>>
>>>> Does it make sense for you ?
>>>>
>>> Yes.
>>>
>>> BTW, the reference you are removing is the only one
>>> that exists in the tree:
>>>
>>> # grep -Fr bits/errno_values.h .
>>> ./libc/sysdeps/linux/common/bits/errno.h:# include 
>>>
>>> After your patch these four files seems to be not referenced
>>> from anywhere:
>>>
>>> # find -name errno_values.h
>>> ./libc/sysdeps/linux/mips/bits/errno_values.h
>>> ./libc/sysdeps/linux/alpha/bits/errno_values.h
>>> ./libc/sysdeps/linux/sparc/bits/errno_values.h
>>> ./libc/sysdeps/linux/common/bits/errno_values.h
>>> --
>>> vda
>>>
>> yes, I intend to remove all of them... they seems to be now useless.
>> I think errno values should be correctly defined within kernel headers
>> and correctly managed by kernel.
>> Indeed, following the headers inclusion chain it should work
>>
>> linux/errno.h -> asm-/errno.h -> asm-generic/errno.h ->
>> asm-generic/errno-base.h
>>
>> Ciao,
>> Carmelo
>>
>> ___
>> uClibc mailing list
>> uClibc@uclibc.org
>> http://busybox.net/cgi-bin/mailman/listinfo/uclibc
>>
> 

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

Re: [PATCH] aio support for uClibc

[Carmelo Amoroso]

Cristi Magherusan wrote:
> Hello,
> 
> You can find attached the patch that adds into librt optional support
> for stubs of the aio functions, as I promised a few days ago.
> 
> It's mostly a copy/paste from glibc, with a few modifications needed for
> it to compile, I hope I haven't missed anything and that there won't be
> license-related issues.
> 
> Best regards,
> Cristi
> 
> 
It may be worth running the open posix testsuite from the LTP,
even only the AIO part just to verify that it is compliant
and that all required interface are there.

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

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

Re: [PATCH] aio support for uClibc

[Carmelo AMOROSO]

Cristi Magherusan wrote:
> Hello,
> 
> On Sat, 2008-07-05 at 11:26 +0200, Bernhard Fischer wrote:
>> From a short glance, we want the exact opposite: No stubs but the real
>> implementation. 
> Afaik, there are no public aio_*() syscalls offered by the kernel, and
> even glibc has only stubs and no real implementation.
> 
have you had a look at sysdeps/pthread/aio_xxx.c implementations ?

>> Also in my POV putting all the aio_*() into one
>> librt/aio.c would be preferred, but that's just cosmetics, admittedly.
> I'll create another patch that addresses this.
> 
> Best regards,
> Cristi
> 
> 
> 
> 
> 
> ___
> uClibc mailing list
> uClibc@uclibc.org
> http://busybox.net/cgi-bin/mailman/listinfo/uclibc

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

[PATCH] uClibc_mutex.h: do not include pthread.h

[Carmelo AMOROSO]

Hi All,
after having merged recent uClibc_mutex.h into nptl branch I've seen a 
problem in building 'dvdr-tools' application. The problem is that a 
source file of this application use a variable "BOOL clone".
This source includes stdio.h -> uClibc_stdio.h -> uClibc_mutex.h -> 
pthread.h -> sched.h.

In sched.h there is the clone prototype defined causing the clashing.

I think that uCibc_mutex.h could simply include  
for getting the definition of pthread_mutex_t, and I'm not sure it 
really needs including pthread.h.


So the attached dummy patch is intended to fix it.

Cheers,
Carmelo

Index: libc/sysdeps/linux/common/bits/uClibc_mutex.h
===
--- libc/sysdeps/linux/common/bits/uClibc_mutex.h   (revision 22609)
+++ libc/sysdeps/linux/common/bits/uClibc_mutex.h   (working copy)
@@ -12,8 +12,7 @@
 
 #ifdef __UCLIBC_HAS_THREADS__
 
-#include 
-#include 
+#include 
 
 #define __UCLIBC_MUTEX_TYPEpthread_mutex_t
 
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc

Re: libc_hidden_proto removal en masse

[Carmelo AMOROSO]

Denys Vlasenko wrote:
> Hi,
> 
> Seems like removal of libc_hidden_proto's for functions
> from string.h went without major catastrophes.
> 
> I would like to go ahead and remove all other
> libc_hidden_proto's from .c files. I plan to do it
> on coming weekend.
> 
> If this will interfere with your work, please
> let me know before Friday.
> 
> I am especially worried about Carmelo's merge -
> Carmelo, is my plan ok with you?
> 
> Thanks,
> --
> vda
> 
Hi Denys,
yes go ahead. I'll resynch it later.
I've almost all nptl merged with trunk (except for some misc/internal 
part) and I'll push back to nptl branch this week as agreed with Khem 
for the ARM port.

Cheers,
Carmelo



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

Re: libc_hidden_proto removal en masse

[Carmelo AMOROSO]

Denys Vlasenko wrote:
> Hi,
> 
> Seems like removal of libc_hidden_proto's for functions
> from string.h went without major catastrophes.
> 
> I would like to go ahead and remove all other
> libc_hidden_proto's from .c files. I plan to do it
> on coming weekend.
> 
> If this will interfere with your work, please
> let me know before Friday.
> 
> I am especially worried about Carmelo's merge -
> Carmelo, is my plan ok with you?
> 
> Thanks,
> --
> vda
> 
I'd like to highlight that we need to fix the testsuite build system.
I've sent a patch recently putting together some suggestions by Bernard, 
Bernd and others. I'd like to have it reviewed so that it can be merged in.

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

Re: libc_hidden_proto removal en masse

[Carmelo AMOROSO]

Bernhard Fischer wrote:
> On Tue, Jul 08, 2008 at 09:05:28AM +0200, Carmelo AMOROSO wrote:
> 
>> I'd like to highlight that we need to fix the testsuite build system.
>> I've sent a patch recently putting together some suggestions by Bernard, 
>> Bernd and others. I'd like to have it reviewed so that it can be merged in.
> 
> I remember that it looked reasonable but i admit that i didn't try it.
> If it works for you then please go ahead and install it.
> 
yes, fully tested (I'll check it again anyway).
Some problems on nptl/tls tests as I pointed out because these are 
intended to use some internals headers not installed. But this will be 
handled separately.

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

Re: [PATCH] uClibc_mutex.h: do not include pthread.h

[Carmelo AMOROSO]

Carmelo AMOROSO wrote:
> Hi All,
> after having merged recent uClibc_mutex.h into nptl branch I've seen a 
> problem in building 'dvdr-tools' application. The problem is that a 
> source file of this application use a variable "BOOL clone".
> This source includes stdio.h -> uClibc_stdio.h -> uClibc_mutex.h -> 
> pthread.h -> sched.h.
> In sched.h there is the clone prototype defined causing the clashing.
> 
> I think that uCibc_mutex.h could simply include  
> for getting the definition of pthread_mutex_t, and I'm not sure it 
> really needs including pthread.h.
> 
> So the attached dummy patch is intended to fix it.
> 
> Cheers,
> Carmelo
> 
Unfortunately this patch doesn't work on linuxthreads, so currently 
discard it.
I'll go back to this later. I'll keep this change privately for my nptl 
branch.

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

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

Re: libc_hidden_proto removal en masse

[Carmelo AMOROSO]

Carmelo AMOROSO wrote:
> Bernhard Fischer wrote:
>> On Tue, Jul 08, 2008 at 09:05:28AM +0200, Carmelo AMOROSO wrote:
>>
>>> I'd like to highlight that we need to fix the testsuite build system.
>>> I've sent a patch recently putting together some suggestions by Bernard, 
>>> Bernd and others. I'd like to have it reviewed so that it can be merged in.
>> I remember that it looked reasonable but i admit that i didn't try it.
>> If it works for you then please go ahead and install it.
>>
> yes, fully tested (I'll check it again anyway).
> Some problems on nptl/tls tests as I pointed out because these are 
> intended to use some internals headers not installed. But this will be 
> handled separately.
> 
> Carmelo
> ___
> uClibc mailing list
> uClibc@uclibc.org
> http://busybox.net/cgi-bin/mailman/listinfo/uclibc
> 

Re-tested on trynk>

Command line:
make V=y TEST_INSTALLED_UCLIBC=y UCLIBC_ONLY=y test_compile

Output:


make -C test compile
make -C  args compile
sh4-linux-uclibc-gcc  -Wall -Wstrict-prototypes  -Os -funit-at-a-time 
-fno-tree-loop-optimize -fno-tree-dominator-opts -fno-strength-reduce 
-fstrict-aliasing -mprefergot -Os -D_GNU_SOURCE -I../../test-ml -m4 
-nostdinc -I../../install_dir/usr/include 
-I/opt/STM/STLinux-2.3/devkit/sh4_uclibc/lib/gcc/sh4-linux-uclibc/4.2.1/include 
   -c arg_test.c -o arg_test.o
sh4-linux-uclibc-gcc  -s -B../../lib -Wl,-rpath,../../lib 
-Wl,-rpath-link,../../lib -Wl,-rpath,./ 
-Wl,--dynamic-linker,"/lib"/ld-uClibc.so.0 -Wl,--hash-style=gnu 
arg_test.o -o arg_test

.

As you can only install_dir/usr/include and the gcc include folder is
used for building.

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

[PATCH] sh4 supports new {s,g]rlimit syscall

[Carmelo AMOROSO]

Hi Paul,
are you ok with changing default behaviour on sh4 regarding RLIMIT 
wrapper. The change in the attached patch was required to fix 
LTP/setrlimit02 test case.


Cheers,
Carmelo
Index: libc/sysdeps/linux/sh/bits/uClibc_arch_features.h
===
--- libc/sysdeps/linux/sh/bits/uClibc_arch_features.h   (revision 22683)
+++ libc/sysdeps/linux/sh/bits/uClibc_arch_features.h   (working copy)
@@ -22,7 +22,7 @@
 #undef __UCLIBC_BROKEN_CREATE_MODULE__
 
 /* does your target have to worry about older [gs]etrlimit() ? */
-#define __UCLIBC_HANDLE_OLDER_RLIMIT__
+#undef __UCLIBC_HANDLE_OLDER_RLIMIT__
 
 /* does your target have an asm .set ? */
 #define __UCLIBC_HAVE_ASM_SET_DIRECTIVE__
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc

Re: [PATCH] sh4 supports new {s,g]rlimit syscall

[Carmelo AMOROSO]

Paul Mundt wrote:
> On Tue, Jul 08, 2008 at 10:26:11AM +0200, Carmelo AMOROSO wrote:
>> Hi Paul,
>> are you ok with changing default behaviour on sh4 regarding RLIMIT 
>> wrapper. The change in the attached patch was required to fix 
>> LTP/setrlimit02 test case.
>>
> Looks fine to me.
> 
Thanks. merged.

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

Re: svn commit: branches/uClibc-nptl/test: locale locale-mbwc

[Carmelo AMOROSO]

Bernhard Fischer wrote:
> On Wed, Jul 09, 2008 at 07:19:38AM -0700, [EMAIL PROTECTED] wrote:
>> Author: carmelo
>> Date: 2008-07-09 07:19:37 -0700 (Wed, 09 Jul 2008)
>> New Revision: 22707
>>
>> Log:
>> Added new tests for 'locale' support- taken from glibc; added new part for 
>> testing UTF-8 encoding
>>
>> Added:
>>   branches/uClibc-nptl/test/locale-mbwc/
> 
> Shouldn't this also be added to trunk, i.e. would it have been better to
> add it to trunk and pull that addition into the branch?

I'm doing it on both. Further, likely tomorrow I'll post some fixes we 
did to fix some failures on locale tests.

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

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

NPTL branch almost merged with trunk @ rev 22714

[Carmelo AMOROSO]

Hi Steve, Khem, Mike, all ...
well just an update on the NPTL branch synch&merge work.

I've discussed privately with Khem that is working on re-basing ARM nptl 
port and agreed to commit all the merged stuff I had on my nptl working 
copy.
In the recent weeks I've merged/integrated and tested a lot of work from 
trunk making a almost synchronized nptl branch (at least of sh4 port).

At this point the current status of the NPTL branch is that it is 
working fine for sh4 and should still build and work for mips.

So I kindly ask Steve to test again on his mips hw (apologies idvance 
for any breakage I could have done).

Khem now is working to rebase his ARM patches on top of the freashen 
branch and than commit his stuff.

If no issues from mips side (hopefully) we can say to have again a 
stable nptl branch for al three supported archs.

There are other few files not completely merged with trunk that need 
more investigation (misc/internals and some other headers), but 
excluding these all the differences between nptl and trunk should be 
related to NPTL and TLS part.

I'll take care of merging future incoming changes on trunk back to nptl 
branch.

After that, hopefully in the next weeks (next two weeks I'll be not 
available), we will be ready to move all to trunk.

It was hard, but I'm sure we'll success at the end.

Thanks and best regards,
Carmelo

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

Re: svn commit: branches/uClibc-nptl: ldso/ldso/mips libc/sysdeps/linux/mips l etc...

[Carmelo AMOROSO]

[EMAIL PROTECTED] wrote:
> Author: kraj
> Date: 2008-07-09 16:36:41 -0700 (Wed, 09 Jul 2008)
> New Revision: 22725
> 
> Log:
> Revert the mips related fixed that got in due to the trunk merge and also add 
> pt-__syscall_rt_sigaction.c for mips
> 
> Added:
>
> branches/uClibc-nptl/libpthread/nptl/sysdeps/unix/sysv/linux/mips/pt-__syscall_rt_sigaction.c
> 
> Modified:
>branches/uClibc-nptl/ldso/ldso/mips/elfinterp.c
>branches/uClibc-nptl/libc/sysdeps/linux/mips/Makefile.arch
>branches/uClibc-nptl/libc/sysdeps/linux/mips/clone.S
>branches/uClibc-nptl/libc/sysdeps/linux/mips/sys/asm.h
>
> branches/uClibc-nptl/libpthread/nptl/sysdeps/unix/sysv/linux/mips/Makefile.arch
> 
> 
Aplogies for mips unwanted commit.
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc

Re: svn commit: branches/uClibc-nptl/libc: inet misc/sysvipc stdio sysdeps/linux/co etc...

[Carmelo AMOROSO]

[EMAIL PROTECTED] wrote:
> Author: kraj
> Date: 2008-07-09 16:52:41 -0700 (Wed, 09 Jul 2008)
> New Revision: 22726
> 
> Log:
> Fix the builds without STDIO_FUTEXES. Fix msgecv and msgsend to compile on 
> ARM as well.
> 
> Modified:
>branches/uClibc-nptl/libc/inet/resolv.c
>branches/uClibc-nptl/libc/misc/sysvipc/msgq.c
>branches/uClibc-nptl/libc/stdio/_stdio.c
>branches/uClibc-nptl/libc/stdio/_stdio.h
>branches/uClibc-nptl/libc/stdio/fflush.c
>branches/uClibc-nptl/libc/sysdeps/linux/common/bits/uClibc_mutex.h
>branches/uClibc-nptl/libc/sysdeps/linux/common/bits/uClibc_stdio.h
>branches/uClibc-nptl/libc/sysdeps/linux/common/pause.c
> 
> Hi Khem,
I've had a series of __UCLIBC_IO_MUTEX_ macro to be used for I/O 
locking and keeping hidden all internal mutex strategy (using futexes or 
pthread).
Thanks for pointing out build problem when futexes are disabled, but 
there should be a better way to fix it. I'll have a look again at 
IO_MUTEX macro and fix it again.

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

Re: svn commit: branches/uClibc-nptl/libc: inet misc/sysvipc stdio sysdeps/linux/co etc...

[Carmelo AMOROSO]

[EMAIL PROTECTED] wrote:
> Author: kraj
> Date: 2008-07-09 16:52:41 -0700 (Wed, 09 Jul 2008)
> New Revision: 22726
> 
> Log:
> Fix the builds without STDIO_FUTEXES. Fix msgecv and msgsend to compile on 
> ARM as well.
> 
> Modified:
>branches/uClibc-nptl/libc/inet/resolv.c

>  [SNIP]
> 
> 
> Changeset:
> Modified: branches/uClibc-nptl/libc/inet/resolv.c
> ===
> --- branches/uClibc-nptl/libc/inet/resolv.c   2008-07-09 23:36:41 UTC (rev 
> 22725)
> +++ branches/uClibc-nptl/libc/inet/resolv.c   2008-07-09 23:52:41 UTC (rev 
> 22726)
> @@ -155,6 +155,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  

Hi Khem,
for my curiosity.. why did you need to add tls.h ?
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc

SVN NPTL branch doesn't check for trailing whitespaces

[Carmelo AMOROSO]

Hi All,
I'm not svn expert, but I've noted that the nptl branch doesn't take 
care of trailing whitespaces on files and accept them silently, the same 
doesn't happen on trunk.
Indeed I've committed some files on branch without problems and then, 
moving on trunk I've discovered the problems (sorry for that).

Is someone knows how to fix the nptl branch to reject commit when files 
have trailing whitespaces, please do.


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

Re: libc.so.6: aborted attempt to load

[Carmelo AMOROSO]

saravanan chanemouganandam wrote:
> /Hi all; /
> // 
> /I am trying to cross compile dropbear package outside the snapgear 
> source tree for and embedded
> solution running ARM-linux on IXP425 Big endian system.  /
> // 
> /The package builds correctly using make PROGRAMS="dropbear scp" with 
> options CC=arm-linux-gcc -mbig-endian. /
> /But, when I download and execute the scp: ELF 32-bit MSB executable, 
> ARM ,version 1 (ARM), for GNU/Linux 2.0.0, dynamically linked/
> /(uses shared libs), for GNU/Linux 2.0.0, not stripped ...into my board, 
> I get the following error../
> // 
> /# ./scp
> libc.so.6: aborted attempt to load ./scp!/
> // 

It seems not be correctly built.. it is referring to glibc.
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc

Re: libc.so.6: aborted attempt to load

[Carmelo AMOROSO]

saravanan chanemouganandam wrote:
> Hi David,
>  
> I got stuck up in applying openssl patches from ocf link. Could you 
> please send me those patches to reinclude to
> give support for openssh.
>  
> Fix to openssh will be really helpful.
>  
> thanks
> Sara.
it seems not be uclibc related discussion, please move to proper list.

Thanks,
Carmelo
> 
> On Thu, Jul 10, 2008 at 2:40 PM, David McCullough 
> <[EMAIL PROTECTED] 
> > wrote:
> 
> 
> Jivin saravanan chanemouganandam lays it down ...
>  > Hello David,
>  >
>  > I am using vendors ADI linux distribution which uses snapgear
> linux and tool
>  > chain to build kernel and rootfs. The distro contains
>  > older versions of dropbear and doesn't provide support to build
> ssh and sshd
>  > ( missing libssl ). Even snapgear's latest version doesn't
> include support
>  > for building ssh ( throws missing openssl). I don't know whether
> am missing
>  > something to build ssh packages inside
>  > snapgear. There are discussion about patches for ssh with older
> version but
>  > am not interested with the older version.
> 
> We do not include openssl in the dist due to export issues in
> Australia.  We
> can provide a patch though.
> 
> You can locate dist instructions and a newer openssl patch from:
> 
>ocf-linux.sourceforge.net 
> 
> If you get stuck I can send you a patch to re-include it.
> 
>  > So I prefer to build dropbear an alternative to ssh outside the
> snapgear
>  > tree.
>  >
>  > Well am using the stable version of
> arm-linux-tools-20061213.tar.gz from
>  > snapgear and moreover static leaves out a larger in size that doesn't
>  > interest well for the small flash size.
>  >
>  > I think by default it builds against glibc and not using uclibc.
> Is there a
>  > way to override by compiler options to use
>  > uclibc while building ?
> 
> You need to build against the includes and libraries built when you
> build the dist.  It is possible by setting ROOTDIR to point at the dist
> toplevel and setting CC = $(ROOTDIR)/tools/ucfront-gcc arm-linux-gcc
> 
> But you will be much better off adding your apps to the dist build,
> 
> Cheers,
> Davidm
> 
> 
>  > On Thu, Jul 10, 2008 at 1:53 PM, David McCullough <
>  > [EMAIL PROTECTED]
> > wrote:
>  >
>  > >
>  > > Jivin saravanan chanemouganandam lays it down ...
>  > > > *Hi all; *
>  > > > **
>  > > > *I am trying to cross compile dropbear package outside the
> snapgear
>  > > source
>  > > > tree for and embedded
>  > > > solution running ARM-linux on IXP425 Big endian system.  *
>  > > > **
>  > > > *The package builds correctly using make PROGRAMS="dropbear
> scp" with
>  > > > options CC=arm-linux-gcc -mbig-endian. *
>  > > > *But, when I download and execute the scp: ELF 32-bit MSB
> executable, ARM
>  > > > ,version 1 (ARM), for GNU/Linux 2.0.0, dynamically linked*
>  > > > *(uses shared libs), for GNU/Linux 2.0.0, not stripped
> ...into my board,
>  > > I
>  > > > get the following error..*
>  > >
>  > > This will build dropbear against the compiler libraries,  not the
>  > > snapgear libraries.
>  > >
>  > > The compilers are glibc based,  the snapgear dist will be
> uClibc based.
>  > > You will not be able to run the dropbear executable under the
> snapgear
>  > > image because the glibc libraries will not be there.
>  > >
>  > > You could try adding "-static",  but if it depends on any
> shared libs
>  > > you will be out of luck.  Check this with "ldd dropbear"
>  > >
>  > > > **
>  > > > *# ./scp
>  > > > libc.so.6: aborted attempt to load ./scp!*
>  > > > **
>  > > > *Snap shots of few libraries on the /lib of the target board
> are *
>  > > > **
>  > > >  0 lrwxrwxrwx1 00  24 ld-linux.so.2
> -> /lib/
>  > > > ld-uClibc-0.9.27.so 
> 
>  > > >   22 -rwxrwxrwx1 00   21312
> ld-uClibc-0.9.27.so
> 
>  > > >0 lrwxrwxrwx1 00  19 ld-uClibc.so.0 ->
>  > > > ld-uClibc-0.9.27.so 
> 
>  > > >0 lrwxrwxrwx1 00  19 libc.so.0 ->
>  > > > libuClibc-0.9.27.so 
> 
>  > > >   11 -rw-rw-rw-1 00   10688
> libcrypt-0.9.27.so 
>  > > >0 lrwxrwxrwx1 00  18 libcrypt.so.0 ->
>  > > > libcrypt-0.9.27.so 

Re: uclibc and glibc

[Carmelo AMOROSO]

saravanan chanemouganandam wrote:
> Hi all,
>  
> I am having a problem on the Intel IXP425 big endian system running 
> Snapgear
> linux (choosen uClibc) distro version.  On the development x86 machine,  
> I have installed
> (/usr/local/arm-linux) arm-linux tool chain 
> arm-linux-tools-20061213.tar.gz  for cross compilation.
>  
> All packages under the snapgear soruce tree ( snapgear/user) compiles 
> well. But, when I try to compile
> the package outside the snapgear source tree using make 
> CC=/arm-linux-gcc CFLAGS+=-mbig-endian it
> throws lots of errors.
>  
> A simple hello world program on the boards throws
> # ./hello.o
> libc.so.6: aborted attempt to load ./hello.o!
>  
> I think it is built against glibc and not uclibc. Can somebody point me 
> how to cross compile a simple program for a
> Big endian system ? 
>  
> Thanks
> Sara
> 
again, it seems a problem due to a mis-configured toolchain.
I don't know snapgear, but if you talk about libc.so.6 it's clear this 
is not uclibc.

Ask to the right list... please.

> 
> 
> 
> Check news, cricket, entertainment and astrology right from your mobile. 
> Browse http://m.msnindia.com from your GPRS mobile phone. Try it now! 
> 
> 
> 
> 
> 
> ___
> uClibc mailing list
> uClibc@uclibc.org
> http://busybox.net/cgi-bin/mailman/listinfo/uclibc

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

Re: svn commit: branches/uClibc-nptl/libc: inet misc/sysvipc stdio sysdeps/linux/co etc...

[Carmelo Amoroso]

2008/7/10 Bernhard Fischer <[EMAIL PROTECTED]>:
> On Thu, Jul 10, 2008 at 08:04:03AM -0700, Khem Raj wrote:
>>On Thu, 2008-07-10 at 12:11 +0200, Carmelo AMOROSO wrote:
>
>>> Hi Khem,
>>> for my curiosity.. why did you need to add tls.h ?
>>
>>To get USE__TLS
>
> ISTR that this was a leftover from glibc, so perhaps we should put this
> into uClibc_config.h or get rid of it?

Indeed it was not required for me (sh4-nptl)... Khem may you check it again ?

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

Active developers list

[Carmelo Amoroso]

Hi All,
sometimes it could be difficult, unless account matches with real name,
identify who is doing what, so I'd kindly ask each of you with commit
right on uclibc to reply to this mail and provide the triplet

full name - email - account.

Or it could be add a file DEVELOPERS with related info
or extend the MAINTEINERS.

I think it is important knowing this mapping, otherwise some misunderstanding
may happens when replying to svn commit message.

If you think this useful, please fill the table below.

So this is me:

Full Name   | E-mails| uClibc account
-
Carmelo Amoroso | [EMAIL PROTECTED] | [EMAIL PROTECTED]
   [EMAIL PROTECTED]
-


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

Re: Active developers list

[Carmelo AMOROSO]

Hans-Christian Egtvedt wrote:
> On Fri, 2008-07-11 at 01:26 +0200, Carmelo Amoroso wrote:
>> Hi All,
>> sometimes it could be difficult, unless account matches with real name,
>> identify who is doing what, so I'd kindly ask each of you with commit
>> right on uclibc to reply to this mail and provide the triplet
>>
>> full name - email - account.
>>
>> Or it could be add a file DEVELOPERS with related info
>> or extend the MAINTEINERS.
>>
> 
> Is not the MAINTAINERS file intended for just this information?
> 
not all developers with commit provilegs are list as MAINTAINERS

> What you lack is mapping from maintainer <=> uClibc.org account?
>
yes

> Could the commit messages (I have yet to trigger one of those...) be
> sent to an alternative address?
> 
> If you want all your (unread?) uclibc.org email forwarded somewhere,
> just add a .forward file in your $HOME directory.
> 
it is not what I need

>> I think it is important knowing this mapping, otherwise some misunderstanding
>> may happens when replying to svn commit message.
>>
> 
> What kind of misunderstanding?
> 
example: (Denys let'me use you as example)

vda makes a commit: so you'll see a message from [EMAIL PROTECTED]
someone replies to the commit message
then you see another reply from "Denys Vlasenko": do you know that vda 
and Denys are the same person ? is not so easy understand this.

Yes vapier is well known, what for newbies is not so clear sometimes 
this mapping. This is my point.

>> If you think this useful, please fill the table below.
>>
>> So this is me:
>>
>> Full Name   | E-mails| uClibc account
>> -
>> Carmelo Amoroso | [EMAIL PROTECTED] | [EMAIL PROTECTED]
>>[EMAIL PROTECTED]
>> -
> 
> -
> Hans-Christian Egtvedt | [EMAIL PROTECTED] | [EMAIL PROTECTED]
> -
> 
> My email and name are ridiculous long ;)
> 
in your case, you have chosen an account understandable

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

Re: Active developers list

[Carmelo AMOROSO]

A proposal for a DEVELOPERS file.

Active Developers List

Note: For the hard of thinking, this list is meant to remain in alphabetical
order. If you could add yourselves to it in alphabetical order that would be
so much easier.

P: Person
E: Person's email address
W: Web-page with status/info
A: Account used for commit

--

P: Carmelo Amoroso
E: [EMAIL PROTECTED] / [EMAIL PROTECTED]
W: www.stlinux.com
A: [EMAIL PROTECTED]
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc

Re: svn commit: branches/uClibc-nptl/libc

[Carmelo AMOROSO]

[EMAIL PROTECTED] wrote:
> Author: kraj
> Date: 2008-07-11 01:02:04 -0700 (Fri, 11 Jul 2008)
> New Revision: 22772
> 
> Log:
> Signed-off-by: Khem Raj <[EMAIL PROTECTED]>
> Append the objects.
> 
> 
> Modified:
>branches/uClibc-nptl/libc/Makefile.in
> 
> 
> Changeset:
> Modified: branches/uClibc-nptl/libc/Makefile.in
> ===
> --- branches/uClibc-nptl/libc/Makefile.in 2008-07-11 07:59:33 UTC (rev 
> 22771)
> +++ branches/uClibc-nptl/libc/Makefile.in 2008-07-11 08:02:04 UTC (rev 
> 22772)
> @@ -38,17 +38,17 @@
>  include $(libc_DIR)/unistd/Makefile.in
>  
>  ifeq ($(DOPIC),y)
> -libc-a-y = $(libc-y:.o=.os) $(libc-static-y:.o=.os)
> +libc-a-y += $(libc-y:.o=.os) $(libc-static-y:.o=.os)
>  else
> -libc-a-y = $(libc-y) $(libc-static-y)
> +libc-a-y += $(libc-y) $(libc-static-y)
>  endif
>  
>  ifeq ($(DOMULTI),n)
> -libc-so-y = $(libc-y:.o=.os) $(libc-shared-y)
> +libc-so-y += $(libc-y:.o=.os) $(libc-shared-y)
>  else
>  all_sources = $(libc-y:.o=.c)
>  all_sources += $(libc-shared-y:.oS=.c)
> -libc-multi-y = $(filter-out $(libc-nomulti-y:.o=.c),$(all_sources))
> +libc-multi-y += $(filter-out $(libc-nomulti-y:.o=.c),$(all_sources))
>  endif
>  
>  lib-a-y += $(top_builddir)lib/libc.a
> 

Khem
if you need this fix, it menas that in some part you are using 
erroneously libc-a-y and libc-so-y.
Since a lot of time (aligned from trunk) we should use in internal 
Makefile libc-y for file common in static and dynamic libs, 
libc-shared-y for dynamic only and libc-static-y for dynamic only.
So please review your arm Makefile and revert this change.

Ciao,
Carmelo
> ___
> uClibc-cvs mailing list
> [EMAIL PROTECTED]
> http://busybox.net/cgi-bin/mailman/listinfo/uclibc-cvs
> 

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

Re: [PATCH] locale test fix.

[Carmelo AMOROSO]

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 comment are welcome.
> 
> Best Regards,
> Filippo.
> 
> This patch fixes several locale tests:
> 
> libc/stdlib/_strtod.c   -> tst_wcstod;
> libc/stdlib/stdlib.c-> tst_mblen, tst_mbtowc, tst_wctomb;
> libc/stdio/_scanf.c -> tst_swscanf;
> libc/string/strncmp.c   -> tst_wcsncmp;
> libc/misc/wchar/wchar.c -> tst_mbrlen, tst_mbrtowc, tst_wcswidth.
> 
> Signed-off-by: Filippo Arcidiacono <[EMAIL PROTECTED]>
> 

Hi All,
is there anybody having some experience on locale that could review this 
patch.
This work has been produced by Filippo (a my collegue) and I've already 
reviewed together, so may be worth someone else have a look at.
We are confident on the fixes as confirmed by having fixed some tests 
from glibc.
We would like to integrated them into trunk soon.

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

Re: libc_hidden_proto removal en masse

[Carmelo AMOROSO]

Bernd Schmidt wrote:
> Carmelo AMOROSO wrote:
> 
>> I'd like to highlight that we need to fix the testsuite build system.
>> I've sent a patch recently putting together some suggestions by 
>> Bernard, Bernd and others. I'd like to have it reviewed so that it can 
>> be merged in.
> 
> I had missed that in the old thread.  The patch looks OK to me.
> 
> 
> Bernd
Hi Bernd,
thanks for feedback. The work is already in.

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

Re: svn commit: branches/uClibc-nptl/test: locale locale-mbwc

[Carmelo AMOROSO]

Bernhard Fischer wrote:
> On Wed, Jul 09, 2008 at 05:08:40PM +0200, Carmelo AMOROSO wrote:
> 
> Sounds like your revision 22684 broke the auto-testers since a plain
> $ make check
> doesn't work (anymore? Not sure if it worked before, i suspect it did).
> 
> We need at least (Makefile.in):
> -test check:
> +test check: test_compile
> 

Yes, you're right. aplogies. The reason is that I do etsting into two 
steps: firstly cross-compile them, then install and use make run to 
execute them so I forgot the one shot case.

> Also, the test dir has to pickup the correct flags, which it currently
> doesn't, i think.
> Care to have a look?
> 
Yes, now we don't use all CFLAGS used for building the uclibc, so likely 
we are missign something. Currently I'm not able to check it.

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

Re: svn commit: branches/uClibc-nptl/test: locale locale-mbwc

[Carmelo AMOROSO]

Bernhard Fischer wrote:
> On Fri, Jul 11, 2008 at 05:41:42PM +0200, Bernhard Fischer wrote:
>> On Wed, Jul 09, 2008 at 05:08:40PM +0200, Carmelo AMOROSO wrote:
>>
>> Sounds like your revision 22684 broke the auto-testers since a plain
>> $ make check
>> doesn't work (anymore? Not sure if it worked before, i suspect it did).
>>
>> We need at least (Makefile.in):
>> -test check:
>> +test check: test_compile
>>
>> Also, the test dir has to pickup the correct flags, which it currently
>> doesn't, i think.
>> Care to have a look?
> 
> I've fixed these now.
> The test/Rules.mk apparently has grown it's own incarnation of the
> toplevel Rules.mk.
> 
> 
> I'd be glad if you can make sure that the new locale-mbwc tests are only
> run if wchar is enabled. Otherwise i get the expected:
> 
>   TEST_LINK locale-mbwc/ tst_iswalnum
> In file included from tsp_common.c:17,
>  from tst_iswalnum.c:7:
> tst_types.h:14:19: error: wchar.h: No such file or directory
> tst_types.h:15:20: error: wctype.h: No such file or directory
> 
> TIA,
> 
I was too in hurry in committing . I'm guilty

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

Re: NPTL branch almost merged with trunk @ rev 22714

[Carmelo Amoroso]

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 synch&merge work.
>>
>> I've discussed privately with Khem that is working on re-basing ARM nptl 
>> port and agreed to commit all the merged stuff I had on my nptl working 
>> copy.
>> In the recent weeks I've merged/integrated and tested a lot of work from 
>> trunk making a almost synchronized nptl branch (at least of sh4 port).
>>
>> At this point the current status of the NPTL branch is that it is 
>> working fine for sh4 and should still build and work for mips.
>>
>> So I kindly ask Steve to test again on his mips hw (apologies idvance 
>> for any breakage I could have done).
>>
>> Khem now is working to rebase his ARM patches on top of the freashen 
>> branch and than commit his stuff.
>>
>> If no issues from mips side (hopefully) we can say to have again a 
>> stable nptl branch for al three supported archs.
>>
>> There are other few files not completely merged with trunk that need 
>> more investigation (misc/internals and some other headers), but 
>> excluding these all the differences between nptl and trunk should be 
>> related to NPTL and TLS part.
>>
>> I'll take care of merging future incoming changes on trunk back to nptl 
>> branch.
>>
>> After that, hopefully in the next weeks (next two weeks I'll be not 
>> available), we will be ready to move all to trunk.
> 
> Seeing you doing all this, I really hesitate to do libc_hidden_proto
> removal before you merge nptl branch to trunk - it (removal) will touch
> almost every .c and .h file!
> 
> So I will wait ~three weeks for the merge to complete.
> 
Ok Denys, thanks a lot... this will reduce my ffort in merge all these files.
> BTW, will there be a new uclibc release just before the merge?  ;) ;) ;)
definitely yes.

> --
> vda
>
cheers,
carmelo
  ___
> uClibc mailing list
> uClibc@uclibc.org
> http://busybox.net/cgi-bin/mailman/listinfo/uclibc
> 

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

Re: seg fault before main() in _pthread_cleanup_push_defer

[Carmelo Amoroso]

On 17/07/2008, Karl Hiramoto <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Previously i was using gcc 3.4.6, uclibc 0.28.3, kernel 2.6.16  and my
> program worked.
>
> I upgraded to gcc 4.2.4, uclibc 0.29, kernel 2.6.26  (using the current
> buildroot trunk  and linuxthreads.old)
>
> And now i have:
>
> running gdb on the target:
>
>  gdb /usr/bin/myprog
> GNU gdb 6.6
> Copyright (C) 2006 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "armeb-linux-uclibc"...
> Using host libthread_db library "/lib/libthread_db.so.1".
> (gdb) break main
> Breakpoint 1 at 0xc0e8: file /home/karl/Work/myprog.c, line 355.
> (gdb) run
> Starting program: /usr/bin/myprog
> [Thread debugging using libthread_db enabled]
> [New Thread 1024 (LWP 1321)]
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1024 (LWP 1321)]
> 0x400beb70 in _pthread_cleanup_push_defer () from /lib/libc.so.0
>
>
> # /strace /usr/bin/myprog
> execve("/usr/bin/myprog", ["/usr/bin/myprog"], [/* 6 vars */]) = 0
> syscall: unknown syscall trap 0x0017
>
>
>
> A lot of other software i have on the target works, but  I'm trying to
> debug what is going wrong with  this case of the segfault before main().
>
>
> Any ideas of things i can try?
> --
> Karl
>
Hi,
it seems you are accesing a null function pointer... this should be guarded
by checking for its not null value, but why it's not working is not clear.
This sounds to me something related to weak symbols issue, but only
with a deep analysis could be fuly understood.
May be something caused by usage of UCLIBC_MUTEX_LOCK macros.
Just an hint to continue with debugging.

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

Re: Changing runtime directory

[Carmelo AMOROSO]

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 building my target system in /target/
>>
>> I can simply compile uClibc for my target system without any errors. But 
>> when I chose "make PREFIX=/target install_runtime" the uClibc-runtimes are 
>> installed in /target/usr/i586-linux-uclibc/lib. I think, that this is not a 
>> big problem, but is it possible to install it just in /target/lib ?
>>
> 
> what happens when you set RUNTIME_PREFIX=/target/lib either in .config
> or on make commandline.
> 
> Thx
> 
> -Khem
Hi,
to achieve what you want, you need to set RUNTIME_PREFIX= (/target in your case) and set in .config the following

SHARED_LIB_LOADER_PREFIX="/lib"
RUNTIME_PREFIX="/"
DEVEL_PREFIX="/usr"

If you have other doubts, please post your .config.

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

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

Re: svn commit: branches/uClibc-nptl: include libc/stdlib/malloc-standard libc etc...

[Carmelo AMOROSO]

Carmelo AMOROSO wrote:
> [EMAIL PROTECTED] wrote:
>> Author: kraj
>> Date: 2008-07-11 15:22:24 -0700 (Fri, 11 Jul 2008)
>> New Revision: 22805
>>
>> Log:
>> Signed-off-by: Khem Raj <[EMAIL PROTECTED]>
>> Hush compiler for extern inline warnings by using __extern_inline macro, 
>> this also makes gcc 4.3 happy.
>>
>> warning: C99 inline functions are not supported; using GNU89  
>> warning: to disable this warning use -fgnu89-inline or the gnu
>>
>> Also fix this other warning.
>>
>> warning: missing braces around initializer
>> warning: (near initialization for '_stdio_streams[0].__lock.__
>>
>>
>> Modified:
>>branches/uClibc-nptl/include/ctype.h
>>branches/uClibc-nptl/libc/stdlib/malloc-standard/malloc.h
>>branches/uClibc-nptl/libc/sysdeps/linux/common/bits/cmathcalls.h
>>branches/uClibc-nptl/libc/sysdeps/linux/common/bits/uClibc_mutex.h
>>branches/uClibc-nptl/libc/sysdeps/linux/m68k/bits/mathinline.h
>>branches/uClibc-nptl/libpthread/nptl/sysdeps/pthread/bits/libc-lock.h
>>branches/uClibc-nptl/libpthread/nptl/sysdeps/pthread/pthread.h
>>
>>
>>
>>
> [SNIP]
>> Modified: branches/uClibc-nptl/libpthread/nptl/sysdeps/pthread/pthread.h
>> ===
>> --- branches/uClibc-nptl/libpthread/nptl/sysdeps/pthread/pthread.h   
>> 2008-07-11 22:20:59 UTC (rev 22804)
>> +++ branches/uClibc-nptl/libpthread/nptl/sysdeps/pthread/pthread.h   
>> 2008-07-11 22:22:24 UTC (rev 22805)
>> @@ -65,22 +65,22 @@
>>  
>>  /* Mutex initializers.  */
>>  #define PTHREAD_MUTEX_INITIALIZER \
>> -  { { 0, 0, 0, 0, 0, 0 } }
>> +  { { 0, 0, 0, 0, 0, { 0 } } }
>>  #ifdef __USE_GNU
>>  # if __WORDSIZE == 64
>>  #  define PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP \
>> -  { { 0, 0, 0, 0, PTHREAD_MUTEX_RECURSIVE_NP, 0 } }
>> +  { { 0, 0, 0, 0, PTHREAD_MUTEX_RECURSIVE_NP, { 0 } } }
>>  #  define PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP \
>> -  { { 0, 0, 0, 0, PTHREAD_MUTEX_ERRORCHECK_NP, 0 } }
>> +  { { 0, 0, 0, 0, PTHREAD_MUTEX_ERRORCHECK_NP, { 0 } } }
>>  #  define PTHREAD_ADAPTIVE_MUTEX_INITIALIZER_NP \
>> -  { { 0, 0, 0, 0, PTHREAD_MUTEX_ADAPTIVE_NP, 0 } }
>> +  { { 0, 0, 0, 0, PTHREAD_MUTEX_ADAPTIVE_NP, { 0 } } }
>>  # else
>>  #  define PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP \
>> -  { { 0, 0, 0, PTHREAD_MUTEX_RECURSIVE_NP, 0, 0 } }
>> +  { { 0, 0, 0, PTHREAD_MUTEX_RECURSIVE_NP, 0, { 0 } } }
>>  #  define PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP \
>> -  { { 0, 0, 0, PTHREAD_MUTEX_ERRORCHECK_NP, 0, 0 } }
>> +  { { 0, 0, 0, PTHREAD_MUTEX_ERRORCHECK_NP, 0, { 0 } } }
>>  #  define PTHREAD_ADAPTIVE_MUTEX_INITIALIZER_NP \
>> -  { { 0, 0, 0, PTHREAD_MUTEX_ADAPTIVE_NP, 0, 0 } }
>> +  { { 0, 0, 0, PTHREAD_MUTEX_ADAPTIVE_NP, 0, { 0 } } }
>>  # endif
>>  #endif
>>  
> 
> Hi Khem,
> this change is producing new warnings on my side:
> 
> sh4-linux-uclibc-gcc -c libc/misc/utmp/utent.c -o 
> libc/misc/utmp/utent.os -include ./include/libc-symbols.h -Wall 
> -Wstrict-prototypes -fno-strict-aliasing -ml -m4 -fno-stack-protector 
> -fno-builtin -nostdinc -I./include -I. -I./libc/sysdeps/linux/sh 
> -DUCLIBC_INTERNAL -std=gnu99 -Os -funit-at-a-time 
> -fno-tree-loop-optimize -fno-tree-dominator-opts -fno-strength-reduce 
> -fstrict-aliasing -mprefergot -DNDEBUG -I./libpthread/nptl 
> -I./libpthread/nptl/sysdeps/unix/sysv/linux/sh/sh4 
> -I./libpthread/nptl/sysdeps/unix/sysv/linux/sh 
> -I./libpthread/nptl/sysdeps/sh 
> -I./libpthread/nptl/sysdeps/unix/sysv/linux 
> -I./libpthread/nptl/sysdeps/pthread 
> -I./libpthread/nptl/sysdeps/pthread/bits 
> -I./libpthread/nptl/sysdeps/generic -I./ldso/ldso/sh -I./ldso/include 
> -I/opt/STM/STLinux-2.3/devkit/sh4_uclibc/target/usr/include/ 
> -I/opt/STM/STLinux-2.3/devkit/sh4_uclibc/lib/gcc/sh4-linux-uclibc/4.2.1//include-fixed
>  
> -I/opt/STM/STLinux-2.3/devkit/sh4_uclibc/lib/gcc/sh4-linux-uclibc/4.2.1/include
>  
> -DNDEBUG -D__USE_STDIO_FUTEXES__ -fPIC -DPIC -MT libc/misc/utmp/utent.os 
> -MD -MP -MF libc/misc/utmp/.utent.os.dep
> 
> 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 related to use of futex.
> 
> Carmelo

Looked at this better, and I'm convinced it's not correct.
pthread_mutex_t contains all scalar entries, extra braces are not required.
> ___
> uClibc-cvs mailing list
> [EMAIL PROTECTED]
> http://busybox.net/cgi-bin/mailman/listinfo/uclibc-cvs
> 

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

Re: svn commit: branches/uClibc-nptl: include libc/stdlib/malloc-standard libc etc...

[Carmelo AMOROSO]

[EMAIL PROTECTED] wrote:
> Author: kraj
> Date: 2008-07-11 15:22:24 -0700 (Fri, 11 Jul 2008)
> New Revision: 22805
> 
> Log:
> Signed-off-by: Khem Raj <[EMAIL PROTECTED]>
> Hush compiler for extern inline warnings by using __extern_inline macro, this 
> also makes gcc 4.3 happy.
> 
> warning: C99 inline functions are not supported; using GNU89  
> warning: to disable this warning use -fgnu89-inline or the gnu
> 
> Also fix this other warning.
> 
> warning: missing braces around initializer
> warning: (near initialization for '_stdio_streams[0].__lock.__
> 
> 
> Modified:
>branches/uClibc-nptl/include/ctype.h
>branches/uClibc-nptl/libc/stdlib/malloc-standard/malloc.h
>branches/uClibc-nptl/libc/sysdeps/linux/common/bits/cmathcalls.h
>branches/uClibc-nptl/libc/sysdeps/linux/common/bits/uClibc_mutex.h
>branches/uClibc-nptl/libc/sysdeps/linux/m68k/bits/mathinline.h
>branches/uClibc-nptl/libpthread/nptl/sysdeps/pthread/bits/libc-lock.h
>branches/uClibc-nptl/libpthread/nptl/sysdeps/pthread/pthread.h
> 
> 
> Changeset:
> Modified: branches/uClibc-nptl/libc/stdlib/malloc-standard/malloc.h
> ===
> --- branches/uClibc-nptl/libc/stdlib/malloc-standard/malloc.h 2008-07-11 
> 22:20:59 UTC (rev 22804)
> +++ branches/uClibc-nptl/libc/stdlib/malloc-standard/malloc.h 2008-07-11 
> 22:22:24 UTC (rev 22805)
> @@ -23,6 +23,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  libc_hidden_proto(mmap)
>  libc_hidden_proto(sysconf)
> 

Hi Khem, may you explain why this is needed ? for 
_pthread_cleanup_push/pop warning ?

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

Re: svn commit: trunk/uClibc/libc/stdio

[Carmelo AMOROSO]

[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 vprintf_internal
> * vsnprintf, vdprintf.c, vasprintf.c use
>   vprintf_internal directly
> 
> This makes sprintf faster (since it doesn't do any locking)
> and stops it from pulling in fseek in static compile.
> 
> 
> 
> Added:
>trunk/uClibc/libc/stdio/_vfprintf_internal.c
>trunk/uClibc/libc/stdio/_vfwprintf_internal.c
> 
> Modified:
>trunk/uClibc/libc/stdio/Makefile.in
>trunk/uClibc/libc/stdio/_stdio.h
>trunk/uClibc/libc/stdio/_vfprintf.c
>trunk/uClibc/libc/stdio/vasprintf.c
>trunk/uClibc/libc/stdio/vdprintf.c
>trunk/uClibc/libc/stdio/vsnprintf.c
>trunk/uClibc/libc/stdio/vswprintf.c
> 
> 
[SNIP]
> Modified: trunk/uClibc/libc/stdio/_vfprintf.c
> ===
> --- trunk/uClibc/libc/stdio/_vfprintf.c   2008-04-09 11:38:48 UTC (rev 
> 21682)
> +++ trunk/uClibc/libc/stdio/_vfprintf.c   2008-04-09 19:51:18 UTC (rev 
> 21683)
> @@ -1198,7 +1198,7 @@
>  
>  #endif
>  /**/
> -#if defined(L_vfprintf) || defined(L_vfwprintf)
> +#if defined(L__vfprintf_internal) || defined(L__vfwprintf_internal)
>  
>  /* We only support ascii digits (or their USC equivalent codes) in
>   * precision and width settings in *printf (wide) format strings.
> @@ -1207,14 +1207,15 @@
>  
>  static size_t _charpad(FILE * __restrict stream, int padchar, size_t numpad);
>  
> -#ifdef L_vfprintf
> +#ifdef L__vfprintf_internal
>  
> -#define VFPRINTF vfprintf
> +#define VFPRINTF_internal _vfprintf_internal
>  #define FMT_TYPE char
>  #define OUTNSTR _outnstr
>  #define STRLEN  strlen
>  #define _PPFS_init _ppfs_init
> -#define OUTPUT(F,S)  fputs_unlocked(S,F)
> +/* Pulls in fseek: #define OUTPUT(F,S)   fputs_unlocked(S,F) */
> +#define OUTPUT(F,S)  __stdio_fwrite((const unsigned char 
> *)(S),strlen(S),(F))

Hi Denys,
while running some test on nptl bracn with runtime assertion enabled,
I've discoverd that this change is causing uclibc aborting due to an
assert(bytes) in __stdio_fwrite, while calling fputs_unlocked all works
fine. I'd like to understand better the rationale behind and I'm
wondering if the problem is present in trunk with other arch than sh4.

To exploit the problem you simply need to call a printf with a format
string (i.e. printf("val=%d\n",x) ).

Please let me know your comments, thanks.

Carmelo

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

Re: svn commit: trunk/uClibc/libc/stdio

[Carmelo AMOROSO]

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,
>>   then calls vprintf_internal
>> * vsnprintf, vdprintf.c, vasprintf.c use
>>   vprintf_internal directly
>>
>> This makes sprintf faster (since it doesn't do any locking)
>> and stops it from pulling in fseek in static compile.
>>
>>
>>
>> Added:
>>trunk/uClibc/libc/stdio/_vfprintf_internal.c
>>trunk/uClibc/libc/stdio/_vfwprintf_internal.c
>>
>> Modified:
>>trunk/uClibc/libc/stdio/Makefile.in
>>trunk/uClibc/libc/stdio/_stdio.h
>>trunk/uClibc/libc/stdio/_vfprintf.c
>>trunk/uClibc/libc/stdio/vasprintf.c
>>trunk/uClibc/libc/stdio/vdprintf.c
>>trunk/uClibc/libc/stdio/vsnprintf.c
>>trunk/uClibc/libc/stdio/vswprintf.c
>>
>>
> [SNIP]
>> Modified: trunk/uClibc/libc/stdio/_vfprintf.c
>> ===
>> --- trunk/uClibc/libc/stdio/_vfprintf.c  2008-04-09 11:38:48 UTC (rev 
>> 21682)
>> +++ trunk/uClibc/libc/stdio/_vfprintf.c  2008-04-09 19:51:18 UTC (rev 
>> 21683)
>> @@ -1198,7 +1198,7 @@
>>  
>>  #endif
>>  /**/
>> -#if defined(L_vfprintf) || defined(L_vfwprintf)
>> +#if defined(L__vfprintf_internal) || defined(L__vfwprintf_internal)
>>  
>>  /* We only support ascii digits (or their USC equivalent codes) in
>>   * precision and width settings in *printf (wide) format strings.
>> @@ -1207,14 +1207,15 @@
>>  
>>  static size_t _charpad(FILE * __restrict stream, int padchar, size_t 
>> numpad);
>>  
>> -#ifdef L_vfprintf
>> +#ifdef L__vfprintf_internal
>>  
>> -#define VFPRINTF vfprintf
>> +#define VFPRINTF_internal _vfprintf_internal
>>  #define FMT_TYPE char
>>  #define OUTNSTR _outnstr
>>  #define STRLEN  strlen
>>  #define _PPFS_init _ppfs_init
>> -#define OUTPUT(F,S) fputs_unlocked(S,F)
>> +/* Pulls in fseek: #define OUTPUT(F,S)  fputs_unlocked(S,F) */
>> +#define OUTPUT(F,S) __stdio_fwrite((const unsigned char 
>> *)(S),strlen(S),(F))
> 
> Hi Denys,
> while running some test on nptl bracn with runtime assertion enabled,
> I've discoverd that this change is causing uclibc aborting due to an
> assert(bytes) in __stdio_fwrite, while calling fputs_unlocked all works
> fine. I'd like to understand better the rationale behind and I'm
> wondering if the problem is present in trunk with other arch than sh4.
> 
> To exploit the problem you simply need to call a printf with a format
> string (i.e. printf("val=%d\n",x) ).
> 
> Please let me know your comments, thanks.
> 
> Carmelo
> 
Hi,
doing further analysis, I've figure out why we fail using 
__stdio_fwrite. Basically __stdio_fwrite expects at least 1 bytes. 
fputs_unlocked(S,F) calls fwrite_unlocked and this calls __stdio_fwrite 
only if bytes to be written are > 0, otherwise simply returs 0 (that is 
correct). During the parsing of format spec it could happen that 
__stdio_fwrite is called passing an empty string and with assertion 
enabled it will abort.
So, I think that using fputs_unlocked is fine, I don't see any other 
reasons for calling __stdio_fwrite directly.

Cheers,
Carmelo
> ___
> uClibc mailing list
> uClibc@uclibc.org
> http://busybox.net/cgi-bin/mailman/listinfo/uclibc
> 

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

Re: [PATCH] sh: Fix args for __uClibc_main() in crt1.S

[Carmelo AMOROSO]

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 "r4" here.
> It is not documented, but because ldso/ldso/sh/dl-startup.h explicitly sets
>  0 to r4 just before jump here, there must be a kind of calling convention.
> So, I preserve the code, and add a comment that this is the way to pass
> rtld_fini from prior routine.
> I really can't find any documents about this convention, though.
> 
> /yoshii
> 
> ---
> sh: Fix args for __uClibc_main() in crt1.S
>   add missing 7th arg "stack_end".
>   add comment of undocumented usage of r4.
>   fix comment of expected __uClibc_main() prototype.
> 
> diff --git a/libc/sysdeps/linux/sh/crt1.S b/libc/sysdeps/linux/sh/crt1.S
> --- a/libc/sysdeps/linux/sh/crt1.S
> +++ b/libc/sysdeps/linux/sh/crt1.S
> @@ -24,6 +24,11 @@
>  
>   At this entry point, most registers' values are unspecified, except:
>  
> +   r4Contains a function pointer to be registered with 
> `atexit'.
> + This is how the dynamic linker arranges to have DT_FINI
> + functions called for shared libraries that have been loaded
> + before this code runs.
> +
> spThe stack contains the arguments and environment:
>   0(sp)   argc
>   4(sp)   argv[0]
> @@ -48,7 +53,8 @@ _start:
>   mov.l @r15+,r5
>   mov r15, r6
>  
> - /* Push the fini func onto the stack */
> + /* Push the stack_end, rtld_fini and fini func onto the stack */
> + mov.l r6,@-r15
>   mov.l r4,@-r15
>   mov.l L_fini,r0
>   mov.l r0,@-r15
> @@ -57,7 +63,7 @@ _start:
>   mov.l L_main,r4
>   mov.l L_init,r7
>  
> - /* __uClibc_main (main, argc, argv, init, fini) */
> + /* __uClibc_main (main, argc, argv, init, fini, rtld_fini, stack_end) */
>  
>   /* Let the libc call main and exit with its return code.  */
>   mov.l L_uClibc_main,r1
> 

Hi Takashi,
your point is correct and the patch looks fine. Looking again at the 
ld.so -> _start flow, yes sh4 forces rtld_fini to be NULL (r4 = 0 set in 
dl-startup.h as you told), so this means that on sh4 we do not call the 
_dl_fini destructor, loosing eventually to call the destructors of the 
dependant shared objects.
It should be simple enough to write a test showing this.
I'll spend a few time longer to look at what it's happening on glibc 
part, and eventually integrate your patch by setting the rtld_fini (6 ^ 
args) too.

Thanks a lot,
Carmelo
> ___
> uClibc mailing list
> uClibc@uclibc.org
> http://busybox.net/cgi-bin/mailman/listinfo/uclibc
> 

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

Re: [PATCH] sh: Fix args for __uClibc_main() in crt1.S

[Carmelo AMOROSO]

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 code pushed register "r4" here.
>> It is not documented, but because ldso/ldso/sh/dl-startup.h explicitly sets
>>  0 to r4 just before jump here, there must be a kind of calling convention.
>> So, I preserve the code, and add a comment that this is the way to pass
>> rtld_fini from prior routine.
>> I really can't find any documents about this convention, though.
>>
>> /yoshii
>>
>> ---
>> sh: Fix args for __uClibc_main() in crt1.S
>>   add missing 7th arg "stack_end".
>>   add comment of undocumented usage of r4.
>>   fix comment of expected __uClibc_main() prototype.
>>
>> diff --git a/libc/sysdeps/linux/sh/crt1.S b/libc/sysdeps/linux/sh/crt1.S
>> --- a/libc/sysdeps/linux/sh/crt1.S
>> +++ b/libc/sysdeps/linux/sh/crt1.S
>> @@ -24,6 +24,11 @@
>>  
>>  At this entry point, most registers' values are unspecified, except:
>>  
>> +   r4   Contains a function pointer to be registered with 
>> `atexit'.
>> +This is how the dynamic linker arranges to have DT_FINI
>> +functions called for shared libraries that have been loaded
>> +before this code runs.
>> +
>> sp   The stack contains the arguments and environment:
>>  0(sp)   argc
>>  4(sp)   argv[0]
>> @@ -48,7 +53,8 @@ _start:
>>  mov.l @r15+,r5
>>  mov r15, r6
>>  
>> -/* Push the fini func onto the stack */
>> +/* Push the stack_end, rtld_fini and fini func onto the stack */
>> +mov.l r6,@-r15
>>  mov.l r4,@-r15
>>  mov.l L_fini,r0
>>  mov.l r0,@-r15
>> @@ -57,7 +63,7 @@ _start:
>>  mov.l L_main,r4
>>  mov.l L_init,r7
>>  
>> -/* __uClibc_main (main, argc, argv, init, fini) */
>> +/* __uClibc_main (main, argc, argv, init, fini, rtld_fini, stack_end) */
>>  
>>  /* Let the libc call main and exit with its return code.  */
>>  mov.l L_uClibc_main,r1
>>
> 
> Hi Takashi,
> your point is correct and the patch looks fine. Looking again at the 
> ld.so -> _start flow, yes sh4 forces rtld_fini to be NULL (r4 = 0 set in 
> dl-startup.h as you told), so this means that on sh4 we do not call the 
> _dl_fini destructor, loosing eventually to call the destructors of the 
> dependant shared objects.
> It should be simple enough to write a test showing this.

Well, I've written the test and, as I thought, we do not call the 
destructor for any dependant shared objects.

> I'll spend a few time longer to look at what it's happening on glibc 
> part, and eventually integrate your patch by setting the rtld_fini (6 ^ 
> args) too.
> 
Indeed glibc (sysdeps/sh/dl-machine.h: _start) passes in r4 the _dl_fini
instead of NULL. This makes dso's destructor get properly called.

I'll see how to integrate a test case into the test-suite too.

Full fix will come soon.
Carmelo

> Thanks a lot,
> Carmelo
>> ___
>> uClibc mailing list
>> uClibc@uclibc.org
>> http://busybox.net/cgi-bin/mailman/listinfo/uclibc
>>
> 
> ___
> uClibc mailing list
> uClibc@uclibc.org
> http://busybox.net/cgi-bin/mailman/listinfo/uclibc
> 

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

Re: [PATCH] sh: Fix args for __uClibc_main() in crt1.S

[Carmelo AMOROSO]

Carmelo AMOROSO wrote:

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 code pushed register "r4" here.
It is not documented, but because ldso/ldso/sh/dl-startup.h 
explicitly sets
 0 to r4 just before jump here, there must be a kind of calling 
convention.

So, I preserve the code, and add a comment that this is the way to pass
rtld_fini from prior routine.
I really can't find any documents about this convention, though.

/yoshii

---
sh: Fix args for __uClibc_main() in crt1.S
  add missing 7th arg "stack_end".
  add comment of undocumented usage of r4.
  fix comment of expected __uClibc_main() prototype.

diff --git a/libc/sysdeps/linux/sh/crt1.S b/libc/sysdeps/linux/sh/crt1.S
--- a/libc/sysdeps/linux/sh/crt1.S
+++ b/libc/sysdeps/linux/sh/crt1.S
@@ -24,6 +24,11 @@
 
 At this entry point, most registers' values are unspecified, 
except:
 
+   r4Contains a function pointer to be registered with 
`atexit'.

+This is how the dynamic linker arranges to have DT_FINI
+functions called for shared libraries that have been loaded
+before this code runs.
+
spThe stack contains the arguments and environment:
0(sp)argc
 4(sp)argv[0]
@@ -48,7 +53,8 @@ _start:
 mov.l @r15+,r5
 mov r15, r6
 
-/* Push the fini func onto the stack */

+/* Push the stack_end, rtld_fini and fini func onto the stack */
+mov.l r6,@-r15
 mov.l r4,@-r15
 mov.l L_fini,r0
 mov.l r0,@-r15
@@ -57,7 +63,7 @@ _start:
 mov.l L_main,r4
 mov.l L_init,r7
 
-/* __uClibc_main (main, argc, argv, init, fini) */
+/* __uClibc_main (main, argc, argv, init, fini, rtld_fini, 
stack_end) */
 
 /* Let the libc call main and exit with its return code.  */

 mov.l L_uClibc_main,r1



Hi Takashi,
your point is correct and the patch looks fine. Looking again at the 
ld.so -> _start flow, yes sh4 forces rtld_fini to be NULL (r4 = 0 set 
in dl-startup.h as you told), so this means that on sh4 we do not call 
the _dl_fini destructor, loosing eventually to call the destructors of 
the dependant shared objects.

It should be simple enough to write a test showing this.


Well, I've written the test and, as I thought, we do not call the 
destructor for any dependant shared objects.


I'll spend a few time longer to look at what it's happening on glibc 
part, and eventually integrate your patch by setting the rtld_fini (6 
^ args) too.



Indeed glibc (sysdeps/sh/dl-machine.h: _start) passes in r4 the _dl_fini
instead of NULL. This makes dso's destructor get properly called.

I'll see how to integrate a test case into the test-suite too.

Full fix will come soon.
Carmelo


Thanks a lot,
Carmelo



Hi,
please find attached another patch to completely fix the sh4 startup 
sequence (in addition to the patch of Yoshii).


As you can see from the log below, DSO's destructor now is called.

Paul, does it sound good for you ?


_dl_protect_relro:124: RELRO protecting 
/home/carmelo/uclibc-libs/lib/ld-uClibc.so.0:  start:0x2956f000, 
end:0x2957
_dl_get_ready_to_run:898: calling INIT: 
/home/carmelo/uclibc-libs/lib/libc.so.0


_dl_get_ready_to_run:898: calling INIT: ./libfoo.so

foo constructor called !
_dl_get_ready_to_run:927: Calling _dl_allocate_tls_init()!
transfering control to application @ 0x400354
Calling foo()
foo called ... by carmelo
_dl_fini:132:
calling FINI: ./libfoo.so

foo destructor called !

Thanks,
Carmelo
Fix ldso startup sequence by passing via r4 the rtls finalizer
_dl_fini to the user application. This will be the 6^ arg of
__uClibc_main and will be registered with 'atexit'.
In this way the dynamic linker will be able to call destructors
defined within the loaded DSO.

Signed-off-by: Carmelo Amoroso <[EMAIL PROTECTED]>

Index: ldso/ldso/sh/dl-startup.h
===
--- ldso/ldso/sh/dl-startup.h   (revision 162)
+++ ldso/ldso/sh/dl-startup.h   (working copy)
@@ -12,10 +12,20 @@
 "  bsrfr0\n"
 "  add #4, r4\n"
 ".jmp_loc:\n"
-"  jmp @r0\n"
-"  mov#0, r4   !call _start with arg == 0\n"
+   "   mov r0, r8  ! Save the user entry point address in r8\n"
+   "   mov.l   .L_got, r12 ! Load the GOT on r12\n"
+   "   mova.L_got, r0\n"
+   "   add r0, r12\n"
+   "   mov.l   .L_dl_fini, r0\n"
+   "   mov.l   @(r0,r12), r4   ! Pass the finalizer in r4\n"
+"  jmp @r8\n"
+   "  

Re: [PATCH] sh: Fix args for __uClibc_main() in crt1.S

[Carmelo AMOROSO]

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 different way.

> I've add small patch. Though I am really not confidence of correctness
> This one set the pointer to _dl_init() after simple PC-relative relocation.
> 
[SNIP]
> 
> I even dont know if what rtld_fini do is this or not, though ;)
> But, without fix, no "fini" line appears.

Yes, it's rtld_fini doing this. This is the flow:
__uClibc_main -> main() -> exit -> __uClibc_fini() -> rtld_fini

> 
> /yoshii
> 
> ---
> SH: dl-startup.h: Set pointer to _dl_fini as an arg to _start.
> 
> ldso/ldso/sh/dl-startup.h |6 +-
> 1 files changed, 5 insertions(+), 1 deletions(-)
> 
> diff --git a/ldso/ldso/sh/dl-startup.h b/ldso/ldso/sh/dl-startup.h
> index 3e59093..398846c 100644
> --- a/ldso/ldso/sh/dl-startup.h
> +++ b/ldso/ldso/sh/dl-startup.h
> @@ -12,10 +12,14 @@ __asm__(
> "bsrfr0\n"
> "add#4, r4\n"
> ".jmp_loc:\n"
> +"stspr, r1! pr == here\n"
> +"mov.l.L_dl_fini, r4\n"
> "jmp@r0\n"
> -"mov#0, r4 !call _start with arg == 0\n"
> +"addr1, r4 !call _start with arg _dl_init\n"
> ".L_dl_start:\n"
> ".long   _dl_start-.jmp_loc\n"
> +".L_dl_fini:\n"
> +".long   _dl_fini-.jmp_loc\n"
> ".size_start,.-_start\n"
> ".previous\n"
> );
> -- 1.5.4.5

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 ?

My solution is based on a more generic solution using a GOT entry.
What is the best solution ? comments ?

Carmelo

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

Re: [PATCH] sh: Fix args for __uClibc_main() in crt1.S

[Carmelo AMOROSO]

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 code tells us that this 
> program is
> more or less under such a restriction, I think.
> But, yes, this one could result some difficulty on future re-construction.
> 
>> My solution is based on a more generic solution using a GOT entry.
>> What is the best solution ? comments ?
> May I? May I say, My code is better because it is 12 bytes smaller!
> as a joke. Thank you.
> Your GOT approach is more generic, and seems to be common seeing other 
> ARCHs does the same(except m68k and mips?). Please feel free to ignore
> my code. I'm happy to see the issue fixed by the combined code.
> 
> Cheers.
> /yoshii
> 

Ok,
I'll commit it. Good collaborative work ;-)

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

Re: gentoo patchset

[Carmelo AMOROSO]

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 tree? Personally, I'm most interested about the libm
> ones, but the other ones may be nice to have too.
> 
> Best regards,
> Cristi
> 
> [1] http://www.gentoo-portage.com/AJAX/Ebuild/66923
> [2] http://mirror.mcs.anl.gov/pub/gentoo/distfiles/
> uClibc-0.9.28.3-patches-1.8.tar.bz2
> 
> 
Being this patch set against 0.9.28 release, that is an old release,
  I assume that most of these fixes should be already into the current 
main stream. Doing this kind of analysis, even if could shown some 
unknown problem, is time consuming. I honestly don't have time for this now.

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

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

Re: gentoo patchset

[Carmelo Amoroso]

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 tree? Personally, I'm most interested about the libm
>>> ones, but the other ones may be nice to have too.
>>>
>>> Best regards,
>>> Cristi
>>>
>>> [1] http://www.gentoo-portage.com/AJAX/Ebuild/66923
>>> [2] http://mirror.mcs.anl.gov/pub/gentoo/distfiles/
>>> uClibc-0.9.28.3-patches-1.8.tar.bz2
>>>
>>>
>> Being this patch set against 0.9.28 release, that is an old release,
>>   I assume that most of these fixes should be already into the current 
>> main stream. Doing this kind of analysis, even if could shown some 
>> unknown problem, is time consuming. I honestly don't have time for this now.
> 
> The ones I know for sure that are missing both from the latest release and CVS
> are the ones that add those extra functions to libm, and that I really need 
> in 
> order to compile kvm and link it against uClibc.
> 
> Best regards,
> Cristi
> 

May you create an ad hoc patch for this missing libm functions
and propose for adding to uclibc. A config option will be required
to selectively enable/disable this extra... what are they ?

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

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

Re: Default Password for uclibc login

[Carmelo Amoroso]

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.
> 
> Does anyone whats the default password is?
> 
> need your guys help..
> 
> thanks
> Mandeep
> 

Hi,
not a uclibc issue, Please ask to busybox list.

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

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

Re: svn commit: branches/uClibc-nptl/test/dlopen

[Carmelo Amoroso]

On 15/08/2008, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Author: kraj
> Date: 2008-08-14 22:28:09 -0700 (Thu, 14 Aug 2008)
> New Revision: 23082
>
> Log:
> Use pthread_once now __pthread_once is not defined in tests.
>
>
Hi Khem,
why is it not defined ? if so, the extern declaration is not longer
required, anyway I've some concern with this change.

carmelo
> Modified:
>branches/uClibc-nptl/test/dlopen/libtest.c
>
>
> Changeset:
> Modified: branches/uClibc-nptl/test/dlopen/libtest.c
> ===
> --- branches/uClibc-nptl/test/dlopen/libtest.c2008-08-15 05:26:51 UTC 
> (rev
> 23081)
> +++ branches/uClibc-nptl/test/dlopen/libtest.c2008-08-15 05:28:09 UTC 
> (rev
> 23082)
> @@ -7,7 +7,7 @@
>  void dltest(uint32_t **value1, uint32_t **value2);
>  void dltest(uint32_t **value1, uint32_t **value2)
>  {
> - *value1 = (uint32_t *) __pthread_once;
> + *value1 = (uint32_t *) pthread_once;
>   *value2 = (uint32_t *) pthread_self;
>  }
>
>
> ___
> uClibc-cvs mailing list
> [EMAIL PROTECTED]
> http://busybox.net/cgi-bin/mailman/listinfo/uclibc-cvs
>
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc

Re: system() not working properly after moving to uClibc

[Carmelo Amoroso]

On 14/08/2008, mzhang <[EMAIL PROTECTED]> wrote:
> Hello folks,
>
> We are migrating to Linux-2.6.10+uClibc-0.9.28.1+Busybox-1.2.2.1 on a
> mipsel embedded platform from Linux kernel 2.4 + glibc 1.x. Everything
> in our application seems working fine except the "system()" call.
>
> Our application is multi-threaded and "the system()" call worked in the
> main thread, but after all other threads (around 10) are running, the
> "system()" call stopped working and returns "-1".  We tried the simplest
> one "system("ls")" and it failed with "-1".
>
Hi,
may you attach the output with strace ? what is the errno ?
have you tried to debug it a bit ? does it happen with current main stream ?

> The application has been running on the old system for 4 years and we
> never had this problem. So presumably, we think it might have something
> to do with the fork() and pthread implementation in the uClibc.
>
> I searched in the mailing list and nothing comes close. So, any help is
> appreciated here.
>
> Thanks,
>
> Michael
>
>
>
>
> ___
> uClibc mailing list
> uClibc@uclibc.org
> http://busybox.net/cgi-bin/mailman/listinfo/uclibc
>
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc

Re: confirmed working NPTL revision?

[Carmelo Amoroso]

Cristi Magherusan wrote:
> Hello,
> 
> Can anyone tell which revision of the NPTL branch is tested and
> confirmed to work well on x86? 

None, only mips, arm and sh4 have nptl support.

Also, a new status report for the merge
> with the NPTL branch would be greatly appreciated.
> 
> The current HEAD is failing to build with this message:
> 
>   GEN libpthread/nptl/pthread-errnos.c
>   CC libpthread/nptl/pthread-errnos.s
> make[1]: *** No rule to make target `nptl_arch_headers'.  Stop.
> make: *** [pregen] Error 2
> 
> Best regards,
> Cristi
> 

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

Re: confirmed working NPTL revision?

[Carmelo AMOROSO]

Cristi Magherusan wrote:
> On Tue, 2008-08-19 at 08:34 +0200, Carmelo Amoroso wrote:
>> Cristi Magherusan wrote:
>>> Hello,
>>>
>>> Can anyone tell which revision of the NPTL branch is tested and
>>> confirmed to work well on x86? 
>> None, only mips, arm and sh4 have nptl support.
> 
> Can we hope for a x86 version in the (near) future?
> 
> My application (the kvm userspace tool) needs Thread Local Storage
> support and some other things from the libc. It seems the main uclibc
> branch lacks the TLS stuff and it is present in the NPTL one.
> 
TLS does not imply NTPL. TLS concerns handling of a new kind of 
relocation and it should be provided by the dynamic linker, while NPTL 
is the Posix implementation on a pthread library rather then using 
linuxthreads implementation.
Said that, I don't think addign TLS support for i386 is difficult, but 
we need someone having time to spend on it.

> What could be the complexity/difficulty of implementing NPTL support on
> x86?
>
do you need TLS support or NPTL pthread library too?

> Regards,
> Cristi
> 
Carmelo
> 
> 
> 
> 
> ___
> uClibc mailing list
> uClibc@uclibc.org
> http://busybox.net/cgi-bin/mailman/listinfo/uclibc

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

Re: svn commit: branches/uClibc-nptl: include libc/stdlib/malloc-standard libc etc...

[Carmelo AMOROSO]

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 related to use of futex.
>>>
>>> Carmelo
>>> 
>> Looked at this better, and I'm convinced it's not correct.
>> pthread_mutex_t contains all scalar entries, extra braces are not required.
>>   
> 
> I'm also seeing this in my port on the "tile" architecture, using the
> latest nptl branch code now.  In my build I use -Werror, since I don't
> want to accidentally start building code with obvious warnings in it, so
> I'll have to #ifdef the extra braces away on our architecture (yuck).
> 
> I have a different, though somewhat related problem; I've changed the
> lowlevellock code to be more efficient on our architecture, so the "int
> __lock" has to be "__lll_lock_t lock" (a two-word struct), and I pull
> that type and the __LLL_LOCK_INITIALIZER into pthreadtypes.h, then use
> it in pthread.h.
> 
> But maybe we should just admit that there's going to be architectural
> skew here, and move the definition of the initializer into the
> per-architecture pthreadtypes.h, to go next to the actual structure
> definition that it's initializing?
> 

Hi Chris,
let me have a look...

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

[PATCH] sh : a little optimization in clone.S

[Carmelo AMOROSO]

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
A little optimization in clone sanity check: use a delayed branch
instruction (bt/s) so that null pointer check for second input
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   (working copy)
@@ -44,7 +44,7 @@
 clone:
/* sanity check arguments.  */
tst r4, r4
-   bt  0f
+   bt/s0f
tst r5, r5
bf/s1f
 mov#+__NR_clone, r3
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc

Re: [PATCH] sh: fix __HAVE_SHARED__ condition in crti.S.

[Carmelo AMOROSO]

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 used (only)in NON-shared case ?
> 
Well, this change has been committed by lethal at
http://www.uclibc.org/cgi-bin/viewcvs.cgi/trunk/uClibc/libc/sysdeps/linux/sh/crti.S?rev=16426&view=diff&r1=16426&r2=16425&p1=trunk/uClibc/libc/sysdeps/linux/sh/crti.S&p2=/trunk/uClibc/libc/sysdeps/linux/sh/crti.S

so, unless there something I'm not understanding too, I suppose it was a 
typo by Paul (aka lethal).
Paul, my you give some lights on this change ?

I'm wondering anyway it the could be a testcase to show a potential 
problem (if this is wrong).

Carmelo
> I did some cleanups as well as invert that conditions.
> Actually, "push r12" is not needed in non-shared case. But, I've left it
>  untouched, because I don't want to modify the function epilogue(crtn.S).
> If fixed, we will have 4 bytes smaller code. Anyone want it ?
> 
> Regards,
> /yoshii
> ---
> libc/sysdeps/linux/sh/crti.S:
>   Fix(invert) __HAVE_SHARED__ condition.
>   Reorder/eliminate instructions.
> 
> Signed-off-by: Takashi YOSHII <[EMAIL PROTECTED]>
> ---
> diff --git a/libc/sysdeps/linux/sh/crti.S b/libc/sysdeps/linux/sh/crti.S
> index a74f96e..a092b78 100644
> --- a/libc/sysdeps/linux/sh/crti.S
> +++ b/libc/sysdeps/linux/sh/crti.S
> @@ -12,20 +12,17 @@ _init:
>   mov.l   r12,@-r15
>   mov.l   r14,@-r15
>   sts.l   pr,@-r15
> -#ifndef __HAVE_SHARED__
> + mov r15,r14
> +#ifdef __HAVE_SHARED__
>   mova.L6,r0
>   mov.l   .L6,r12
> - add r0,r12
> -#endif   
> - mov r15,r14
>   bra 1f
> - nop
> + add r0,r12
>   .align 2
> -#ifndef __HAVE_SHARED__
>  .L6:
>   .long   _GLOBAL_OFFSET_TABLE_
> -#endif
>  1:
> +#endif
>   
>   .section .fini
>   .hidden  _fini
> @@ -37,19 +34,15 @@ _fini:
>   mov.l   r14,@-r15
>   sts.l   pr,@-r15
>   mov r15,r14
> -#ifndef __HAVE_SHARED__
> +#ifdef __HAVE_SHARED__
>   mov.l   .L11,r12
>   mova.L11,r0
> - add r0,r12
> -#endif   
> -
>   bra 1f
> - nop
> + add r0,r12
>   .align 2
> -#ifndef __HAVE_SHARED__
>  .L11:
>   .long   _GLOBAL_OFFSET_TABLE_
> -#endif
>  1:
> +#endif
>   
>   .ident  "GCC: (GNU) 3.3.2"
> 
> ___
> uClibc mailing list
> uClibc@uclibc.org
> http://busybox.net/cgi-bin/mailman/listinfo/uclibc
> 

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

Re: [PATCH] sh : a little optimization in clone.S

[Carmelo AMOROSO]

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 are thinking that it could not be a real 
optimization due to potential unuseful i-cache miss.
So, I need to clarify it before. sorry ;-)

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

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

Re: [PATCH] sh: fix __HAVE_SHARED__ condition in crti.S.

[Carmelo AMOROSO]

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 this should be "ifdef", but "ifndef".
>>> Or, are there any reason that GOT should be used (only)in NON-shared case ?
>>>
>> Well, this change has been committed by lethal at
>> http://www.uclibc.org/cgi-bin/viewcvs.cgi/trunk/uClibc/libc/sysdeps/linux/sh/crti.S?rev=16426&view=diff&r1=16426&r2=16425&p1=trunk/uClibc/libc/sysdeps/linux/sh/crti.S&p2=/trunk/uClibc/libc/sysdeps/linux/sh/crti.S
>>
>> so, unless there something I'm not understanding too, I suppose it was a 
>> typo by Paul (aka lethal).
>> Paul, my you give some lights on this change ?
>>
> I had to think about this briefly. It was part of the SH-2 work done by
> Mark Shinwell (added to Cc). The disabling of GOT related code in the
> non-shared case was intentional, but I don't immediately recall what the
> rationale was.
> 
yes, but as Yoshii spotted, the code now seems doing just the opposite.

> Original thread here:
> 
>   http://www.uclibc.org/lists/uclibc/2006-October/016617.html
> 
> I expect that it's related to the ABI, in that we also don't have the GOT
> references in the FDPIC case, so it should likely be conditionalized for
> the targets that actually emit _GLOBAL_OFFSET_TABLE_, rather than
> depending on __HAVE_SHARED__. While I hit this on FDPIC, I would wager
> that Mark hit this on shared FLAT (which we don't have support in-tree
> for anyways) on his internal libc.
> 

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

Re: confirmed working NPTL revision?

[Carmelo AMOROSO]

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?
> 
> Perhaps it would be better to update the non-old libpthread to something
> recent and add TLS to that. The .old is the proven fallback AFAIU.
> 
absolutely agreed.
>> I can volunteer, but I may need someone more experienced to guide me. 
> 
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 for explanation whenever you want... if we can/know, we 
can help.
Volunteers are always welcome.

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

REJECT : Re: [PATCH] sh : a little optimization in clone.S

[Carmelo AMOROSO]

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 on. After a discussion with a colleague of mine, really sh4 
>> architectural expert, we are thinking that it could not be a real 
>> optimization due to potential unuseful i-cache miss.
>> So, I need to clarify it before. sorry ;-)
>>
> You could work around that by prefetching the icache line earlier on in
> the entry, but if you do that, you will want to measure to see if you
> still have any savings from using the delayed branch. I expect the
> prefetch will negate any micro-optimized win you are aiming for with the
> delayed branch.
> 
Thanks Paul for this feedback.
Indeed, in the delay slot it should be done instruction that are 
required to the instruction at the destination target and later.

So, discard this patch.

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

Re: static linking for pthreads in nptl branch?

[Carmelo AMOROSO]

Chris Metcalf wrote:
> I seem to recall seeing some comment somewhere that static linking
> didn't work with pthread programs in the NPTL branch.  
No, there were bugs in the past but all fixed. We use nptl branch for 
sh4 statically linked too... unless I did not push back these fix to the 
SVN nptl branch, it sould work fine as well.
Let me find where/when I fixed this for sh.

Cheers,
Carmelo
Of course, I had
> to go and debug a crash bug for a few hours first before I actually
> remembered.  :-)
> 
> The problem I ended up looking at was that
> __pthread_initialize_minimal() is called from __uClibc_init(), but since
> the caller is being linked from libc.a after libpthread.a has been fully
> processed, the function chosen is the one in libc.a, rather than the one
> in libpthread, even though that one is listed earlier on the command
> line.  Is this the bug?  Is there more to it?
> 
> I'm going to make the (hacky?) change to have libpthread.a (static only)
> include a copy of libc/misc/internals/__uClibc_main.o, which should mean
> that when you link statically with -lpthread -lc, you'll get the pthread
> __uClibc_main(), and therefore the pthread
> __pthread_initialize_minimal().  But I suspect there may be more than
> that that is broken.  And clearly this doesn't help the case of losers
> who do "-lc -lpthread", which is not that uncommon.
> 
>  //tilera/main/tools/uclibc/libpthread/nptl/Makefile.in#1 -
> /u/cmetcalf/p4/m3/tools/uclibc/libpthread/nptl/Makefile.in 
> @@ -247,7 +247,7 @@
> libc-cancellation.c)
>  libpthread-nonshared-y += $(patsubst
> %,$(PTHREAD_OUT)/%.oS,$(libpthread_static_SRC))
> 
> -libpthread-a-y := $(patsubst
> $(PTHREAD_DIR)/%.c,$(PTHREAD_OUT)/%.o,$(libpthread_a_SRC))
> +libpthread-a-y := $(patsubst
> $(PTHREAD_DIR)/%.c,$(PTHREAD_OUT)/%.o,$(libpthread_a_SRC))
> libc/misc/internals/__uClibc_main.o
>  libpthread-so-y := $(patsubst
> $(PTHREAD_DIR)/%.c,$(PTHREAD_OUT)/%.oS,$(libpthread_so_SRC))
>  libpthread-static-y += $(patsubst
> $(PTHREAD_DIR)/%.c,$(PTHREAD_OUT)/%.o,$(libpthread_a_SRC)
> $(libpthread_static_SRC))
> 

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

Re: static linking for pthreads in nptl branch?

[Carmelo AMOROSO]

Forwarded just in case this reply previously was not received.
I got an error from the mailer.

Carmelo

 Original Message 
Subject: Re: static linking for pthreads in nptl branch?
Date: Mon, 01 Sep 2008 10:27:53 +0200
From: Carmelo AMOROSO <[EMAIL PROTECTED]>
Organization: STMicroelectronics - Ltd
To: Carmelo AMOROSO <[EMAIL PROTECTED]>
CC: Chris Metcalf <[EMAIL PROTECTED]>, uclibc@uclibc.org
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

Carmelo AMOROSO wrote:
> Chris Metcalf wrote:
>> I seem to recall seeing some comment somewhere that static linking
>> didn't work with pthread programs in the NPTL branch.  
> No, there were bugs in the past but all fixed. We use nptl branch for 
> sh4 statically linked too... unless I did not push back these fix to the 
> SVN nptl branch, it sould work fine as well.
> Let me find where/when I fixed this for sh.
> 
Well, the changes I did are all into the SVN nptl branch, at they are
related to __uClibc_main.c.

> Cheers,
> Carmelo
> Of course, I had
>> to go and debug a crash bug for a few hours first before I actually
>> remembered.  :-)
>>
>> The problem I ended up looking at was that
>> __pthread_initialize_minimal() is called from __uClibc_init(), but since
>> the caller is being linked from libc.a after libpthread.a has been fully
>> processed, the function chosen is the one in libc.a, rather than the one
>> in libpthread, even though that one is listed earlier on the command
>> line.  Is this the bug?  Is there more to it?
>>
It's not totally correct. When doing static link, the linker ld starts
reading your object trying to resolve undefined symbols against linked
libraries as listed: but once it finds a symbol in a object .o, it
includes all exported symbols, that may be used later for resolving
other undefined.
To understand what/where your linker load symbols from, I suggest you to
produce a link map by using -Wl,--map,my_map_file when linking your
application.
I'm sure map file will show what it's going wrong: it worked for me
perfectly at that time.

Feel free to send your mapfile, and I'll see if I can help.

Be sure you are aligned with current SVN nptl branch.

>> I'm going to make the (hacky?) change to have libpthread.a (static only)
>> include a copy of libc/misc/internals/__uClibc_main.o, which should mean
>> that when you link statically with -lpthread -lc, you'll get the pthread
>> __uClibc_main(), and therefore the pthread
>> __pthread_initialize_minimal().  But I suspect there may be more than
>> that that is broken.  And clearly this doesn't help the case of losers
>> who do "-lc -lpthread", which is not that uncommon.
>>
I don't think it is the proper fix. uClibc_main must be in libc only.

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

Re: static linking for pthreads in nptl branch?

[Carmelo Amoroso]

Chris Metcalf wrote:
> On 9/1/2008 2:51 AM, Carmelo AMOROSO wrote:
>> Chris Metcalf wrote:
>>> I seem to recall seeing some comment somewhere that static linking
>>> didn't work with pthread programs in the NPTL branch.  
>> No, there were bugs in the past but all fixed. We use nptl branch for
>> sh4 statically linked too... unless I did not push back these fix to
>> the SVN nptl branch, it sould work fine as well.
>> Let me find where/when I fixed this for sh.
> 
> It looks like my real problem was specific to some changes I made in our
> malloc.  We use the "mspace" malloc that is in later versions of Doug
> Lea's malloc, and one thing we do for performance is to give each thread
> its own mspace arena for allocation.  To make this fast for
> single-threaded programs we have a stub pthread_mspace() routine in libc
> and the real one in libpthread.  But if it's only referenced from libc
> (from malloc), then when a static link is done, we end up getting the
> single-threaded version from libc instead of the multi-threaded version
> in libpthread.  (Of course it works fine with shared objects.)
> 
> For now I'm fixing this by adding a dummy reference to pthread_mspace
> from nptl/init.c so it always gets resolved early enough in the static
> link process.  It seems like any pthread symbols not explicitly
> mentioned in nptl/pthread_create.c would have this problem too, though:
> for example, if you had a function in libc that wanted to be thread-safe
> when linked with -pthread and so called pthread_mutex_init() to set up a
> mutex in malloc'ed memory (for example), it would actually end up
> getting the libc version of pthread_mutex_init() when linked
> statically.  The libpthread versions of pthread_mutex_lock() and unlock
> are linked in properly since they're referenced in pthread_create().
> 
> I suspect the solution to all of this is to make sure to always
> "register" the correct function pointers for the whole API when
> libpthread's initialization code is called, so that the libc versions
> always end up doing a lookup on the registered function pointer and
> calling that, even with static linking.
> 

Hi Chris,
I understand your point, but can we say that we are building
a multi-threaded application if we don't call pthread_create
(that means linking pthread_create.o) ?

I think that you should define your stub for mspace as weak,
and, for the static case, call it by guarding against NULL...
if I've understood it correctly.

Cheers,
Carmelo

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

Re: [PATCH] sh: fix __HAVE_SHARED__ condition in crti.S.

[Carmelo AMOROSO]

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 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 used (only)in NON-shared 
>>>>> case ?
>>>>>
>>>> Well, this change has been committed by lethal at
>>>> http://www.uclibc.org/cgi-bin/viewcvs.cgi/trunk/uClibc/libc/sysdeps/linux/sh/crti.S?rev=16426&view=diff&r1=16426&r2=16425&p1=trunk/uClibc/libc/sysdeps/linux/sh/crti.S&p2=/trunk/uClibc/libc/sysdeps/linux/sh/crti.S
>>>>
>>>> so, unless there something I'm not understanding too, I suppose it was a 
>>>> typo by Paul (aka lethal).
>>>> Paul, my you give some lights on this change ?
>>>>
>>> I had to think about this briefly. It was part of the SH-2 work done by
>>> Mark Shinwell (added to Cc). The disabling of GOT related code in the
>>> non-shared case was intentional, but I don't immediately recall what the
>>> rationale was.
>>>
>> yes, but as Yoshii spotted, the code now seems doing just the opposite.
>>
> Good point, it seems I'm unable to read in that case. :-)
> 
> Inverting it seems to be the reasonable thing to do. I'll give it a test
> and check in Yoshii-san's patch if nothing breaks.
> 
Hi Paul,
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 object file and I build it 
as a PIC object, then the compiler will create the proper 
_GLOBAL_OFFSET_TABLE_ entry and will produce the proper code to load and 
use r12.
Yes, glibc _init function does it, but I'm thinking that it is useless.
I cannot see a scenario in which this may fail. Are we sure we need this 
code at all? or we simply have taken the code as is from glibc in the past ?

I agree that the patch is logically correct, but we might add extra 
useless code.

Indeed, never before, I had problem using uclibc on sh4 due to this 
missing code.

Cheers,
Carmelo


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

Re: static linking for pthreads in nptl branch?

[Carmelo AMOROSO]

Chris Metcalf wrote:
> On 9/1/2008 11:29 AM, Carmelo Amoroso wrote:
>> Chris Metcalf wrote:
>>> It looks like my real problem was specific to some changes I made in our
>>> malloc.  We use the "mspace" malloc that is in later versions of Doug
>>> Lea's malloc, and one thing we do for performance is to give each thread
>>> its own mspace arena for allocation.  To make this fast for
>>> single-threaded programs we have a stub pthread_mspace() routine in libc
>>> and the real one in libpthread.  But if it's only referenced from libc
>>> (from malloc), then when a static link is done, we end up getting the
>>> single-threaded version from libc instead of the multi-threaded version
>>> in libpthread.  (Of course it works fine with shared objects.)
>>>
>>> For now I'm fixing this by adding a dummy reference to pthread_mspace
>>> from nptl/init.c so it always gets resolved early enough in the static
>>> link process.  It seems like any pthread symbols not explicitly
>>> mentioned in nptl/pthread_create.c would have this problem too, though:
>>> for example, if you had a function in libc that wanted to be thread-safe
>>> when linked with -pthread and so called pthread_mutex_init() to set up a
>>> mutex in malloc'ed memory (for example), it would actually end up
>>> getting the libc version of pthread_mutex_init() when linked
>>> statically.  The libpthread versions of pthread_mutex_lock() and unlock
>>> are linked in properly since they're referenced in pthread_create().
>>>
>>> I suspect the solution to all of this is to make sure to always
>>> "register" the correct function pointers for the whole API when
>>> libpthread's initialization code is called, so that the libc versions
>>> always end up doing a lookup on the registered function pointer and
>>> calling that, even with static linking.
>>>
>>
>> I understand your point, but can we say that we are building
>> a multi-threaded application if we don't call pthread_create
>> (that means linking pthread_create.o) ?
> 
> Sorry I wasn't clear.  Supposing we have a static library (or a function
> in libc.a) that wants to be thread-safe if it's linked with pthread, and
> still work if it's used in a single-thread program.  It calls
> pthread_mutex_init().  The main program does call pthread_create(), so
> when we link statically we do get a bunch of non-stub pthread functions
> -- but not pthread_mutex_init(), which we still get the stub for (unless
> the main program also called it).  Oops!  :-)
> 
Hi Chris,
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 libc
that calls pthread_mutex_init, and yes, when statically linked, even if 
using -lpthread, it was bind to the libc stub. At that time I fixed 
opendir by adding a memset to clear the lock data.
(see http://www.uclibc.org/cgi-bin/viewcvs.cgi?rev=20625&view=rev)

What about adding PTHREAD_STATIC_FN_REQUIRE (pthread_mutex_init)
in nptl/init.c ? were you thinking to this with the word 'register'.
I did not test it, but it may be sufficient.


>> I think that you should define your stub for mspace as weak,
>> and, for the static case, call it by guarding against NULL...
>> if I've understood it correctly.
> 
> I don't think weak will help in this case.  The weak undef will still
> just bind to the libc version, even if it's a weak def and the
> libpthread one is strong.
> 
yes, you're right.
> Thanks!
> 
Cheers,
Carmelo
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc

Re: static linking for pthreads in nptl branch?

[Carmelo AMOROSO]

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 libc
>> that calls pthread_mutex_init, and yes, when statically linked, even
>> if using -lpthread, it was bind to the libc stub. At that time I fixed
>> opendir by adding a memset to clear the lock data.
>> (see http://www.uclibc.org/cgi-bin/viewcvs.cgi?rev=20625&view=rev)
> 
> Since I just made that example up, it's funny that it was a real problem :-)
> 
:-)
>> What about adding PTHREAD_STATIC_FN_REQUIRE (pthread_mutex_init)
>> in nptl/init.c ? were you thinking to this with the word 'register'.
>> I did not test it, but it may be sufficient.
> 
> I had been thinking of just using the same shared model of "struct
> pthread_functions", but that's probably overkill, since it would bring
> in all of libpthread.a even if the application only used a few
> functions.  So perhaps just the extra PTHREAD_STATIC_FN_REQUIRE is the
> right approach.  It also avoids the scary assumption that
> PTHREAD_MUTEX_INITIALIZER is also all-zeroes on all platforms.
> 
Well, I've tried it using the old test case I had for the opendir 
problem, and with this fix pthread_mutex_init, in a static 
multi-threaded app, is now linked from libptrhead.a instead of libc.a 
(weaks.o).
If the app were single-threaded (-> pthread_create not called), then it 
would correctly resolved into the empty stub provided ad hoc by weaks.o.

Please, may you try with your application and see if it works as well ?

Carmelo

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

Re: Does the svn offer anonymous http access?

[Carmelo AMOROSO]

163Xman wrote:
>  Hello all,
>   It seems i am behind a firewall, and not able to access svn protocol.
> 
> Songmao
>  
>  
Yes, http is not supported. svn protocol requires same HTTP requests 
that your firewall should allow.

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

Re: Revision 20625, opendir

[Carmelo AMOROSO]

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 to the nptl 
>> branch
>> (one of this changes are exactly on weaks pthread symbols) and I'll
>> check again if this
>> fix is still required (anyway, glibc has the memset as I added into the 
>> uclibc),
>> but your point is correct.
> 
> Thanks for the update.  I don't really mind the change itself, but I 
> wanted to be sure it's not hiding a bug elsewhere.  It would be bad if 
> NPTL used real locking for single-threaded, statically linked binaries.
> 
 >
 > Bernd

Hi Bernd,
just an update. The problem was just the opposite. In NPTL 
multi-threaded, statically linked binaries, the locking functions were 
always empty stab (from weaks.o) instead of real ones from libpthread.a.

After recent discussions with Chris Metcalf, I figured out a better fix 
to be done in NPTL to force linking real locking functions in MT 
applications.
At this point the memset from opendir can be removed and reverted to the 
previous code: it was basically a work around.
Anyway, before committing, I'd try to check what happens on trunk with 
linuxthreads too.

Cheers,
Carmelo

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

Re: [PATCH] sh: fix __HAVE_SHARED__ condition in crti.S.

[Carmelo AMOROSO]

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 object file and I build it 
>> as a PIC object, then the compiler will create the proper 
>> _GLOBAL_OFFSET_TABLE_ entry and will produce the proper code to load and 
>> use r12.
>> Yes, glibc _init function does it, but I'm thinking that it is useless.
>> I cannot see a scenario in which this may fail. Are we sure we need this 
>> code at all? or we simply have taken the code as is from glibc in the past ?
>>
> I expect it is just something that was blindly copied from glibc. I
> wasn't the one that copied it in to uclibc originally, but I would wager
> it's a sanity measure to work around old compilers.
> 
interesting !
> The GCC ident references 3.3.2, I don't have anything that old sitting
> around any more, 
neither I have.
> but it might be worth testing out with something before
> that to see if the proper entry is generated without the init/fini help
> before deciding whether to axe the code completely or not.
> 
Yoshii, are you able to try with older gcc ? or was you able to produce 
a testcase ?

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

Re: static linking for pthreads in nptl branch?

[Carmelo AMOROSO]

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 in the past.
>>> It was related to opendir function that is the only function within libc
>>> that calls pthread_mutex_init, and yes, when statically linked, even
>>> if using -lpthread, it was bind to the libc stub. At that time I fixed
>>> opendir by adding a memset to clear the lock data.
>>> (see http://www.uclibc.org/cgi-bin/viewcvs.cgi?rev=20625&view=rev)
>>> 
>> Since I just made that example up, it's funny that it was a real problem :-)
>>
>>   
>>> What about adding PTHREAD_STATIC_FN_REQUIRE (pthread_mutex_init)
>>> in nptl/init.c ? were you thinking to this with the word 'register'.
>>> I did not test it, but it may be sufficient.
>>> 
>> I had been thinking of just using the same shared model of "struct
>> pthread_functions", but that's probably overkill, since it would bring
>> in all of libpthread.a even if the application only used a few
>> functions.  So perhaps just the extra PTHREAD_STATIC_FN_REQUIRE is the
>> right approach.  It also avoids the scary assumption that
>> PTHREAD_MUTEX_INITIALIZER is also all-zeroes on all platforms.
>>   
> 
> I think we also need to add
> 
> /* Used by __UCLIBC_MUTEX_LOCK for the libc locking code. */
> PTHREAD_STATIC_FN_REQUIRE (_pthread_cleanup_pop_restore)
> PTHREAD_STATIC_FN_REQUIRE (_pthread_cleanup_push_defer)
> 
> in pthread_create.c to avoid getting the stub versions.
> 
Yes, I've already add this into my working dir. It's on the way for svn too.

Carmelo


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

Re: [PATCH] sh: fix __HAVE_SHARED__ condition in crti.S.

[Carmelo AMOROSO]

Paul Mundt wrote:
> On Wed, Sep 03, 2008 at 05:47:56PM +0200, Carmelo AMOROSO wrote:
>> 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 object file and I build it 
>>>> as a PIC object, then the compiler will create the proper 
>>>> _GLOBAL_OFFSET_TABLE_ entry and will produce the proper code to load and 
>>>> use r12.
>>>> Yes, glibc _init function does it, but I'm thinking that it is useless.
>>>> I cannot see a scenario in which this may fail. Are we sure we need this 
>>>> code at all? or we simply have taken the code as is from glibc in the 
>>>> past ?
>>>>
>>> I expect it is just something that was blindly copied from glibc. I
>>> wasn't the one that copied it in to uclibc originally, but I would wager
>>> it's a sanity measure to work around old compilers.
>>>
>> interesting !
>>> The GCC ident references 3.3.2, I don't have anything that old sitting
>>> around any more, 
>> neither I have.
>>> but it might be worth testing out with something before
>>> that to see if the proper entry is generated without the init/fini help
>>> before deciding whether to axe the code completely or not.
>>>
>> Yoshii, are you able to try with older gcc ? or was you able to produce 
>> a testcase ?
>>
> Well, Sugioka-san has 3.04 and 2.97 binaries, but nothing beyond that.
> On the other hand, we're not even realistically able to build the kernel
> with anything that old, so it's likely not even worth bothering with.
> 
> Given that, and the fact we don't have a test case that manages to trip
> up the logic, we may as well just kill it off. The logic has been
> completely inverted from day one also, so it's unlikely anyone seriously
> tested or depended on this in the first place. If there were compiler
> issues earlier on, the inverted logic would obviously not have fixed this
> either. So, how about this?
> 
Absolutely agreed. That's what I was thinking.
Please commit.

Carmelo
> ---
> 
>  libc/sysdeps/linux/sh/crti.S |   23 ---
>  1 file changed, 23 deletions(-)
> 
> Index: libc/sysdeps/linux/sh/crti.S
> ===
> --- libc/sysdeps/linux/sh/crti.S  (revision 23132)
> +++ libc/sysdeps/linux/sh/crti.S  (working copy)
> @@ -1,5 +1,3 @@
> -#include 
> -
>   .file   "crti.S"
>   .text
>   
> @@ -12,19 +10,10 @@
>   mov.l   r12,@-r15
>   mov.l   r14,@-r15
>   sts.l   pr,@-r15
> -#ifndef __HAVE_SHARED__
> - mova.L6,r0
> - mov.l   .L6,r12
> - add r0,r12
> -#endif   
>   mov r15,r14
>   bra 1f
>   nop
>   .align 2
> -#ifndef __HAVE_SHARED__
> -.L6:
> - .long   _GLOBAL_OFFSET_TABLE_
> -#endif
>  1:
>   
>   .section .fini
> @@ -37,19 +26,7 @@
>   mov.l   r14,@-r15
>   sts.l   pr,@-r15
>   mov r15,r14
> -#ifndef __HAVE_SHARED__
> - mov.l   .L11,r12
> - mova.L11,r0
> - add r0,r12
> -#endif   
> -
>   bra 1f
>   nop
>   .align 2
> -#ifndef __HAVE_SHARED__
> -.L11:
> - .long   _GLOBAL_OFFSET_TABLE_
> -#endif
>  1:
> - 
> - .ident  "GCC: (GNU) 3.3.2"
> 

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

Re: static linking for pthreads in nptl branch?

[Carmelo AMOROSO]

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 in the past.
>>>> It was related to opendir function that is the only function within libc
>>>> that calls pthread_mutex_init, and yes, when statically linked, even
>>>> if using -lpthread, it was bind to the libc stub. At that time I fixed
>>>> opendir by adding a memset to clear the lock data.
>>>> (see http://www.uclibc.org/cgi-bin/viewcvs.cgi?rev=20625&view=rev)
>>>> 
>>> Since I just made that example up, it's funny that it was a real problem :-)
>>>
>>>   
>>>> What about adding PTHREAD_STATIC_FN_REQUIRE (pthread_mutex_init)
>>>> in nptl/init.c ? were you thinking to this with the word 'register'.
>>>> I did not test it, but it may be sufficient.
>>>> 
>>> I had been thinking of just using the same shared model of "struct
>>> pthread_functions", but that's probably overkill, since it would bring
>>> in all of libpthread.a even if the application only used a few
>>> functions.  So perhaps just the extra PTHREAD_STATIC_FN_REQUIRE is the
>>> right approach.  It also avoids the scary assumption that
>>> PTHREAD_MUTEX_INITIALIZER is also all-zeroes on all platforms.
>>>   
>> I think we also need to add
>>
>> /* Used by __UCLIBC_MUTEX_LOCK for the libc locking code. */
>> PTHREAD_STATIC_FN_REQUIRE (_pthread_cleanup_pop_restore)
>> PTHREAD_STATIC_FN_REQUIRE (_pthread_cleanup_push_defer)
>>
>> in pthread_create.c to avoid getting the stub versions.
>>
> Yes, I've already add this into my working dir. It's on the way for svn too.
> 
> Carmelo
> 
> 
I did it yesterday Revision: 23310
> ___
> uClibc mailing list
> uClibc@uclibc.org
> http://busybox.net/cgi-bin/mailman/listinfo/uclibc
> 

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

Re: [PATCH] locale test fix.

[Carmelo Amoroso]

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 comment are welcome.
>>>
>>> Best Regards,
>>> Filippo.
>>>
>>> This patch fixes several locale tests:
>>>
>>> libc/stdlib/_strtod.c   -> tst_wcstod;
>>> libc/stdlib/stdlib.c-> tst_mblen, tst_mbtowc, tst_wctomb;
>>> libc/stdio/_scanf.c -> tst_swscanf;
>>> libc/string/strncmp.c   -> tst_wcsncmp;
>>> libc/misc/wchar/wchar.c -> tst_mbrlen, tst_mbrtowc, tst_wcswidth.
>>>
>>> Signed-off-by: Filippo Arcidiacono <[EMAIL PROTECTED]>
>>>
>> Hi All,
>> is there anybody having some experience on locale that could review this 
>> patch.
>> This work has been produced by Filippo (a my collegue) and I've already 
>> reviewed together, so may be worth someone else have a look at.
>> We are confident on the fixes as confirmed by having fixed some tests 
>>from glibc.
>> We would like to integrated them into trunk soon.
> 
> Seems like nobody spotted problems with the patch, Carmelo, please
> apply.
> 
> TIA,
>
Yes, it is on on my next week todo list.

Carmelo


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

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

Re: status of 0.9.30 release

[Carmelo Amoroso]

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 he was the designated RM.
>>
>> What are the outstanding regressions versus 0.9.29 on your arch? i386
>> seems to be in a good shape, AFAICS. Perhaps it would be nice to look
>> at the open issues in mantis and fix a couple of them for .30-rc1.
>> Just a thought..
> 
> I'm interested in finding regressions too, because I'm seriously considering 
> putting out a .30 of my own just so there's a known set of bugs to test 
> against.  (Considering that nothing's been checked into the repository for 
> two weeks, this seems like a nice point to do it...)
> 
I agree, I don't see any real issues for postponing to ship a .30 release
just now.
I stopped for a while nptl merge because involved in kernel stuff,
but I'll go back to uclibc next week.
As you have seen, I've fixed a problem in ntpl static link.
I've discovered similar problrms on trunk (using linuxthreads.old) at least
on sh4 (but I think it's a common problem).
I'll come with a test case soon, but being this issue affecting static binaries,
I don't think it can delay .30 release.

I don't know Mike's plan, but he is silent since a long time.

> I was working on this last week, but upgrading my laptop to Kubuntu 8.04 
> knocked me offline for a week.  Back now. :)
> 
> Right now, I'm upgrading my Firmware Linux targets from 0.9.29 to svn.  I'll 
> let you know what breaks, and hopefully patch it up for a quick .30.  I 
> should be able to test x86, x86-64, mips (both endiannesses), arm little 
> endian, and powerpc.  (And maybe sparc if it suddenly decides to work, but it 
> didn't under 0.9.29.)
>
I'll try to test sh4 on trunk too.

> Rob
> _
Carmelo
___
> uClibc mailing list
> uClibc@uclibc.org
> http://busybox.net/cgi-bin/mailman/listinfo/uclibc
> 

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

Re: status of 0.9.30 release

[Carmelo Amoroso]

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?
>>> vapier would know, ISTR that he was the designated RM.
>>>
>>> What are the outstanding regressions versus 0.9.29 on your arch? i386
>>> seems to be in a good shape, AFAICS. Perhaps it would be nice to look
>>> at the open issues in mantis and fix a couple of them for .30-rc1.
>>> Just a thought..
>>
>> I'm interested in finding regressions too, because I'm seriously 
>> considering putting out a .30 of my own just so there's a known set of 
>> bugs to test against.  (Considering that nothing's been checked into 
>> the repository for two weeks, this seems like a nice point to do it...)
>>
> I agree, I don't see any real issues for postponing to ship a .30 release
> just now.
> I stopped for a while nptl merge because involved in kernel stuff,
> but I'll go back to uclibc next week.
> As you have seen, I've fixed a problem in ntpl static link.
> I've discovered similar problrms on trunk (using linuxthreads.old) at least
> on sh4 (but I think it's a common problem).
> I'll come with a test case soon, but being this issue affecting static 
> binaries,
> I don't think it can delay .30 release.
> 

Indeed I've few pending patches to push that may be worth
including in .30 release.

- locale supports fixes
- an optimized sh4 memcpy implementation (currently used
   since a long time in uclibc-nptl, glibc and kernel)
- getdents

> I don't know Mike's plan, but he is silent since a long time.
> 
>> I was working on this last week, but upgrading my laptop to Kubuntu 
>> 8.04 knocked me offline for a week.  Back now. :)
>>
>> Right now, I'm upgrading my Firmware Linux targets from 0.9.29 to 
>> svn.  I'll let you know what breaks, and hopefully patch it up for a 
>> quick .30.  I should be able to test x86, x86-64, mips (both 
>> endiannesses), arm little endian, and powerpc.  (And maybe sparc if it 
>> suddenly decides to work, but it didn't under 0.9.29.)
>>
> I'll try to test sh4 on trunk too.
> 
>> Rob
>> _
> Carmelo
> ___
>> uClibc mailing list
>> uClibc@uclibc.org
>> http://busybox.net/cgi-bin/mailman/listinfo/uclibc
>>
> 
> 

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

Re: status of 0.9.30 release

[Carmelo Amoroso]

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 merge?
>>>>>
>>>>> What is the status of the 0.9.30 release?
>>>> vapier would know, ISTR that he was the designated RM.
>>>>
>>>> What are the outstanding regressions versus 0.9.29 on your arch? i386
>>>> seems to be in a good shape, AFAICS. Perhaps it would be nice to look
>>>> at the open issues in mantis and fix a couple of them for .30-rc1.
>>>> Just a thought..
>>> I'm interested in finding regressions too, because I'm seriously
>>> considering putting out a .30 of my own just so there's a known set of
>>> bugs to test against.  (Considering that nothing's been checked into the
>>> repository for two weeks, this seems like a nice point to do it...)
>> I agree, I don't see any real issues for postponing to ship a .30 release
>> just now.
> 
> I've found a few, starting with the fact that it doesn't seem to build on 
> mips:
> 
>   CC libc/stdlib/__cxa_finalize.os
> In file included from libc/stdlib/__cxa_finalize.c:8:
> libc/stdlib/_atexit.c: In function '__cxa_finalize':
> libc/stdlib/_atexit.c:205: warning: implicit declaration of function 'typeof'
> libc/stdlib/_atexit.c:205: error: expected ';' before '__prev'
> libc/stdlib/_atexit.c:205: error: '__prev' undeclared (first use in this 
> function)
> libc/stdlib/_atexit.c:205: error: (Each undeclared identifier is reported 
> only 
> once
> libc/stdlib/_atexit.c:205: error: for each function it appears in.)
> libc/stdlib/_atexit.c:205: error: expected ';' before '__prev'
> libc/stdlib/_atexit.c:205: error: expected ';' before '__prev'
> libc/stdlib/_atexit.c:205: error: expected ';' before '__prev'
> libc/stdlib/_atexit.c:205: error: invalid lvalue in asm output 0
> make: *** [libc/stdlib/__cxa_finalize.os] Error 1
> 
> Working on it...
> 
>> I stopped for a while nptl merge because involved in kernel stuff,
>> but I'll go back to uclibc next week.
> 
> I'm looking at the -svn version because 0.9.29 doesn't have TLS and current 
> glibc absolutely won't build on a host that doesn't have TLS.  (Yes, even 
> when trying to cross-compile it.)  This means you can't cross compile from a 
> uClibc system to a glibc system, so you can't build Linux From Scratch 6.3 
> under FWL 0.9.0.
> 
> I realize that moving to svn doesn't inherently solve that, but if I'm 
> contemplating patching the heck out of something (I don't need NPTL, just 
> TLS), then more than year old version probably isn't the best basis for it.
> 
>> As you have seen, I've fixed a problem in ntpl static link.
> 
> Which nptl branch is this?  The sjhill one that only does super hitachi, the 
> arm one from the code sourcery guys, or the other one?  To be honest, I 
> haven't looked at any of those this year because they all seem totally 
> stalled.
> 
Yes, there is just one NPTL branch supporting now, all integrated together,
mips/arm/sh4. Almost synchronized with trunk. Containing the patches
I was referring missing from trunk... at least for sh4 fully tested (LTP too),
really used in a production system from ST's customers.
It seems you have missed a lot of recent works and commit done by Khem and 
myself.

>> I've discovered similar problrms on trunk (using linuxthreads.old) at least
>> on sh4 (but I think it's a common problem).
>


> I don't have an emulator I can run an sh4 linux kernel under.  I've build an 
> sh4 cross compiler and uClibc (0.9.29) based root filesystem with busybox and 
> a native toolchain, but qemu 0.9.1 system emulation only has a toy sh4 board 
> that nobody knows how to make work and doesn't have any interesting hardware 
> attached to it anyway.  (The systems I'm using have a virtual hard drive and 
> network card so I can build natively under 'em using distcc to call out to 
> the cross compiler.  The qemu sh4 emulation I can't even get to boot to a 
> shell prompt via serial console.)
>
Don't worry, I've real working sh4 hw with its toolchain. I'll test it.

>> I'll come with a test case soon, but being this issue affecting static
>> binaries, I don&#x

Re: Has uClibc passed the LTP tests?

[Carmelo AMOROSO]

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  
> -1 on error and setting ERRNO. On my machine, the INTERNAL_SYSCALL  
> version of the function is not being called -- it's the  
> __syscall_fadvise64_64 version that's being called.
> 
> * in the posix_fadvise tests, the advice value the kernel is seeing is  
> corrupted - it sees 63794 for all values passed in (the tests send  
> each advice value from 0-5). Interestingly, if I run the tests using  
> strace, the value the kernel sees is 87, except for the first one,  
> where it correctly sees 0. The returns values are correct, as the  
> INTERNAL_SYSCALL code is being used in this case.
> 
> So I'm wondering if there has been a successful run of the LTP tests  
> on the various arches, and this is my problem, or if this is a new  
> issue.
> 
> My kernel is 2.6.16. I'm not sure what version of uClibc I'm using,  
> but it's some flavor of 0.9.28. I copied the most recent version of  
> posix_fadvise.c and posix_fadvise64.c from the cvs repository.
> 
> 
> -Corinna Schultz
> IBM LTC
> 
Hi COrinna,
please try adding #include ... you should get 
INTERNALL_SYSCALL macro defined.
We are going to commit a fix for this.

Let me know,

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

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

Re: fadvise gclibc vs uclibc

[Carmelo AMOROSO]

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 too much  
>> about the system call mechanism, so this may be something obvious :)
> 
> There were historically bugs in that area IIRC due to the kernel lagging
> a bit behind. Look for e.g. ASSUME_FADVISE64_64_SYSCALL and look at e.g.
> http://sourceware.org/bugzilla/show_bug.cgi?id=781
> Tested patches are welcome.
> 
> HTH,
> 
Hi Corinna,
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 code (-errno) instead
of simply setting properly errno and returning -1.

Man pages are not clear on this behaviour, it depends on POSIX standards
it want be compliant to, so a clear understanding it's required
before closing this issues.

Anyway, some real bugs have been discovered in uclibc implementation
and will be fixed asap.

As Bernhard said, tested patches are welcome.

Cheers,
Carmelo

> PS: since you seem to be interrested in powerpc, let me point you to
> the heads-up that we will remove problematic parts of libm for powerpc,
> in case you have not seen it:
> http://uclibc.org/lists/uclibc/2008-September/019988.html
> If nobody fixes these issues by either getting properly licensed impls
> or by reimplementing the problematic bits under an acceptable license,
> then the powerpc specific hunks of libm will be removed from svn.
> ___
> uClibc mailing list
> uClibc@uclibc.org
> http://busybox.net/cgi-bin/mailman/listinfo/uclibc
> 

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

Re: svn commit: trunk/uClibc/libc/stdio

[Carmelo AMOROSO]

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 and __STDIO_STREAM_TRANS_TO_WRITE thing,
>>>   then calls vprintf_internal
>>> * vsnprintf, vdprintf.c, vasprintf.c use
>>>   vprintf_internal directly
>>>
>>> This makes sprintf faster (since it doesn't do any locking)
>>> and stops it from pulling in fseek in static compile.
>>>
>>>
>>>
>>> Added:
>>>trunk/uClibc/libc/stdio/_vfprintf_internal.c
>>>trunk/uClibc/libc/stdio/_vfwprintf_internal.c
>>>
>>> Modified:
>>>trunk/uClibc/libc/stdio/Makefile.in
>>>trunk/uClibc/libc/stdio/_stdio.h
>>>trunk/uClibc/libc/stdio/_vfprintf.c
>>>trunk/uClibc/libc/stdio/vasprintf.c
>>>trunk/uClibc/libc/stdio/vdprintf.c
>>>trunk/uClibc/libc/stdio/vsnprintf.c
>>>trunk/uClibc/libc/stdio/vswprintf.c
>>>
>>>
>> [SNIP]
>>> Modified: trunk/uClibc/libc/stdio/_vfprintf.c
>>> ===
>>> --- trunk/uClibc/libc/stdio/_vfprintf.c2008-04-09 11:38:48 UTC 
>>> (rev 21682)
>>> +++ trunk/uClibc/libc/stdio/_vfprintf.c2008-04-09 19:51:18 UTC 
>>> (rev 21683)
>>> @@ -1198,7 +1198,7 @@
>>>  
>>>  #endif
>>>  /**/ 
>>>
>>> -#if defined(L_vfprintf) || defined(L_vfwprintf)
>>> +#if defined(L__vfprintf_internal) || defined(L__vfwprintf_internal)
>>>  
>>>  /* We only support ascii digits (or their USC equivalent codes) in
>>>   * precision and width settings in *printf (wide) format strings.
>>> @@ -1207,14 +1207,15 @@
>>>  
>>>  static size_t _charpad(FILE * __restrict stream, int padchar, size_t 
>>> numpad);
>>>  
>>> -#ifdef L_vfprintf
>>> +#ifdef L__vfprintf_internal
>>>  
>>> -#define VFPRINTF vfprintf
>>> +#define VFPRINTF_internal _vfprintf_internal
>>>  #define FMT_TYPE char
>>>  #define OUTNSTR _outnstr
>>>  #define STRLEN  strlen
>>>  #define _PPFS_init _ppfs_init
>>> -#define OUTPUT(F,S)fputs_unlocked(S,F)
>>> +/* Pulls in fseek: #define OUTPUT(F,S)fputs_unlocked(S,F) */
>>> +#define OUTPUT(F,S)__stdio_fwrite((const unsigned char 
>>> *)(S),strlen(S),(F))
>>
>> Hi Denys,
>> while running some test on nptl bracn with runtime assertion enabled,
>> I've discoverd that this change is causing uclibc aborting due to an
>> assert(bytes) in __stdio_fwrite, while calling fputs_unlocked all works
>> fine. I'd like to understand better the rationale behind and I'm
>> wondering if the problem is present in trunk with other arch than sh4.
>>
>> To exploit the problem you simply need to call a printf with a format
>> string (i.e. printf("val=%d\n",x) ).
>>
>> Please let me know your comments, thanks.
>>
>> Carmelo
>>
> Hi,
> doing further analysis, I've figure out why we fail using 
> __stdio_fwrite. Basically __stdio_fwrite expects at least 1 bytes. 
> fputs_unlocked(S,F) calls fwrite_unlocked and this calls __stdio_fwrite 
> only if bytes to be written are > 0, otherwise simply returs 0 (that is 
> correct). During the parsing of format spec it could happen that 
> __stdio_fwrite is called passing an empty string and with assertion 
> enabled it will abort.
> So, I think that using fputs_unlocked is fine, I don't see any other 
> reasons for calling __stdio_fwrite directly.
> 
> Cheers,
> Carmelo

Fix applied in rev 23367.
Carmelo
>> ___
>> uClibc mailing list
>> uClibc@uclibc.org
>> http://busybox.net/cgi-bin/mailman/listinfo/uclibc
>>
> 
> 

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

Re: [PATCH] locale test fix.

[Carmelo AMOROSO]

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 trunk revision.
>>>>
>>>> Any comment are welcome.
>>>>
>>>> Best Regards,
>>>> Filippo.
>>>>
>>>> This patch fixes several locale tests:
>>>>
>>>> libc/stdlib/_strtod.c   -> tst_wcstod;
>>>> libc/stdlib/stdlib.c-> tst_mblen, tst_mbtowc, tst_wctomb;
>>>> libc/stdio/_scanf.c -> tst_swscanf;
>>>> libc/string/strncmp.c   -> tst_wcsncmp;
>>>> libc/misc/wchar/wchar.c -> tst_mbrlen, tst_mbrtowc, tst_wcswidth.
>>>>
>>>> Signed-off-by: Filippo Arcidiacono <[EMAIL PROTECTED]>
>>>>
>>> Hi All,
>>> is there anybody having some experience on locale that could review 
>>> this patch.
>>> This work has been produced by Filippo (a my collegue) and I've 
>>> already reviewed together, so may be worth someone else have a look at.
>>> We are confident on the fixes as confirmed by having fixed some tests 
>>> from glibc.
>>> We would like to integrated them into trunk soon.
>>
>> Seems like nobody spotted problems with the patch, Carmelo, please
>> apply.
>>
>> TIA,
>>
> Yes, it is on on my next week todo list.
> 
> Carmelo
> 
Done in rev 23369.

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

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