From ricard.wanderlof at axis.com Mon Mar 3 06:42:24 2008 From: ricard.wanderlof at axis.com (Ricard Wanderlof) Date: Mon, 3 Mar 2008 15:42:24 +0100 (CET) Subject: [PATCH] make getaddrinfo hint AI_ADDRCONFIG work In-Reply-To: <20080221175631.GA7161@real.realitydiluted.com> References: <20080221151646.GA4751@real.realitydiluted.com> <47BDA596.8070107@st.com> <20080221175631.GA7161@real.realitydiluted.com> Message-ID: On Thu, 21 Feb 2008, sjhill at realitydiluted.com wrote: > On Thu, Feb 21, 2008 at 05:13:28PM +0000, Joseph S. Myers wrote: >> >> No, glibc hasn't moved to GPLv3 yet. It's not moving until the glibc SC >> has got suitable wording from the FSF for an exception to allow GPLv2-only >> programs to continue to be linked with LGPLv3 glibc, and the FSF is being >> extremely slow about producing wording for any GPLv3 exceptions at all. >> > Cool, thanks for the info Joe! So...Ricard go snag the code from > glibc :). Ok, almost done. Just a few issues before submitting a patch. glibc uses getifaddrs() to accomplish this, which nicely enough is already part of uClibc's libc/inet/ifaddrs.c, although it has been #if 0'd out as it has not been needed before. Removing the #if 0's adds about 4.6 kB to the size of the resulting .so file (which is already about 268 kB on our architecture (CRISv32)). So should there be a config option to enable the getaddrinfo AI_ADDRCONFIG hint to work, or is 4.6 kB too little for anyone to worry about at this stage? /Ricard -- Ricard Wolf Wanderl?f ricardw(at)axis.com Axis Communications AB, Lund, Sweden www.axis.com Phone +46 46 272 2016 Fax +46 46 13 61 30 From thiagogalesi at gmail.com Mon Mar 3 04:58:59 2008 From: thiagogalesi at gmail.com (Thiago Galesi) Date: Mon, 3 Mar 2008 09:58:59 -0300 Subject: Problems with syscall for SH Message-ID: <82ecf08e0803030458k5135ca13g9c3b340ba0a3a479@mail.gmail.com> Hello I am trying this with svn uclibc, and even with (moderately) old versions the result is the same. I saw this problem discussed in older messages (for other archs), but it was not solved them There is a conflict with the definition of syscall (in .h) and the implementation (for SH). this is the .h (include/unistd.h) extern long int syscall (long int __sysno, ...) __THROW; this is the .c (libc/sysdeps/linux/sh/syscall.c) long syscall(long sysnum, long arg1, long arg2, long arg3, long arg4, long arg5, long arg6) Problem is, if I take the .c prototype and put it in the .h, things will not work (eg. there are problems with compiling pthread) What would be the correct way to deal with this? Most archs don't have this problem, as they have a syscall.S file, ARM uses a .c, I'll try to figure out from there. Thanks -- - Thiago Galesi From kraj at mvista.com Mon Mar 3 09:17:29 2008 From: kraj at mvista.com (Khem Raj) Date: Mon, 03 Mar 2008 09:17:29 -0800 Subject: [PATCH] make getaddrinfo hint AI_ADDRCONFIG work In-Reply-To: References: <20080221151646.GA4751@real.realitydiluted.com> <47BDA596.8070107@st.com> <20080221175631.GA7161@real.realitydiluted.com> Message-ID: <47CC32A9.40000@mvista.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ricard Wanderlof wrote: | On Thu, 21 Feb 2008, sjhill at realitydiluted.com wrote: | |> On Thu, Feb 21, 2008 at 05:13:28PM +0000, Joseph S. Myers wrote: |>> No, glibc hasn't moved to GPLv3 yet. It's not moving until the glibc SC |>> has got suitable wording from the FSF for an exception to allow GPLv2-only |>> programs to continue to be linked with LGPLv3 glibc, and the FSF is being |>> extremely slow about producing wording for any GPLv3 exceptions at all. |>> |> Cool, thanks for the info Joe! So...Ricard go snag the code from |> glibc :). | | Ok, almost done. Just a few issues before submitting a patch. | | glibc uses getifaddrs() to accomplish this, which nicely enough is already | part of uClibc's libc/inet/ifaddrs.c, although it has been #if 0'd out as | it has not been needed before. Removing the #if 0's adds about 4.6 kB to | the size of the resulting .so file (which is already about 268 kB on our | architecture (CRISv32)). So should there be a config option to enable the | getaddrinfo AI_ADDRCONFIG hint to work, or is 4.6 kB too little for anyone | to worry about at this stage? Addding option would be a good thing to do in my opinion. - -Khem -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHzDKpUjbQJxVzeZQRAjKpAJ4pUSJ9SDxbFjB2ASGmsTbfuGst3ACfYiAJ QAR6z91vLQMXh5KdrthC8dU= =g0Ng -----END PGP SIGNATURE----- From jpereiran at gmail.com Mon Mar 3 08:02:18 2008 From: jpereiran at gmail.com (Jorge Pereira) Date: Mon, 3 Mar 2008 13:02:18 -0300 Subject: doubt about uClibc++ Message-ID: <5a0574590803030802o1b98f559n5546c0df93582ad7@mail.gmail.com> Hi all! somebody got it compile and use "uClibc++" in uClinux/ARM? so, i can't compile using gcc/arm. my env below! uClibc++-0.2.2# uClinux-dist-20051014# root at campinho uClinux-dist-20051014# arm-linux-gcc -v Using built-in specs. Target: arm-uclinuxeabi Configured with: /scratch/paul/lite/uclinux/src/gcc-4.2/configure --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=arm-uclinuxeabi --enable-threads --disable-libmudflap --disable-libssp --disable-libgomp --disable-libstdcxx-pch --with-gnu-as --with-gnu-ld --enable-languages=c,c++ --disable-shared --with-pkgversion=CodeSourcery Sourcery G++ Lite 2007q3-51 --with-bugurl=https://support.codesourcery.com/GNUToolchain/ --disable-nls --prefix=/opt/codesourcery --with-sysroot=/opt/codesourcery/arm-uclinuxeabi/libc --with-build-sysroot=/scratch/paul/lite/uclinux/install/arm-uclinuxeabi/libc --enable-poison-system-directories --with-build-time-tools=/scratch/paul/lite/uclinux/install/arm-uclinuxeabi/bin --with-build-time-tools=/scratch/paul/lite/uclinux/install/arm-uclinuxeabi/bin Thread model: single gcc version 4.2.1 (CodeSourcery Sourcery G++ Lite 2007q3-51) root at campinho uClinux-dist-20051014# []s -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/uclibc/attachments/20080303/ed6f3984/attachment.htm From ynglingatal at comhem.se Mon Mar 3 10:31:53 2008 From: ynglingatal at comhem.se (Mats Erik Andersson) Date: Mon, 03 Mar 2008 19:31:53 +0100 Subject: [Testcode] Source regex_old.c is clearly flawed! Message-ID: <1204569113.21482.23.camel@asus.bellman.mea> Hello again folks, I supply a test program that clearly demonstrates regex_old.c of uClibc-0.9.29 regex.c of uClibc-0.9.28 to be seriously disfunctional. The testprogram fails for 11 out of 48 strings, where the new regex.c of uClibc-0.9.29 as well as glibc succeed. The toolchain was constructed from binutils-2.17, gcc-4.1.2, and uClibc-0.9.29 for i386. The complexity of regex_old.c is to grave for me to resolve the error on my own, but the failing strings clearly display that the problem lies in the interplay between repetitions "{n}" and "*" as well as "?". "+" is not affected here. Thus the case "zero_time_ok == 1" must be checked in repetitions. All testing patterns are crafted to use at least strings built from the words "ab" and "ba". The maintainer of this code will probably find the string "baab" to provide most insight, since it provokes most of the failures. The test program is very verbose with test strings and patterns, and their grouping intends to simplify visual patterns. Best regards M E Andersson -------------- next part -------------- A non-text attachment was scrubbed... Name: test_regex.c Type: text/x-csrc Size: 1835 bytes Desc: not available Url : http://busybox.net/lists/uclibc/attachments/20080303/862c1f6e/attachment.c From sjhill at realitydiluted.com Mon Mar 3 10:39:54 2008 From: sjhill at realitydiluted.com (sjhill at realitydiluted.com) Date: Mon, 3 Mar 2008 12:39:54 -0600 Subject: doubt about uClibc++ In-Reply-To: <5a0574590803030802o1b98f559n5546c0df93582ad7@mail.gmail.com> References: <5a0574590803030802o1b98f559n5546c0df93582ad7@mail.gmail.com> Message-ID: <20080303183954.GA12326@real.realitydiluted.com> > somebody got it compile and use "uClibc++" in uClinux/ARM? so, i can't > compile using gcc/arm. > > my env below! > [SNIP] > > Thread model: single > gcc version 4.2.1 (CodeSourcery Sourcery G++ Lite 2007q3-51) > root at campinho uClinux-dist-20051014# > I hope I do not come off as crabby and Drepper-like, but go bug CodeSourcery for support. You got the toolchain from them and unless they are going to provide you with complete source to the toolchain and provide it to someone on the list to attempt a test build, it's not our problem. Thanks and have a nice day. -Steve From natanael.copa at gmail.com Tue Mar 4 01:12:44 2008 From: natanael.copa at gmail.com (Natanael Copa) Date: Tue, 04 Mar 2008 10:12:44 +0100 Subject: splice(2), vmsplice(2) and tee(2)? Message-ID: <1204621964.10088.7.camel@nc.nor.wtbts.org> Hi, Any plans to implement splice(2), vmsplice(2) and tee(2) for x86? -nc From sjhill at realitydiluted.com Tue Mar 4 05:20:13 2008 From: sjhill at realitydiluted.com (sjhill at realitydiluted.com) Date: Tue, 4 Mar 2008 07:20:13 -0600 Subject: doubt about uClibc++ In-Reply-To: <47CD4AB1.4070709@parrot.com> References: <5a0574590803030802o1b98f559n5546c0df93582ad7@mail.gmail.com> <20080303183954.GA12326@real.realitydiluted.com> <47CD4AB1.4070709@parrot.com> Message-ID: <20080304132013.GA21307@real.realitydiluted.com> On Tue, Mar 04, 2008 at 02:12:17PM +0100, Matthieu CASTET wrote: > For the record "CodeSourcery Sourcery G++ Lite 2007q3-51" source code is > avaible on codesourcery web site [1]. > Also AFAIK codesourcery do lot's of work in offical gcc tree... > That's cool! I never go to their site, so didn't know. Thanks! I am well aware of their work on GCC, as a couple of guys there have helped me privately with a number of bugs. My statement was made because typically vendors of toolchains make their money from support. But if the source is available, that gives us something work from. -Steve From matthieu.castet at parrot.com Tue Mar 4 05:12:17 2008 From: matthieu.castet at parrot.com (Matthieu CASTET) Date: Tue, 04 Mar 2008 14:12:17 +0100 Subject: doubt about uClibc++ In-Reply-To: <20080303183954.GA12326@real.realitydiluted.com> References: <5a0574590803030802o1b98f559n5546c0df93582ad7@mail.gmail.com> <20080303183954.GA12326@real.realitydiluted.com> Message-ID: <47CD4AB1.4070709@parrot.com> sjhill at realitydiluted.com wrote: >> somebody got it compile and use "uClibc++" in uClinux/ARM? so, i can't >> compile using gcc/arm. >> >> my env below! >> > [SNIP] >> Thread model: single >> gcc version 4.2.1 (CodeSourcery Sourcery G++ Lite 2007q3-51) >> root at campinho uClinux-dist-20051014# >> > I hope I do not come off as crabby and Drepper-like, but go bug > CodeSourcery for support. You got the toolchain from them and > unless they are going to provide you with complete source to the > toolchain and provide it to someone on the list to attempt a test > build, it's not our problem. Thanks and have a nice day. For the record "CodeSourcery Sourcery G++ Lite 2007q3-51" source code is avaible on codesourcery web site [1]. Also AFAIK codesourcery do lot's of work in offical gcc tree... Matthieu [1] http://www.codesourcery.com/gnu_toolchains/arm/download.html From jvhiii at yahoo.com Tue Mar 4 16:50:29 2008 From: jvhiii at yahoo.com (John VanHorne) Date: Tue, 4 Mar 2008 16:50:29 -0800 (PST) Subject: Status of uClibc NPTL on MIPS Message-ID: <298077.34443.qm@web39510.mail.mud.yahoo.com> I see from reading through the mail archives that the uClibc-nptl branch supports MIPS, and that this is currently being tested. I'm just wondering if you have an idea when the testing will be complete. And will there be a new release of uClibc once NPTL is merged to the trunk? Thanks, -John ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ From carmelo73 at gmail.com Wed Mar 5 00:28:45 2008 From: carmelo73 at gmail.com (Carmelo Amoroso) Date: Wed, 05 Mar 2008 09:28:45 +0100 Subject: Problems with syscall for SH In-Reply-To: <82ecf08e0803030458k5135ca13g9c3b340ba0a3a479@mail.gmail.com> References: <82ecf08e0803030458k5135ca13g9c3b340ba0a3a479@mail.gmail.com> Message-ID: <47CE59BD.1090505@gmail.com> Thiago Galesi wrote: > Hello > > I am trying this with svn uclibc, and even with (moderately) old > versions the result is the same. > > I saw this problem discussed in older messages (for other archs), but > it was not solved them > > There is a conflict with the definition of syscall (in .h) and the > implementation (for SH). > > this is the .h (include/unistd.h) > > extern long int syscall (long int __sysno, ...) __THROW; > > this is the .c (libc/sysdeps/linux/sh/syscall.c) > > long syscall(long sysnum, > long arg1, long arg2, long arg3, > long arg4, long arg5, long arg6) > > Problem is, if I take the .c prototype and put it in the .h, things > will not work (eg. there are problems with compiling pthread) > > What would be the correct way to deal with this? Most archs don't have > this problem, as they have a syscall.S file, ARM uses a .c, I'll try > to figure out from there. > > Thanks Hello Thiago, I cannot do any test just now, hopefully tomorrow I will do a check on my sh4. Carmelo From carmelo73 at gmail.com Wed Mar 5 03:41:07 2008 From: carmelo73 at gmail.com (Carmelo Amoroso) Date: Wed, 05 Mar 2008 12:41:07 +0100 Subject: [PATCH] Makefile.in: better clean Message-ID: <47CE86D3.2070404@gmail.com> Hi All, I've discovered (at least on nptl branch) that issuing make clean from the top dir not all files are cleaned-up (i.e. some symlink into nptl directory). This causes 'svn status' showing a lot of ? due files not controlled by CM. I've found that the clean target in top Makefile.in doesn't call make objclean_y (while it calls headers_clean-y). Doing this fix, we can remove the find commnad. I've tested the patch on trunk doing a full build for sh4/linuxthread.old then a 'make clean' and 'svn status' without extra files left. Any concerns with the patch ? Please, find attached the log of the clean -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: make_clean.patch Url: http://busybox.net/lists/uclibc/attachments/20080305/c874a8c9/attachment.diff -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: clean.log Url: http://busybox.net/lists/uclibc/attachments/20080305/c874a8c9/attachment-0001.diff From carmelo.amoroso at st.com Thu Mar 6 09:37:32 2008 From: carmelo.amoroso at st.com (Carmelo AMOROSO) Date: Thu, 06 Mar 2008 18:37:32 +0100 Subject: Problems with syscall for SH In-Reply-To: <47CE59BD.1090505@gmail.com> References: <82ecf08e0803030458k5135ca13g9c3b340ba0a3a479@mail.gmail.com> <47CE59BD.1090505@gmail.com> Message-ID: <47D02BDC.9080807@st.com> Carmelo Amoroso wrote: > Thiago Galesi wrote: > >> Hello >> >> I am trying this with svn uclibc, and even with (moderately) old >> versions the result is the same. >> >> I saw this problem discussed in older messages (for other archs), but >> it was not solved them >> >> There is a conflict with the definition of syscall (in .h) and the >> implementation (for SH). >> >> this is the .h (include/unistd.h) >> >> extern long int syscall (long int __sysno, ...) __THROW; >> >> this is the .c (libc/sysdeps/linux/sh/syscall.c) >> >> long syscall(long sysnum, >> long arg1, long arg2, long arg3, >> long arg4, long arg5, long arg6) >> >> Problem is, if I take the .c prototype and put it in the .h, things >> will not work (eg. there are problems with compiling pthread) >> >> What would be the correct way to deal with this? Most archs don't have >> this problem, as they have a syscall.S file, ARM uses a .c, I'll try >> to figure out from there. >> >> Thanks >> > > Hello Thiago, > I cannot do any test just now, hopefully tomorrow > I will do a check on my sh4. > > Carmelo > Hello, I did a simple test call syscall(100, 1, 2,3,4) and I did not get any problem at compile time.. where is the conflict you have ? can you post some error messages ? Carmelo > _______________________________________________ > uClibc mailing list > uClibc at uclibc.org > http://busybox.net/cgi-bin/mailman/listinfo/uclibc > > From thiagogalesi at gmail.com Thu Mar 6 10:22:45 2008 From: thiagogalesi at gmail.com (Thiago Galesi) Date: Thu, 6 Mar 2008 15:22:45 -0300 Subject: Problems with syscall for SH In-Reply-To: <47D02BDC.9080807@st.com> References: <82ecf08e0803030458k5135ca13g9c3b340ba0a3a479@mail.gmail.com> <47CE59BD.1090505@gmail.com> <47D02BDC.9080807@st.com> Message-ID: <82ecf08e0803061022x22bab1dep656faad7acf6d6db@mail.gmail.com> Hello It is not a problem compiling an application that uses syscall, but rather, building uclibc (using buildroot.uclibc as part of toolchain build). Yours Thiago Galesi On Thu, Mar 6, 2008 at 2:37 PM, Carmelo AMOROSO wrote: > > Carmelo Amoroso wrote: > > Thiago Galesi wrote: > > > >> Hello > >> > >> I am trying this with svn uclibc, and even with (moderately) old > >> versions the result is the same. > >> > >> I saw this problem discussed in older messages (for other archs), but > >> it was not solved them > >> > >> There is a conflict with the definition of syscall (in .h) and the > >> implementation (for SH). > >> > >> this is the .h (include/unistd.h) > >> > >> extern long int syscall (long int __sysno, ...) __THROW; > >> > >> this is the .c (libc/sysdeps/linux/sh/syscall.c) > >> > >> long syscall(long sysnum, > >> long arg1, long arg2, long arg3, > >> long arg4, long arg5, long arg6) > >> > >> Problem is, if I take the .c prototype and put it in the .h, things > >> will not work (eg. there are problems with compiling pthread) > >> > >> What would be the correct way to deal with this? Most archs don't have > >> this problem, as they have a syscall.S file, ARM uses a .c, I'll try > >> to figure out from there. > >> > >> Thanks > >> > > > > Hello Thiago, > > I cannot do any test just now, hopefully tomorrow > > I will do a check on my sh4. > > > > Carmelo > > > Hello, > I did a simple test call syscall(100, 1, 2,3,4) and I did not get any > problem at compile > time.. where is the conflict you have ? can you post some error messages ? > > Carmelo > > _______________________________________________ > > uClibc mailing list > > uClibc at uclibc.org > > http://busybox.net/cgi-bin/mailman/listinfo/uclibc > > > > > > -- - Thiago Galesi From carmelo.amoroso at st.com Thu Mar 6 11:00:14 2008 From: carmelo.amoroso at st.com (Carmelo AMOROSO) Date: Thu, 06 Mar 2008 20:00:14 +0100 Subject: Problems with syscall for SH In-Reply-To: <82ecf08e0803061022x22bab1dep656faad7acf6d6db@mail.gmail.com> References: <82ecf08e0803030458k5135ca13g9c3b340ba0a3a479@mail.gmail.com> <47CE59BD.1090505@gmail.com> <47D02BDC.9080807@st.com> <82ecf08e0803061022x22bab1dep656faad7acf6d6db@mail.gmail.com> Message-ID: <47D03F3E.9000601@st.com> Thiago Galesi wrote: > Hello > > It is not a problem compiling an application that uses syscall, but > rather, building uclibc (using buildroot.uclibc as part of toolchain > build). > > Yours > > Thiago Galesi > ??? I'm a bit confused. I don't have any problems to build uClibc, neither almost 500 packages against uclibc. I don't use buildroot anyway. Please, post some logs if available. Carmelo > On Thu, Mar 6, 2008 at 2:37 PM, Carmelo AMOROSO wrote: > >> Carmelo Amoroso wrote: >> > Thiago Galesi wrote: >> > >> >> Hello >> >> >> >> I am trying this with svn uclibc, and even with (moderately) old >> >> versions the result is the same. >> >> >> >> I saw this problem discussed in older messages (for other archs), but >> >> it was not solved them >> >> >> >> There is a conflict with the definition of syscall (in .h) and the >> >> implementation (for SH). >> >> >> >> this is the .h (include/unistd.h) >> >> >> >> extern long int syscall (long int __sysno, ...) __THROW; >> >> >> >> this is the .c (libc/sysdeps/linux/sh/syscall.c) >> >> >> >> long syscall(long sysnum, >> >> long arg1, long arg2, long arg3, >> >> long arg4, long arg5, long arg6) >> >> >> >> Problem is, if I take the .c prototype and put it in the .h, things >> >> will not work (eg. there are problems with compiling pthread) >> >> >> >> What would be the correct way to deal with this? Most archs don't have >> >> this problem, as they have a syscall.S file, ARM uses a .c, I'll try >> >> to figure out from there. >> >> >> >> Thanks >> >> >> > >> > Hello Thiago, >> > I cannot do any test just now, hopefully tomorrow >> > I will do a check on my sh4. >> > >> > Carmelo >> > >> Hello, >> I did a simple test call syscall(100, 1, 2,3,4) and I did not get any >> problem at compile >> time.. where is the conflict you have ? can you post some error messages ? >> >> Carmelo >> > _______________________________________________ >> > uClibc mailing list >> > uClibc at uclibc.org >> > http://busybox.net/cgi-bin/mailman/listinfo/uclibc >> > >> > >> >> >> > > > > From thiagogalesi at gmail.com Thu Mar 6 12:10:18 2008 From: thiagogalesi at gmail.com (Thiago Galesi) Date: Thu, 6 Mar 2008 17:10:18 -0300 Subject: Problems with syscall for SH In-Reply-To: <47D03F3E.9000601@st.com> References: <82ecf08e0803030458k5135ca13g9c3b340ba0a3a479@mail.gmail.com> <47CE59BD.1090505@gmail.com> <47D02BDC.9080807@st.com> <82ecf08e0803061022x22bab1dep656faad7acf6d6db@mail.gmail.com> <47D03F3E.9000601@st.com> Message-ID: <82ecf08e0803061210p61180981ga1c4efdbb3f69e95@mail.gmail.com> Hello There you go CC libc/sysdeps/linux/sh/syscall.os libc/sysdeps/linux/sh/syscall.c:11: error: conflicting types for 'syscall' ./include/unistd.h:1016: error: previous declaration of 'syscall' was here libc/sysdeps/linux/sh/syscall.c:11: error: conflicting types for 'syscall' ./include/unistd.h:1016: error: previous declaration of 'syscall' was here Thanks Thiago Galesi On Thu, Mar 6, 2008 at 4:00 PM, Carmelo AMOROSO wrote: > Thiago Galesi wrote: > > Hello > > > > It is not a problem compiling an application that uses syscall, but > > rather, building uclibc (using buildroot.uclibc as part of toolchain > > build). > > > > Yours > > > > Thiago Galesi > > > ??? I'm a bit confused. I don't have any problems to build uClibc, > neither almost 500 packages > against uclibc. I don't use buildroot anyway. > Please, post some logs if available. > > Carmelo > > > > On Thu, Mar 6, 2008 at 2:37 PM, Carmelo AMOROSO wrote: > > > >> Carmelo Amoroso wrote: > >> > Thiago Galesi wrote: > >> > > >> >> Hello > >> >> > >> >> I am trying this with svn uclibc, and even with (moderately) old > >> >> versions the result is the same. > >> >> > >> >> I saw this problem discussed in older messages (for other archs), but > >> >> it was not solved them > >> >> > >> >> There is a conflict with the definition of syscall (in .h) and the > >> >> implementation (for SH). > >> >> > >> >> this is the .h (include/unistd.h) > >> >> > >> >> extern long int syscall (long int __sysno, ...) __THROW; > >> >> > >> >> this is the .c (libc/sysdeps/linux/sh/syscall.c) > >> >> > >> >> long syscall(long sysnum, > >> >> long arg1, long arg2, long arg3, > >> >> long arg4, long arg5, long arg6) > >> >> > >> >> Problem is, if I take the .c prototype and put it in the .h, things > >> >> will not work (eg. there are problems with compiling pthread) > >> >> > >> >> What would be the correct way to deal with this? Most archs don't have > >> >> this problem, as they have a syscall.S file, ARM uses a .c, I'll try > >> >> to figure out from there. > >> >> > >> >> Thanks > >> >> > >> > > >> > Hello Thiago, > >> > I cannot do any test just now, hopefully tomorrow > >> > I will do a check on my sh4. > >> > > >> > Carmelo > >> > > >> Hello, > >> I did a simple test call syscall(100, 1, 2,3,4) and I did not get any > >> problem at compile > >> time.. where is the conflict you have ? can you post some error messages ? > >> > >> Carmelo > >> > _______________________________________________ > >> > uClibc mailing list > >> > uClibc at uclibc.org > >> > http://busybox.net/cgi-bin/mailman/listinfo/uclibc > >> > > >> > > >> > >> > >> > > > > > > > > > > -- - Thiago Galesi From kraj at mvista.com Thu Mar 6 13:45:30 2008 From: kraj at mvista.com (Khem Raj) Date: Thu, 06 Mar 2008 13:45:30 -0800 Subject: gcc headers needed for ARM EABI build Message-ID: <47D065FA.6050401@mvista.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Currently on trunk when building uclibc for ARM with EABI support it needs unwind.h header from gcc headers. We have -nostdinc option added in rules.mak so the build does not pick up this header. I think that removing nostdinc might not be a likable solution. Does someone else has a better idea? Thanks - -Khem -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH0GX6UjbQJxVzeZQRAhOqAJ9cEpXwAAQZwRgLOylPxYLf7xdKfgCcDf+E YgxSmYUptbOcYMVuscCXwfU= =xrJN -----END PGP SIGNATURE----- From joseph at codesourcery.com Thu Mar 6 16:32:05 2008 From: joseph at codesourcery.com (Joseph S. Myers) Date: Fri, 7 Mar 2008 00:32:05 +0000 (UTC) Subject: gcc headers needed for ARM EABI build In-Reply-To: <47D065FA.6050401@mvista.com> References: <47D065FA.6050401@mvista.com> Message-ID: On Thu, 6 Mar 2008, Khem Raj wrote: > We have -nostdinc option added in rules.mak so the build does not pick > up this header. The line CFLAGS += -iwithprefix include-fixed -iwithprefix include is supposed to ensure that GCC's internal headers are picked up. Perhaps it's broken; the old version using -print-file-name=include certainly worked (although needing patching to work with 4.3's include-fixed). -- Joseph S. Myers joseph at codesourcery.com From jpereiran at gmail.com Fri Mar 7 04:44:09 2008 From: jpereiran at gmail.com (Jorge Pereira) Date: Fri, 7 Mar 2008 09:44:09 -0300 Subject: arm7tdmi - NXP LPC2468 - gcc/g++/libstdc++, it's possible? Message-ID: <5a0574590803070444i59fada4et50bb39c2b9422061@mail.gmail.com> hi folks! it's possible bulding gcc/g++/libstdc++ to arm? i try following many days and don't success. so, i need gcc/g++ (3.3 or beetter) /libstdc++/threads to running in my LPC2468 board. somebody can help or tell me where found paper? thkz! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/uclibc/attachments/20080307/1e6423ee/attachment.htm From jpereiran at gmail.com Fri Mar 7 08:26:03 2008 From: jpereiran at gmail.com (Jorge Pereira) Date: Fri, 7 Mar 2008 13:26:03 -0300 Subject: arm7tdmi - NXP LPC2468 - gcc/g++/libstdc++, it's possible? In-Reply-To: <56d259a00803070716w58d512e5ve7b9b02a2d6bce59@mail.gmail.com> References: <5a0574590803070444i59fada4et50bb39c2b9422061@mail.gmail.com> <56d259a00803070716w58d512e5ve7b9b02a2d6bce59@mail.gmail.com> Message-ID: <5a0574590803070826o7afdd2cdg2ad71bb6b8abf8a5@mail.gmail.com> hi! so, i am trying running a simple app using c++, below following a code example. *jjpn at campinho hello$ *cat -n testecpp.cpp 1 #include 2 #include 3 #include 4 5 using namespace std; 6 7 class Teste { 8 private: 9 char texto[32]; 10 11 public: 12 Teste(void); 13 ~Teste(void); 14 static Teste *get(void); 15 void setTexto(const char *texto); 16 const char *getTexto(void); 17 }; 18 19 Teste::Teste(void) 20 { 21 22 } 23 24 Teste::~Teste(void) 25 { 26 27 } 28 29 Teste *Teste::get(void) 30 { 31 static Teste singleton; 32 return &singleton; 33 } 34 35 void Teste::setTexto(const char *texto) 36 { 37 strncpy(&this->texto[0], texto, sizeof(this->texto)); 38 } 39 40 const char *Teste::getTexto(void) 41 { 42 return &this->texto[0]; 43 } 44 45 int main(int main, char *argv[]) 46 { 47 Teste teste; 48 Teste *pteste = new Teste(); 49 50 Teste::get()->setTexto("Jorge Pereira: singleton"); 51 pteste->setTexto("Jorge Pereira: pointer"); 52 teste.setTexto("Jorge Pereira: static"); 53 54 cout << "Nome: singleton = " << Teste::get()->getTexto() << endl; 55 cout << "Nome: pointer = " << pteste->getTexto() << endl; 56 cout << "Nome: static = " << teste.getTexto() << endl; 57 58 printf("Hello World utilizando printf()\n"); 59 60 delete pteste; 61 62 return 0; 63 } 64 *jjpn at campinho hello$* i am using a gcc/g++ below. *jjpn at campinho hello$* arm-uclinuxeabi-g++ -v Using built-in specs. Target: arm-uclinuxeabi Configured with: /scratch/paul/lite/uclinux/src/gcc-4.2/configure --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=arm-uclinuxeabi --enable-threads --disable-libmudflap --disable-libssp --disable-libgomp --disable-libstdcxx-pch --with-gnu-as --with-gnu-ld --enable-languages=c,c++ --disable-shared --with-pkgversion=CodeSourcery Sourcery G++ Lite 2007q3-51 --with-bugurl=https://support.codesourcery.com/GNUToolchain/ --disable-nls --prefix=/opt/codesourcery --with-sysroot=/opt/codesourcery/arm-uclinuxeabi/libc --with-build-sysroot=/scratch/paul/lite/uclinux/install/arm-uclinuxeabi/libc --enable-poison-system-directories --with-build-time-tools=/scratch/paul/lite/uclinux/install/arm-uclinuxeabi/bin --with-build-time-tools=/scratch/paul/lite/uclinux/install/arm-uclinuxeabi/bin Thread model: single gcc version 4.2.1 (CodeSourcery Sourcery G++ Lite 2007q3-51) *jjpn at campinho hello$* compiling... *jjpn at campinho hello$* arm-uclinuxeabi-g++ -Os -pipe -fno-common -fno-builtin -Wall -nostdinc++ -I/opt/uClibc++/include -l:/opt/uClibc++/lib/libuClibc++.a -L/opt/uClibc++/lib/ -o testecpp.bin testecpp.cpp -Wl,-elf2flt="-r" *jjpn at campinho hello$ *file testecpp.bin testecpp.bin: BFLT executable - version 4 ram *jjpn at campinho hello$ *ls -lh testecpp.bin -rw-r--r-- 1 jjpn jjpn 61K 2008-03-07 13:19 testecpp.bin *jjpn at campinho hello$* when a try execute a BIN on board (LPC2468 from embedded artistis) a receive this message *#* cat /proc/version Linux version 2.6.11.8-hsc0BEIJING (user at eadevenv) (gcc version 2.95.320010315 (release)(ColdFire patches - 20010318 from http://fiddes.net/coldfire/)(uClinuxXIP and shared lib patches from http://www.snapgear.com/) ) #189 Wed Dec 26 16:06:12 CET 2007 *#* ./testecpp.bin Illegal instruction *#* Questions!! 1) why this message appear? 2) exist any form to "running a c++ app in this board LPC2468 from embedded artists?? My priority is compile using gcc/g++/threads 3.4 or better. thankz a lot! []s On Fri, Mar 7, 2008 at 12:16 PM, Martin Guy wrote: > Hi! > linux-arm is the list for linux kernel developers, not compilers or > cross-compilers. > What exactly are you trying to do? On what machine do you want to run > the compiler? On the arm board itself? > > M > -- Regards, + ---------------------------------------------------------------------------------+ Jorge Pereira, From: Olinda/Pe/Brazil Home: http://www.jorgepereira.com.br/ E-mail: jpereiran at gmail.com, jorge at jorgepereira.com.br Mobile: +55 (81) 8833-2484 My Public Key: http://www.jorgepereira.com.br/public.pgp + ---------------------------------------------------------------------------------+ "Se voc? ama alguma coisa, liberte-a; Se ela n?o voltar a ti, cace-a e mate-a." +----------------------------------------------------------------------------------+ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/uclibc/attachments/20080307/a785dd54/attachment.htm From kraj at mvista.com Fri Mar 7 08:42:48 2008 From: kraj at mvista.com (Khem Raj) Date: Fri, 07 Mar 2008 08:42:48 -0800 Subject: arm7tdmi - NXP LPC2468 - gcc/g++/libstdc++, it's possible? In-Reply-To: <5a0574590803070826o7afdd2cdg2ad71bb6b8abf8a5@mail.gmail.com> References: <5a0574590803070444i59fada4et50bb39c2b9422061@mail.gmail.com> <56d259a00803070716w58d512e5ve7b9b02a2d6bce59@mail.gmail.com> <5a0574590803070826o7afdd2cdg2ad71bb6b8abf8a5@mail.gmail.com> Message-ID: <47D17088.9050304@mvista.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jorge Pereira wrote: | when a try execute a BIN on board (LPC2468 from embedded artistis) a | receive this message | | *#* cat /proc/version | Linux version 2.6.11.8-hsc0BEIJING (user at eadevenv) (gcc version 2.95.3 | 20010315 (release)(ColdFire patches - 20010318 from | http://fiddes.net/coldfire/)(uClinux | XIP and shared lib patches | from http://www.snapgear.com/) ) #189 Wed | Dec 26 16:06:12 CET 2007 | *#* ./testecpp.bin | Illegal instruction | *#* | | Questions!! | | 1) why this message appear? arm7tdmi is ARMv4T instruction set. Your problem could be that gcc might not be generating code for this architecture by default instead a newer one. what happens when you use -mcpu=arm7tdmi | 2) exist any form to "running a c++ app in this board LPC2468 from | embedded artists?? | | My priority is compile using gcc/g++/threads 3.4 or better. - -Khem -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH0XCIUjbQJxVzeZQRAh6uAJ9rEpk7ojmrG+FqoNVLcEQEy1RSqACgioqL AiIX4dqahXtvITve12iMViw= =S+Zo -----END PGP SIGNATURE----- From jpereiran at gmail.com Fri Mar 7 08:47:45 2008 From: jpereiran at gmail.com (Jorge Pereira) Date: Fri, 7 Mar 2008 13:47:45 -0300 Subject: arm7tdmi - NXP LPC2468 - gcc/g++/libstdc++, it's possible? In-Reply-To: <47D17088.9050304@mvista.com> References: <5a0574590803070444i59fada4et50bb39c2b9422061@mail.gmail.com> <56d259a00803070716w58d512e5ve7b9b02a2d6bce59@mail.gmail.com> <5a0574590803070826o7afdd2cdg2ad71bb6b8abf8a5@mail.gmail.com> <47D17088.9050304@mvista.com> Message-ID: <5a0574590803070847m2b929194i7ffb5604791f6382@mail.gmail.com> hi! i try. *jjpn at campinho hello$* arm-uclinuxeabi-g++ -mcpu=arm7tdmi -Os -fomit-frame-pointer -fno-common -fno-builtin -Wall -Wl,-elf2flt="-r" -o testecpp.bin testecpp.cpp -nostdinc++ -l:/opt/uClibc++/lib/libuClibc++.a -I/opt/uClibc++/include *jjpn at campinho hello$* file testecpp.bin testecpp.bin: BFLT executable - version 4 ram *jjpn at campinho hello$ * and send to board, and receive msg. # ./testecpp.bin Illegal instruction # On Fri, Mar 7, 2008 at 1:42 PM, Khem Raj wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Jorge Pereira wrote: > > > | when a try execute a BIN on board (LPC2468 from embedded artistis) a > | receive this message > | > | *#* cat /proc/version > | Linux version 2.6.11.8-hsc0BEIJING (user at eadevenv) (gcc version 2.95.3 > | 20010315 (release)(ColdFire patches - 20010318 from > | http://fiddes.net/coldfire/)(uClinux > | XIP and shared lib patches > | from http://www.snapgear.com/) ) #189 Wed > | Dec 26 16:06:12 CET 2007 > | *#* ./testecpp.bin > | Illegal instruction > | *#* > | > | Questions!! > | > | 1) why this message appear? > > arm7tdmi is ARMv4T instruction set. Your problem could be that gcc might > not be generating code for this architecture by default instead a newer > one. what happens when you use -mcpu=arm7tdmi > > > > | 2) exist any form to "running a c++ app in this board LPC2468 from > | embedded artists?? > | > | My priority is compile using gcc/g++/threads 3.4 or better. > > > - -Khem > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFH0XCIUjbQJxVzeZQRAh6uAJ9rEpk7ojmrG+FqoNVLcEQEy1RSqACgioqL > AiIX4dqahXtvITve12iMViw= > =S+Zo > -----END PGP SIGNATURE----- > -- Regards, + ---------------------------------------------------------------------------------+ Jorge Pereira, From: Olinda/Pe/Brazil Home: http://www.jorgepereira.com.br/ E-mail: jpereiran at gmail.com, jorge at jorgepereira.com.br Mobile: +55 (81) 8833-2484 My Public Key: http://www.jorgepereira.com.br/public.pgp + ---------------------------------------------------------------------------------+ "Se voc? ama alguma coisa, liberte-a; Se ela n?o voltar a ti, cace-a e mate-a." +----------------------------------------------------------------------------------+ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/uclibc/attachments/20080307/c288bdc3/attachment.htm From kraj at mvista.com Fri Mar 7 11:32:29 2008 From: kraj at mvista.com (Khem Raj) Date: Fri, 07 Mar 2008 11:32:29 -0800 Subject: gcc headers needed for ARM EABI build In-Reply-To: References: <47D065FA.6050401@mvista.com> Message-ID: <47D1984D.9080301@mvista.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Joseph S. Myers wrote: | On Thu, 6 Mar 2008, Khem Raj wrote: | |> We have -nostdinc option added in rules.mak so the build does not pick |> up this header. | | The line | | CFLAGS += -iwithprefix include-fixed -iwithprefix include | | is supposed to ensure that GCC's internal headers are picked up. Perhaps | it's broken; yes it seems so. I can see that the directory is listed in the search path when I add -v to gcc. But gcc really is not picking the header from it. the old version using -print-file-name=include certainly | worked (although needing patching to work with 4.3's include-fixed). | may be we can use -print-file-name=include and -print-file-name=include - -fixed instead. - -- Khem Raj MontaVista Software Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH0ZhNUjbQJxVzeZQRAmRfAJ4iKr3OkmzT7/NTrXjWaEMpnBoySgCfXPsp V/Hr9dEKJGzUJwBp0aDEpcI= =gFUQ -----END PGP SIGNATURE----- From vibi_sreenivasan at cms.com Sat Mar 8 06:16:46 2008 From: vibi_sreenivasan at cms.com (vibi) Date: Sat, 08 Mar 2008 14:16:46 +0000 Subject: help : mutex sharing between processes Message-ID: <1204985806.2786.41.camel@root> hello, i am trying to use sharing of mutex between processes on linux. i am using functions pthread_mutexattr_init followed by pthread_mutexattr_setpshared . in pc (kernel = 2.6.22.1,libpthread-2.5.so) it is running ok. but in arm-linux (kernel = 2.6.23.9, libuClibc-0.9.28.so,libpthread-0.9.28.so ) i am getting error for pthread_mutexattr_setpshared function. is this function not implemented in uClibc , if not where must i start from, so that i could contribute it back. please help. thanks in advance thanks & regards vibi sreenivasan From carmelo73 at gmail.com Sat Mar 8 08:51:44 2008 From: carmelo73 at gmail.com (Carmelo Amoroso) Date: Sat, 08 Mar 2008 17:51:44 +0100 Subject: help : mutex sharing between processes In-Reply-To: <1204985806.2786.41.camel@root> References: <1204985806.2786.41.camel@root> Message-ID: <47D2C420.7050400@gmail.com> vibi wrote: > hello, > i am trying to use sharing of mutex between processes on linux. > i am using functions pthread_mutexattr_init followed by > pthread_mutexattr_setpshared . > > in pc (kernel = 2.6.22.1,libpthread-2.5.so) it is running ok. > but in arm-linux (kernel = 2.6.23.9, > libuClibc-0.9.28.so,libpthread-0.9.28.so ) > i am getting error for pthread_mutexattr_setpshared function. what kind of error ? this way nobody can't help you. Post a sample, command line used to compile, output, results showed at execution time... whatever... and also use gdb to debug your app too by your self. Cheers, Carmelo > > is this function not implemented in uClibc , if not > where must i start from, so that i could contribute it back. > please help. > > thanks in advance > > thanks & regards > vibi sreenivasan > > _______________________________________________ > uClibc mailing list > uClibc at uclibc.org > http://busybox.net/cgi-bin/mailman/listinfo/uclibc > From carmelo73 at gmail.com Sat Mar 8 09:01:00 2008 From: carmelo73 at gmail.com (Carmelo Amoroso) Date: Sat, 08 Mar 2008 18:01:00 +0100 Subject: Problems with syscall for SH In-Reply-To: <82ecf08e0803061210p61180981ga1c4efdbb3f69e95@mail.gmail.com> References: <82ecf08e0803030458k5135ca13g9c3b340ba0a3a479@mail.gmail.com> <47CE59BD.1090505@gmail.com> <47D02BDC.9080807@st.com> <82ecf08e0803061022x22bab1dep656faad7acf6d6db@mail.gmail.com> <47D03F3E.9000601@st.com> <82ecf08e0803061210p61180981ga1c4efdbb3f69e95@mail.gmail.com> Message-ID: <47D2C64C.5060705@gmail.com> Thiago Galesi wrote: > Hello > > There you go > > CC libc/sysdeps/linux/sh/syscall.os > libc/sysdeps/linux/sh/syscall.c:11: error: conflicting types for 'syscall' > ./include/unistd.h:1016: error: previous declaration of 'syscall' was here > libc/sysdeps/linux/sh/syscall.c:11: error: conflicting types for 'syscall' > ./include/unistd.h:1016: error: previous declaration of 'syscall' was here > > Thanks > > Thiago Galesi > Hello Thiago, I don't have any problem compiling this (using trunk r21275). Follows a log for my build .................... ads.old/sysdeps/pthread -I./libpthread/linuxthreads.old -I./libpthread -I/Users/carmelo/work/buildroot/toolchain_build_sh4/linux/include/ -iwith prefix include-fixed -iwithprefix include -fPIC 360 sh4-linux-uclibc-gcc -c libc/sysdeps/linux/sh/syscall.c -o libc/sysdeps/linux/sh/syscall.os -include ./include/libc-symbols.h -Wall -Wstrict-pro totypes -fno-strict-aliasing -Wnested-externs -Wshadow -Wmissing-noreturn -Wmissing-format-attribute -Wformat=2 -Wmissing-prototypes -Wmissing-d eclarations -Wnonnull -Wundef -ml -m4 -fno-stack-protector -fno-builtin -nostdinc -I./include -I. -I./libc/sysdeps/linux/sh -std=gnu99 -Os -funi t-at-a-time -fno-tree-loop-optimize -fno-tree-dominator-opts -fno-strength-reduce -fstrict-aliasing -mprefergot -I./libpthread/linuxthreads.old/ sysdeps/unix/sysv/linux/sh -I./libpthread/linuxthreads.old/sysdeps/sh -I./libpthread/linuxthreads.old/sysdeps/unix/sysv/linux -I./libpthread/lin uxthreads.old/sysdeps/pthread -I./libpthread/linuxthreads.old -I./libpthread -I/Users/carmelo/work/buildroot/toolchain_build_sh4/linux/include/ -iwithprefix include-fixed -iwithprefix include -fPIC 361 sh4-linux-uclibc-gcc -c libc/sysdeps/linux/sh/pread_write.c -o libc/sysdeps/linux/sh/pread_write.os -include ./include/libc-symbols.h -Wall -Wst rict-prototypes -fno-strict-aliasing -Wnested-externs -Wshadow -Wmissing-noreturn -Wmissing-format-attribute -Wformat=2 -Wmissing-prototypes -Wm issing-declarations -Wnonnull -Wundef -ml -m4 -fno- .............................. sh4-linux-uclibc-gcc --version sh4-linux-uclibc-gcc (GCC) 4.2.1 Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. What version of gcc are you using ? and waht is your full command line ? Carmelo > On Thu, Mar 6, 2008 at 4:00 PM, Carmelo AMOROSO wrote: >> Thiago Galesi wrote: >> > Hello >> > >> > It is not a problem compiling an application that uses syscall, but >> > rather, building uclibc (using buildroot.uclibc as part of toolchain >> > build). >> > >> > Yours >> > >> > Thiago Galesi >> > >> ??? I'm a bit confused. I don't have any problems to build uClibc, >> neither almost 500 packages >> against uclibc. I don't use buildroot anyway. >> Please, post some logs if available. >> >> Carmelo >> >> >>> On Thu, Mar 6, 2008 at 2:37 PM, Carmelo AMOROSO wrote: >> > >> >> Carmelo Amoroso wrote: >> >> > Thiago Galesi wrote: >> >> > >> >> >> Hello >> >> >> >> >> >> I am trying this with svn uclibc, and even with (moderately) old >> >> >> versions the result is the same. >> >> >> >> >> >> I saw this problem discussed in older messages (for other archs), but >> >> >> it was not solved them >> >> >> >> >> >> There is a conflict with the definition of syscall (in .h) and the >> >> >> implementation (for SH). >> >> >> >> >> >> this is the .h (include/unistd.h) >> >> >> >> >> >> extern long int syscall (long int __sysno, ...) __THROW; >> >> >> >> >> >> this is the .c (libc/sysdeps/linux/sh/syscall.c) >> >> >> >> >> >> long syscall(long sysnum, >> >> >> long arg1, long arg2, long arg3, >> >> >> long arg4, long arg5, long arg6) >> >> >> >> >> >> Problem is, if I take the .c prototype and put it in the .h, things >> >> >> will not work (eg. there are problems with compiling pthread) >> >> >> >> >> >> What would be the correct way to deal with this? Most archs don't have >> >> >> this problem, as they have a syscall.S file, ARM uses a .c, I'll try >> >> >> to figure out from there. >> >> >> >> >> >> Thanks >> >> >> >> >> > >> >> > Hello Thiago, >> >> > I cannot do any test just now, hopefully tomorrow >> >> > I will do a check on my sh4. >> >> > >> >> > Carmelo >> >> > >> >> Hello, >> >> I did a simple test call syscall(100, 1, 2,3,4) and I did not get any >> >> problem at compile >> >> time.. where is the conflict you have ? can you post some error messages ? >> >> >> >> Carmelo >> >> > _______________________________________________ >> >> > uClibc mailing list >> >> > uClibc at uclibc.org >> >> > http://busybox.net/cgi-bin/mailman/listinfo/uclibc >> >> > >> >> > >> >> >> >> >> >> >> > >> > >> > >> > >> >> > > > From kraj at mvista.com Sat Mar 8 13:04:21 2008 From: kraj at mvista.com (Khem Raj) Date: Sat, 8 Mar 2008 13:04:21 -0800 Subject: help : mutex sharing between processes In-Reply-To: <1204985806.2786.41.camel@root> References: <1204985806.2786.41.camel@root> Message-ID: On Mar 8, 2008, at 6:16 AM, vibi wrote: > hello, > i am trying to use sharing of mutex between processes on linux. > i am using functions pthread_mutexattr_init followed by > pthread_mutexattr_setpshared . > > in pc (kernel = 2.6.22.1,libpthread-2.5.so) it is running ok. > but in arm-linux (kernel = 2.6.23.9, > libuClibc-0.9.28.so,libpthread-0.9.28.so ) > i am getting error for pthread_mutexattr_setpshared function. > I dont think linuxthreads in uclibc has this. You can use uclibc-nptl branch currently for sh/mips or you can try buildroot to get arm nptl which should have the process shared mutexes. > -Khem From kraj at mvista.com Sat Mar 8 13:07:09 2008 From: kraj at mvista.com (Khem Raj) Date: Sat, 8 Mar 2008 13:07:09 -0800 Subject: gcc headers needed for ARM EABI build In-Reply-To: <47D1984D.9080301@mvista.com> References: <47D065FA.6050401@mvista.com> <47D1984D.9080301@mvista.com> Message-ID: <0D2C6FFB-13B0-4E39-A8A7-ABF95330D81E@mvista.com> > > may be we can use -print-file-name=include and -print-file- > name=include > - -fixed instead. it turns out to be that I had NPTL headers installed and I was doing build with LinuxThreads so it was picking arm specific unwind.h from /usr/include. Once I removed that it worked all well. Thanks -Khem From kraj at mvista.com Sat Mar 8 13:31:11 2008 From: kraj at mvista.com (Khem Raj) Date: Sat, 8 Mar 2008 13:31:11 -0800 Subject: [PATCH] Use do_rem to get rid of undefined __raise() error on ARM Message-ID: <7878D8A9-A814-45B6-ADD6-204BBFB143D4@mvista.com> Hi, While compiling trunk on ARM with GCC 4.2 and enabling LDSO_GNU_HASH_SUPPORT I stumbled upon this problem. GCC made a call to libgcc function __aeabi_uidivmod()->__div0()- >__raise() and raise is not yet compiled in at the time of compiling ldso so I got well known undefined symbol __raise problem This patch uses the do_rem () macro to do the same operation. OK ? Thanks Khem Raj MontaVista -------------- next part -------------- A non-text attachment was scrubbed... Name: uclibc-raise-error.patch Type: application/octet-stream Size: 797 bytes Desc: not available Url : http://busybox.net/lists/uclibc/attachments/20080308/996dcc06/attachment.obj -------------- next part -------------- From carmelo73 at gmail.com Sat Mar 8 23:16:18 2008 From: carmelo73 at gmail.com (Carmelo Amoroso) Date: Sun, 09 Mar 2008 08:16:18 +0100 Subject: [PATCH] Use do_rem to get rid of undefined __raise() error on ARM In-Reply-To: <7878D8A9-A814-45B6-ADD6-204BBFB143D4@mvista.com> References: <7878D8A9-A814-45B6-ADD6-204BBFB143D4@mvista.com> Message-ID: <47D38EC2.9050009@gmail.com> Khem Raj wrote: > Hi, > > While compiling trunk on ARM with GCC 4.2 and enabling > LDSO_GNU_HASH_SUPPORT I stumbled upon this problem. > GCC made a call to libgcc function > __aeabi_uidivmod()->__div0()->__raise() and raise is not yet compiled in > at the time of compiling ldso > so I got well known undefined symbol __raise problem > > This patch uses the do_rem () macro to do the same operation. > > OK ? > > Thanks > > Khem Raj > MontaVista > > Hi Khem, patch merged. Thanks Carmelo > > > ------------------------------------------------------------------------ > > _______________________________________________ > uClibc mailing list > uClibc at uclibc.org > http://busybox.net/cgi-bin/mailman/listinfo/uclibc From vibi_sreenivasan at cms.com Sun Mar 9 00:43:17 2008 From: vibi_sreenivasan at cms.com (vibi) Date: Sun, 09 Mar 2008 08:43:17 +0000 Subject: help : mutex sharing between processes In-Reply-To: References: <1204985806.2786.41.camel@root> Message-ID: <1205052197.2820.9.camel@root> hi , thanks for your support. I will try with buildroot to get arm ntpl. Thanks & Regards vibi sreenivasan On Sat, 2008-03-08 at 13:04 -0800, Khem Raj wrote: > On Mar 8, 2008, at 6:16 AM, vibi wrote: > > > hello, > > i am trying to use sharing of mutex between processes on linux. > > i am using functions pthread_mutexattr_init followed by > > pthread_mutexattr_setpshared . > > > > in pc (kernel = 2.6.22.1,libpthread-2.5.so) it is running ok. > > but in arm-linux (kernel = 2.6.23.9, > > libuClibc-0.9.28.so,libpthread-0.9.28.so ) > > i am getting error for pthread_mutexattr_setpshared function. > > > > I dont think linuxthreads in uclibc has this. You can use uclibc-nptl > branch currently for sh/mips > or you can try buildroot to get arm nptl which should have the process > shared mutexes. > > > > -Khem > > > From vibi_sreenivasan at cms.com Sun Mar 9 01:22:35 2008 From: vibi_sreenivasan at cms.com (vibi) Date: Sun, 09 Mar 2008 09:22:35 +0000 Subject: help : mutex sharing between processes In-Reply-To: <47D2C420.7050400@gmail.com> References: <1204985806.2786.41.camel@root> <47D2C420.7050400@gmail.com> Message-ID: <1205054555.2820.29.camel@root> hello, thanks for your support. i was checking whether sharing mutex between process is implemented.this is the code i used to test the same. #include #include #include int main (void) { pthread_mutexattr_t psharedm; if (pthread_mutexattr_init (&psharedm)) { printf ("error initializing mutex attribute\n"); fflush (stdout); exit (EXIT_FAILURE); } if (pthread_mutexattr_setpshared (&psharedm,PTHREAD_PROCESS_SHARED)) { printf ("error setting shared attribute for mutex \n"); fflush (stdout); pthread_mutexattr_destroy (&psharedm); exit (EXIT_FAILURE); } } for compiling in pc i used gcc -o -lpthread for cross-compiling i used arm-linux-gcc -o -lpthread while i executed this in pc , it did not give any error message but when i executed in target h/w i got "error setting shared attribute for mutex" i doubt whether sharing of mutex between process is implemented for this version of uClibc. thanks & regards vibi sreenivasan On Sat, 2008-03-08 at 17:51 +0100, Carmelo Amoroso wrote: > vibi wrote: > > hello, > > i am trying to use sharing of mutex between processes on linux. > > i am using functions pthread_mutexattr_init followed by > > pthread_mutexattr_setpshared . > > > > in pc (kernel = 2.6.22.1,libpthread-2.5.so) it is running ok. > > but in arm-linux (kernel = 2.6.23.9, > > libuClibc-0.9.28.so,libpthread-0.9.28.so ) > > i am getting error for pthread_mutexattr_setpshared function. > what kind of error ? this way nobody can't help you. > Post a sample, command line used to compile, output, results showed at > execution time... whatever... and also use gdb to debug your app too > by your self. > > Cheers, > Carmelo > > > > is this function not implemented in uClibc , if not > > where must i start from, so that i could contribute it back. > > please help. > > > > thanks in advance > > > > thanks & regards > > vibi sreenivasan > > > > _______________________________________________ > > uClibc mailing list > > uClibc at uclibc.org > > http://busybox.net/cgi-bin/mailman/listinfo/uclibc > > > > From peter.kjellerstedt at axis.com Mon Mar 10 01:28:37 2008 From: peter.kjellerstedt at axis.com (Peter Kjellerstedt) Date: Mon, 10 Mar 2008 09:28:37 +0100 Subject: svn commit: trunk/uClibc/ldso/ldso Message-ID: <50BF37ECE4954A4BA18C08D0C2CF88CB01A44521@exmail1.se.axis.com> > -----Original Message----- > From: uclibc-cvs-bounces at uclibc.org > [mailto:uclibc-cvs-bounces at uclibc.org] On Behalf Of carmelo at uclibc.org > Sent: den 9 mars 2008 08:07 > To: uclibc-cvs at uclibc.org > Subject: svn commit: trunk/uClibc/ldso/ldso > > Author: carmelo > Date: 2008-03-08 23:07:20 -0800 (Sat, 08 Mar 2008) > New Revision: 21278 > > Log: > Khem Raj writes: > While compiling trunk on ARM with GCC 4.2 and enabling > LDSO_GNU_HASH_SUPPORT I stumbled upon this problem. > GCC made a call to libgcc function > __aeabi_uidivmod()->__div0()->__raise() and raise is not yet > compiled in at the time of compiling ldso > so I got well known undefined symbol __raise problem > > This patch uses the do_rem () macro to do the same operation. > > Modified: > trunk/uClibc/ldso/ldso/dl-hash.c > > Changeset: > Modified: trunk/uClibc/ldso/ldso/dl-hash.c > =================================================================== > --- trunk/uClibc/ldso/ldso/dl-hash.c 2008-03-08 21:33:40 UTC > (rev 21277) > +++ trunk/uClibc/ldso/ldso/dl-hash.c 2008-03-09 07:07:20 UTC > (rev 21278) > @@ -204,11 +204,12 @@ > > unsigned int hashbit1 = hash & (__ELF_NATIVE_CLASS - 1); > unsigned int hashbit2 = ((hash >> tpnt->l_gnu_shift) & (__ELF_NATIVE_CLASS - 1)); > - > + unsigned long rem; > + do_rem (rem, hash, tpnt->nbucket); > _dl_assert (bitmask != NULL); > > if (unlikely((bitmask_word >> hashbit1) & (bitmask_word >> hashbit2) & 1)) { > - Elf32_Word bucket = tpnt->l_gnu_buckets[hash % tpnt->nbucket]; > + Elf32_Word bucket = tpnt->l_gnu_buckets[rem]; > > if (bucket != 0) { > const Elf32_Word *hasharr = &tpnt->l_gnu_chain_zero[bucket]; You should move the calculation of rem to within the if statement, since the modulo operation is time consuming and the if statement is marked as unlikely(), i.e.: if (unlikely((bitmask_word >> hashbit1) & (bitmask_word >> hashbit2) & 1)) { Elf32_Word bucket; unsigned long rem; do_rem(rem, hash, tpnt->nbucket); bucket = tpnt->l_gnu_buckets[rem]; //Peter From carmelo.amoroso at st.com Tue Mar 11 03:27:05 2008 From: carmelo.amoroso at st.com (Carmelo AMOROSO) Date: Tue, 11 Mar 2008 11:27:05 +0100 Subject: svn commit: trunk/uClibc/ldso/ldso In-Reply-To: <50BF37ECE4954A4BA18C08D0C2CF88CB01A44521@exmail1.se.axis.com> References: <50BF37ECE4954A4BA18C08D0C2CF88CB01A44521@exmail1.se.axis.com> Message-ID: <47D65E79.1020205@st.com> Peter Kjellerstedt wrote: > You should move the calculation of rem to within the if statement, > since the modulo operation is time consuming and the if statement > is marked as unlikely(), i.e.: > > if (unlikely((bitmask_word >> hashbit1) & (bitmask_word >> > hashbit2) & 1)) { > Elf32_Word bucket; > unsigned long rem; > > do_rem(rem, hash, tpnt->nbucket); > bucket = tpnt->l_gnu_buckets[rem]; > > //Peter > Done, thanks. Carmelo > _______________________________________________ > uClibc mailing list > uClibc at uclibc.org > http://busybox.net/cgi-bin/mailman/listinfo/uclibc > > From charlie.xiang at asokausa.com Tue Mar 11 03:27:06 2008 From: charlie.xiang at asokausa.com (Charlie Xiang) Date: Tue, 11 Mar 2008 03:27:06 -0700 Subject: Help me , Support IPV6? Message-ID: Hi? How are you? I have some problem when I use uclibc-0.9.19, I want to get some help from you, Thanks! I want to add some applet about IPV6 such as ifconfig and ping6, but when I build the source code of ifconfig ,I found uclibc don?t support the API such as inet_pton()? Need I do some other configure if I want to support IPV6 api when I use uclibc-0.9.19; Do the uclibc-0.9.19 support IPV6? Thanks && Best Regards! Charlie(??) 2008-03-11 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/uclibc/attachments/20080311/ac053011/attachment.htm From filippo.arcidiacono at st.com Tue Mar 11 04:04:08 2008 From: filippo.arcidiacono at st.com (Filippo ARCIDIACONO) Date: Tue, 11 Mar 2008 12:04:08 +0100 Subject: Help me , Support IPV6? In-Reply-To: Message-ID: <002101c88367$a1ab7e20$838182a4@st.com> I suppose do you men uclibc-0.9.29 not uclibc-0.9.19. To enable IPV6 support you have to do the following steps: make menuconfig and then select the options: -> Networking Support -> IP version 6 Support The next time, I suggest to you to post a new message without replay to something else. Filippo Arcidiacono. > -----Original Message----- > From: uclibc-bounces at uclibc.org > [mailto:uclibc-bounces at uclibc.org] On Behalf Of Charlie Xiang > Sent: Tuesday, March 11, 2008 11:27 AM > To: uclibc at mail.uclibc.org > Subject: Help me , Support IPV6? > > Hi? > > How are you? > > > > I have some problem when I use uclibc-0.9.19, I > want to get some help from you, Thanks! > > > > I want to add some applet about IPV6 such as ifconfig and > ping6, but when I build the source code of ifconfig ,I found > uclibc don?t support > > > > the API such as inet_pton()? Need I do some other configure > if I want to support IPV6 api when I use uclibc-0.9.19; Do > the uclibc-0.9.19 > > > > support IPV6? > > > > > > > > Thanks && Best Regards! > > > > Charlie(??) > > > > 2008-03-11 > > > > From ricard.wanderlof at axis.com Tue Mar 11 05:35:52 2008 From: ricard.wanderlof at axis.com (Ricard Wanderlof) Date: Tue, 11 Mar 2008 13:35:52 +0100 (CET) Subject: [PATCH] make getaddrinfo hint AI_ADDRCONFIG work In-Reply-To: <20080221175631.GA7161@real.realitydiluted.com> References: <20080221151646.GA4751@real.realitydiluted.com> <47BDA596.8070107@st.com> <20080221175631.GA7161@real.realitydiluted.com> Message-ID: On Thu, 21 Feb 2008, sjhill at realitydiluted.com wrote: > On Thu, Feb 21, 2008 at 05:13:28PM +0000, Joseph S. Myers wrote: >> >> No, glibc hasn't moved to GPLv3 yet. It's not moving until the glibc SC >> has got suitable wording from the FSF for an exception to allow GPLv2-only >> programs to continue to be linked with LGPLv3 glibc, and the FSF is being >> extremely slow about producing wording for any GPLv3 exceptions at all. >> > Cool, thanks for the info Joe! So...Ricard go snag the code from glibc > :). Ok, here is the patch. It adds support for the AI_ADDRCONFIG flag in the hints->ai_flags parameter to getaddrinfo(3). (More detailed description, mostly from my previous post, but repeated here:) We experienced a problem with a product when IPv6 is compiled into the product (and uClibc) but selectively disabled by a user. In this case, IPv6 traffic was still be generated, which in this particular case was not acceptable. The problem turned out to be in getaddrinfo(). When hints.ai_flags has the AI_ADDRCONFIG bit set in a call to getaddrinfo, IPv4 and IPv6 addresses should only be returned if the system has at least one address of the appropriate type configured. However, this turned out not to be the case, and both types of addresses were returned in any case, causing IPv6 DNS traffic even if no interface had an IPv6 address configured. The following patch fixes the problem, by copying the __check_pf() function from glibc, and ultimately using this function in getaddrinfo() to check for available protocol families on the interface in question. In order to do this, the previously not used (#if 0'd) code in lic/inet/ifaddrs.c has been enabled. Since the size of the resulting uClibc library file grows slightly (4.6 kbytes on the architecture we use), there's also a config variable which has to be enabled to use this feature. The patch also fixes a bug which caused an infinite loop when hints->ai_flags had the AI_ADDRCONFIG bit set (the lines around ++g in the patch). (Perhaps this was a failed attempt att fixing the problem at some time, as the coresponding glibc version does not seem to have the corresponding if-followed-by-continue clause. It has been in the svn repo since the first entry in 2002 (svn 4414) ). I've also included the patch as an attachement. It was made against svn 21288, head of the development tree att the time of writing. I'd like to commit this patch within a week unless anyone has any objections. /Ricard -- Ricard Wolf Wanderl?f ricardw(at)axis.com Axis Communications AB, Lund, Sweden www.axis.com Phone +46 46 272 2016 Fax +46 46 13 61 30 diff -urN uClibc-org/extra/Configs/Config.in uClibc/extra/Configs/Config.in --- uClibc-org/extra/Configs/Config.in 2008-03-11 11:59:04.301036000 +0100 +++ uClibc/extra/Configs/Config.in 2008-03-11 12:53:58.880468000 +0100 @@ -702,6 +702,18 @@ Most people can safely answer N. +config UCLIBC_SUPPORT_AI_ADDRCONFIG + bool "Support the AI_ADDRCONFIG flag" + depends on UCLIBC_USE_NETLINK + default n + help + The implementation of AI_ADDRCONFIG is aligned with the glibc + implementation using netlink to query interfaces to find both + ipv4 and ipv6 support. This is only needed if an application uses + the AI_ADDRCONFIG flag. + + Most people can safely answer N. + config UCLIBC_HAS_BSD_RES_CLOSE bool "Support res_close() (bsd-compat)" default n diff -urN uClibc-org/include/ifaddrs.h uClibc/include/ifaddrs.h --- uClibc-org/include/ifaddrs.h 1970-01-01 01:00:00.000000000 +0100 +++ uClibc/include/ifaddrs.h 2008-03-11 12:53:58.885463000 +0100 @@ -0,0 +1,19 @@ +#ifndef _IFADDRS_H +#include +#include +#include + +struct in6addrinfo +{ + enum { + in6ai_deprecated = 1, + in6ai_temporary = 2, + in6ai_homeaddress = 4 + } flags; + uint32_t addr[4]; +}; + +extern void __check_pf (bool *seen_ipv4, bool *seen_ipv6) + attribute_hidden; + +#endif /* ifaddrs.h */ diff -urN uClibc-org/libc/inet/check_pf.c uClibc/libc/inet/check_pf.c --- uClibc-org/libc/inet/check_pf.c 1970-01-01 01:00:00.000000000 +0100 +++ uClibc/libc/inet/check_pf.c 2008-03-11 12:53:58.972404000 +0100 @@ -0,0 +1,65 @@ +/* Determine protocol families for which interfaces exist. Generic version. + Copyright (C) 2003, 2006 Free Software Foundation, Inc. + This file is part of the GNU C Library. + + The GNU C Library is free software; you can redistribute it and/or + modify it under the terms of the GNU Lesser General Public + License as published by the Free Software Foundation; either + version 2.1 of the License, or (at your option) any later version. + + The GNU C Library is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Lesser General Public License for more details. + + You should have received a copy of the GNU Lesser General Public + License along with the GNU C Library; if not, write to the Free + Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA + 02111-1307 USA. */ + +#include +#include +#include + + +void +attribute_hidden +__check_pf (bool *seen_ipv4, bool *seen_ipv6) +{ + *seen_ipv4 = false; + *seen_ipv6 = false; +#if __UCLIBC_SUPPORT_AI_ADDRCONFIG__ + { + /* Get the interface list via getifaddrs. */ + struct ifaddrs *ifa = NULL; + struct ifaddrs *runp; + if (getifaddrs (&ifa) != 0) + { + /* We cannot determine what interfaces are available. Be + optimistic. */ + *seen_ipv4 = true; +#if __UCLIBC_HAS_IPV6__ + *seen_ipv6 = true; +#endif /* __UCLIBC_HAS_IPV6__ */ + return; + } + + for (runp = ifa; runp != NULL; runp = runp->ifa_next) + if (runp->ifa_addr->sa_family == PF_INET) + *seen_ipv4 = true; +#if __UCLIBC_HAS_IPV6__ + else if (runp->ifa_addr->sa_family == PF_INET6) + *seen_ipv6 = true; +#endif /* __UCLIBC_HAS_IPV6__ */ + + (void) freeifaddrs (ifa); + } +#else + /* AI_ADDRCONFIG is disabled, assume both ipv4 and ipv6 available. */ + *seen_ipv4 = true; +#if __UCLIBC_HAS_IPV6__ + *seen_ipv6 = true; +#endif /* __UCLIBC_HAS_IPV6__ */ + +#endif /* __UCLIBC_SUPPORT_AI_ADDRCONFIG__ */ +} diff -urN uClibc-org/libc/inet/getaddrinfo.c uClibc/libc/inet/getaddrinfo.c --- uClibc-org/libc/inet/getaddrinfo.c 2008-03-11 11:59:13.041801000 +0100 +++ uClibc/libc/inet/getaddrinfo.c 2008-03-11 12:53:58.980404000 +0100 @@ -66,6 +66,7 @@ #include #include #include +#include libc_hidden_proto(memcpy) libc_hidden_proto(memset) @@ -156,19 +157,29 @@ { 0, PF_UNSPEC, 0, 0, 0, NULL, NULL, NULL }; #endif - static int addrconfig (sa_family_t af) { int s; int ret; int saved_errno = errno; - s = socket(af, SOCK_DGRAM, 0); - if (s < 0) - ret = (errno == EMFILE) ? 1 : 0; + bool seen_ipv4; + bool seen_ipv6; + + __check_pf(&seen_ipv4, &seen_ipv6); + if (af == AF_INET) + ret = (int)seen_ipv4; + else if (af == AF_INET6) + ret = (int)seen_ipv6; else { - close(s); - ret = 1; + s = socket(af, SOCK_DGRAM, 0); + if (s < 0) + ret = (errno == EMFILE) ? 1 : 0; + else + { + close(s); + ret = 1; + } } __set_errno (saved_errno); return ret; @@ -373,6 +384,9 @@ int rc; int v4mapped = (req->ai_family == PF_UNSPEC || req->ai_family == PF_INET6) && (req->ai_flags & AI_V4MAPPED); + bool seen_ipv4; + bool seen_ipv6; + __check_pf(&seen_ipv4, &seen_ipv6); if (req->ai_protocol || req->ai_socktype) { @@ -560,14 +574,16 @@ #if __UCLIBC_HAS_IPV6__ if (req->ai_family == AF_UNSPEC || req->ai_family == AF_INET6) - gethosts (AF_INET6, struct in6_addr); + if (!(req->ai_flags & AI_ADDRCONFIG) || seen_ipv6) + gethosts (AF_INET6, struct in6_addr); #endif no_inet6_data = no_data; if (req->ai_family == AF_INET || (!v4mapped && req->ai_family == AF_UNSPEC) || (v4mapped && (no_inet6_data != 0 || (req->ai_flags & AI_ALL)))) - gethosts (AF_INET, struct in_addr); + if (!(req->ai_flags & AI_ADDRCONFIG) || seen_ipv4) + gethosts (AF_INET, struct in_addr); if (no_data != 0 && no_inet6_data != 0) { @@ -695,6 +711,13 @@ for (st2 = st; st2 != NULL; st2 = st2->next) { + if (req->ai_flags & AI_ADDRCONFIG) + if (family == AF_INET && !seen_ipv4) + break; +#if __UCLIBC_HAS_IPV6__ + else if (family == AF_INET6 && !seen_ipv6) + break; +#endif *pai = malloc (sizeof (struct addrinfo) + socklen + namelen); if (*pai == NULL) return -EAI_MEMORY; @@ -853,7 +876,10 @@ if (hints->ai_family == g->family || hints->ai_family == AF_UNSPEC) { if ((hints->ai_flags & AI_ADDRCONFIG) && !addrconfig(g->family)) + { + ++g; continue; + } j++; if (pg == NULL || pg->gaih != g->gaih) { diff -urN uClibc-org/libc/inet/ifaddrs.c uClibc/libc/inet/ifaddrs.c --- uClibc-org/libc/inet/ifaddrs.c 2008-03-11 11:59:12.614228000 +0100 +++ uClibc/libc/inet/ifaddrs.c 2008-03-11 12:53:58.987404000 +0100 @@ -22,7 +22,7 @@ #include #include #include -/*#include */ +#include #include #include #include @@ -57,7 +57,7 @@ #if __ASSUME_NETLINK_SUPPORT -#if 0 /* unused code */ +#if __UCLIBC_SUPPORT_AI_ADDRCONFIG__ /* struct to hold the data for one ifaddrs entry, so we can allocate everything at once. */ struct ifaddrs_storage @@ -74,7 +74,7 @@ } addr, netmask, broadaddr; char name[IF_NAMESIZE + 1]; }; -#endif /* unused code */ +#endif /* __UCLIBC_SUPPORT_AI_ADDRCONFIG__ */ void @@ -324,7 +324,7 @@ } -#if 0 /* unused code */ +#if __UCLIBC_SUPPORT_AI_ADDRCONFIG__ /* We know the number of RTM_NEWLINK entries, so we reserve the first # of entries for this type. All RTM_NEWADDR entries have an index pointer to the RTM_NEWLINK entry. To find the entry, create @@ -562,7 +562,7 @@ if ((rta_payload + 1) <= sizeof (ifas[ifa_index].name)) { ifas[ifa_index].ifa.ifa_name = ifas[ifa_index].name; - *(char *) __mempcpy (ifas[ifa_index].name, rta_data, + *(char *) mempcpy (ifas[ifa_index].name, rta_data, rta_payload) = '\0'; } break; @@ -761,7 +761,7 @@ if (rta_payload + 1 <= sizeof (ifas[ifa_index].name)) { ifas[ifa_index].ifa.ifa_name = ifas[ifa_index].name; - *(char *) __mempcpy (ifas[ifa_index].name, rta_data, + *(char *) mempcpy (ifas[ifa_index].name, rta_data, rta_payload) = '\0'; } else @@ -872,6 +872,6 @@ } #endif -#endif /* unused code */ +#endif /* __UCLIBC_SUPPORT_AI_ADDRCONFIG__ */ #endif /* __ASSUME_NETLINK_SUPPORT */ diff -urN uClibc-org/libc/inet/ifaddrs.h uClibc/libc/inet/ifaddrs.h --- uClibc-org/libc/inet/ifaddrs.h 1970-01-01 01:00:00.000000000 +0100 +++ uClibc/libc/inet/ifaddrs.h 2008-03-11 12:53:58.990405000 +0100 @@ -0,0 +1,74 @@ +/* ifaddrs.h -- declarations for getting network interface addresses + Copyright (C) 2002 Free Software Foundation, Inc. + This file is part of the GNU C Library. + + The GNU C Library is free software; you can redistribute it and/or + modify it under the terms of the GNU Lesser General Public + License as published by the Free Software Foundation; either + version 2.1 of the License, or (at your option) any later version. + + The GNU C Library is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Lesser General Public License for more details. + + You should have received a copy of the GNU Lesser General Public + License along with the GNU C Library; if not, write to the Free + Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA + 02111-1307 USA. */ + +#ifndef _IFADDRS_H +#define _IFADDRS_H 1 + +#include +#include + +__BEGIN_DECLS + +/* The `getifaddrs' function generates a linked list of these structures. + Each element of the list describes one network interface. */ +struct ifaddrs +{ + struct ifaddrs *ifa_next; /* Pointer to the next structure. */ + + char *ifa_name; /* Name of this network interface. */ + unsigned int ifa_flags; /* Flags as from SIOCGIFFLAGS ioctl. */ + + struct sockaddr *ifa_addr; /* Network address of this interface. */ + struct sockaddr *ifa_netmask; /* Netmask of this interface. */ + union + { + /* At most one of the following two is valid. If the IFF_BROADCAST + bit is set in `ifa_flags', then `ifa_broadaddr' is valid. If the + IFF_POINTOPOINT bit is set, then `ifa_dstaddr' is valid. + It is never the case that both these bits are set at once. */ + struct sockaddr *ifu_broadaddr; /* Broadcast address of this interface. */ + struct sockaddr *ifu_dstaddr; /* Point-to-point destination address. */ + } ifa_ifu; + /* These very same macros are defined by for `struct ifaddr'. + So if they are defined already, the existing definitions will be fine. */ +# ifndef ifa_broadaddr +# define ifa_broadaddr ifa_ifu.ifu_broadaddr +# endif +# ifndef ifa_dstaddr +# define ifa_dstaddr ifa_ifu.ifu_dstaddr +# endif + + void *ifa_data; /* Address-specific data (may be unused). */ +}; + + +/* Create a linked list of `struct ifaddrs' structures, one for each + network interface on the host machine. If successful, store the + list in *IFAP and return 0. On errors, return -1 and set `errno'. + + The storage returned in *IFAP is allocated dynamically and can + only be properly freed by passing it to `freeifaddrs'. */ +extern int getifaddrs (struct ifaddrs **__ifap) __THROW; + +/* Reclaim the storage allocated by a previous `getifaddrs' call. */ +extern void freeifaddrs (struct ifaddrs *__ifa) __THROW; + +__END_DECLS + +#endif /* ifaddrs.h */ diff -urN uClibc-org/libc/inet/Makefile.in uClibc/libc/inet/Makefile.in --- uClibc-org/libc/inet/Makefile.in 2008-03-11 11:59:12.429280000 +0100 +++ uClibc/libc/inet/Makefile.in 2008-03-11 12:53:58.933416000 +0100 @@ -9,7 +9,7 @@ CSRC := getservice.c getproto.c hostid.c getnetent.c getnetbynm.c getnetbyad.c \ inet_net.c ntop.c herror.c if_index.c gai_strerror.c getaddrinfo.c \ - in6_addr.c ether_addr.c ntohl.c opensock.c ifaddrs.c + in6_addr.c ether_addr.c ntohl.c opensock.c ifaddrs.c check_pf.c # multi source addr.c CSRC += inet_aton.c inet_addr.c inet_ntoa.c inet_makeaddr.c inet_lnaof.c \ diff -urN uClibc-org/libc/inet/netlinkaccess.h uClibc/libc/inet/netlinkaccess.h --- uClibc-org/libc/inet/netlinkaccess.h 2008-03-11 11:59:12.693149000 +0100 +++ uClibc/libc/inet/netlinkaccess.h 2008-03-11 12:53:59.066408000 +0100 @@ -61,13 +61,13 @@ }; -#if 0 /* unused code */ +#ifdef __UCLIBC_SUPPORT_AI_ADDRCONFIG__ #if __ASSUME_NETLINK_SUPPORT == 0 extern int __no_netlink_support attribute_hidden; #else # define __no_netlink_support 0 #endif -#endif /* unused code */ +#endif /* __UCLIBC_SUPPORT_AI_ADDRCONFIG__ */ extern int __netlink_open (struct netlink_handle *h) attribute_hidden; -------------- next part -------------- diff -urN uClibc-org/extra/Configs/Config.in uClibc/extra/Configs/Config.in --- uClibc-org/extra/Configs/Config.in 2008-03-11 11:59:04.301036000 +0100 +++ uClibc/extra/Configs/Config.in 2008-03-11 12:53:58.880468000 +0100 @@ -702,6 +702,18 @@ Most people can safely answer N. +config UCLIBC_SUPPORT_AI_ADDRCONFIG + bool "Support the AI_ADDRCONFIG flag" + depends on UCLIBC_USE_NETLINK + default n + help + The implementation of AI_ADDRCONFIG is aligned with the glibc + implementation using netlink to query interfaces to find both + ipv4 and ipv6 support. This is only needed if an application uses + the AI_ADDRCONFIG flag. + + Most people can safely answer N. + config UCLIBC_HAS_BSD_RES_CLOSE bool "Support res_close() (bsd-compat)" default n diff -urN uClibc-org/include/ifaddrs.h uClibc/include/ifaddrs.h --- uClibc-org/include/ifaddrs.h 1970-01-01 01:00:00.000000000 +0100 +++ uClibc/include/ifaddrs.h 2008-03-11 12:53:58.885463000 +0100 @@ -0,0 +1,19 @@ +#ifndef _IFADDRS_H +#include +#include +#include + +struct in6addrinfo +{ + enum { + in6ai_deprecated = 1, + in6ai_temporary = 2, + in6ai_homeaddress = 4 + } flags; + uint32_t addr[4]; +}; + +extern void __check_pf (bool *seen_ipv4, bool *seen_ipv6) + attribute_hidden; + +#endif /* ifaddrs.h */ diff -urN uClibc-org/libc/inet/check_pf.c uClibc/libc/inet/check_pf.c --- uClibc-org/libc/inet/check_pf.c 1970-01-01 01:00:00.000000000 +0100 +++ uClibc/libc/inet/check_pf.c 2008-03-11 12:53:58.972404000 +0100 @@ -0,0 +1,65 @@ +/* Determine protocol families for which interfaces exist. Generic version. + Copyright (C) 2003, 2006 Free Software Foundation, Inc. + This file is part of the GNU C Library. + + The GNU C Library is free software; you can redistribute it and/or + modify it under the terms of the GNU Lesser General Public + License as published by the Free Software Foundation; either + version 2.1 of the License, or (at your option) any later version. + + The GNU C Library is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Lesser General Public License for more details. + + You should have received a copy of the GNU Lesser General Public + License along with the GNU C Library; if not, write to the Free + Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA + 02111-1307 USA. */ + +#include +#include +#include + + +void +attribute_hidden +__check_pf (bool *seen_ipv4, bool *seen_ipv6) +{ + *seen_ipv4 = false; + *seen_ipv6 = false; +#if __UCLIBC_SUPPORT_AI_ADDRCONFIG__ + { + /* Get the interface list via getifaddrs. */ + struct ifaddrs *ifa = NULL; + struct ifaddrs *runp; + if (getifaddrs (&ifa) != 0) + { + /* We cannot determine what interfaces are available. Be + optimistic. */ + *seen_ipv4 = true; +#if __UCLIBC_HAS_IPV6__ + *seen_ipv6 = true; +#endif /* __UCLIBC_HAS_IPV6__ */ + return; + } + + for (runp = ifa; runp != NULL; runp = runp->ifa_next) + if (runp->ifa_addr->sa_family == PF_INET) + *seen_ipv4 = true; +#if __UCLIBC_HAS_IPV6__ + else if (runp->ifa_addr->sa_family == PF_INET6) + *seen_ipv6 = true; +#endif /* __UCLIBC_HAS_IPV6__ */ + + (void) freeifaddrs (ifa); + } +#else + /* AI_ADDRCONFIG is disabled, assume both ipv4 and ipv6 available. */ + *seen_ipv4 = true; +#if __UCLIBC_HAS_IPV6__ + *seen_ipv6 = true; +#endif /* __UCLIBC_HAS_IPV6__ */ + +#endif /* __UCLIBC_SUPPORT_AI_ADDRCONFIG__ */ +} diff -urN uClibc-org/libc/inet/getaddrinfo.c uClibc/libc/inet/getaddrinfo.c --- uClibc-org/libc/inet/getaddrinfo.c 2008-03-11 11:59:13.041801000 +0100 +++ uClibc/libc/inet/getaddrinfo.c 2008-03-11 12:53:58.980404000 +0100 @@ -66,6 +66,7 @@ #include #include #include +#include libc_hidden_proto(memcpy) libc_hidden_proto(memset) @@ -156,19 +157,29 @@ { 0, PF_UNSPEC, 0, 0, 0, NULL, NULL, NULL }; #endif - static int addrconfig (sa_family_t af) { int s; int ret; int saved_errno = errno; - s = socket(af, SOCK_DGRAM, 0); - if (s < 0) - ret = (errno == EMFILE) ? 1 : 0; + bool seen_ipv4; + bool seen_ipv6; + + __check_pf(&seen_ipv4, &seen_ipv6); + if (af == AF_INET) + ret = (int)seen_ipv4; + else if (af == AF_INET6) + ret = (int)seen_ipv6; else { - close(s); - ret = 1; + s = socket(af, SOCK_DGRAM, 0); + if (s < 0) + ret = (errno == EMFILE) ? 1 : 0; + else + { + close(s); + ret = 1; + } } __set_errno (saved_errno); return ret; @@ -373,6 +384,9 @@ int rc; int v4mapped = (req->ai_family == PF_UNSPEC || req->ai_family == PF_INET6) && (req->ai_flags & AI_V4MAPPED); + bool seen_ipv4; + bool seen_ipv6; + __check_pf(&seen_ipv4, &seen_ipv6); if (req->ai_protocol || req->ai_socktype) { @@ -560,14 +574,16 @@ #if __UCLIBC_HAS_IPV6__ if (req->ai_family == AF_UNSPEC || req->ai_family == AF_INET6) - gethosts (AF_INET6, struct in6_addr); + if (!(req->ai_flags & AI_ADDRCONFIG) || seen_ipv6) + gethosts (AF_INET6, struct in6_addr); #endif no_inet6_data = no_data; if (req->ai_family == AF_INET || (!v4mapped && req->ai_family == AF_UNSPEC) || (v4mapped && (no_inet6_data != 0 || (req->ai_flags & AI_ALL)))) - gethosts (AF_INET, struct in_addr); + if (!(req->ai_flags & AI_ADDRCONFIG) || seen_ipv4) + gethosts (AF_INET, struct in_addr); if (no_data != 0 && no_inet6_data != 0) { @@ -695,6 +711,13 @@ for (st2 = st; st2 != NULL; st2 = st2->next) { + if (req->ai_flags & AI_ADDRCONFIG) + if (family == AF_INET && !seen_ipv4) + break; +#if __UCLIBC_HAS_IPV6__ + else if (family == AF_INET6 && !seen_ipv6) + break; +#endif *pai = malloc (sizeof (struct addrinfo) + socklen + namelen); if (*pai == NULL) return -EAI_MEMORY; @@ -853,7 +876,10 @@ if (hints->ai_family == g->family || hints->ai_family == AF_UNSPEC) { if ((hints->ai_flags & AI_ADDRCONFIG) && !addrconfig(g->family)) + { + ++g; continue; + } j++; if (pg == NULL || pg->gaih != g->gaih) { diff -urN uClibc-org/libc/inet/ifaddrs.c uClibc/libc/inet/ifaddrs.c --- uClibc-org/libc/inet/ifaddrs.c 2008-03-11 11:59:12.614228000 +0100 +++ uClibc/libc/inet/ifaddrs.c 2008-03-11 12:53:58.987404000 +0100 @@ -22,7 +22,7 @@ #include #include #include -/*#include */ +#include #include #include #include @@ -57,7 +57,7 @@ #if __ASSUME_NETLINK_SUPPORT -#if 0 /* unused code */ +#if __UCLIBC_SUPPORT_AI_ADDRCONFIG__ /* struct to hold the data for one ifaddrs entry, so we can allocate everything at once. */ struct ifaddrs_storage @@ -74,7 +74,7 @@ } addr, netmask, broadaddr; char name[IF_NAMESIZE + 1]; }; -#endif /* unused code */ +#endif /* __UCLIBC_SUPPORT_AI_ADDRCONFIG__ */ void @@ -324,7 +324,7 @@ } -#if 0 /* unused code */ +#if __UCLIBC_SUPPORT_AI_ADDRCONFIG__ /* We know the number of RTM_NEWLINK entries, so we reserve the first # of entries for this type. All RTM_NEWADDR entries have an index pointer to the RTM_NEWLINK entry. To find the entry, create @@ -562,7 +562,7 @@ if ((rta_payload + 1) <= sizeof (ifas[ifa_index].name)) { ifas[ifa_index].ifa.ifa_name = ifas[ifa_index].name; - *(char *) __mempcpy (ifas[ifa_index].name, rta_data, + *(char *) mempcpy (ifas[ifa_index].name, rta_data, rta_payload) = '\0'; } break; @@ -761,7 +761,7 @@ if (rta_payload + 1 <= sizeof (ifas[ifa_index].name)) { ifas[ifa_index].ifa.ifa_name = ifas[ifa_index].name; - *(char *) __mempcpy (ifas[ifa_index].name, rta_data, + *(char *) mempcpy (ifas[ifa_index].name, rta_data, rta_payload) = '\0'; } else @@ -872,6 +872,6 @@ } #endif -#endif /* unused code */ +#endif /* __UCLIBC_SUPPORT_AI_ADDRCONFIG__ */ #endif /* __ASSUME_NETLINK_SUPPORT */ diff -urN uClibc-org/libc/inet/ifaddrs.h uClibc/libc/inet/ifaddrs.h --- uClibc-org/libc/inet/ifaddrs.h 1970-01-01 01:00:00.000000000 +0100 +++ uClibc/libc/inet/ifaddrs.h 2008-03-11 12:53:58.990405000 +0100 @@ -0,0 +1,74 @@ +/* ifaddrs.h -- declarations for getting network interface addresses + Copyright (C) 2002 Free Software Foundation, Inc. + This file is part of the GNU C Library. + + The GNU C Library is free software; you can redistribute it and/or + modify it under the terms of the GNU Lesser General Public + License as published by the Free Software Foundation; either + version 2.1 of the License, or (at your option) any later version. + + The GNU C Library is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Lesser General Public License for more details. + + You should have received a copy of the GNU Lesser General Public + License along with the GNU C Library; if not, write to the Free + Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA + 02111-1307 USA. */ + +#ifndef _IFADDRS_H +#define _IFADDRS_H 1 + +#include +#include + +__BEGIN_DECLS + +/* The `getifaddrs' function generates a linked list of these structures. + Each element of the list describes one network interface. */ +struct ifaddrs +{ + struct ifaddrs *ifa_next; /* Pointer to the next structure. */ + + char *ifa_name; /* Name of this network interface. */ + unsigned int ifa_flags; /* Flags as from SIOCGIFFLAGS ioctl. */ + + struct sockaddr *ifa_addr; /* Network address of this interface. */ + struct sockaddr *ifa_netmask; /* Netmask of this interface. */ + union + { + /* At most one of the following two is valid. If the IFF_BROADCAST + bit is set in `ifa_flags', then `ifa_broadaddr' is valid. If the + IFF_POINTOPOINT bit is set, then `ifa_dstaddr' is valid. + It is never the case that both these bits are set at once. */ + struct sockaddr *ifu_broadaddr; /* Broadcast address of this interface. */ + struct sockaddr *ifu_dstaddr; /* Point-to-point destination address. */ + } ifa_ifu; + /* These very same macros are defined by for `struct ifaddr'. + So if they are defined already, the existing definitions will be fine. */ +# ifndef ifa_broadaddr +# define ifa_broadaddr ifa_ifu.ifu_broadaddr +# endif +# ifndef ifa_dstaddr +# define ifa_dstaddr ifa_ifu.ifu_dstaddr +# endif + + void *ifa_data; /* Address-specific data (may be unused). */ +}; + + +/* Create a linked list of `struct ifaddrs' structures, one for each + network interface on the host machine. If successful, store the + list in *IFAP and return 0. On errors, return -1 and set `errno'. + + The storage returned in *IFAP is allocated dynamically and can + only be properly freed by passing it to `freeifaddrs'. */ +extern int getifaddrs (struct ifaddrs **__ifap) __THROW; + +/* Reclaim the storage allocated by a previous `getifaddrs' call. */ +extern void freeifaddrs (struct ifaddrs *__ifa) __THROW; + +__END_DECLS + +#endif /* ifaddrs.h */ diff -urN uClibc-org/libc/inet/Makefile.in uClibc/libc/inet/Makefile.in --- uClibc-org/libc/inet/Makefile.in 2008-03-11 11:59:12.429280000 +0100 +++ uClibc/libc/inet/Makefile.in 2008-03-11 12:53:58.933416000 +0100 @@ -9,7 +9,7 @@ CSRC := getservice.c getproto.c hostid.c getnetent.c getnetbynm.c getnetbyad.c \ inet_net.c ntop.c herror.c if_index.c gai_strerror.c getaddrinfo.c \ - in6_addr.c ether_addr.c ntohl.c opensock.c ifaddrs.c + in6_addr.c ether_addr.c ntohl.c opensock.c ifaddrs.c check_pf.c # multi source addr.c CSRC += inet_aton.c inet_addr.c inet_ntoa.c inet_makeaddr.c inet_lnaof.c \ diff -urN uClibc-org/libc/inet/netlinkaccess.h uClibc/libc/inet/netlinkaccess.h --- uClibc-org/libc/inet/netlinkaccess.h 2008-03-11 11:59:12.693149000 +0100 +++ uClibc/libc/inet/netlinkaccess.h 2008-03-11 12:53:59.066408000 +0100 @@ -61,13 +61,13 @@ }; -#if 0 /* unused code */ +#ifdef __UCLIBC_SUPPORT_AI_ADDRCONFIG__ #if __ASSUME_NETLINK_SUPPORT == 0 extern int __no_netlink_support attribute_hidden; #else # define __no_netlink_support 0 #endif -#endif /* unused code */ +#endif /* __UCLIBC_SUPPORT_AI_ADDRCONFIG__ */ extern int __netlink_open (struct netlink_handle *h) attribute_hidden; From mansoor.ahamed at ti.com Tue Mar 11 06:47:27 2008 From: mansoor.ahamed at ti.com (Basheer, Mansoor Ahamed) Date: Tue, 11 Mar 2008 19:17:27 +0530 Subject: mknod fails for major/minor number greater than 255 Message-ID: <010C7BAE6783F34D9AC336EE5A01A088057E4204@dbde01.ent.ti.com> Current mknod implementation fails for major/minor number greater than 255. I'm suggesting following change. Please comment. -Mansoor Signed-off-by: Mansoor Ahamed --- uClibc/libc/sysdeps/linux/common/mknod.c 2008-03-11 17:43:54.000000000 +0530 +++ uClibc-new/libc/sysdeps/linux/common/mknod.c 2008-03-11 17:45:21.000000000 +0530 @@ -20,9 +20,8 @@ static inline _syscall3(int, __syscall_m int mknod(const char *path, mode_t mode, dev_t dev) { /* We must convert the dev_t value to a __kernel_dev_t */ - __kernel_dev_t k_dev; + __kernel_dev_t k_dev = (__kernel_dev_t)dev; - k_dev = ((major(dev) & 0xff) << 8) | (minor(dev) & 0xff); return __syscall_mknod(path, mode, k_dev); } libc_hidden_def(mknod) From filippo.arcidiacono at st.com Tue Mar 11 09:37:16 2008 From: filippo.arcidiacono at st.com (Filippo ARCIDIACONO) Date: Tue, 11 Mar 2008 17:37:16 +0100 Subject: [PATCH] wprintf overflow In-Reply-To: Message-ID: <003501c88396$2b0bb620$838182a4@st.com> Hi, Your patch fix the problem when a wide character is in the format string, but there Are some problem if the wide char is in the format specifier. Have you any idea about this one? In my opinion your patch have to be the follow (just to be in synch with the latest version of the thrunk): --- uClibc-nptl-new/libc/stdio/_vfprintf.c 2008-03-11 17:22:16.590005000 +0100 +++ uClibc-nptl-SVN-thrunk/libc/stdio/_vfprintf.c 2008-02-07 08:04:14.400000000 +0100 @@ -896,8 +896,7 @@ int attribute_hidden _ppfs_parsespec(ppf if ((buf[i] = (char) (((wchar_t *) ppfs->fmtpos)[i-1])) != (((wchar_t *) ppfs->fmtpos)[i-1]) ) { - buf[i] = 0; - break; + return -1; } } while (buf[i++] && (i < sizeof(buf))); buf[sizeof(buf)-1] = 0; > -----Original Message----- > From: uclibc-bounces at uclibc.org > [mailto:uclibc-bounces at uclibc.org] On Behalf Of Kevin Cernekee > Sent: Tuesday, February 26, 2008 6:46 AM > To: Carmelo AMOROSO > Cc: uclibc at uclibc.org > Subject: Re: [PATCH] wprintf overflow > > > On Thu, 7 Feb 2008, Carmelo AMOROSO wrote: > > > The fix I committed I think it's better... because solve the stack > > overflow but keep the check against higher character. > > I tested it and it works. Let me know your comments. > > Hi, > > One of the concerns I had with that loop is that it always > aborts the parser if it trips on a "wider" character during > the copy, even if it wasn't part of the format specifier. > For instance: > > wprintf(L"%d %d %d \x0101\n", 1, 2, 3); > > I don't know if this is a problem in real life, but I erred > on the side of caution and wound up using this fix: > > --- uClibc-nptl-0.9.29-20070423.orig/libc/stdio/_vfprintf.c > 2006-06-19 19:32:05.000000000 -0700 > +++ uClibc-nptl-0.9.29-20070423/libc/stdio/_vfprintf.c > 2008-01-16 15:18:19.000000000 -0800 > @@ -893,10 +893,13 @@ > fmt = buf + 1; > i = 0; > do { > + if(i == sizeof(buf)) > + break; > if ((buf[i] = (char) (((wchar_t *) > ppfs->fmtpos)[i-1])) > != (((wchar_t *) ppfs->fmtpos)[i-1]) > ) { > - return -1; > + buf[i] = 0; > + break; > } > } while (buf[i++]); > buf[sizeof(buf)-1] = 0; > _______________________________________________ > uClibc mailing list > uClibc at uclibc.org > http://busybox.net/cgi-bin/mailman/listinfo/uclibc > From lsjunk1 at cableone.net Tue Mar 11 14:40:54 2008 From: lsjunk1 at cableone.net (Lance Spaulding) Date: Tue, 11 Mar 2008 15:40:54 -0600 Subject: uClibc Digest, Vol 32, Issue 8 In-Reply-To: References: Message-ID: <47D6FC66.4040006@cableone.net> uclibc-request at uclibc.org wrote: > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 8 Mar 2008 13:04:21 -0800 > From: Khem Raj > Subject: Re: help : mutex sharing between processes > To: vibi_sreenivasan at cms.com > Cc: uclibc at uclibc.org > Message-ID: > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > > On Mar 8, 2008, at 6:16 AM, vibi wrote: > > >> hello, >> i am trying to use sharing of mutex between processes on linux. >> i am using functions pthread_mutexattr_init followed by >> pthread_mutexattr_setpshared . >> >> in pc (kernel = 2.6.22.1,libpthread-2.5.so) it is running ok. >> but in arm-linux (kernel = 2.6.23.9, >> libuClibc-0.9.28.so,libpthread-0.9.28.so ) >> i am getting error for pthread_mutexattr_setpshared function. >> >> > > I dont think linuxthreads in uclibc has this. You can use uclibc-nptl > branch currently for sh/mips > or you can try buildroot to get arm nptl which should have the process > shared mutexes. > > > -Khem > > Hi Khem, I'm also in need of process-shared semaphores but on an x86 platform. Is there a branch with NPTL support for x86 somewhere? If so, do you have a pointer? Thanks in advance, Lance From charlie.xiang at asokausa.com Tue Mar 11 19:29:56 2008 From: charlie.xiang at asokausa.com (Charlie Xiang) Date: Tue, 11 Mar 2008 19:29:56 -0700 Subject: Help me , Support IPV6 API? Message-ID: Hi? I have enable the option of IPV6 such as following make menuconfig Networking Support IP version 6 Support I can see the IPV6 information in the file of /proc/net/,and can ping it from other pc with ipv6 address, but I Can't see the ipaddress information of IPV6 format with command of ifconfig , So I rebuild the source code of ifconfig and ping6, I found some API such as inet_pton() and gethostbyname can't work ? So I wander whether uclibc-0.9.19 support IPV6 API? How can make API of IPV6 work well? Thanks && Best Regards! Charlie(??) 2008-03-12 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/uclibc/attachments/20080311/eb07fed7/attachment.htm From mansoor.ahamed at ti.com Tue Mar 11 23:03:00 2008 From: mansoor.ahamed at ti.com (Basheer, Mansoor Ahamed) Date: Wed, 12 Mar 2008 11:33:00 +0530 Subject: [PATCH] mknod fix for major/minor number greater than 255 Message-ID: <010C7BAE6783F34D9AC336EE5A01A08805853E13@dbde01.ent.ti.com> Hi, Current mknod implementation fails for major/minor number greater than 255. I'm suggesting following change. Please comment. -Mansoor Signed-off-by: Mansoor Ahamed --- libc/sysdeps/linux/common/mknod.c 2008-03-11 17:43:54.000000000 +0530 +++ libc/sysdeps/linux/common/mknod.c 2008-03-11 17:45:21.000000000 +0530 @@ -20,9 +20,8 @@ static inline _syscall3(int, __syscall_m int mknod(const char *path, mode_t mode, dev_t dev) { /* We must convert the dev_t value to a __kernel_dev_t */ - __kernel_dev_t k_dev; + __kernel_dev_t k_dev = (__kernel_dev_t)dev; - k_dev = ((major(dev) & 0xff) << 8) | (minor(dev) & 0xff); return __syscall_mknod(path, mode, k_dev); } libc_hidden_def(mknod) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/uclibc/attachments/20080312/7bc696ae/attachment.htm From mansoor.ahamed at gmail.com Tue Mar 11 23:27:24 2008 From: mansoor.ahamed at gmail.com (Basheer Mansoor Ahamed) Date: Wed, 12 Mar 2008 11:57:24 +0530 Subject: [PATCH] mknod fix for major/minor number greater than 255 In-Reply-To: <8b0871980803112324o2154790vc72c26cf5b529eb6@mail.gmail.com> References: <010C7BAE6783F34D9AC336EE5A01A08805853E13@dbde01.ent.ti.com> <8b0871980803112324o2154790vc72c26cf5b529eb6@mail.gmail.com> Message-ID: <8b0871980803112327k2d3f8089m5bcd746e8b86d816@mail.gmail.com> Hi, Resending message (my outlook settings corrupts inline patch) from gmail account. Current mknod implementation fails for major/minor number greater than 255. I'm suggesting following change. Please comment. -Mansoor Signed-off-by: Mansoor Ahamed --- libc/sysdeps/linux/common/mknod.c 2008-03-11 17:43:54.000000000 +0530 +++ libc/sysdeps/linux/common/mknod.c 2008-03-11 17:45:21.000000000 +0530 @@ -20,9 +20,8 @@ static inline _syscall3(int, __syscall_m int mknod(const char *path, mode_t mode, dev_t dev) { /* We must convert the dev_t value to a __kernel_dev_t */ - __kernel_dev_t k_dev; + __kernel_dev_t k_dev = (__kernel_dev_t)dev; - k_dev = ((major(dev) & 0xff) << 8) | (minor(dev) & 0xff); return __syscall_mknod(path, mode, k_dev); } libc_hidden_def(mknod) From kraj at mvista.com Tue Mar 11 23:34:46 2008 From: kraj at mvista.com (Khem Raj) Date: Tue, 11 Mar 2008 23:34:46 -0700 Subject: [PATCH] mknod fix for major/minor number greater than 255 In-Reply-To: <010C7BAE6783F34D9AC336EE5A01A08805853E13@dbde01.ent.ti.com> References: <010C7BAE6783F34D9AC336EE5A01A08805853E13@dbde01.ent.ti.com> Message-ID: <1B51C7F4-3249-4E6A-A292-900B8E11D5CC@mvista.com> On Mar 11, 2008, at 11:03 PM, Basheer, Mansoor Ahamed wrote: > Hi, > > Current mknod implementation fails for major/minor number greater > than 255. is linux kernel supporting major/minor numbers greater than 255 ? > > I'm suggesting following change. Please comment. > > -Mansoor > > Signed-off-by: Mansoor Ahamed > > --- libc/sysdeps/linux/common/mknod.c 2008-03-11 17:43:54.000000000 > +0530 > +++ libc/sysdeps/linux/common/mknod.c 2008-03-11 17:45:21.000000000 > +0530 > @@ -20,9 +20,8 @@ static inline _syscall3(int, __syscall_m int > mknod(const char *path, mode_t mode, dev_t dev) { > /* We must convert the dev_t value to a __kernel_dev_t */ > - __kernel_dev_t k_dev; > + __kernel_dev_t k_dev = (__kernel_dev_t)dev; > > - k_dev = ((major(dev) & 0xff) << 8) | (minor(dev) & 0xff); > return __syscall_mknod(path, mode, k_dev); } > libc_hidden_def(mknod) > > _______________________________________________ > uClibc mailing list > uClibc at uclibc.org > http://busybox.net/cgi-bin/mailman/listinfo/uclibc Khem Raj MontaVista -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/uclibc/attachments/20080311/b0e0b547/attachment-0001.htm From rpjday at crashcourse.ca Tue Mar 11 23:41:15 2008 From: rpjday at crashcourse.ca (Robert P. J. Day) Date: Wed, 12 Mar 2008 02:41:15 -0400 (EDT) Subject: [PATCH] mknod fix for major/minor number greater than 255 In-Reply-To: <1B51C7F4-3249-4E6A-A292-900B8E11D5CC@mvista.com> References: <010C7BAE6783F34D9AC336EE5A01A08805853E13@dbde01.ent.ti.com> <1B51C7F4-3249-4E6A-A292-900B8E11D5CC@mvista.com> Message-ID: On Tue, 11 Mar 2008, Khem Raj wrote: > > On Mar 11, 2008, at 11:03 PM, Basheer, Mansoor Ahamed wrote: > > > Hi, > > > > Current mknod implementation fails for major/minor number greater than 255. > > is linux kernel supporting major/minor numbers greater than 255 ? the *kernel* supports major/minor numbers of bit length (12,20). it's only userspace that restricts their values to (8,8). rday -- ======================================================================== Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA ======================================================================== From mansoor.ahamed at ti.com Tue Mar 11 23:56:44 2008 From: mansoor.ahamed at ti.com (Basheer, Mansoor Ahamed) Date: Wed, 12 Mar 2008 12:26:44 +0530 Subject: [PATCH] mknod fix for major/minor number greater than 255 In-Reply-To: Message-ID: <010C7BAE6783F34D9AC336EE5A01A08805853E72@dbde01.ent.ti.com> Robert Wrote [mailto:rpjday at crashcourse.ca] > > On Tue, 11 Mar 2008, Khem Raj wrote: > > > > > On Mar 11, 2008, at 11:03 PM, Basheer, Mansoor Ahamed wrote: > > > > > Hi, > > > > > > Current mknod implementation fails for major/minor number greater than > 255. > > > > is linux kernel supporting major/minor numbers greater than 255 ? > > the *kernel* supports major/minor numbers of bit length (12,20). it's > only userspace that restricts their values to (8,8). > Yes Robert you are right. For example USB endpoint devices use major 442 (drivers/usb/core/endpoint.c). Also, __kernel_dev_t for ARM should be "unsigned int" and not "unsigned short". Signed-off-by: Mansoor Ahamed --- libc/sysdeps/linux/common/mknod.c 2008-03-11 17:43:54.000000000 +0530 +++ libc/sysdeps/linux/common/mknod.c 2008-03-11 17:45:21.000000000 +++ +0530 @@ -20,9 +20,8 @@ static inline _syscall3(int, __syscall_m int mknod(const char *path, mode_t mode, dev_t dev) { /* We must convert the dev_t value to a __kernel_dev_t */ - __kernel_dev_t k_dev; + __kernel_dev_t k_dev = (__kernel_dev_t)dev; - k_dev = ((major(dev) & 0xff) << 8) | (minor(dev) & 0xff); return __syscall_mknod(path, mode, k_dev); } libc_hidden_def(mknod) --- libc/sysdeps/linux/arm/bits/kernel_types.h +++ libc/sysdeps/linux/arm/bits/kernel_types.h @@ -7,7 +7,7 @@ #ifndef __ARCH_ARM_POSIX_TYPES_H #define __ARCH_ARM_POSIX_TYPES_H -typedef unsigned short __kernel_dev_t; +typedef unsigned int __kernel_dev_t; typedef unsigned long __kernel_ino_t; typedef unsigned short __kernel_mode_t; typedef unsigned short __kernel_nlink_t; @@ -31,7 +31,7 @@ typedef unsigned short __kernel_old_uid_t; typedef unsigned short __kernel_old_gid_t; typedef long long __kernel_loff_t; -typedef __kernel_dev_t __kernel_old_dev_t; +typedef unsigned short __kernel_old_dev_t; typedef struct { #ifdef __USE_ALL -Mansoor From kraj at mvista.com Wed Mar 12 00:22:23 2008 From: kraj at mvista.com (Khem Raj) Date: Wed, 12 Mar 2008 00:22:23 -0700 Subject: [PATCH] mknod fix for major/minor number greater than 255 In-Reply-To: <010C7BAE6783F34D9AC336EE5A01A08805853E72@dbde01.ent.ti.com> References: <010C7BAE6783F34D9AC336EE5A01A08805853E72@dbde01.ent.ti.com> Message-ID: <4E3616CF-5E9F-4DF2-998F-49ACA6DF3F17@mvista.com> On Mar 11, 2008, at 11:56 PM, Basheer, Mansoor Ahamed wrote: > > > Robert Wrote [mailto:rpjday at crashcourse.ca] >> >> On Tue, 11 Mar 2008, Khem Raj wrote: >> >>> >>> On Mar 11, 2008, at 11:03 PM, Basheer, Mansoor Ahamed wrote: >>> >>>> Hi, >>>> >>>> Current mknod implementation fails for major/minor number greater > than >> 255. >>> >>> is linux kernel supporting major/minor numbers greater than 255 ? >> >> the *kernel* supports major/minor numbers of bit length (12,20). >> it's >> only userspace that restricts their values to (8,8). >> > > Yes Robert you are right. For example USB endpoint devices use major > 442 > (drivers/usb/core/endpoint.c). > > > Also, __kernel_dev_t for ARM should be "unsigned int" and not > "unsigned > short". > > Signed-off-by: Mansoor Ahamed > > --- libc/sysdeps/linux/common/mknod.c 2008-03-11 17:43:54.000000000 > +0530 > +++ libc/sysdeps/linux/common/mknod.c 2008-03-11 17:45:21.000000000 > +++ +0530 > @@ -20,9 +20,8 @@ static inline _syscall3(int, __syscall_m int > mknod(const char *path, mode_t mode, dev_t dev) { > /* We must convert the dev_t value to a __kernel_dev_t */ > - __kernel_dev_t k_dev; > + __kernel_dev_t k_dev = (__kernel_dev_t)dev; > > - k_dev = ((major(dev) & 0xff) << 8) | (minor(dev) & 0xff); > return __syscall_mknod(path, mode, k_dev); } > libc_hidden_def(mknod) OK. the change looks ok. A testcase would be good to have. > > > > > --- libc/sysdeps/linux/arm/bits/kernel_types.h > +++ libc/sysdeps/linux/arm/bits/kernel_types.h > @@ -7,7 +7,7 @@ > #ifndef __ARCH_ARM_POSIX_TYPES_H > #define __ARCH_ARM_POSIX_TYPES_H > > -typedef unsigned short __kernel_dev_t; > +typedef unsigned int __kernel_dev_t; > typedef unsigned long __kernel_ino_t; > typedef unsigned short __kernel_mode_t; > typedef unsigned short __kernel_nlink_t; > @@ -31,7 +31,7 @@ > typedef unsigned short __kernel_old_uid_t; > typedef unsigned short __kernel_old_gid_t; > typedef long long __kernel_loff_t; > -typedef __kernel_dev_t __kernel_old_dev_t; > +typedef unsigned short __kernel_old_dev_t; > This also looks ok. > typedef struct { > #ifdef __USE_ALL > > -Mansoor > Khem Raj MontaVista From mansoor.ahamed at ti.com Wed Mar 12 01:57:34 2008 From: mansoor.ahamed at ti.com (Basheer, Mansoor Ahamed) Date: Wed, 12 Mar 2008 14:27:34 +0530 Subject: [PATCH] mknod fix for major/minor number greater than 255 In-Reply-To: <4E3616CF-5E9F-4DF2-998F-49ACA6DF3F17@mvista.com> Message-ID: <010C7BAE6783F34D9AC336EE5A01A08805853F43@dbde01.ent.ti.com> Khem Raj wrote: > > On Mar 11, 2008, at 11:56 PM, Basheer, Mansoor Ahamed wrote: > > > > > > > Robert Wrote [mailto:rpjday at crashcourse.ca] > >> > >> On Tue, 11 Mar 2008, Khem Raj wrote: > >> > >>> > >>> On Mar 11, 2008, at 11:03 PM, Basheer, Mansoor Ahamed wrote: > >>> > >>>> Hi, > >>>> > >>>> Current mknod implementation fails for major/minor number greater > > than > >> 255. > >>> > >>> is linux kernel supporting major/minor numbers greater than 255 ? > >> > >> the *kernel* supports major/minor numbers of bit length (12,20). > >> it's > >> only userspace that restricts their values to (8,8). > >> > > > > Yes Robert you are right. For example USB endpoint devices use major > > 442 > > (drivers/usb/core/endpoint.c). > > > > > > > Also, __kernel_dev_t for ARM should be "unsigned int" and not > > "unsigned > > short". > > > > Signed-off-by: Mansoor Ahamed > > > > --- libc/sysdeps/linux/common/mknod.c 2008-03-11 17:43:54.000000000 > > +0530 > > +++ libc/sysdeps/linux/common/mknod.c 2008-03-11 17:45:21.000000000 > > +++ +0530 > > @@ -20,9 +20,8 @@ static inline _syscall3(int, __syscall_m int > > mknod(const char *path, mode_t mode, dev_t dev) { > > /* We must convert the dev_t value to a __kernel_dev_t */ > > - __kernel_dev_t k_dev; > > + __kernel_dev_t k_dev = (__kernel_dev_t)dev; > > > > - k_dev = ((major(dev) & 0xff) << 8) | (minor(dev) & 0xff); > > return __syscall_mknod(path, mode, k_dev); } > > libc_hidden_def(mknod) > > > OK. the change looks ok. A testcase would be good to have. > > > > > > > > > > > --- libc/sysdeps/linux/arm/bits/kernel_types.h > > +++ libc/sysdeps/linux/arm/bits/kernel_types.h > > @@ -7,7 +7,7 @@ > > #ifndef __ARCH_ARM_POSIX_TYPES_H > > #define __ARCH_ARM_POSIX_TYPES_H > > > > -typedef unsigned short __kernel_dev_t; > > +typedef unsigned int __kernel_dev_t; > > typedef unsigned long __kernel_ino_t; > > typedef unsigned short __kernel_mode_t; > > typedef unsigned short __kernel_nlink_t; > > @@ -31,7 +31,7 @@ > > typedef unsigned short __kernel_old_uid_t; > > typedef unsigned short __kernel_old_gid_t; > > typedef long long __kernel_loff_t; > > -typedef __kernel_dev_t __kernel_old_dev_t; > > +typedef unsigned short __kernel_old_dev_t; > > > > This also looks ok. > > > typedef struct { > > #ifdef __USE_ALL > > How do I provide the test application? I should register for svn developer access or attach the test application in an email? -Mansoor From filippo.arcidiacono at st.com Wed Mar 12 04:03:49 2008 From: filippo.arcidiacono at st.com (Filippo ARCIDIACONO) Date: Wed, 12 Mar 2008 12:03:49 +0100 Subject: [PATCH] wprintf overflow Message-ID: <005401c88430$c0fa1290$838182a4@st.com> Hi, Apologies, discard my previous patch (I inverted the old with new file in the diff command), consider the follow one: --- uClibc-nptl-SVN-thrunk/libc/stdio/_vfprintf.c 2008-02-07 08:04:14.400000000 +0100 +++ uClibc-nptl-new/libc/stdio/_vfprintf.c 2008-03-12 11:50:47.930003000 +0100 @@ -896,7 +896,8 @@ int attribute_hidden _ppfs_parsespec(ppf if ((buf[i] = (char) (((wchar_t *) ppfs->fmtpos)[i-1])) != (((wchar_t *) ppfs->fmtpos)[i-1]) ) { - return -1; + buf[i] = 0; + break; } } while (buf[i++] && (i < sizeof(buf))); buf[sizeof(buf)-1] = 0; > -----Original Message----- > From: filippo arcidiacono [mailto:filippo.arcidiacono at st.com] > Sent: Tuesday, March 11, 2008 5:37 PM > To: 'Kevin Cernekee'; 'Carmelo AMOROSO' > Cc: 'uclibc at uclibc.org' > Subject: RE: [PATCH] wprintf overflow > > Hi, > Your patch fix the problem when a wide character is in the > format string, but there Are some problem if the wide char is > in the format specifier. Have you any idea about this one? > In my opinion your patch have to be the follow (just to be in > synch with the latest version of the thrunk): > --- uClibc-nptl-new/libc/stdio/_vfprintf.c 2008-03-11 > 17:22:16.590005000 +0100 > +++ uClibc-nptl-SVN-thrunk/libc/stdio/_vfprintf.c > 2008-02-07 08:04:14.400000000 +0100 > @@ -896,8 +896,7 @@ int attribute_hidden _ppfs_parsespec(ppf > if ((buf[i] = (char) (((wchar_t *) > ppfs->fmtpos)[i-1])) > != (((wchar_t *) ppfs->fmtpos)[i-1]) > ) { > - buf[i] = 0; > - break; > + return -1; > } > } while (buf[i++] && (i < sizeof(buf))); > buf[sizeof(buf)-1] = 0; > > > -----Original Message----- > > From: uclibc-bounces at uclibc.org > > [mailto:uclibc-bounces at uclibc.org] On Behalf Of Kevin Cernekee > > Sent: Tuesday, February 26, 2008 6:46 AM > > To: Carmelo AMOROSO > > Cc: uclibc at uclibc.org > > Subject: Re: [PATCH] wprintf overflow > > > > > > On Thu, 7 Feb 2008, Carmelo AMOROSO wrote: > > > > > The fix I committed I think it's better... because solve > the stack > > > overflow but keep the check against higher character. > > > I tested it and it works. Let me know your comments. > > > > Hi, > > > > One of the concerns I had with that loop is that it always > aborts the > > parser if it trips on a "wider" character during the copy, > even if it > > wasn't part of the format specifier. > > For instance: > > > > wprintf(L"%d %d %d \x0101\n", 1, 2, 3); > > > > I don't know if this is a problem in real life, but I erred on the > > side of caution and wound up using this fix: > > > > --- uClibc-nptl-0.9.29-20070423.orig/libc/stdio/_vfprintf.c > > 2006-06-19 19:32:05.000000000 -0700 > > +++ uClibc-nptl-0.9.29-20070423/libc/stdio/_vfprintf.c > > 2008-01-16 15:18:19.000000000 -0800 > > @@ -893,10 +893,13 @@ > > fmt = buf + 1; > > i = 0; > > do { > > + if(i == sizeof(buf)) > > + break; > > if ((buf[i] = (char) (((wchar_t *) > > ppfs->fmtpos)[i-1])) > > != (((wchar_t *) ppfs->fmtpos)[i-1]) > > ) { > > - return -1; > > + buf[i] = 0; > > + break; > > } > > } while (buf[i++]); > > buf[sizeof(buf)-1] = 0; > > _______________________________________________ > > uClibc mailing list > > uClibc at uclibc.org > > http://busybox.net/cgi-bin/mailman/listinfo/uclibc > > > From Haresh_Eswari at Dell.com Wed Mar 12 04:29:15 2008 From: Haresh_Eswari at Dell.com (Haresh_Eswari at Dell.com) Date: Wed, 12 Mar 2008 16:59:15 +0530 Subject: need help on compiling uClibc 0.9.29 for mipsel platform Message-ID: <4112A5EBE8485449B6A0F7F0D12F48F12EE5C5@blrx3m14.blr.amer.dell.com> Hi, I was trying to build uClibc-0.9.29 for mipsel I gave command like make CROSS=mipsel-linux- I am getting following error mipsel-linux-ld : cannot open linker script file ldscripts/elf32btsmip.xsw : No such file or directory But i am able to see that file /2.6kernel/rootfs/mipsel-linux/lib/ldscripts/ How should i set the path for that? Thanks, Haresh E.L. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/uclibc/attachments/20080312/a52761ed/attachment.htm From carmelo.amoroso at st.com Wed Mar 12 06:10:12 2008 From: carmelo.amoroso at st.com (Carmelo AMOROSO) Date: Wed, 12 Mar 2008 14:10:12 +0100 Subject: need help on compiling uClibc 0.9.29 for mipsel platform In-Reply-To: <4112A5EBE8485449B6A0F7F0D12F48F12EE5C5@blrx3m14.blr.amer.dell.com> References: <4112A5EBE8485449B6A0F7F0D12F48F12EE5C5@blrx3m14.blr.amer.dell.com> Message-ID: <47D7D634.8010402@st.com> Haresh_Eswari at Dell.com wrote: > > Hi, > > I was trying to build uClibc-0.9.29 for mipsel > > I gave command like > > make CROSS=mipsel-linux- > > I am getting following error > > mipsel-linux-ld : cannot open linker script file > ldscripts/elf32btsmip.xsw : No such file or directory > > But i am able to see that file > > /2.6kernel/rootfs/mipsel-linux/lib/ldscripts/ > > > How should i set the path for that? > > Thanks, > Haresh E.L. > Where did you get the toolchain from ? I suspect it is a misconfiguration problem of the binutils (ld). You should check how it has been configured, in particular the values used for the configuration option --prefix, --libdir. Carmelo > > ------------------------------------------------------------------------ > > _______________________________________________ > uClibc mailing list > uClibc at uclibc.org > http://busybox.net/cgi-bin/mailman/listinfo/uclibc From sjhill at realitydiluted.com Wed Mar 12 06:51:25 2008 From: sjhill at realitydiluted.com (sjhill at realitydiluted.com) Date: Wed, 12 Mar 2008 08:51:25 -0500 Subject: need help on compiling uClibc 0.9.29 for mipsel platform In-Reply-To: <4112A5EBE8485449B6A0F7F0D12F48F12EE5C5@blrx3m14.blr.amer.dell.com> References: <4112A5EBE8485449B6A0F7F0D12F48F12EE5C5@blrx3m14.blr.amer.dell.com> Message-ID: <20080312135125.GA9955@real.realitydiluted.com> > mipsel-linux-ld : cannot open linker script file > ldscripts/elf32btsmip.xsw : No such file or directory > > But i am able to see that file > > /2.6kernel/rootfs/mipsel-linux/lib/ldscripts/ > > > How should i set the path for that? > This is a toolchain problem, not a uClibc problem. Where and how did you get your cross toolchain? From mansoor.ahamed at ti.com Wed Mar 12 07:05:10 2008 From: mansoor.ahamed at ti.com (Basheer, Mansoor Ahamed) Date: Wed, 12 Mar 2008 19:35:10 +0530 Subject: [PATCH] mknod fix for major/minor number greater than 255 In-Reply-To: <47D79E29.8030207@st.com> Message-ID: <010C7BAE6783F34D9AC336EE5A01A08805854132@dbde01.ent.ti.com> Basheer, Mansoor Ahamed wrote: > > Khem Raj wrote: > > > >> On Mar 11, 2008, at 11:56 PM, Basheer, Mansoor Ahamed wrote: > >> > >> > >>> Robert Wrote [mailto:rpjday at crashcourse.ca] > >>> > >>>> On Tue, 11 Mar 2008, Khem Raj wrote: > >>>> > >>>> > >>>>> On Mar 11, 2008, at 11:03 PM, Basheer, Mansoor Ahamed wrote: > >>>>> > >>>>> > >>>>>> Hi, > >>>>>> > >>>>>> Current mknod implementation fails for major/minor number greater > >>>>>> > >>> than > >>> > >>>> 255. > >>>> > >>>>> is linux kernel supporting major/minor numbers greater than 255 ? > >>>>> > >>>> the *kernel* supports major/minor numbers of bit length (12,20). > >>>> it's > >>>> only userspace that restricts their values to (8,8). > >>>> > >>>> > >>> Yes Robert you are right. For example USB endpoint devices use major > >>> 442 > >>> (drivers/usb/core/endpoint.c). > >>> > >>> Also, __kernel_dev_t for ARM should be "unsigned int" and not > >>> "unsigned > >>> short". > >>> > >>> Signed-off-by: Mansoor Ahamed > >>> > >>> --- libc/sysdeps/linux/common/mknod.c 2008-03-11 17:43:54.000000000 > >>> +0530 > >>> +++ libc/sysdeps/linux/common/mknod.c 2008-03-11 17:45:21.000000000 > >>> +++ +0530 > >>> @@ -20,9 +20,8 @@ static inline _syscall3(int, __syscall_m int > >>> mknod(const char *path, mode_t mode, dev_t dev) { > >>> /* We must convert the dev_t value to a __kernel_dev_t */ > >>> - __kernel_dev_t k_dev; > >>> + __kernel_dev_t k_dev = (__kernel_dev_t)dev; > >>> > >>> - k_dev = ((major(dev) & 0xff) << 8) | (minor(dev) & 0xff); > >>> return __syscall_mknod(path, mode, k_dev); } > >>> libc_hidden_def(mknod) > >>> > >> OK. the change looks ok. A testcase would be good to have. > >> > >> > >>> > >>> > >>> --- libc/sysdeps/linux/arm/bits/kernel_types.h > >>> +++ libc/sysdeps/linux/arm/bits/kernel_types.h > >>> @@ -7,7 +7,7 @@ > >>> #ifndef __ARCH_ARM_POSIX_TYPES_H > >>> #define __ARCH_ARM_POSIX_TYPES_H > >>> > >>> -typedef unsigned short __kernel_dev_t; > >>> +typedef unsigned int __kernel_dev_t; > >>> typedef unsigned long __kernel_ino_t; > >>> typedef unsigned short __kernel_mode_t; > >>> typedef unsigned short __kernel_nlink_t; > >>> @@ -31,7 +31,7 @@ > >>> typedef unsigned short __kernel_old_uid_t; > >>> typedef unsigned short __kernel_old_gid_t; > >>> typedef long long __kernel_loff_t; > >>> -typedef __kernel_dev_t __kernel_old_dev_t; > >>> +typedef unsigned short __kernel_old_dev_t; > >>> > >>> > >> This also looks ok. > >> > >> > >>> typedef struct { > >>> #ifdef __USE_ALL > >>> > >>> > > > > How do I provide the test application? I should register for svn > > developer access or attach the test application in an email? > > > > -Mansoor > > I have attached test application with this mail. -Mansoor -------------- next part -------------- A non-text attachment was scrubbed... Name: tst1-mknod.c Type: application/octet-stream Size: 1712 bytes Desc: tst1-mknod.c Url : http://busybox.net/lists/uclibc/attachments/20080312/48caa6ac/attachment-0001.obj From john.voltz at gmail.com Wed Mar 12 09:37:10 2008 From: john.voltz at gmail.com (John Voltz) Date: Wed, 12 Mar 2008 12:37:10 -0400 Subject: segfault in uClibc Message-ID: <46a136670803120937n46fccb15hc8f4d7b9a1d4a824@mail.gmail.com> Hi, I've been trying to get the blackbox window manager to work properly with uClibc 0.9.29 with no success. I had it working fine in the past with uClibc 0.9.28, now it segfaults during startup with 0.9.29. I noticed that if I delete the /usr/share/blackbox/styles directory, blackbox will run ok, but obviously it doesn't apply the colors and fonts and other niceness. Here is a stack trace from Eclipse using avr32 gdb: Thread [1] (Suspended: Signal 'SIGSEGV' received. Description: Segmentation fault.) 9 std::__unguarded_linear_insert<__gnu_cxx::__normal_iterator > >, std::string>() staging_dir/usr/avr32-linux-uclibc/include/c++/4.2.1/ext/atomicity.h:83 0x00018d46 8 std::__insertion_sort<__gnu_cxx::__normal_iterator > > >() staging_dir/usr/avr32-linux-uclibc/include/c++/4.2.1/bits/stl_algo.h:2352 0x00019a0a 7 std::__final_insertion_sort<__gnu_cxx::__normal_iterator > > >() staging_dir/usr/avr32-linux-uclibc/include/c++/4.2.1/bits/basic_string.h:234 0x00019bce 6 BScreen::parseMenuFile() blackbox-0.70.1/src/Screen.cc:444 0x00013d0c 5 BScreen::parseMenuFile() staging_dir/usr/avr32-linux-uclibc/include/c++/4.2.1/ext/atomicity.h:70 0x00013800 4 BScreen::InitMenu() staging_dir/usr/avr32-linux-uclibc/include/c++/4.2.1/bits/basic_string.h:288 0x00016328 3 BScreen() staging_dir/usr/avr32-linux-uclibc/include/c++/4.2.1/bits/basic_string.h:236 0x00017018 2 Blackbox() blackbox-0.70.1/src/blackbox.cc:370 0x00039cae 1 main() blackbox-0.70.1/src/main.cc:115 0x0003aa82 and here is the output from strace: open("/usr/share/blackbox/menu", O_RDONLY) = 4 ioctl(4, TCGETS, 0x7fe2beec) = -1 ENOTTY (Inappropriate ioctl for de) read(4, "# This is the default menu file "..., 4096) = 3213 stat("/usr/share/blackbox/styles", {st_mode=S_IFDIR|0775, st_size=4096, ...}) =0 open("/usr/share/blackbox/styles", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = 5 fstat(5, {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0 fcntl(5, F_SETFD, FD_CLOEXEC) = 0 getdents64(5, /* d_reclen == 0, problem here *//* 0 entries */, 4096) = 184 getdents64(5, /* 0 entries */, 4096) = 0 close(5) = 0 --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV +++ I'm not sure where to go from here, any debugging tips you folks can offer would be greatly appreciated. Thanks, John Voltz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/uclibc/attachments/20080312/c2ab98f5/attachment.htm From Haresh_Eswari at Dell.com Wed Mar 12 22:09:46 2008 From: Haresh_Eswari at Dell.com (Haresh_Eswari at Dell.com) Date: Thu, 13 Mar 2008 10:39:46 +0530 Subject: need help on compiling uClibc 0.9.29 for mipsel platform In-Reply-To: <20080312135125.GA9955@real.realitydiluted.com> References: <4112A5EBE8485449B6A0F7F0D12F48F12EE5C5@blrx3m14.blr.amer.dell.com> <20080312135125.GA9955@real.realitydiluted.com> Message-ID: <4112A5EBE8485449B6A0F7F0D12F48F12EE628@blrx3m14.blr.amer.dell.com> I am able to build this. I changed the path and it worked. -----Original Message----- From: sjhill at realitydiluted.com [mailto:sjhill at realitydiluted.com] Sent: Wednesday, March 12, 2008 7:21 PM To: L, Haresh Cc: uclibc at uclibc.org Subject: Re: need help on compiling uClibc 0.9.29 for mipsel platform > mipsel-linux-ld : cannot open linker script file > ldscripts/elf32btsmip.xsw : No such file or directory > > But i am able to see that file > > /2.6kernel/rootfs/mipsel-linux/lib/ldscripts/ > > > How should i set the path for that? > This is a toolchain problem, not a uClibc problem. Where and how did you get your cross toolchain? From hans-christian.egtvedt at atmel.com Wed Mar 12 23:36:57 2008 From: hans-christian.egtvedt at atmel.com (Hans-Christian Egtvedt) Date: Thu, 13 Mar 2008 07:36:57 +0100 Subject: segfault in uClibc In-Reply-To: <46a136670803120937n46fccb15hc8f4d7b9a1d4a824@mail.gmail.com> References: <46a136670803120937n46fccb15hc8f4d7b9a1d4a824@mail.gmail.com> Message-ID: <1205390217.6797.9.camel@localhost> On Wed, 2008-03-12 at 12:37 -0400, John Voltz wrote: > Hi, > > I've been trying to get the blackbox window manager to work properly > with uClibc 0.9.29 with no success. I had it working fine in the past > with uClibc 0.9.28, now it segfaults during startup with 0.9.29. I > noticed that if I delete the /usr/share/blackbox/styles directory, > blackbox will run ok, but obviously it doesn't apply the colors and > fonts and other niceness. Here is a stack trace from Eclipse using > avr32 gdb: > Which toolchain are you using, i.e. GCC and Binutils? -- With kind regards, Hans-Christian Egtvedt, Applications Engineer From hans-christian.egtvedt at atmel.com Thu Mar 13 03:28:26 2008 From: hans-christian.egtvedt at atmel.com (Hans-Christian Egtvedt) Date: Thu, 13 Mar 2008 11:28:26 +0100 Subject: segfault in uClibc In-Reply-To: <46a136670803130325g54cacf68n3974ac085ddf3d23@mail.gmail.com> References: <46a136670803120937n46fccb15hc8f4d7b9a1d4a824@mail.gmail.com> <1205390217.6797.9.camel@localhost> <46a136670803130325g54cacf68n3974ac085ddf3d23@mail.gmail.com> Message-ID: <1205404106.8626.0.camel@localhost> On Thu, 2008-03-13 at 06:25 -0400, John Voltz wrote: > Yes, the current versions of GCC and binutils using buildroot. > uClibc Buildroot? Buildroot fork for AVR32? I think the atmel-2.2 branch of the AVR32 fork might contain some fixes you could try out. -- With kind regards, Hans-Christian Egtvedt, Applications Engineer From john.voltz at gmail.com Thu Mar 13 03:25:26 2008 From: john.voltz at gmail.com (John Voltz) Date: Thu, 13 Mar 2008 06:25:26 -0400 Subject: segfault in uClibc In-Reply-To: <1205390217.6797.9.camel@localhost> References: <46a136670803120937n46fccb15hc8f4d7b9a1d4a824@mail.gmail.com> <1205390217.6797.9.camel@localhost> Message-ID: <46a136670803130325g54cacf68n3974ac085ddf3d23@mail.gmail.com> Yes, the current versions of GCC and binutils using buildroot. John On Thu, Mar 13, 2008 at 2:36 AM, Hans-Christian Egtvedt < hans-christian.egtvedt at atmel.com> wrote: > On Wed, 2008-03-12 at 12:37 -0400, John Voltz wrote: > > Hi, > > > > I've been trying to get the blackbox window manager to work properly > > with uClibc 0.9.29 with no success. I had it working fine in the past > > with uClibc 0.9.28, now it segfaults during startup with 0.9.29. I > > noticed that if I delete the /usr/share/blackbox/styles directory, > > blackbox will run ok, but obviously it doesn't apply the colors and > > fonts and other niceness. Here is a stack trace from Eclipse using > > avr32 gdb: > > > > Which toolchain are you using, i.e. GCC and Binutils? > > -- > With kind regards, > Hans-Christian Egtvedt, Applications Engineer > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/uclibc/attachments/20080313/64bc614b/attachment.htm From john.voltz at gmail.com Thu Mar 13 03:40:02 2008 From: john.voltz at gmail.com (John Voltz) Date: Thu, 13 Mar 2008 06:40:02 -0400 Subject: segfault in uClibc In-Reply-To: <1205404106.8626.0.camel@localhost> References: <46a136670803120937n46fccb15hc8f4d7b9a1d4a824@mail.gmail.com> <1205390217.6797.9.camel@localhost> <46a136670803130325g54cacf68n3974ac085ddf3d23@mail.gmail.com> <1205404106.8626.0.camel@localhost> Message-ID: <46a136670803130340n33324724ofcb81cd4ec460d95@mail.gmail.com> I've got the fork on Google code pretty much in sync with upstream now. How do I get access to the atmel-2.2 branch? I assume you are working in git? John On Thu, Mar 13, 2008 at 6:28 AM, Hans-Christian Egtvedt < hans-christian.egtvedt at atmel.com> wrote: > On Thu, 2008-03-13 at 06:25 -0400, John Voltz wrote: > > Yes, the current versions of GCC and binutils using buildroot. > > > > uClibc Buildroot? Buildroot fork for AVR32? > > I think the atmel-2.2 branch of the AVR32 fork might contain some fixes > you could try out. > > -- > With kind regards, > Hans-Christian Egtvedt, Applications Engineer > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/uclibc/attachments/20080313/e2926c9c/attachment.htm From hans-christian.egtvedt at atmel.com Thu Mar 13 04:16:15 2008 From: hans-christian.egtvedt at atmel.com (Hans-Christian Egtvedt) Date: Thu, 13 Mar 2008 12:16:15 +0100 Subject: segfault in uClibc In-Reply-To: <46a136670803130340n33324724ofcb81cd4ec460d95@mail.gmail.com> References: <46a136670803120937n46fccb15hc8f4d7b9a1d4a824@mail.gmail.com> <1205390217.6797.9.camel@localhost> <46a136670803130325g54cacf68n3974ac085ddf3d23@mail.gmail.com> <1205404106.8626.0.camel@localhost> <46a136670803130340n33324724ofcb81cd4ec460d95@mail.gmail.com> Message-ID: <1205406975.8626.3.camel@localhost> On Thu, 2008-03-13 at 06:40 -0400, John Voltz wrote: > I've got the fork on Google code pretty much in sync with upstream > now. How do I get access to the atmel-2.2 branch? I assume you are > working in git? > git-clone git://www.atmel.no/~hcegtvedt/buildroot/avr32.git and pull the atmel-2.2 branch afterwards. I am working on synchronizing with upstream as I type, but there was some conflicts here and there ;) I need to get in sync to make proper patches for upstream again. -- With kind regards, Hans-Christian Egtvedt, Applications Engineer From jpereiran at gmail.com Thu Mar 13 07:39:46 2008 From: jpereiran at gmail.com (Jorge Pereira) Date: Thu, 13 Mar 2008 11:39:46 -0300 Subject: mknod fails for major/minor number greater than 255 In-Reply-To: <010C7BAE6783F34D9AC336EE5A01A088057E4204@dbde01.ent.ti.com> References: <010C7BAE6783F34D9AC336EE5A01A088057E4204@dbde01.ent.ti.com> Message-ID: <5a0574590803130739q41aa5764g74ea7bded41a990f@mail.gmail.com> i agre, jjpn at campinho debug.main.x86$ grep __kernel_dev_t -n /usr/include/linux/types.h 10:typedef __u32 __kernel_dev_t; 13:typedef __kernel_dev_t dev_t; jjpn at campinho debug.main.x86$ this operation is very simple...i don't think other solution for this. []s On Tue, Mar 11, 2008 at 10:47 AM, Basheer, Mansoor Ahamed < mansoor.ahamed at ti.com> wrote: > Current mknod implementation fails for major/minor number greater than > 255. > > I'm suggesting following change. Please comment. > > -Mansoor > > Signed-off-by: Mansoor Ahamed > > --- uClibc/libc/sysdeps/linux/common/mknod.c 2008-03-11 > 17:43:54.000000000 +0530 > +++ uClibc-new/libc/sysdeps/linux/common/mknod.c