From vda.linux at googlemail.com Wed Jul 2 06:13:40 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Wed, 2 Jul 2008 15:13:40 +0200 Subject: Update on NPTL status In-Reply-To: <48592C29.9020703@gmail.com> References: <48592C29.9020703@gmail.com> Message-ID: <200807021513.40357.vda.linux@googlemail.com> 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 From carmelo.amoroso at st.com Wed Jul 2 09:07:18 2008 From: carmelo.amoroso at st.com (Carmelo AMOROSO) Date: Wed, 02 Jul 2008 18:07:18 +0200 Subject: Update on NPTL status In-Reply-To: <200807021513.40357.vda.linux@googlemail.com> References: <48592C29.9020703@gmail.com> <200807021513.40357.vda.linux@googlemail.com> Message-ID: <486BA7B6.3090605@st.com> 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 at uclibc.org > http://busybox.net/cgi-bin/mailman/listinfo/uclibc > > From carmelo.amoroso at st.com Wed Jul 2 09:19:21 2008 From: carmelo.amoroso at st.com (Carmelo AMOROSO) Date: Wed, 02 Jul 2008 18:19:21 +0200 Subject: Test build failed due to UCLIBC_INTERNAL header rework In-Reply-To: <20080611142255.GB3795@mx.loc> References: <484E8F54.3070903@st.com> <484E9679.405@t-online.de> <484EAC7A.6000409@st.com> <484EFD1F.2000004@t-online.de> <20080611134141.GA7383@caradoc.them.org> <484FDCCF.6070209@t-online.de> <20080611142255.GB3795@mx.loc> Message-ID: <486BAA89.3060105@st.com> 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 at 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 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: fix_test_build.patch Url: http://busybox.net/lists/uclibc/attachments/20080702/dc82e22e/attachment.txt From carmelo.amoroso at st.com Wed Jul 2 09:30:51 2008 From: carmelo.amoroso at st.com (Carmelo AMOROSO) Date: Wed, 02 Jul 2008 18:30:51 +0200 Subject: [PATCH] update bits/errno.h to include kernel header errno.h instead of errno_values.h In-Reply-To: <2ccd6e3c0806130044l322f6b75s2f8ad73f71446ac8@mail.gmail.com> References: <484F941A.1040303@st.com> <200806111744.29405.vda.linux@googlemail.com> <484FF56D.3070104@st.com> <2ccd6e3c0806130044l322f6b75s2f8ad73f71446ac8@mail.gmail.com> Message-ID: <486BAD3B.9030105@st.com> Carmelo Amoroso wrote: > Hello, > any concerns on this changes ? > merged ;-) Carmelo > 2008/6/11 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 at uclibc.org >> http://busybox.net/cgi-bin/mailman/listinfo/uclibc >> > From vda.linux at googlemail.com Wed Jul 2 13:27:29 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Wed, 2 Jul 2008 22:27:29 +0200 Subject: Update on NPTL status In-Reply-To: <486BA7B6.3090605@st.com> References: <48592C29.9020703@gmail.com> <200807021513.40357.vda.linux@googlemail.com> <486BA7B6.3090605@st.com> Message-ID: <200807022227.29314.vda.linux@googlemail.com> On Wednesday 02 July 2008 18:07, Carmelo AMOROSO wrote: > >> 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? > > 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. I will be happy either way. New release is much needed. -- vda From cristi.magherusan at net.utcluj.ro Thu Jul 3 18:15:45 2008 From: cristi.magherusan at net.utcluj.ro (Cristi Magherusan) Date: Fri, 04 Jul 2008 04:15:45 +0300 Subject: [PATCH] aio support for uClibc Message-ID: <1215134145.12545.7.camel@localhost> 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 -- Ing. Cristi M?gheru?an, Universitatea Tehnic? din Cluj-Napoca Centrul de Comunica?ii "Pusztai Kalman" Tel. 0264/401247 http://cc.utcluj.ro -------------- next part -------------- A non-text attachment was scrubbed... Name: uClibc-aio.patch Type: text/x-patch Size: 23472 bytes Desc: not available Url : http://busybox.net/lists/uclibc/attachments/20080704/97c2a4b7/attachment-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://busybox.net/lists/uclibc/attachments/20080704/97c2a4b7/attachment-0001.pgp From carmelo73 at gmail.com Fri Jul 4 13:00:05 2008 From: carmelo73 at gmail.com (Carmelo Amoroso) Date: Fri, 04 Jul 2008 22:00:05 +0200 Subject: [PATCH] aio support for uClibc In-Reply-To: <1215134145.12545.7.camel@localhost> References: <1215134145.12545.7.camel@localhost> Message-ID: <486E8145.7090602@gmail.com> 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 at uclibc.org > http://busybox.net/cgi-bin/mailman/listinfo/uclibc From rep.dot.nop at gmail.com Sat Jul 5 02:26:25 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Sat, 5 Jul 2008 11:26:25 +0200 Subject: [PATCH] aio support for uClibc In-Reply-To: <486E8145.7090602@gmail.com> References: <1215134145.12545.7.camel@localhost> <486E8145.7090602@gmail.com> Message-ID: <20080705092625.GF10734@mx.loc> On Fri, Jul 04, 2008 at 10:00:05PM +0200, Carmelo Amoroso wrote: >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. From cristi.magherusan at net.utcluj.ro Sat Jul 5 06:38:01 2008 From: cristi.magherusan at net.utcluj.ro (Cristi Magherusan) Date: Sat, 05 Jul 2008 16:38:01 +0300 Subject: [PATCH] aio support for uClibc In-Reply-To: <20080705092625.GF10734@mx.loc> References: <1215134145.12545.7.camel@localhost> <486E8145.7090602@gmail.com> <20080705092625.GF10734@mx.loc> Message-ID: <1215265081.21784.4.camel@localhost> 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. > 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 -- Ing. Cristi M?gheru?an, Universitatea Tehnic? din Cluj-Napoca Centrul de Comunica?ii "Pusztai Kalman" Tel. 0264/401247 http://cc.utcluj.ro -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://busybox.net/lists/uclibc/attachments/20080705/1abfac09/attachment.pgp From vda.linux at googlemail.com Sun Jul 6 16:21:34 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Mon, 7 Jul 2008 01:21:34 +0200 Subject: [PATCH] optional fork() stub for NOMMU targets Message-ID: <200807070121.34552.vda.linux@googlemail.com> Hi, Current uclibc svn can't be used unmodified to build uClinux-dist-2008R1-RC8 on blackfin. One problem is that uClinux-dist-2008R1-RC8 requires fork(), as a bare minimum, a stub which always fails. I propose the following patch (adapted from ADI's uclibc tree) which make it an option in uclibc svn. Mike, do you like this patch? -- vda -------------- next part -------------- A non-text attachment was scrubbed... Name: 1.patch Type: text/x-diff Size: 2814 bytes Desc: not available Url : http://busybox.net/lists/uclibc/attachments/20080707/ce39c94b/attachment.patch From carmelo.amoroso at st.com Mon Jul 7 02:51:44 2008 From: carmelo.amoroso at st.com (Carmelo AMOROSO) Date: Mon, 07 Jul 2008 11:51:44 +0200 Subject: [PATCH] aio support for uClibc In-Reply-To: <1215265081.21784.4.camel@localhost> References: <1215134145.12545.7.camel@localhost> <486E8145.7090602@gmail.com> <20080705092625.GF10734@mx.loc> <1215265081.21784.4.camel@localhost> Message-ID: <4871E730.6@st.com> 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 at uclibc.org > http://busybox.net/cgi-bin/mailman/listinfo/uclibc From carmelo.amoroso at st.com Mon Jul 7 07:32:08 2008 From: carmelo.amoroso at st.com (Carmelo AMOROSO) Date: Mon, 07 Jul 2008 16:32:08 +0200 Subject: [PATCH] uClibc_mutex.h: do not include pthread.h Message-ID: <487228E8.3000105@st.com> 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 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: uclibc_mutex.patch Url: http://busybox.net/lists/uclibc/attachments/20080707/e0b214b0/attachment.txt From vda.linux at googlemail.com Mon Jul 7 20:18:24 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Tue, 8 Jul 2008 05:18:24 +0200 Subject: libc_hidden_proto removal en masse Message-ID: <200807080518.24106.vda.linux@googlemail.com> 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 From carmelo.amoroso at st.com Mon Jul 7 23:57:40 2008 From: carmelo.amoroso at st.com (Carmelo AMOROSO) Date: Tue, 08 Jul 2008 08:57:40 +0200 Subject: libc_hidden_proto removal en masse In-Reply-To: <200807080518.24106.vda.linux@googlemail.com> References: <200807080518.24106.vda.linux@googlemail.com> Message-ID: <48730FE4.1090700@st.com> 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 From carmelo.amoroso at st.com Tue Jul 8 00:05:28 2008 From: carmelo.amoroso at st.com (Carmelo AMOROSO) Date: Tue, 08 Jul 2008 09:05:28 +0200 Subject: libc_hidden_proto removal en masse In-Reply-To: <200807080518.24106.vda.linux@googlemail.com> References: <200807080518.24106.vda.linux@googlemail.com> Message-ID: <487311B8.2070902@st.com> 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 From rep.dot.nop at gmail.com Tue Jul 8 00:42:58 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Tue, 8 Jul 2008 09:42:58 +0200 Subject: libc_hidden_proto removal en masse In-Reply-To: <487311B8.2070902@st.com> References: <200807080518.24106.vda.linux@googlemail.com> <487311B8.2070902@st.com> Message-ID: <20080708074258.GB21132@mx.loc> 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. From carmelo.amoroso at st.com Tue Jul 8 00:41:02 2008 From: carmelo.amoroso at st.com (Carmelo AMOROSO) Date: Tue, 08 Jul 2008 09:41:02 +0200 Subject: libc_hidden_proto removal en masse In-Reply-To: <20080708074258.GB21132@mx.loc> References: <200807080518.24106.vda.linux@googlemail.com> <487311B8.2070902@st.com> <20080708074258.GB21132@mx.loc> Message-ID: <48731A0E.2060104@st.com> 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 From carmelo.amoroso at st.com Tue Jul 8 00:49:12 2008 From: carmelo.amoroso at st.com (Carmelo AMOROSO) Date: Tue, 08 Jul 2008 09:49:12 +0200 Subject: [PATCH] uClibc_mutex.h: do not include pthread.h In-Reply-To: <487228E8.3000105@st.com> References: <487228E8.3000105@st.com> Message-ID: <48731BF8.1080900@st.com> 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 at uclibc.org > http://busybox.net/cgi-bin/mailman/listinfo/uclibc From carmelo.amoroso at st.com Tue Jul 8 00:59:11 2008 From: carmelo.amoroso at st.com (Carmelo AMOROSO) Date: Tue, 08 Jul 2008 09:59:11 +0200 Subject: libc_hidden_proto removal en masse In-Reply-To: <48731A0E.2060104@st.com> References: <200807080518.24106.vda.linux@googlemail.com> <487311B8.2070902@st.com> <20080708074258.GB21132@mx.loc> <48731A0E.2060104@st.com> Message-ID: <48731E4F.9030102@st.com> 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 at 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 From carmelo.amoroso at st.com Tue Jul 8 01:26:11 2008 From: carmelo.amoroso at st.com (Carmelo AMOROSO) Date: Tue, 08 Jul 2008 10:26:11 +0200 Subject: [PATCH] sh4 supports new {s,g]rlimit syscall Message-ID: <487324A3.203@st.com> 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 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rlimit.patch Url: http://busybox.net/lists/uclibc/attachments/20080708/0b212620/attachment.txt From lethal at linux-sh.org Tue Jul 8 02:15:51 2008 From: lethal at linux-sh.org (Paul Mundt) Date: Tue, 8 Jul 2008 18:15:51 +0900 Subject: [PATCH] sh4 supports new {s,g]rlimit syscall In-Reply-To: <487324A3.203@st.com> References: <487324A3.203@st.com> Message-ID: <20080708091551.GA7380@linux-sh.org> 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. From carmelo.amoroso at st.com Tue Jul 8 03:32:48 2008 From: carmelo.amoroso at st.com (Carmelo AMOROSO) Date: Tue, 08 Jul 2008 12:32:48 +0200 Subject: [PATCH] sh4 supports new {s,g]rlimit syscall In-Reply-To: <20080708091551.GA7380@linux-sh.org> References: <487324A3.203@st.com> <20080708091551.GA7380@linux-sh.org> Message-ID: <48734250.3060101@st.com> 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 From chanemouganandam at gmail.com Tue Jul 8 09:14:05 2008 From: chanemouganandam at gmail.com (saravanan chanemouganandam) Date: Tue, 8 Jul 2008 18:14:05 +0200 Subject: Big Endian cross compilation Message-ID: <87c084000807080914t6a57e0f4we950b162cd897c13@mail.gmail.com> Hi all, I am a newbie to work on the Intel IXP425 board a big endian system running Snapgear linux (choosen uClibc) distro version. On the development x86 machine, I have installed (at /usr/local/arm-linux) arm-linux tool chain arm-linux-tools-20061213.tar.gz for cross compilation. All the 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. Can somebody point me how to cross compile packages outside snapgear source tree for a Big endian system ? Thanks Sara -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/uclibc/attachments/20080708/d5b27681/attachment.htm From rep.dot.nop at gmail.com Wed Jul 9 08:04:16 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Wed, 9 Jul 2008 17:04:16 +0200 Subject: svn commit: branches/uClibc-nptl/test: locale locale-mbwc In-Reply-To: <20080709141938.DB97A3C674@busybox.net> References: <20080709141938.DB97A3C674@busybox.net> Message-ID: <20080709150416.GA28475@mx.loc> On Wed, Jul 09, 2008 at 07:19:38AM -0700, carmelo at uclibc.org 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? From carmelo.amoroso at st.com Wed Jul 9 08:08:40 2008 From: carmelo.amoroso at st.com (Carmelo AMOROSO) Date: Wed, 09 Jul 2008 17:08:40 +0200 Subject: svn commit: branches/uClibc-nptl/test: locale locale-mbwc In-Reply-To: <20080709150416.GA28475@mx.loc> References: <20080709141938.DB97A3C674@busybox.net> <20080709150416.GA28475@mx.loc> Message-ID: <4874D478.50306@st.com> Bernhard Fischer wrote: > On Wed, Jul 09, 2008 at 07:19:38AM -0700, carmelo at uclibc.org 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 at uclibc.org > http://busybox.net/cgi-bin/mailman/listinfo/uclibc > From carmelo.amoroso at st.com Wed Jul 9 09:59:38 2008 From: carmelo.amoroso at st.com (Carmelo AMOROSO) Date: Wed, 09 Jul 2008 18:59:38 +0200 Subject: NPTL branch almost merged with trunk @ rev 22714 Message-ID: <4874EE7A.60505@st.com> 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 From carmelo.amoroso at st.com Thu Jul 10 02:54:04 2008 From: carmelo.amoroso at st.com (Carmelo AMOROSO) Date: Thu, 10 Jul 2008 11:54:04 +0200 Subject: svn commit: branches/uClibc-nptl: ldso/ldso/mips libc/sysdeps/linux/mips l etc... In-Reply-To: <20080709233645.489CA3C6D4@busybox.net> References: <20080709233645.489CA3C6D4@busybox.net> Message-ID: <4875DC3C.8060704@st.com> kraj at uclibc.org 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. From carmelo.amoroso at st.com Thu Jul 10 03:03:51 2008 From: carmelo.amoroso at st.com (Carmelo AMOROSO) Date: Thu, 10 Jul 2008 12:03:51 +0200 Subject: svn commit: branches/uClibc-nptl/libc: inet misc/sysvipc stdio sysdeps/linux/co etc... In-Reply-To: <20080709235244.4C7033C6D4@busybox.net> References: <20080709235244.4C7033C6D4@busybox.net> Message-ID: <4875DE87.9080103@st.com> kraj at uclibc.org 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_xxxx 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 From carmelo.amoroso at st.com Thu Jul 10 03:11:04 2008 From: carmelo.amoroso at st.com (Carmelo AMOROSO) Date: Thu, 10 Jul 2008 12:11:04 +0200 Subject: svn commit: branches/uClibc-nptl/libc: inet misc/sysvipc stdio sysdeps/linux/co etc... In-Reply-To: <20080709235244.4C7033C6D4@busybox.net> References: <20080709235244.4C7033C6D4@busybox.net> Message-ID: <4875E038.7050306@st.com> kraj at uclibc.org 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 ? From carmelo.amoroso at st.com Thu Jul 10 03:40:48 2008 From: carmelo.amoroso at st.com (Carmelo AMOROSO) Date: Thu, 10 Jul 2008 12:40:48 +0200 Subject: SVN NPTL branch doesn't check for trailing whitespaces Message-ID: <4875E730.3070508@st.com> 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 From chanemouganandam at gmail.com Thu Jul 10 04:40:47 2008 From: chanemouganandam at gmail.com (saravanan chanemouganandam) Date: Thu, 10 Jul 2008 13:40:47 +0200 Subject: libc.so.6: aborted attempt to load Message-ID: <87c084000807100440y281a85e2q263ec6f22845c70a@mail.gmail.com> *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!* ** *Snap shots of few libraries on the /lib of the target board are * ** 0 lrwxrwxrwx 1 0 0 24 ld-linux.so.2 -> /lib/ ld-uClibc-0.9.27.so 22 -rwxrwxrwx 1 0 0 21312 ld-uClibc-0.9.27.so 0 lrwxrwxrwx 1 0 0 19 ld-uClibc.so.0 -> ld-uClibc-0.9.27.so 0 lrwxrwxrwx 1 0 0 19 libc.so.0 -> libuClibc-0.9.27.so 11 -rw-rw-rw- 1 0 0 10688 libcrypt-0.9.27.so 0 lrwxrwxrwx 1 0 0 18 libcrypt.so.0 -> libcrypt-0.9.27.so 930 -rwxr-xr-x 1 0 0 946960 libcrypto.so.0.9.8 73 -rw-rw-rw- 1 0 0 276256 libuClibc-0.9.27.so 5 -rw-rw-rw- 1 0 0 4120 libutil-0.9.27.so 0 lrwxrwxrwx 1 0 0 17 libutil.so.0 -> libutil-0.9.27.so ** *I think I'm getting this error because I'm using the snapgear packages with uClibc instead of glibc and tool chain arm-linux-tools-20061213.tar.gz.* ** *Any ideas on how to correct this in the makefiles to use the correct dynamic linking libraries? * ** *Thanks Sara* ** -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/uclibc/attachments/20080710/b2455f9f/attachment.htm From rep.dot.nop at gmail.com Thu Jul 10 04:52:20 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Thu, 10 Jul 2008 13:52:20 +0200 Subject: libc.so.6: aborted attempt to load In-Reply-To: <87c084000807100440y281a85e2q263ec6f22845c70a@mail.gmail.com> References: <87c084000807100440y281a85e2q263ec6f22845c70a@mail.gmail.com> Message-ID: <20080710115220.GA3717@mx.loc> On Thu, Jul 10, 2008 at 01:40:47PM +0200, saravanan chanemouganandam wrote: >*Hi all; * Hi, Your MUA inserts odd '*' characters. >** >*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!* >** >*Snap shots of few libraries on the /lib of the target board are * >** > 0 lrwxrwxrwx 1 0 0 24 ld-linux.so.2 -> /lib/ >ld-uClibc-0.9.27.so > 22 -rwxrwxrwx 1 0 0 21312 ld-uClibc-0.9.27.so > 0 lrwxrwxrwx 1 0 0 19 ld-uClibc.so.0 -> >ld-uClibc-0.9.27.so > 0 lrwxrwxrwx 1 0 0 19 libc.so.0 -> >libuClibc-0.9.27.so > 11 -rw-rw-rw- 1 0 0 10688 libcrypt-0.9.27.so > 0 lrwxrwxrwx 1 0 0 18 libcrypt.so.0 -> >libcrypt-0.9.27.so > 930 -rwxr-xr-x 1 0 0 946960 libcrypto.so.0.9.8 >73 -rw-rw-rw- 1 0 0 276256 libuClibc-0.9.27.so > 5 -rw-rw-rw- 1 0 0 4120 libutil-0.9.27.so > 0 lrwxrwxrwx 1 0 0 17 libutil.so.0 -> >libutil-0.9.27.so >** >*I think I'm getting this error because I'm using the snapgear packages with > >uClibc instead of glibc and tool chain arm-linux-tools-20061213.tar.gz.* A couple of comments: You should ask this question to the people who provided you with that "arm-linux-tools-20061213.tar" which sounds a bit old. If they do not answer, then go to http://buildroot.uclibc.org/ Last but not least, the current stable release of uClibc is 0.9.29, 0.9.27 is quite old. >** >*Any ideas on how to correct this in the makefiles to use the correct >dynamic linking libraries? * Fix your toolchain. From carmelo.amoroso at st.com Thu Jul 10 04:47:14 2008 From: carmelo.amoroso at st.com (Carmelo AMOROSO) Date: Thu, 10 Jul 2008 13:47:14 +0200 Subject: libc.so.6: aborted attempt to load In-Reply-To: <87c084000807100440y281a85e2q263ec6f22845c70a@mail.gmail.com> References: <87c084000807100440y281a85e2q263ec6f22845c70a@mail.gmail.com> Message-ID: <4875F6C2.2000109@st.com> 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. From chanemouganandam at gmail.com Thu Jul 10 05:06:05 2008 From: chanemouganandam at gmail.com (saravanan chanemouganandam) Date: Thu, 10 Jul 2008 14:06:05 +0200 Subject: libc.so.6: aborted attempt to load In-Reply-To: <20080710115326.GA18091@securecomputing.com> References: <87c084000807100440y281a85e2q263ec6f22845c70a@mail.gmail.com> <20080710115326.GA18091@securecomputing.com> Message-ID: <87c084000807100506l45e5666fudaa9ddaa29e8140f@mail.gmail.com> 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. 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 ? Thanks sara On Thu, Jul 10, 2008 at 1:53 PM, David McCullough < David_Mccullough at securecomputing.com> 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 lrwxrwxrwx 1 0 0 24 ld-linux.so.2 -> /lib/ > > ld-uClibc-0.9.27.so > > 22 -rwxrwxrwx 1 0 0 21312 ld-uClibc-0.9.27.so > > 0 lrwxrwxrwx 1 0 0 19 ld-uClibc.so.0 -> > > ld-uClibc-0.9.27.so > > 0 lrwxrwxrwx 1 0 0 19 libc.so.0 -> > > libuClibc-0.9.27.so > > 11 -rw-rw-rw- 1 0 0 10688 libcrypt-0.9.27.so > > 0 lrwxrwxrwx 1 0 0 18 libcrypt.so.0 -> > > libcrypt-0.9.27.so > > 930 -rwxr-xr-x 1 0 0 946960 libcrypto.so.0.9.8 > > 73 -rw-rw-rw- 1 0 0 276256 libuClibc-0.9.27.so > > 5 -rw-rw-rw- 1 0 0 4120 libutil-0.9.27.so > > 0 lrwxrwxrwx 1 0 0 17 libutil.so.0 -> > > libutil-0.9.27.so > > ** > > *I think I'm getting this error because I'm using the snapgear packages > with > > > > uClibc instead of glibc and tool chain arm-linux-tools-20061213.tar.gz.* > > ** > > *Any ideas on how to correct this in the makefiles to use the correct > > dynamic linking libraries? * > > There is a version of dropbear in the snapgear/uClinux-dist, just use > that or upgrade it to the version you want and build dropbeasr within > the dist's build framework and you won't have any problems, > > Cheers, > Davidm > > -- > David McCullough, david_mccullough at securecomputing.com, Ph:+61 > 734352815 > Secure Computing - SnapGear http://www.uCdot.org > http://www.snapgear.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/uclibc/attachments/20080710/bfef4c83/attachment-0001.htm From chanemouganandam at gmail.com Thu Jul 10 06:55:45 2008 From: chanemouganandam at gmail.com (saravanan chanemouganandam) Date: Thu, 10 Jul 2008 15:55:45 +0200 Subject: libc.so.6: aborted attempt to load In-Reply-To: <20080710124038.GA18218@securecomputing.com> References: <87c084000807100440y281a85e2q263ec6f22845c70a@mail.gmail.com> <20080710115326.GA18091@securecomputing.com> <87c084000807100506l45e5666fudaa9ddaa29e8140f@mail.gmail.com> <20080710124038.GA18218@securecomputing.com> Message-ID: <87c084000807100655g4c3dba7cla8388315c3f9cdc2@mail.gmail.com> 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. On Thu, Jul 10, 2008 at 2:40 PM, David McCullough < David_Mccullough at securecomputing.com> 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 < > > David_Mccullough at securecomputing.com> 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 lrwxrwxrwx 1 0 0 24 ld-linux.so.2 -> /lib/ > > > > ld-uClibc-0.9.27.so < > http://ld-uclibc-0.9.27.so/> > > > > 22 -rwxrwxrwx 1 0 0 21312 ld-uClibc-0.9.27.so > > > > > 0 lrwxrwxrwx 1 0 0 19 ld-uClibc.so.0 -> > > > > ld-uClibc-0.9.27.so < > http://ld-uclibc-0.9.27.so/> > > > > 0 lrwxrwxrwx 1 0 0 19 libc.so.0 -> > > > > libuClibc-0.9.27.so < > http://libuclibc-0.9.27.so/> > > > > 11 -rw-rw-rw- 1 0 0 10688 libcrypt-0.9.27.so > > > > 0 lrwxrwxrwx 1 0 0 18 libcrypt.so.0 -> > > > > libcrypt-0.9.27.so > > > > 930 -rwxr-xr-x 1 0 0 946960 libcrypto.so.0.9.8 > > > > 73 -rw-rw-rw- 1 0 0 276256 libuClibc-0.9.27.so > > > > > 5 -rw-rw-rw- 1 0 0 4120 libutil-0.9.27.so > > > > 0 lrwxrwxrwx 1 0 0 17 libutil.so.0 -> > > > > libutil-0.9.27.so > > > > ** > > > > *I think I'm getting this error because I'm using the snapgear > packages > > > with > > > > > > > > uClibc instead of glibc and tool chain > arm-linux-tools-20061213.tar.gz.* > > > > ** > > > > *Any ideas on how to correct this in the makefiles to use the correct > > > > dynamic linking libraries? * > > > > > > There is a version of dropbear in the snapgear/uClinux-dist, just use > > > that or upgrade it to the version you want and build dropbeasr within > > > the dist's build framework and you won't have any problems, > > > > > > Cheers, > > > Davidm > > > > > > -- > > > David McCullough, david_mccullough at securecomputing.com, Ph:+61 > > > 734352815 > > > Secure Computing - SnapGear http://www.uCdot.org< > http://www.ucdot.org/> > > > http://www.snapgear.com > > > > > -- > David McCullough, david_mccullough at securecomputing.com, Ph:+61 > 734352815 > Secure Computing - SnapGear http://www.uCdot.org > http://www.snapgear.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/uclibc/attachments/20080710/5d49145e/attachment.htm From saravanan_sprt at hotmail.com Thu Jul 10 06:51:22 2008 From: saravanan_sprt at hotmail.com (saravanan chanemouganandam) Date: Thu, 10 Jul 2008 19:21:22 +0530 Subject: uclibc and glibc Message-ID: 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 compilethe 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.olibc.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 ? ThanksSara _________________________________________________________________ Wish to Marry Now? Click Here to Register FREE http://www.shaadi.com/registration/user/index.php?ptnr=mhottag -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/uclibc/attachments/20080710/7b15799d/attachment.htm From carmelo.amoroso at st.com Thu Jul 10 07:28:52 2008 From: carmelo.amoroso at st.com (Carmelo AMOROSO) Date: Thu, 10 Jul 2008 16:28:52 +0200 Subject: libc.so.6: aborted attempt to load In-Reply-To: <87c084000807100655g4c3dba7cla8388315c3f9cdc2@mail.gmail.com> References: <87c084000807100440y281a85e2q263ec6f22845c70a@mail.gmail.com> <20080710115326.GA18091@securecomputing.com> <87c084000807100506l45e5666fudaa9ddaa29e8140f@mail.gmail.com> <20080710124038.GA18218@securecomputing.com> <87c084000807100655g4c3dba7cla8388315c3f9cdc2@mail.gmail.com> Message-ID: <48761CA4.7020107@st.com> 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 > > 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 < > > David_Mccullough at securecomputing.com > > 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 lrwxrwxrwx 1 0 0 24 ld-linux.so.2 > -> /lib/ > > > > ld-uClibc-0.9.27.so > > > > > 22 -rwxrwxrwx 1 0 0 21312 > ld-uClibc-0.9.27.so > > > > > 0 lrwxrwxrwx 1 0 0 19 ld-uClibc.so.0 -> > > > > ld-uClibc-0.9.27.so > > > > > 0 lrwxrwxrwx 1 0 0 19 libc.so.0 -> > > > > libuClibc-0.9.27.so > > > > > 11 -rw-rw-rw- 1 0 0 10688 > libcrypt-0.9.27.so > > > > 0 lrwxrwxrwx 1 0 0 18 libcrypt.so.0 -> > > > > libcrypt-0.9.27.so > > > > 930 -rwxr-xr-x 1 0 0 946960 > libcrypto.so.0.9.8 > > > > 73 -rw-rw-rw- 1 0 0 276256 > libuClibc-0.9.27.so > > > > > 5 -rw-rw-rw- 1 0 0 4120 > libutil-0.9.27.so > > > > 0 lrwxrwxrwx 1 0 0 17 libutil.so.0 -> > > > > libutil-0.9.27.so > > > > ** > > > > *I think I'm getting this error because I'm using the > snapgear packages > > > with > > > > > > > > uClibc instead of glibc and tool chain > arm-linux-tools-20061213.tar.gz.* > > > > ** > > > > *Any ideas on how to correct this in the makefiles to use the > correct > > > > dynamic linking libraries? * > > > > > > There is a version of dropbear in the snapgear/uClinux-dist, > just use > > > that or upgrade it to the version you want and build dropbeasr > within > > > the dist's build framework and you won't have any problems, > > > > > > Cheers, > > > Davidm > > > > > > -- > > > David McCullough, david_mccullough at securecomputing.com > , Ph:+61 > > > 734352815 > > > Secure Computing - SnapGear http://www.uCdot.org > > > > http://www.snapgear.com > > > > > -- > David McCullough, david_mccullough at securecomputing.com > , Ph:+61 734352815 > Secure Computing - SnapGear http://www.uCdot.org > http://www.snapgear.com > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > uClibc mailing list > uClibc at uclibc.org > http://busybox.net/cgi-bin/mailman/listinfo/uclibc From carmelo.amoroso at st.com Thu Jul 10 07:30:33 2008 From: carmelo.amoroso at st.com (Carmelo AMOROSO) Date: Thu, 10 Jul 2008 16:30:33 +0200 Subject: uclibc and glibc In-Reply-To: References: Message-ID: <48761D09.3010901@st.com> 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 at uclibc.org > http://busybox.net/cgi-bin/mailman/listinfo/uclibc From filippo.arcidiacono at st.com Thu Jul 10 07:35:01 2008 From: filippo.arcidiacono at st.com (Filippo ARCIDIACONO) Date: Thu, 10 Jul 2008 16:35:01 +0200 Subject: [PATCH] locale test fix. Message-ID: <006901c8e29a$22e98770$838182a4@st.com> 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 Index: libc/stdlib/_strtod.c =================================================================== --- libc/stdlib/_strtod.c (revision 22698) +++ libc/stdlib/_strtod.c (working copy) @@ -234,7 +234,7 @@ #endif #ifdef __UCLIBC_HAS_LOCALE__ #if defined(L___wcstofpmax) || defined(L___wcstofpmax_l) - wchar_t decpt_wc = __LOCALE_PTR->decimal_point; + wchar_t decpt_wc = __LOCALE_PTR->decimal_point_wc; #else const char *decpt = __LOCALE_PTR->decimal_point; int decpt_len = __LOCALE_PTR->decimal_point_len; Index: libc/stdlib/stdlib.c =================================================================== --- libc/stdlib/stdlib.c (revision 22698) +++ libc/stdlib/stdlib.c (working copy) @@ -929,6 +929,31 @@ libc_hidden_def(_stdlib_mb_cur_max) #endif + +#ifdef __UCLIBC_HAS_LOCALE__ +/* + * The following function return 1 if the encoding is stateful, 0 if stateless. + * To note, until now all the supported encoding are stateless. + */ + +static inline int +is_stateful(unsigned char encoding) +{ + switch (encoding) + { + case __ctype_encoding_7_bit: + case __ctype_encoding_utf8: + case __ctype_encoding_8_bit: + return 0; + default: + assert(0); + return -1; + } +} +#else +#define is_stateful(encoding) 0 +#endif + /**********************************************************************/ #ifdef L_mblen @@ -941,13 +966,16 @@ if (!s) { state.__mask = 0; -#ifdef __CTYPE_HAS_UTF_8_LOCALES - return ENCODING == __ctype_encoding_utf8; -#else - return 0; -#endif +/* In this case we have to return 0 because the only multibyte supported encoding + is utf-8, that is a stateless encoding. See mblen() documentation.*/ + + return is_stateful(ENCODING); } + if (*s == '\0') + /* According to the ISO C 89 standard this is the expected behaviour. */ + return 0; + if ((r = mbrlen(s, n, &state)) == (size_t) -2) { /* TODO: Should we set an error state? */ state.__wc = 0xffffU; /* Make sure we're in an error state. */ @@ -969,13 +997,15 @@ if (!s) { state.__mask = 0; -#ifdef __CTYPE_HAS_UTF_8_LOCALES - return ENCODING == __ctype_encoding_utf8; -#else - return 0; -#endif +/* In this case we have to return 0 because the only multibyte supported encoding + is utf-8, that is a stateless encoding. See mbtowc() documentation.*/ + return is_stateful(ENCODING); } + if (*s == '\0') + /* According to the ISO C 89 standard this is the expected behaviour. */ + return 0; + if ((r = mbrtowc(pwc, s, n, &state)) == (size_t) -2) { /* TODO: Should we set an error state? */ state.__wc = 0xffffU; /* Make sure we're in an error state. */ @@ -996,11 +1026,9 @@ { return (!s) ? -#ifdef __CTYPE_HAS_UTF_8_LOCALES - (ENCODING == __ctype_encoding_utf8) -#else - 0 /* Encoding is stateless. */ -#endif +/* In this case we have to return 0 because the only multibyte supported encoding + is utf-8, that is a stateless encoding. See wctomb() documentation.*/ + is_stateful(ENCODING) : ((ssize_t) wcrtomb(s, swc, NULL)); } Index: libc/stdio/_scanf.c =================================================================== --- libc/stdio/_scanf.c (revision 22698) +++ libc/stdio/_scanf.c (working copy) @@ -1068,9 +1068,6 @@ wc = '.'; } else #endif /* __UCLIBC_HAS_FLOATS__ */ - if (!__isascii(wc)) { - wc = '?'; - } sc->wc = sc->ungot_char = wc; return (int) wc; Index: libc/string/strncmp.c =================================================================== --- libc/string/strncmp.c (revision 22698) +++ libc/string/strncmp.c (working copy) @@ -25,7 +25,7 @@ --n; } - return (n == 0) ? 0 : ((*((Wuchar *)s1) < *((Wuchar *)s2)) ? -1 : 1); + return (n == 0) ? 0 : (*((Wuchar *)s1) - *((Wuchar *)s2)); #else int r = 0; Index: libc/misc/wchar/wchar.c =================================================================== --- libc/misc/wchar/wchar.c (revision 22698) +++ libc/misc/wchar/wchar.c (working copy) @@ -293,10 +293,17 @@ empty_string[0] = 0; /* Init the empty string when necessary. */ s = empty_string; n = 1; + } else if (*s == '\0') { + /* According to the ISO C 89 standard this is the expected behaviour. */ + return 0; } else if (!n) { /* TODO: change error code? */ +#if 0 return (ps->__mask && (ps->__wc == 0xffffU)) ? ((size_t) -1) : ((size_t) -2); +#else + return 0; +#endif } p = s; @@ -865,7 +872,6 @@ + (wc & ((1 << Cwc2c_TT_SHIFT)-1))]; } -#define __WCHAR_REPLACEMENT_CHAR '?' #ifdef __WCHAR_REPLACEMENT_CHAR *dst = (unsigned char) ( u ? u : __WCHAR_REPLACEMENT_CHAR ); #else /* __WCHAR_REPLACEMENT_CHAR */ @@ -1045,7 +1051,7 @@ size_t i; for (i = 0 ; (i < n) && pwcs[i] ; i++) { - if (pwcs[i] != ((unsigned char)(pwcs[i]))) { + if (pwcs[i] != (pwcs[i] & 0x7f)) { return -1; } } From raj.khem at gmail.com Thu Jul 10 08:04:03 2008 From: raj.khem at gmail.com (Khem Raj) Date: Thu, 10 Jul 2008 08:04:03 -0700 Subject: svn commit: branches/uClibc-nptl/libc: inet misc/sysvipc stdio sysdeps/linux/co etc... In-Reply-To: <4875E038.7050306@st.com> References: <20080709235244.4C7033C6D4@busybox.net> <4875E038.7050306@st.com> Message-ID: <1215702243.32070.0.camel@isis> On Thu, 2008-07-10 at 12:11 +0200, Carmelo AMOROSO wrote: > kraj at uclibc.org 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 ? To get USE__TLS > _______________________________________________ > uClibc mailing list > uClibc at uclibc.org > http://busybox.net/cgi-bin/mailman/listinfo/uclibc From rep.dot.nop at gmail.com Thu Jul 10 09:37:20 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Thu, 10 Jul 2008 18:37:20 +0200 Subject: svn commit: branches/uClibc-nptl/libc: inet misc/sysvipc stdio sysdeps/linux/co etc... In-Reply-To: <1215702243.32070.0.camel@isis> References: <20080709235244.4C7033C6D4@busybox.net> <4875E038.7050306@st.com> <1215702243.32070.0.camel@isis> Message-ID: <20080710163720.GA5703@mx.loc> 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? From carmelo73 at gmail.com Thu Jul 10 10:19:35 2008 From: carmelo73 at gmail.com (Carmelo Amoroso) Date: Thu, 10 Jul 2008 19:19:35 +0200 Subject: svn commit: branches/uClibc-nptl/libc: inet misc/sysvipc stdio sysdeps/linux/co etc... In-Reply-To: <20080710163720.GA5703@mx.loc> References: <20080709235244.4C7033C6D4@busybox.net> <4875E038.7050306@st.com> <1215702243.32070.0.camel@isis> <20080710163720.GA5703@mx.loc> Message-ID: <2ccd6e3c0807101019p7383304k1aeea6d2261959d3@mail.gmail.com> 2008/7/10 Bernhard Fischer : > 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 at uclibc.org > http://busybox.net/cgi-bin/mailman/listinfo/uclibc > From rep.dot.nop at gmail.com Thu Jul 10 11:53:02 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Thu, 10 Jul 2008 20:53:02 +0200 Subject: svn commit: branches/uClibc-nptl/libc: inet misc/sysvipc stdio sysdeps/linux/co etc... In-Reply-To: <2ccd6e3c0807101019p7383304k1aeea6d2261959d3@mail.gmail.com> References: <20080709235244.4C7033C6D4@busybox.net> <4875E038.7050306@st.com> <1215702243.32070.0.camel@isis> <20080710163720.GA5703@mx.loc> <2ccd6e3c0807101019p7383304k1aeea6d2261959d3@mail.gmail.com> Message-ID: <20080710185302.GI10734@mx.loc> On Thu, Jul 10, 2008 at 07:19:35PM +0200, Carmelo Amoroso wrote: >2008/7/10 Bernhard Fischer : >> 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 ? If it makes syncing easier, then we can keep them but in this case let's put it into uClibc_config.h with fiddle to pickup "our" notion of affairs. cheers, Bernhard From thekevinday at gmail.com Thu Jul 10 14:44:21 2008 From: thekevinday at gmail.com (Kevin Day) Date: Thu, 10 Jul 2008 16:44:21 -0500 Subject: SVN NPTL branch doesn't check for trailing whitespaces In-Reply-To: <4875E730.3070508@st.com> References: <4875E730.3070508@st.com> Message-ID: On Thu, Jul 10, 2008 at 5:40 AM, Carmelo AMOROSO wrote: > 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 > I have never done it myself, but you need a hook: http://subversion.tigris.org/faq.html#auto-props You want a pre_commit hook so that it will not commit or will be modified on commit before actual commit is transacted So, some script could be made, so the trick would be to do some sort of regex that checks the end of the file for a newline -- Kevin Day From carmelo73 at gmail.com Thu Jul 10 16:26:47 2008 From: carmelo73 at gmail.com (Carmelo Amoroso) Date: Fri, 11 Jul 2008 01:26:47 +0200 Subject: Active developers list Message-ID: <48769AB7.3010307@gmail.com> 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 | carmelo.amoroso at st.com | carmelo at uclibc.org carmelo73 at gmail.com ------------------------------------------------------------- From hans-christian.egtvedt at atmel.com Thu Jul 10 22:44:40 2008 From: hans-christian.egtvedt at atmel.com (Hans-Christian Egtvedt) Date: Fri, 11 Jul 2008 07:44:40 +0200 Subject: Active developers list In-Reply-To: <48769AB7.3010307@gmail.com> References: <48769AB7.3010307@gmail.com> Message-ID: <1215755080.11647.67.camel@localhost> 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? What you lack is mapping from maintainer <=> uClibc.org account? 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. > I think it is important knowing this mapping, otherwise some misunderstanding > may happens when replying to svn commit message. > What kind of misunderstanding? > If you think this useful, please fill the table below. > > So this is me: > > Full Name | E-mails | uClibc account > ------------------------------------------------------------- > Carmelo Amoroso | carmelo.amoroso at st.com | carmelo at uclibc.org > carmelo73 at gmail.com > ------------------------------------------------------------- ?------------------------------------------------------------- Hans-Christian Egtvedt | hans-christian.egtvedt at atmel.com | egtvedt at uclibc.org ------------------------------------------------------------- My email and name are ridiculous long ;) -- With kind regards, Hans-Christian Egtvedt, Applications Engineer From carmelo.amoroso at st.com Thu Jul 10 23:47:08 2008 From: carmelo.amoroso at st.com (Carmelo AMOROSO) Date: Fri, 11 Jul 2008 08:47:08 +0200 Subject: Active developers list In-Reply-To: <1215755080.11647.67.camel@localhost> References: <48769AB7.3010307@gmail.com> <1215755080.11647.67.camel@localhost> Message-ID: <487701EC.1060206@st.com> 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 vda at uclibc.org 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 | carmelo.amoroso at st.com | carmelo at uclibc.org >> carmelo73 at gmail.com >> ------------------------------------------------------------- > > ?------------------------------------------------------------- > Hans-Christian Egtvedt | hans-christian.egtvedt at atmel.com | egtvedt at uclibc.org > ------------------------------------------------------------- > > My email and name are ridiculous long ;) > in your case, you have chosen an account understandable Carmelo From carmelo.amoroso at st.com Fri Jul 11 00:11:08 2008 From: carmelo.amoroso at st.com (Carmelo AMOROSO) Date: Fri, 11 Jul 2008 09:11:08 +0200 Subject: Active developers list In-Reply-To: <487701EC.1060206@st.com> References: <48769AB7.3010307@gmail.com> <1215755080.11647.67.camel@localhost> <487701EC.1060206@st.com> Message-ID: <4877078C.4070108@st.com> A proposal for a DEVELOPERS file. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: DEVELOPERS Url: http://busybox.net/lists/uclibc/attachments/20080711/c40f2d5d/attachment.txt From hans-christian.egtvedt at atmel.com Fri Jul 11 00:28:21 2008 From: hans-christian.egtvedt at atmel.com (Hans-Christian Egtvedt) Date: Fri, 11 Jul 2008 09:28:21 +0200 Subject: Active developers list In-Reply-To: <4877078C.4070108@st.com> References: <48769AB7.3010307@gmail.com> <1215755080.11647.67.camel@localhost> <487701EC.1060206@st.com> <4877078C.4070108@st.com> Message-ID: <1215761301.11647.79.camel@localhost> On Fri, 2008-07-11 at 09:11 +0200, Carmelo AMOROSO wrote: > A proposal for a DEVELOPERS file. > > plain text document attachment (DEVELOPERS) > 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 > S: Status (active, passive, debugger, tester, patcher, gone fishing, etc) ? > ---------------------------------------------------------------------- > > P: Carmelo Amoroso > E: carmelo.amoroso at st.com / carmelo73 at gmail.com One email address per line? I.e. E: carmelo.amoroso at st.com E: carmelo73 at gmail.com > W: www.stlinux.com Really needed? > A: carmelo at uclibc.org -- With kind regards, Hans-Christian Egtvedt, Applications Engineer From rep.dot.nop at gmail.com Fri Jul 11 00:37:10 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Fri, 11 Jul 2008 09:37:10 +0200 Subject: Active developers list In-Reply-To: <487701EC.1060206@st.com> References: <48769AB7.3010307@gmail.com> <1215755080.11647.67.camel@localhost> <487701EC.1060206@st.com> Message-ID: <20080711073710.GA11051@mx.loc> On Fri, Jul 11, 2008 at 08:47:08AM +0200, Carmelo AMOROSO wrote: >Hans-Christian Egtvedt wrote: >> On Fri, 2008-07-11 at 01:26 +0200, Carmelo Amoroso wrote: >>> 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 vda at uclibc.org >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. I do and id(1) on morris would know too, fwiw. > >Yes vapier is well known, what for newbies is not so clear sometimes >this mapping. This is my point. I think that's just a matter of googling a little bit, really. >> >> My email and name are ridiculous long ;) >> >in your case, you have chosen an account understandable bah, boring ;) I could have sworn that i once sent the table below to the busybox-ML but i can't find it in the archives right now. $ cat /mnt/cvs/busybox/AUTHORS.git | sed -e "s/@.*>/@hidden>/g" aaronl = Aaron Lehmann