From filippo.arcidiacono at st.com Wed Apr 2 05:49:22 2008 From: filippo.arcidiacono at st.com (Filippo ARCIDIACONO) Date: Wed, 2 Apr 2008 14:49:22 +0200 Subject: utils/readelf built twice? In-Reply-To: <20080327103114.GA13234@mx.loc> Message-ID: <004101c894bf$fa334eb0$838182a4@st.com> > -----Original Message----- > From: uclibc-bounces at uclibc.org > [mailto:uclibc-bounces at uclibc.org] On Behalf Of Bernhard Fischer > Sent: Thursday, March 27, 2008 11:31 AM > To: Carmelo AMOROSO > Cc: uclibc at uclibc.org > Subject: Re: utils/readelf built twice? > > On Thu, Mar 27, 2008 at 08:06:21AM +0100, Carmelo AMOROSO wrote: > > Bernhard Fischer wrote: > >> Hi, > >> > >> Can anybody confirm that > >> make -C utils > >> builds readelf twice? No. The first one it is only the "echo" command output. That, further, is different from the compilation command. In my opinion there is something to fix. Perhaps, simply removing "@$(disp_compile.c)" call from the "compile.u" routine in Makerules file. The compilation command seems ok. > >> > >> thanks, > >> > > Hi, > > yes you're right !!! > > further, ldconfig the second time is linked with > chroot_realpath too. > > I think i improved the situation yesterday night. Please > holler if i broke something. > > utils/*.c now even build with our default CFLAGS, i.e. with > std=gnu99 Maybe i'll find the time to clean them up a little > bit so they do not throw so many warnings.. > > Thanks, Carmelo, for verifying this and cheers > _______________________________________________ > uClibc mailing list > uClibc at uclibc.org > http://busybox.net/cgi-bin/mailman/listinfo/uclibc > Regards, Filippo Arcidiacono. From rep.dot.nop at gmail.com Wed Apr 2 06:01:11 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Wed, 2 Apr 2008 15:01:11 +0200 Subject: utils/readelf built twice? In-Reply-To: <004101c894bf$fa334eb0$838182a4@st.com> References: <20080327103114.GA13234@mx.loc> <004101c894bf$fa334eb0$838182a4@st.com> Message-ID: <20080402130111.GC9436@mx.loc> On Wed, Apr 02, 2008 at 02:49:22PM +0200, Filippo ARCIDIACONO wrote: > > >> -----Original Message----- >> From: uclibc-bounces at uclibc.org >> [mailto:uclibc-bounces at uclibc.org] On Behalf Of Bernhard Fischer >> Sent: Thursday, March 27, 2008 11:31 AM >> To: Carmelo AMOROSO >> Cc: uclibc at uclibc.org >> Subject: Re: utils/readelf built twice? >> >> On Thu, Mar 27, 2008 at 08:06:21AM +0100, Carmelo AMOROSO wrote: >> > Bernhard Fischer wrote: >> >> Hi, >> >> >> >> Can anybody confirm that >> >> make -C utils >> >> builds readelf twice? >No. The first one it is only the "echo" command output. >That, further, is different from the compilation command. In my opinion >there is something to fix. >Perhaps, simply removing "@$(disp_compile.c)" call from the "compile.u" >routine in Makerules file. >The compilation command seems ok. What revision are you using? As mentioned below, i've since fixed this via ------------------------------------------------------------------------ r21505 | aldot | 2008-03-26 19:49:16 +0100 (Wed, 26 Mar 2008) | 5 lines - improve building utils Either by first compiling objects and linking those or by just passing the source to create the desired binary (this patchlet does the latter). Fixes cosmetic glitch by just not building individual .o (in pwd, at least). ------------------------------------------------------------------------ r21506 | aldot | 2008-03-26 20:40:39 +0100 (Wed, 26 Mar 2008) | 2 lines - fixup stripping of host utils and make host-utils compile with std=gnu99 thanks, >> >> >> >> thanks, >> >> >> > Hi, >> > yes you're right !!! >> > further, ldconfig the second time is linked with >> chroot_realpath too. >> >> I think i improved the situation yesterday night. Please >> holler if i broke something. >> >> utils/*.c now even build with our default CFLAGS, i.e. with >> std=gnu99 Maybe i'll find the time to clean them up a little >> bit so they do not throw so many warnings.. >> >> Thanks, Carmelo, for verifying this and cheers >> _______________________________________________ >> uClibc mailing list >> uClibc at uclibc.org >> http://busybox.net/cgi-bin/mailman/listinfo/uclibc >> > >Regards, > >Filippo Arcidiacono. > From filippo.arcidiacono at st.com Wed Apr 2 06:41:23 2008 From: filippo.arcidiacono at st.com (Filippo ARCIDIACONO) Date: Wed, 2 Apr 2008 15:41:23 +0200 Subject: utils/readelf built twice? In-Reply-To: <20080402130111.GC9436@mx.loc> Message-ID: <004501c894c7$3e22f420$838182a4@st.com> > -----Original Message----- > From: Bernhard Fischer [mailto:rep.dot.nop at gmail.com] > Sent: Wednesday, April 02, 2008 3:01 PM > To: Filippo ARCIDIACONO > Cc: 'Carmelo AMOROSO'; uclibc at uclibc.org > Subject: Re: utils/readelf built twice? > > On Wed, Apr 02, 2008 at 02:49:22PM +0200, Filippo ARCIDIACONO wrote: > > > > > >> -----Original Message----- > >> From: uclibc-bounces at uclibc.org > >> [mailto:uclibc-bounces at uclibc.org] On Behalf Of Bernhard Fischer > >> Sent: Thursday, March 27, 2008 11:31 AM > >> To: Carmelo AMOROSO > >> Cc: uclibc at uclibc.org > >> Subject: Re: utils/readelf built twice? > >> > >> On Thu, Mar 27, 2008 at 08:06:21AM +0100, Carmelo AMOROSO wrote: > >> > Bernhard Fischer wrote: > >> >> Hi, > >> >> > >> >> Can anybody confirm that > >> >> make -C utils > >> >> builds readelf twice? > >No. The first one it is only the "echo" command output. > >That, further, is different from the compilation command. In > my opinion > >there is something to fix. > >Perhaps, simply removing "@$(disp_compile.c)" call from the > "compile.u" > >routine in Makerules file. Looking the trunk tree, this issue has been fixed in the revision 21505. Then it seems ok for me. I don't understood why you had deleted the strip command. > >The compilation command seems ok. > > What revision are you using? I'm using the latest branch revision 17427. > As mentioned below, i've since fixed this via > > -------------------------------------------------------------- > ---------- > r21505 | aldot | 2008-03-26 19:49:16 +0100 (Wed, 26 Mar 2008) > | 5 lines > > - improve building utils > Either by first compiling objects and linking those or by > just passing > the source to create the desired binary (this patchlet does > the latter). > Fixes cosmetic glitch by just not building individual .o > (in pwd, at least). > > -------------------------------------------------------------- > ---------- > r21506 | aldot | 2008-03-26 20:40:39 +0100 (Wed, 26 Mar 2008) > | 2 lines > > - fixup stripping of host utils and make host-utils compile with > std=gnu99 > > thanks, > >> >> > >> >> thanks, > >> >> > >> > Hi, > >> > yes you're right !!! > >> > further, ldconfig the second time is linked with > >> chroot_realpath too. > >> > >> I think i improved the situation yesterday night. Please > holler if i > >> broke something. > >> > >> utils/*.c now even build with our default CFLAGS, i.e. with > >> std=gnu99 Maybe i'll find the time to clean them up a > little bit so > >> they do not throw so many warnings.. > >> > >> Thanks, Carmelo, for verifying this and cheers > >> _______________________________________________ > >> uClibc mailing list > >> uClibc at uclibc.org > >> http://busybox.net/cgi-bin/mailman/listinfo/uclibc > >> > > > >Regards, > > > >Filippo Arcidiacono. > > > Filippo. From vda.linux at googlemail.com Wed Apr 2 07:11:47 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Wed, 2 Apr 2008 16:11:47 +0200 Subject: [PATCH] decouple sprintf and fseek Message-ID: <200804021611.47231.vda.linux@googlemail.com> Hi guys, Can you please review and comment on this bug: http://busybox.net/bugs/view.php?id=2714 Although I technically can commit this change myself, I'd much prefer for it to be reviewed by people who actively work on uclubc codebase. The same patches are attached to this mail. Description: Use of [v]s[n]printf functions seems to pull a bit too much of stdio.h machinery. Only formatting routines are actually needed. For one, seek and write functions ideally should not be linked in. Seems like it can be improved in _vfprintf.c / old_vfprintf.c by factoring out "the core" of vprintf() into separate function (say, "vprintf_internal()"), so that: * vprintf() does locking and __STDIO_STREAM_TRANS_TO_WRITE thing, then calls vprintf_internal(); * vsnprintf, vdprintf.c, vasprintf.c all use vprintf_internal_unlocked() directly [and do not need to set up fake locking now] 2.patch implements this solution. 3.patch removes unneeded initialization of locking. If you are going to apply it, take a look at vsnprintf.c's comment about __bufputc - it seems to be bogus, AFAICS __bufputc initialization has nothing to do with __user_locking. (I did grep around). Signed-off-by: Denys Vlasenko -- vda -------------- next part -------------- A non-text attachment was scrubbed... Name: 2.patch Type: text/x-diff Size: 16000 bytes Desc: not available Url : http://busybox.net/lists/uclibc/attachments/20080402/03361b2e/attachment-0004.patch -------------- next part -------------- A non-text attachment was scrubbed... Name: 3.patch Type: text/x-diff Size: 2660 bytes Desc: not available Url : http://busybox.net/lists/uclibc/attachments/20080402/03361b2e/attachment-0005.patch -------------- next part -------------- A non-text attachment was scrubbed... Name: 2.patch Type: text/x-diff Size: 16000 bytes Desc: not available Url : http://busybox.net/lists/uclibc/attachments/20080402/03361b2e/attachment-0006.patch -------------- next part -------------- A non-text attachment was scrubbed... Name: 3.patch Type: text/x-diff Size: 2660 bytes Desc: not available Url : http://busybox.net/lists/uclibc/attachments/20080402/03361b2e/attachment-0007.patch From carmelo73 at gmail.com Wed Apr 2 14:07:59 2008 From: carmelo73 at gmail.com (Carmelo Amoroso) Date: Wed, 02 Apr 2008 23:07:59 +0200 Subject: [PATCH] Implement error_print_progname In-Reply-To: <87a5b0800803310456mb1415aes6f8bd78d232f9406@mail.gmail.com> References: <87a5b0800803200751u30f61a47s860b6886ee00c105@mail.gmail.com> <47E36819.1070702@gmail.com> <87a5b0800803210447x4d9814dfya153f1ecaacc641d@mail.gmail.com> <87a5b0800803310456mb1415aes6f8bd78d232f9406@mail.gmail.com> Message-ID: <47F3F5AF.1010404@gmail.com> Will Newton wrote: > On Fri, Mar 21, 2008 at 12:47 PM, Will Newton wrote: >> On Fri, Mar 21, 2008 at 7:47 AM, Carmelo Amoroso wrote: >> >> Hi Carmelo, >> >> >> > Will Newton wrote: >> > > Further to the changes to error.c to fix bug #1869 it would be nice if >> > > uClibc supported error_print_progname. The attached patch aims to do >> > > that. >> > > >> > > >> > >> > Hello, >> > this is an old story. uClibc doesn't provide support for error_print_progname >> > even if header error.h declare it. >> > I would like to have it implemented before using. If we know that it's missing, >> > while testing for its value and call it ? >> > This my opinion. >> >> I know, I've been subscribed to this list some time and I have read >> the archives. >> >> As I understand it error_print_progname is a global that is intended >> to be assigned by the user, that is how the interface is intended to >> be used: >> >> "If the global variable error_print_progname is assigned the address >> of a function (i.e., is not NULL), then that function is called >> instead of prefixing the message with the program name and colon. The >> function should print a suitable string to stderr. " >> >> And I think my patch implements that. >> >> error.h is a GNU interface and dropping one part of it >> (error_print_progname) seems to be unnecessarily incompatible. Better >> to remove error.h completely than implement 95% of it, at least then >> e.g. gnulib can be used as a replacement. >> > > Ping! > > Does anyone have any objections to this patch? I'll be happy to > incorporate any improvements people can suggest. > > Thanks, > Hi Will, honestly speaking I did not understand the fact that error_print_progname should be assigned to a user function. Now reading the comment again I'm convinced about that, and yes, your patch looks fine to me. Does anybody have concerns about ? otherwise it can be committed. Carmelo From will.newton at gmail.com Thu Apr 3 04:20:51 2008 From: will.newton at gmail.com (Will Newton) Date: Thu, 3 Apr 2008 12:20:51 +0100 Subject: uclibc segfault in ldso In-Reply-To: <1206722541.3224.58.camel@nigel-x60> References: <1206537761.3605.250.camel@nigel-x60> <1206640602.3605.429.camel@nigel-x60> <1206644186.7589.317.camel@gentoo-jocke.transmode.se> <1206646199.3605.457.camel@nigel-x60> <1206647470.3605.463.camel@nigel-x60> <1206656263.3605.470.camel@nigel-x60> <1206692400.7589.326.camel@gentoo-jocke.transmode.se> <1206720248.3224.51.camel@nigel-x60> <47ED1DBE.9050300@gmail.com> <1206722541.3224.58.camel@nigel-x60> Message-ID: <87a5b0800804030420h6f7982a6s5d6d1f2b422f0ae6@mail.gmail.com> On Fri, Mar 28, 2008 at 5:42 PM, Nigel Kukard wrote: > Yo, > > > > >> Can't see anything, I think you should add printouts in __uClibc_init() > > >> to see if you get there, use the write() sys call as I don't think you > > >> can use any of the libc print functions. > > >> > > >> Non PIE rpm works I guess? > > >> Does rpm work in glibc, both PIE and non PIE? > > >> > > >> Jocke > > > > > > > > > > > > _malloc:921: mmapping more memory > > > _dl_get_ready_to_run:748: Beginning relocation fixups > > > here: 001 > > > here: 002 > > > here: 025 > > > here: 026 > > > Segmentation fault > > > > > > Looks like its choking on pthreads? > > > > > Hi, > > > > I've seen that your are not using the stable linuxthread.old implementation. > > I'd suggest you to rebuild uclibc using linuxthread.old. > > I'm not sure how stable/tested is the linuxthreads (TLS support). > > Dead center Carmelo!!! enabling old pthreads worked. > > Should I debug this further or just work with the old implementation? Hi Nigel, Does the attached patch fix the issue? -------------- next part -------------- A non-text attachment was scrubbed... Name: linuxthreads-new.patch Type: text/x-diff Size: 449 bytes Desc: not available Url : http://busybox.net/lists/uclibc/attachments/20080403/f75f40e7/attachment.patch From abhijitayarekar at gmail.com Thu Apr 3 13:12:27 2008 From: abhijitayarekar at gmail.com (abhijit ayarekar) Date: Thu, 3 Apr 2008 13:12:27 -0700 Subject: Problems in compiling for mips Message-ID: <1ffdbf640804031312y57c17423r5514e99711a6625d@mail.gmail.com> I am trying to compile uclibc-0.9.26 with binutils-2.15, gcc-3.3.3, kernel headers version 2.4.27 when i run make i get the following error [root at shastabuild uClibc-0.9.26]# make CROSS=mips-linux- + ./extra/scripts/fix_includes.sh -k /mnt/hdb/mips-toolchain/kernel/linux-kernel-2.4 -t mips Current kernel version is 2.4.27-ubnt0 Using kernel headers from 2.4.27-ubnt0 for architecture 'mips' provided in directory /mnt/hdb/mips-toolchain/kernel/linux-kernel-2.4 + TOPDIR=. + CC=mips-linux-gcc + /bin/sh extra/scripts/gen_bits_syscall_h.sh + cmp include/bits/sysnum.h include/bits/sysnum.h.new + mv -f include/bits/sysnum.h.new include/bits/sysnum.h make -C libc/sysdeps/linux/common headers make[1]: Entering directory `/mnt/hdb/mips-toolchain/sources/uClibc-0.9.26/libc/sysdeps/linux/common' ln -fs ../libc/sysdeps/linux/common/fpu_control.h ../../../..//include/ make[1]: Leaving directory `/mnt/hdb/mips-toolchain/sources/uClibc-0.9.26/libc/sysdeps/linux/common' make -C libc/sysdeps/linux/mips headers make[1]: Entering directory `/mnt/hdb/mips-toolchain/sources/uClibc-0.9.26/libc/sysdeps/linux/mips' ln -fs ../libc/sysdeps/linux/mips/sgidefs.h ../../../..//include/ ln -fs ../libc/sysdeps/linux/mips/fpu_control.h ../../../..//include/ make[1]: Leaving directory `/mnt/hdb/mips-toolchain/sources/uClibc-0.9.26/libc/sysdeps/linux/mips' make -C ldso make[1]: Entering directory `/mnt/hdb/mips-toolchain/sources/uClibc-0.9.26/ldso' ln -fs ../../include/elf.h include/ ln -fs ../ldso/mips/boot1_arch.h include/ ln -fs ../ldso/mips/ld_syscalls.h include/ ln -fs ../ldso/mips/ld_sysdep.h include/ make -C ldso; make[2]: Entering directory `/mnt/hdb/mips-toolchain/sources/uClibc-0.9.26/ldso/ldso' mips-linux-gcc -Wall -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -Os -mno-split-addresses -mips32 -mtune=mips32 -fPIC -DUCLIBC_RUNTIME_PREFIX=\"/mnt/hdb/mips-toolchain/mips-linux/\" -fno-builtin -nostdinc -I../../ldso/include -I. -I../../include -I/mnt/hdb/mips-toolchain/lib/gcc-lib/mips-linux/3.3.3/include -I../libdl -c ldso.c -o ldso.o In file included from _dl_progname.h:2, from ldso.c:156: mips/elfinterp.c: In function `_dl_parse_relocation_information': mips/elfinterp.c:177: warning: unused variable `old_val' ldso.c: In function `_dl_boot2': ldso.c:362: error: `PAGE_SIZE' undeclared (first use in this function) ldso.c:362: error: (Each undeclared identifier is reported only once ldso.c:362: error: for each function it appears in.) ldso.c:454:2: warning: #warning "Debugging threads on mips won't work till someone fixes this..." ../../ldso/include/ld_syscall.h:56: warning: use of memory input without lvalue in asm operand 7 is deprecated In file included from ldso.c:1343: readelflib1.c: In function `_dl_load_elf_shared_library': readelflib1.c:452: error: `PAGE_SIZE' undeclared (first use in this function) In file included from ldso.c:1343: ../../ldso/include/ld_syscall.h:56: warning: use of memory input without lvalue in asm operand 7 is deprecated ../../ldso/include/ld_syscall.h:56: warning: use of memory input without lvalue in asm operand 7 is deprecated ../../ldso/include/ld_syscall.h:56: warning: use of memory input without lvalue in asm operand 7 is deprecated ../../ldso/include/ld_syscall.h:56: warning: use of memory input without lvalue in asm operand 7 is deprecated ../../ldso/include/ld_syscall.h:56: warning: use of memory input without lvalue in asm operand 7 is deprecated readelflib1.c: In function `_dl_dprintf': readelflib1.c:787: error: `PAGE_SIZE' undeclared (first use in this function) In file included from ldso.c:1343: ../../ldso/include/ld_syscall.h:56: warning: use of memory input without lvalue in asm operand 7 is deprecated In file included from ldso.c:1343: readelflib1.c: In function `_dl_malloc': readelflib1.c:886: error: `PAGE_SIZE' undeclared (first use in this function) In file included from ldso.c:1343: ../../ldso/include/ld_syscall.h:56: warning: use of memory input without lvalue in asm operand 7 is deprecated ../../ldso/include/ld_syscall.h: In function `_dl_mmap': ../../ldso/include/ld_syscall.h:56: warning: use of memory input without lvalue in asm operand 7 is deprecated make[2]: *** [ldso.o] Error 1 make[2]: Leaving directory `/mnt/hdb/mips-toolchain/sources/uClibc-0.9.26/ldso/ldso' make[1]: *** [all] Error 2 make[1]: Leaving directory `/mnt/hdb/mips-toolchain/sources/uClibc-0.9.26/ldso' make: *** [_dir_ldso] Error 2 can anyone please help me solve this problem? regards abhijit -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/uclibc/attachments/20080403/140921d3/attachment.htm From filippo.arcidiacono at st.com Fri Apr 4 00:37:54 2008 From: filippo.arcidiacono at st.com (Filippo ARCIDIACONO) Date: Fri, 4 Apr 2008 09:37:54 +0200 Subject: Problems in compiling for mips In-Reply-To: <1ffdbf640804031312y57c17423r5514e99711a6625d@mail.gmail.com> Message-ID: <005b01c89626$cbf76190$838182a4@st.com> I suggest you to upgrade the uClibc to the 0.9.29 version. > -----Original Message----- > From: uclibc-bounces at uclibc.org > [mailto:uclibc-bounces at uclibc.org] On Behalf Of abhijit ayarekar > Sent: Thursday, April 03, 2008 10:12 PM > To: uclibc at uclibc.org > Subject: Problems in compiling for mips > > I am trying to compile uclibc-0.9.26 with binutils-2.15, > gcc-3.3.3, kernel headers version 2.4.27 > > when i run make i get the following error > > [root at shastabuild uClibc-0.9.26]# make CROSS=mips-linux- > + ./extra/scripts/fix_includes.sh -k > + /mnt/hdb/mips-toolchain/kernel/linux-kernel-2.4 -t mips > Current kernel version is 2.4.27-ubnt0 > > Using kernel headers from 2.4.27-ubnt0 for architecture 'mips' > provided in directory > /mnt/hdb/mips-toolchain/kernel/linux-kernel-2.4 > > + TOPDIR=. > + CC=mips-linux-gcc > + /bin/sh extra/scripts/gen_bits_syscall_h.sh > + cmp include/bits/sysnum.h include/bits/sysnum.h.new mv -f > + include/bits/sysnum.h.new include/bits/sysnum.h > make -C libc/sysdeps/linux/common headers > make[1]: Entering directory > `/mnt/hdb/mips-toolchain/sources/uClibc-0.9.26/libc/sysdeps/li nux/common' > ln -fs ../libc/sysdeps/linux/common/fpu_control.h > ../../../..//include/ > make[1]: Leaving directory > `/mnt/hdb/mips-toolchain/sources/uClibc-0.9.26/libc/sysdeps/li nux/common' > make -C libc/sysdeps/linux/mips headers > make[1]: Entering directory > `/mnt/hdb/mips-toolchain/sources/uClibc-0.9.26/libc/sysdeps/li nux/mips' > ln -fs ../libc/sysdeps/linux/mips/sgidefs.h > ../../../..//include/ ln -fs > ../libc/sysdeps/linux/mips/fpu_control.h ../../../..//include/ > make[1]: Leaving directory > `/mnt/hdb/mips-toolchain/sources/uClibc-0.9.26/libc/sysdeps/li nux/mips' > make -C ldso > make[1]: Entering directory > `/mnt/hdb/mips-toolchain/sources/uClibc-0.9.26/ldso' > ln -fs ../../include/elf.h include/ > ln -fs ../ldso/mips/boot1_arch.h include/ ln -fs > ../ldso/mips/ld_syscalls.h include/ ln -fs > ../ldso/mips/ld_sysdep.h include/ make -C ldso; > make[2]: Entering directory > `/mnt/hdb/mips-toolchain/sources/uClibc-0.9.26/ldso/ldso' > mips-linux-gcc -Wall -Wstrict-prototypes -Wno-trigraphs > -fno-strict-aliasing -Os -mno-split-addresses -mips32 > -mtune=mips32 -fPIC > -DUCLIBC_RUNTIME_PREFIX=\"/mnt/hdb/mips-toolchain/mips-linux/\ " -fno-builtin -nostdinc -I../../ldso/include -I. -> I../../include > -I/mnt/hdb/mips-toolchain/lib/gcc-lib/mips-linux/3.3.3/include > -I../libdl -c ldso.c -o ldso.o In file included from > _dl_progname.h:2, > from ldso.c:156: > mips/elfinterp.c: In function `_dl_parse_relocation_information': > mips/elfinterp.c:177: warning: unused variable `old_val' > ldso.c: In function `_dl_boot2': > ldso.c:362: error: `PAGE_SIZE' undeclared (first use in this function) > ldso.c:362: error: (Each undeclared identifier is reported only once > ldso.c:362: error: for each function it appears in.) > ldso.c:454:2: warning: #warning "Debugging threads on mips > won't work till someone fixes this..." > ../../ldso/include/ld_syscall.h:56: warning: use of memory > input without lvalue in asm operand 7 is deprecated In file > included from ldso.c:1343: > readelflib1.c: In function `_dl_load_elf_shared_library': > readelflib1.c:452: error: `PAGE_SIZE' undeclared (first use > in this function) In file included from ldso.c:1343: > ../../ldso/include/ld_syscall.h:56: warning: use of memory > input without lvalue in asm operand 7 is deprecated > ../../ldso/include/ld_syscall.h:56: warning: use of memory > input without lvalue in asm operand 7 is deprecated > ../../ldso/include/ld_syscall.h:56: warning: use of memory > input without lvalue in asm operand 7 is deprecated > ../../ldso/include/ld_syscall.h:56: warning: use of memory > input without lvalue in asm operand 7 is deprecated > ../../ldso/include/ld_syscall.h:56: warning: use of memory > input without lvalue in asm operand 7 is deprecated > readelflib1.c: In function `_dl_dprintf': > readelflib1.c:787: error: `PAGE_SIZE' undeclared (first use > in this function) In file included from ldso.c:1343: > ../../ldso/include/ld_syscall.h:56: warning: use of memory > input without lvalue in asm operand 7 is deprecated In file > included from ldso.c:1343: > readelflib1.c: In function `_dl_malloc': > readelflib1.c:886: error: `PAGE_SIZE' undeclared (first use > in this function) In file included from ldso.c:1343: > ../../ldso/include/ld_syscall.h:56: warning: use of memory > input without lvalue in asm operand 7 is deprecated > ../../ldso/include/ld_syscall.h: In function `_dl_mmap': > ../../ldso/include/ld_syscall.h:56: warning: use of memory > input without lvalue in asm operand 7 is deprecated > make[2]: *** [ldso.o] Error 1 > make[2]: Leaving directory > `/mnt/hdb/mips-toolchain/sources/uClibc-0.9.26/ldso/ldso' > make[1]: *** [all] Error 2 > make[1]: Leaving directory > `/mnt/hdb/mips-toolchain/sources/uClibc-0.9.26/ldso' > make: *** [_dir_ldso] Error 2 > > can anyone please help me solve this problem? > > regards > abhijit > > From abhijitayarekar at gmail.com Fri Apr 4 10:03:41 2008 From: abhijitayarekar at gmail.com (abhijit ayarekar) Date: Fri, 4 Apr 2008 10:03:41 -0700 Subject: Problems in compiling for mips In-Reply-To: <005b01c89626$cbf76190$838182a4@st.com> References: <1ffdbf640804031312y57c17423r5514e99711a6625d@mail.gmail.com> <005b01c89626$cbf76190$838182a4@st.com> Message-ID: <1ffdbf640804041003l4d37e43al4162b94dae02039c@mail.gmail.com> thanks for the reply :). when i checked the linux src for mips in asm-mips folder PAGE_SIZE was defined only in kernel context. if __KERNEL__ was defined only then was PAGE_SIZE defined. on the other hand PAGE_SIZE is defined for non kernel context in i386 and arm asm folders. i was able to fix the problem by defining PAGE_SIZE in asm-mips/page.h. that compiled the uClibc-0.9.26, then i compiled full build of gcc-3.3.3 and also was able to run test programs on the ubnt litestation2 mips-4kc board. isnt there a patch available for doing this the right way? i understand that making changes in the kernel code is not a good idea. is there a fix available for this problem? i would like to post my findings about the toolchain build procedure but not before getting the right solution for this problem. regards abhijit On Fri, Apr 4, 2008 at 12:37 AM, Filippo ARCIDIACONO < filippo.arcidiacono at st.com> wrote: > I suggest you to upgrade the uClibc to the 0.9.29 version. > > > -----Original Message----- > > From: uclibc-bounces at uclibc.org > > [mailto:uclibc-bounces at uclibc.org] On Behalf Of abhijit ayarekar > > Sent: Thursday, April 03, 2008 10:12 PM > > To: uclibc at uclibc.org > > Subject: Problems in compiling for mips > > > > I am trying to compile uclibc-0.9.26 with binutils-2.15, > > gcc-3.3.3, kernel headers version 2.4.27 > > > > when i run make i get the following error > > > > [root at shastabuild uClibc-0.9.26]# make CROSS=mips-linux- > > + ./extra/scripts/fix_includes.sh -k > > + /mnt/hdb/mips-toolchain/kernel/linux-kernel-2.4 -t mips > > Current kernel version is 2.4.27-ubnt0 > > > > Using kernel headers from 2.4.27-ubnt0 for architecture 'mips' > > provided in directory > > /mnt/hdb/mips-toolchain/kernel/linux-kernel-2.4 > > > > + TOPDIR=. > > + CC=mips-linux-gcc > > + /bin/sh extra/scripts/gen_bits_syscall_h.sh > > + cmp include/bits/sysnum.h include/bits/sysnum.h.new mv -f > > + include/bits/sysnum.h.new include/bits/sysnum.h > > make -C libc/sysdeps/linux/common headers > > make[1]: Entering directory > > `/mnt/hdb/mips-toolchain/sources/uClibc-0.9.26/libc/sysdeps/li > nux/common' > > ln -fs ../libc/sysdeps/linux/common/fpu_control.h > > ../../../..//include/ > > make[1]: Leaving directory > > `/mnt/hdb/mips-toolchain/sources/uClibc-0.9.26/libc/sysdeps/li > nux/common' > > make -C libc/sysdeps/linux/mips headers > > make[1]: Entering directory > > `/mnt/hdb/mips-toolchain/sources/uClibc-0.9.26/libc/sysdeps/li > nux/mips' > > ln -fs ../libc/sysdeps/linux/mips/sgidefs.h > > ../../../..//include/ ln -fs > > ../libc/sysdeps/linux/mips/fpu_control.h ../../../..//include/ > > make[1]: Leaving directory > > `/mnt/hdb/mips-toolchain/sources/uClibc-0.9.26/libc/sysdeps/li > nux/mips' > > make -C ldso > > make[1]: Entering directory > > `/mnt/hdb/mips-toolchain/sources/uClibc-0.9.26/ldso' > > ln -fs ../../include/elf.h include/ > > ln -fs ../ldso/mips/boot1_arch.h include/ ln -fs > > ../ldso/mips/ld_syscalls.h include/ ln -fs > > ../ldso/mips/ld_sysdep.h include/ make -C ldso; > > make[2]: Entering directory > > `/mnt/hdb/mips-toolchain/sources/uClibc-0.9.26/ldso/ldso' > > mips-linux-gcc -Wall -Wstrict-prototypes -Wno-trigraphs > > -fno-strict-aliasing -Os -mno-split-addresses -mips32 > > -mtune=mips32 -fPIC > > -DUCLIBC_RUNTIME_PREFIX=\"/mnt/hdb/mips-toolchain/mips-linux/\ > " -fno-builtin -nostdinc -I../../ldso/include -I. -> I../../include > > -I/mnt/hdb/mips-toolchain/lib/gcc-lib/mips-linux/3.3.3/include > > -I../libdl -c ldso.c -o ldso.o In file included from > > _dl_progname.h:2, > > from ldso.c:156: > > mips/elfinterp.c: In function `_dl_parse_relocation_information': > > mips/elfinterp.c:177: warning: unused variable `old_val' > > ldso.c: In function `_dl_boot2': > > ldso.c:362: error: `PAGE_SIZE' undeclared (first use in this function) > > ldso.c:362: error: (Each undeclared identifier is reported only once > > ldso.c:362: error: for each function it appears in.) > > ldso.c:454:2: warning: #warning "Debugging threads on mips > > won't work till someone fixes this..." > > ../../ldso/include/ld_syscall.h:56: warning: use of memory > > input without lvalue in asm operand 7 is deprecated In file > > included from ldso.c:1343: > > readelflib1.c: In function `_dl_load_elf_shared_library': > > readelflib1.c:452: error: `PAGE_SIZE' undeclared (first use > > in this function) In file included from ldso.c:1343: > > ../../ldso/include/ld_syscall.h:56: warning: use of memory > > input without lvalue in asm operand 7 is deprecated > > ../../ldso/include/ld_syscall.h:56: warning: use of memory > > input without lvalue in asm operand 7 is deprecated > > ../../ldso/include/ld_syscall.h:56: warning: use of memory > > input without lvalue in asm operand 7 is deprecated > > ../../ldso/include/ld_syscall.h:56: warning: use of memory > > input without lvalue in asm operand 7 is deprecated > > ../../ldso/include/ld_syscall.h:56: warning: use of memory > > input without lvalue in asm operand 7 is deprecated > > readelflib1.c: In function `_dl_dprintf': > > readelflib1.c:787: error: `PAGE_SIZE' undeclared (first use > > in this function) In file included from ldso.c:1343: > > ../../ldso/include/ld_syscall.h:56: warning: use of memory > > input without lvalue in asm operand 7 is deprecated In file > > included from ldso.c:1343: > > readelflib1.c: In function `_dl_malloc': > > readelflib1.c:886: error: `PAGE_SIZE' undeclared (first use > > in this function) In file included from ldso.c:1343: > > ../../ldso/include/ld_syscall.h:56: warning: use of memory > > input without lvalue in asm operand 7 is deprecated > > ../../ldso/include/ld_syscall.h: In function `_dl_mmap': > > ../../ldso/include/ld_syscall.h:56: warning: use of memory > > input without lvalue in asm operand 7 is deprecated > > make[2]: *** [ldso.o] Error 1 > > make[2]: Leaving directory > > `/mnt/hdb/mips-toolchain/sources/uClibc-0.9.26/ldso/ldso' > > make[1]: *** [all] Error 2 > > make[1]: Leaving directory > > `/mnt/hdb/mips-toolchain/sources/uClibc-0.9.26/ldso' > > make: *** [_dir_ldso] Error 2 > > > > can anyone please help me solve this problem? > > > > regards > > abhijit > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/uclibc/attachments/20080404/12674d80/attachment-0001.htm From nkukard at lbsd.net Sat Apr 5 03:24:43 2008 From: nkukard at lbsd.net (Nigel Kukard) Date: Sat, 05 Apr 2008 10:24:43 +0000 Subject: uclibc segfault in ldso In-Reply-To: <87a5b0800804030420h6f7982a6s5d6d1f2b422f0ae6@mail.gmail.com> References: <1206537761.3605.250.camel@nigel-x60> <1206640602.3605.429.camel@nigel-x60> <1206644186.7589.317.camel@gentoo-jocke.transmode.se> <1206646199.3605.457.camel@nigel-x60> <1206647470.3605.463.camel@nigel-x60> <1206656263.3605.470.camel@nigel-x60> <1206692400.7589.326.camel@gentoo-jocke.transmode.se> <1206720248.3224.51.camel@nigel-x60> <47ED1DBE.9050300@gmail.com> <1206722541.3224.58.camel@nigel-x60> <87a5b0800804030420h6f7982a6s5d6d1f2b422f0ae6@mail.gmail.com> Message-ID: <1207391083.6817.13.camel@nigel-x60> > > > >> Can't see anything, I think you should add printouts in __uClibc_init() > > > >> to see if you get there, use the write() sys call as I don't think you > > > >> can use any of the libc print functions. > > > >> > > > >> Non PIE rpm works I guess? > > > >> Does rpm work in glibc, both PIE and non PIE? > > > >> > > > >> Jocke > > > > > > > > > > > > > > > > _malloc:921: mmapping more memory > > > > _dl_get_ready_to_run:748: Beginning relocation fixups > > > > here: 001 > > > > here: 002 > > > > here: 025 > > > > here: 026 > > > > Segmentation fault > > > > > > > > Looks like its choking on pthreads? > > > > > > > Hi, > > > > > > I've seen that your are not using the stable linuxthread.old implementation. > > > I'd suggest you to rebuild uclibc using linuxthread.old. > > > I'm not sure how stable/tested is the linuxthreads (TLS support). > > > > Dead center Carmelo!!! enabling old pthreads worked. > > > > Should I debug this further or just work with the old implementation? > > Does the attached patch fix the issue? Nope .... issue persists. -N -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://busybox.net/lists/uclibc/attachments/20080405/24fff9d5/attachment.pgp From filippo.arcidiacono at st.com Mon Apr 7 00:09:52 2008 From: filippo.arcidiacono at st.com (Filippo ARCIDIACONO) Date: Mon, 7 Apr 2008 09:09:52 +0200 Subject: Problems in compiling for mips In-Reply-To: <1ffdbf640804041003l4d37e43al4162b94dae02039c@mail.gmail.com> Message-ID: <000601c8987e$66f9d750$838182a4@st.com> > -----Original Message----- > From: abhijit ayarekar [mailto:abhijitayarekar at gmail.com] > Sent: Friday, April 04, 2008 7:04 PM > To: Filippo ARCIDIACONO > Cc: uclibc at uclibc.org > Subject: Re: Problems in compiling for mips > > thanks for the reply :). > when i checked the linux src for mips in asm-mips folder > PAGE_SIZE was defined only in kernel context. > if __KERNEL__ was defined only then was PAGE_SIZE defined. on > the other hand PAGE_SIZE is defined for non kernel context in > i386 and arm asm folders. i was able to fix the problem by > defining PAGE_SIZE in asm-mips/page.h. that compiled the > uClibc-0.9.26, then i compiled full build of gcc-3.3.3 and > also was able to run test programs on the ubnt litestation2 > mips-4kc board. > isnt there a patch available for doing this the right way? > I understand that making changes in the kernel code is not a > good idea. is there a fix available for this problem? I think, if you upgrade your uClibc tree (0.9.26 is too old) you don't need any patches to solve this problem. In my tree (0.9.29) PAGE_SIZE is defined, for mips arch in libc/sysdeps/mips/bits/uClibc_page.h. > i would like to post my findings about the toolchain build > procedure but not before getting the right solution for this problem. > > regards > abhijit > > On Fri, Apr 4, 2008 at 12:37 AM, Filippo ARCIDIACONO > wrote: > > > I suggest you to upgrade the uClibc to the 0.9.29 version. > > > > -----Original Message----- > > From: uclibc-bounces at uclibc.org > > [mailto:uclibc-bounces at uclibc.org] On Behalf Of > abhijit ayarekar > > Sent: Thursday, April 03, 2008 10:12 PM > > To: uclibc at uclibc.org > > Subject: Problems in compiling for mips > > > > I am trying to compile uclibc-0.9.26 with binutils-2.15, > > gcc-3.3.3, kernel headers version 2.4.27 > > > > when i run make i get the following error > > > > [root at shastabuild uClibc-0.9.26]# make CROSS=mips-linux- > > + ./extra/scripts/fix_includes.sh -k > > + /mnt/hdb/mips-toolchain/kernel/linux-kernel-2.4 -t mips > > Current kernel version is 2.4.27-ubnt0 > > > > Using kernel headers from 2.4.27-ubnt0 for architecture 'mips' > > provided in directory > > /mnt/hdb/mips-toolchain/kernel/linux-kernel-2.4 > > > > + TOPDIR=. > > + CC=mips-linux-gcc > > + /bin/sh extra/scripts/gen_bits_syscall_h.sh > > + cmp include/bits/sysnum.h include/bits/sysnum.h.new mv -f > > + include/bits/sysnum.h.new include/bits/sysnum.h > > make -C libc/sysdeps/linux/common headers > > make[1]: Entering directory > > `/mnt/hdb/mips-toolchain/sources/uClibc-0.9.26/libc/sysdeps/li > nux/common' > > ln -fs ../libc/sysdeps/linux/common/fpu_control.h > > ../../../..//include/ > > make[1]: Leaving directory > > `/mnt/hdb/mips-toolchain/sources/uClibc-0.9.26/libc/sysdeps/li > nux/common' > > make -C libc/sysdeps/linux/mips headers > > make[1]: Entering directory > > `/mnt/hdb/mips-toolchain/sources/uClibc-0.9.26/libc/sysdeps/li > nux/mips' > > ln -fs ../libc/sysdeps/linux/mips/sgidefs.h > > ../../../..//include/ ln -fs > > ../libc/sysdeps/linux/mips/fpu_control.h ../../../..//include/ > > make[1]: Leaving directory > > `/mnt/hdb/mips-toolchain/sources/uClibc-0.9.26/libc/sysdeps/li > nux/mips' > > make -C ldso > > make[1]: Entering directory > > `/mnt/hdb/mips-toolchain/sources/uClibc-0.9.26/ldso' > > ln -fs ../../include/elf.h include/ > > ln -fs ../ldso/mips/boot1_arch.h include/ ln -fs > > ../ldso/mips/ld_syscalls.h include/ ln -fs > > ../ldso/mips/ld_sysdep.h include/ make -C ldso; > > make[2]: Entering directory > > `/mnt/hdb/mips-toolchain/sources/uClibc-0.9.26/ldso/ldso' > > mips-linux-gcc -Wall -Wstrict-prototypes -Wno-trigraphs > > -fno-strict-aliasing -Os -mno-split-addresses -mips32 > > -mtune=mips32 -fPIC > > -DUCLIBC_RUNTIME_PREFIX=\"/mnt/hdb/mips-toolchain/mips-linux/\ > " -fno-builtin -nostdinc -I../../ldso/include -I. -> > I../../include > > -I/mnt/hdb/mips-toolchain/lib/gcc-lib/mips-linux/3.3.3/include > > -I../libdl -c ldso.c -o ldso.o In file included from > > _dl_progname.h:2, > > from ldso.c:156: > > mips/elfinterp.c: In function > `_dl_parse_relocation_information': > > mips/elfinterp.c:177: warning: unused variable `old_val' > > ldso.c: In function `_dl_boot2': > > ldso.c:362: error: `PAGE_SIZE' undeclared (first use > in this function) > > ldso.c:362: error: (Each undeclared identifier is > reported only once > > ldso.c:362: error: for each function it appears in.) > > ldso.c:454:2: warning: #warning "Debugging threads on mips > > won't work till someone fixes this..." > > ../../ldso/include/ld_syscall.h:56: warning: use of memory > > input without lvalue in asm operand 7 is deprecated In file > > included from ldso.c:1343: > > readelflib1.c: In function `_dl_load_elf_shared_library': > > readelflib1.c:452: error: `PAGE_SIZE' undeclared (first use > > in this function) In file included from ldso.c:1343: > > ../../ldso/include/ld_syscall.h:56: warning: use of memory > > input without lvalue in asm operand 7 is deprecated > > ../../ldso/include/ld_syscall.h:56: warning: use of memory > > input without lvalue in asm operand 7 is deprecated > > ../../ldso/include/ld_syscall.h:56: warning: use of memory > > input without lvalue in asm operand 7 is deprecated > > ../../ldso/include/ld_syscall.h:56: warning: use of memory > > input without lvalue in asm operand 7 is deprecated > > ../../ldso/include/ld_syscall.h:56: warning: use of memory > > input without lvalue in asm operand 7 is deprecated > > readelflib1.c: In function `_dl_dprintf': > > readelflib1.c:787: error: `PAGE_SIZE' undeclared (first use > > in this function) In file included from ldso.c:1343: > > ../../ldso/include/ld_syscall.h:56: warning: use of memory > > input without lvalue in asm operand 7 is deprecated In file > > included from ldso.c:1343: > > readelflib1.c: In function `_dl_malloc': > > readelflib1.c:886: error: `PAGE_SIZE' undeclared (first use > > in this function) In file included from ldso.c:1343: > > ../../ldso/include/ld_syscall.h:56: warning: use of memory > > input without lvalue in asm operand 7 is deprecated > > ../../ldso/include/ld_syscall.h: In function `_dl_mmap': > > ../../ldso/include/ld_syscall.h:56: warning: use of memory > > input without lvalue in asm operand 7 is deprecated > > make[2]: *** [ldso.o] Error 1 > > make[2]: Leaving directory > > `/mnt/hdb/mips-toolchain/sources/uClibc-0.9.26/ldso/ldso' > > make[1]: *** [all] Error 2 > > make[1]: Leaving directory > > `/mnt/hdb/mips-toolchain/sources/uClibc-0.9.26/ldso' > > make: *** [_dir_ldso] Error 2 > > > > can anyone please help me solve this problem? > > > > regards > > abhijit > > > > > > > > > Regards, Filippo. From nikelinux at gmail.com Tue Apr 8 21:45:29 2008 From: nikelinux at gmail.com (Nikesh Gawande) Date: Wed, 9 Apr 2008 10:15:29 +0530 Subject: Problem in building busyox for uClibc Message-ID: Hi , I am quiet new in the Linux world. I working on the system having AT91SAM9261 chip all the kernel related issues have been solved. Now I am trying to create the RFS with busybox and uClibc. I have built both of them with cross toolchain for ARM926. But I the busybox is not working with uClibc and it perfectly works with glibc. Is there anything I am missing in the building uClibc or busybox. Please help me. Regards, Nikesh -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/uclibc/attachments/20080409/961d1df6/attachment.htm From vda.linux at googlemail.com Wed Apr 9 12:47:26 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Wed, 9 Apr 2008 21:47:26 +0200 Subject: [PATCH] decouple sprintf and fseek In-Reply-To: <200804021611.47231.vda.linux@googlemail.com> References: <200804021611.47231.vda.linux@googlemail.com> Message-ID: <200804092147.26906.vda.linux@googlemail.com> Hi, On Wednesday 02 April 2008 16:11, Denys Vlasenko wrote: > Can you please review and comment on this bug: > > http://busybox.net/bugs/view.php?id=2714 > > Although I technically can commit this change myself, > I'd much prefer for it to be reviewed by people > who actively work on uclubc codebase. > > The same patches are attached to this mail. I am going to apply these changes. If I break anything, yell at me. If there are testsuite I can run to check for regressions, please point me to it. -- vda From rep.dot.nop at gmail.com Wed Apr 9 13:27:57 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Wed, 9 Apr 2008 22:27:57 +0200 Subject: [PATCH] decouple sprintf and fseek In-Reply-To: <200804092147.26906.vda.linux@googlemail.com> References: <200804021611.47231.vda.linux@googlemail.com> <200804092147.26906.vda.linux@googlemail.com> Message-ID: <20080409202756.GC27200@mx.loc> On Wed, Apr 09, 2008 at 09:47:26PM +0200, Denys Vlasenko wrote: >Hi, > >On Wednesday 02 April 2008 16:11, Denys Vlasenko wrote: >> Can you please review and comment on this bug: >> >> http://busybox.net/bugs/view.php?id=2714 >> >> Although I technically can commit this change myself, >> I'd much prefer for it to be reviewed by people >> who actively work on uclubc codebase. >> >> The same patches are attached to this mail. > >I am going to apply these changes. If I break anything, >yell at me. > >If there are testsuite I can run to check for regressions, >please point me to it. mompls. Following up with out-of-line breakage avoidance.. From vda.linux at googlemail.com Wed Apr 9 14:03:36 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Wed, 9 Apr 2008 23:03:36 +0200 Subject: [PATCH] decouple sprintf and fseek In-Reply-To: <20080409202756.GC27200@mx.loc> References: <200804021611.47231.vda.linux@googlemail.com> <200804092147.26906.vda.linux@googlemail.com> <20080409202756.GC27200@mx.loc> Message-ID: <200804092303.36872.vda.linux@googlemail.com> Hi Bernhard, On Wednesday 09 April 2008 22:27, Bernhard Fischer wrote: > >On Wednesday 02 April 2008 16:11, Denys Vlasenko wrote: > >> Can you please review and comment on this bug: > >> > >> http://busybox.net/bugs/view.php?id=2714 > >> > >> Although I technically can commit this change myself, > >> I'd much prefer for it to be reviewed by people > >> who actively work on uclubc codebase. > >> > >> The same patches are attached to this mail. > > > >I am going to apply these changes. If I break anything, > >yell at me. > > > >If there are testsuite I can run to check for regressions, > >please point me to it. > > mompls. Following up with out-of-line breakage avoidance.. I did not understand you. -- vda From nikelinux at gmail.com Wed Apr 9 22:19:12 2008 From: nikelinux at gmail.com (Nikesh Gawande) Date: Thu, 10 Apr 2008 10:49:12 +0530 Subject: UClibc does not have libgcc_s.so.1 Message-ID: Hi Everybody, I am trying to use uClibc-0.9.29.tar.bz2 and busybox-1.10.0.tar.bz2 over my ARM processor system. but at the boot I am getting the following message and then stops there. /sbKernel panic - not syncing: Attempted to kill init! i n/init: can't load library 'libgcc_s.so.1' I did not find the libgcc_s.so.1 in the built uClibc. Also libgcc_s.so.1 from glibc is copied it into the /usr/lib/ directory but still it is giving the same message. Please help me. Regards, Nikesh -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/uclibc/attachments/20080410/0b08e0ba/attachment.htm From hans-christian.egtvedt at atmel.com Wed Apr 9 22:25:02 2008 From: hans-christian.egtvedt at atmel.com (Hans-Christian Egtvedt) Date: Thu, 10 Apr 2008 07:25:02 +0200 Subject: UClibc does not have libgcc_s.so.1 In-Reply-To: References: Message-ID: <1207805102.1104.6.camel@localhost> On Thu, 2008-04-10 at 10:49 +0530, Nikesh Gawande wrote: > > Hi Everybody, > > I am trying to use uClibc-0.9.29.tar.bz2 and > busybox-1.10.0.tar.bz2 over my ARM processor system. but at the boot I > am > getting the following message and then stops there. > > /sbKernel panic - not syncing: Attempted to kill init! > i n/init: can't load library 'libgcc_s.so.1' > > I did not find the libgcc_s.so.1 in the built uClibc. Also > libgcc_s.so.1 from glibc is > copied it into the /usr/lib/ directory but still it is giving the same > message. Please help me. > AFAIK libgcc is built by GCC, take a peek in your compiler directory. -- With kind regards, Hans-Christian Egtvedt, Applications Engineer From carmelo.amoroso at st.com Wed Apr 9 23:28:34 2008 From: carmelo.amoroso at st.com (Carmelo AMOROSO) Date: Thu, 10 Apr 2008 08:28:34 +0200 Subject: UClibc does not have libgcc_s.so.1 In-Reply-To: <1207805102.1104.6.camel@localhost> References: <1207805102.1104.6.camel@localhost> Message-ID: <47FDB392.20905@st.com> Hans-Christian Egtvedt wrote: > On Thu, 2008-04-10 at 10:49 +0530, Nikesh Gawande wrote: > >> Hi Everybody, >> >> I am trying to use uClibc-0.9.29.tar.bz2 and >> busybox-1.10.0.tar.bz2 over my ARM processor system. but at the boot I >> am >> getting the following message and then stops there. >> >> /sbKernel panic - not syncing: Attempted to kill init! >> i n/init: can't load library 'libgcc_s.so.1' >> >> I did not find the libgcc_s.so.1 in the built uClibc. Also >> libgcc_s.so.1 from glibc is >> copied it into the /usr/lib/ directory but still it is giving the same >> message. Please help me. >> >> > > AFAIK libgcc is built by GCC, take a peek in your compiler directory. > > Absolutely correct. From carmelo.amoroso at st.com Wed Apr 9 23:31:14 2008 From: carmelo.amoroso at st.com (Carmelo AMOROSO) Date: Thu, 10 Apr 2008 08:31:14 +0200 Subject: Problem in building busyox for uClibc In-Reply-To: References: Message-ID: <47FDB432.3050805@st.com> Nikesh Gawande wrote: > Hi , > > I am quiet new in the Linux world. I working on the > system having AT91SAM9261 chip all the kernel related issues have been > solved. Now I am trying to create the RFS with busybox and uClibc. I > have built both of them with cross toolchain for ARM926. But I the > busybox is not working with uClibc and it perfectly works with glibc. > Is there anything I am missing in the building uClibc or busybox. > Please help me. > > Regards, > > Nikesh what errors, what problem ? no trace, no output, no debug info, no info. How do you think somebody could help you. Is it statically linked or not ? Your uclibc configuration ? what libpthread are you using ? recently others are having problem using linuxthrads instead of linuxthread.old . Rebuild your uclibc with debug symbol, and start a real debug session with gdb. Regards, Carmelo > ------------------------------------------------------------------------ > > _______________________________________________ > uClibc mailing list > uClibc at uclibc.org > http://busybox.net/cgi-bin/mailman/listinfo/uclibc From Teemu.Keskinarkaus at cc-systems.com Thu Apr 10 05:16:47 2008 From: Teemu.Keskinarkaus at cc-systems.com (Teemu Keskinarkaus) Date: Thu, 10 Apr 2008 14:16:47 +0200 Subject: Decimalpoint missing Message-ID: <330EC2471BF24E48B513AF1A6975EB6947E2F6@MAIL-UA.ccs.local> Hi, It seems that few other fellow have asked this already, but I couldn't find any answer. I'm using uClibc 0.9.29 and I'm having problems with decimal points. They are missing when printing floating point value as well as reading it with (s)scanf. One solution for this is to disable locale from uClibc. That worked just fine until I had to use program that uses both(locale and printing floating points). What I need to do to get the locale and decimal point working at the same time? One post suggested that the decimal point is missing from the locale. Are there any patches regarding this issue? Thanks. Teemu Keskinarkaus CC-Systems -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/uclibc/attachments/20080410/660f3b3c/attachment.htm From vda.linux at googlemail.com Thu Apr 10 09:09:50 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Thu, 10 Apr 2008 18:09:50 +0200 Subject: Decimalpoint missing In-Reply-To: <330EC2471BF24E48B513AF1A6975EB6947E2F6@MAIL-UA.ccs.local> References: <330EC2471BF24E48B513AF1A6975EB6947E2F6@MAIL-UA.ccs.local> Message-ID: <200804101809.50697.vda.linux@googlemail.com> On Thursday 10 April 2008 14:16, Teemu Keskinarkaus wrote: > Hi, > > It seems that few other fellow have asked this already, but I couldn't > find any answer. > > I'm using uClibc 0.9.29 and I'm having problems with decimal points. > They are missing when printing floating point value as well as reading > it with (s)scanf. One solution for this is to disable locale from > uClibc. That worked just fine until I had to use program that uses > both(locale and printing floating points). > > What I need to do to get the locale and decimal point working at the > same time? One post suggested that the decimal point is missing from the > locale. Are there any patches regarding this issue? Can you post an example which shows the problem? -- vda From vda.linux at googlemail.com Thu Apr 10 16:33:29 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Fri, 11 Apr 2008 01:33:29 +0200 Subject: RFC: [PATCH] do not do libc_hidden_proto() thing for internal functions Message-ID: <200804110133.29156.vda.linux@googlemail.com> Hi Peter, folks, IIUC typically uclibc internal functions are labeled attribute_hidden, which makes them efficiently callable from within dynamically built uclibc and not callable from programs linked against it. I noticed that a few functions, which are not exported in any .h file, are still using libc_hidden_proto(func) method instead. ruserpass() function does both :) - it is labeled attribute_hidden and touched by libc_hidden_proto(ruserpass). This patch converts five such functions to attribute_hidden method: libc/inet/*: inet_ntoa_r libc/inet/rpc/*: ruserpass, xdr_accepted_reply, xdr_rejected_reply libc/misc/time/*: _time_tzset Please let me know if I am missing something here. -- vda -------------- next part -------------- A non-text attachment was scrubbed... Name: 5.patch Type: text/x-diff Size: 4074 bytes Desc: not available Url : http://busybox.net/lists/uclibc/attachments/20080411/981a501c/attachment.patch From Teemu.Keskinarkaus at cc-systems.com Thu Apr 10 21:24:36 2008 From: Teemu.Keskinarkaus at cc-systems.com (Teemu Keskinarkaus) Date: Fri, 11 Apr 2008 06:24:36 +0200 Subject: Decimalpoint missing In-Reply-To: <200804101809.50697.vda.linux@googlemail.com> References: <330EC2471BF24E48B513AF1A6975EB6947E2F6@MAIL-UA.ccs.local> <200804101809.50697.vda.linux@googlemail.com> Message-ID: <330EC2471BF24E48B513AF1A6975EB6947E368@MAIL-UA.ccs.local> > -----Original Message----- > From: Denys Vlasenko [mailto:vda.linux at googlemail.com] > Sent: 10. huhtikuuta 2008 19:10 > To: uclibc at uclibc.org > Cc: Teemu Keskinarkaus > Subject: Re: Decimalpoint missing > > On Thursday 10 April 2008 14:16, Teemu Keskinarkaus wrote: > > Hi, > > > > It seems that few other fellow have asked this already, but I couldn't > > find any answer. > > > > I'm using uClibc 0.9.29 and I'm having problems with decimal points. > > They are missing when printing floating point value as well as reading > > it with (s)scanf. One solution for this is to disable locale from > > uClibc. That worked just fine until I had to use program that uses > > both(locale and printing floating points). > > > > What I need to do to get the locale and decimal point working at the > > same time? One post suggested that the decimal point is missing from the > > locale. Are there any patches regarding this issue? > > Can you post an example which shows the problem? For missing decimalpoint, a simple print example will show the problem. This example will 'work' with uClibc locale enabled. Something like this. #include int main (void) { float f = 1.23; printf("Number is: %f\n",f); return 0; } Output: Number is 123 If I compile uClibc with locale disabled then output: Number is 1.23 (I have removed the trailing zeroes, but you get the point). Now, if I disable the locale to get the decimal point handled ok, the other program (AppWeb webserver) won't work any more. It uses locale somewhere so if linked statically the error occurs when linking and if linked dynamically the error occurs when using the program. Oh, did I mention that I need those floats also in AppWeb. My other program doesn't use locale so 'fix' for it is to disable locale from uClibc, but that doesn't work for AppWeb. -Teemu From Teemu.Keskinarkaus at cc-systems.com Thu Apr 10 21:43:56 2008 From: Teemu.Keskinarkaus at cc-systems.com (Teemu Keskinarkaus) Date: Fri, 11 Apr 2008 06:43:56 +0200 Subject: Decimalpoint missing In-Reply-To: <200804101809.50697.vda.linux@googlemail.com> References: <330EC2471BF24E48B513AF1A6975EB6947E2F6@MAIL-UA.ccs.local> <200804101809.50697.vda.linux@googlemail.com> Message-ID: <330EC2471BF24E48B513AF1A6975EB6947E36A@MAIL-UA.ccs.local> > -----Original Message----- > From: Denys Vlasenko [mailto:vda.linux at googlemail.com] > > Can you post an example which shows the problem? > -- > vda Forgot to add this: http://www.busybox.net/lists/buildroot/2007-March/002166.html There is someone else describing the same problem I'm having now. And I'm using buildroot too to compile uClibc if it turns out to be configuration problem. -Teemu From vda.linux at googlemail.com Fri Apr 11 19:07:07 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sat, 12 Apr 2008 04:07:07 +0200 Subject: RFC: first stab at getting rid of libc_hidden_proto() forest Message-ID: <200804120407.07311.vda.linux@googlemail.com> Hi, I want to make clear that I do not intend to apply this patch without getting a positive review. I don't want people to start thinking "omg, vda can commit this %&&$ and mess up the tree"! I won't. It's really an RFC. What it does: I find the need of having libc_hidden_proto(fprintf) anywhere you want to use fprintf efficiently (i.e. to call it directly, not thru GOT/PLT) to be unmaintainable. First, it clogs up the source. Second, it's too easy to forget to do it, and you get suboptimal code, silently. Third, sometimes it gets even more ugly: you need to know _implementation details_ and dance with #defines like this: #ifdef __UCLIBC_HAS_XLOCALE__ libc_hidden_proto(__ctype_b_loc) #elif __UCLIBC_HAS_CTYPE_TABLES__ libc_hidden_proto(__ctype_b) #endif Fifth: it needs to be repeated in every .c file where you want to use e.g. ctype.h functions! Obvious solution of adding libc_hidden_proto's to .h files does not work so well since we'd like to not pollute them with machinery which doesn't belong to public interface. In the attached patch, I chose to create a "master include file" which includes almost all other headers; and then marks all exported functions(variables) with libc_hidden_proto. The file is called uClibc_libc.h. Currently it does all #includes first, and all libc_hidden_proto's next. Maybe it makes sense to group them by header instead: #include libc_hidden_proto(printf) libc_hidden_proto(sprintf) ... #include ... Anyway. It is meant to be used this way: you include only this file, and you are getting (almost) all headers included for you, and all exported functions libc_hidden_proto'ed. You don't need to do it again and again in each .c file. Lots and lots of #includes and libc_hidden_proto's can be removed; and a lot of churn in adding/removing thme in future is eliminated too. The upside is less crowded .c files. The downside is a somewhat longer build time. The patch demonstrates this approach by performing this surgery on a handful of files, namely: libc/inet/getaddrinfo.c libc/inet/ifaddrs.c libc/inet/resolv.c libc/inet/rpc/pmap_rmt.c libc/inet/rpc/rcmd.c libc/misc/locale/locale.c libc/misc/syslog/syslog.c libc/misc/time/time.c libc/misc/wchar/wchar.c libc/misc/wordexp/wordexp.c libc/stdio/_scanf.c libc/stdio/_vfprintf.c Of these, only libc/misc/locale/locale.c required a little more work to make it build, and a small fix in libc/inet/netlinkaccess.h was needed too. I tried building uclibc with several .configs and fixed all fallout; then I compared object files one-by-one before and after the patch. They seem to be identical except for libc/misc/time/tzset.os. I tracked the difference to this code: void tzset(void) { _time_tzset((time(NULL)) < new_rule_starts); } Before the patch, we were forgetting to treat time() with libc_hidden_proto(time) macro, and it was called thru indirection machinery: 00000000 <__GI_tzset>: - 0: 53 push %ebx - 1: e8 00 00 00 00 call 6 <__GI_tzset+0x6> - 6: 5b pop %ebx - 7: 81 c3 03 00 00 00 add $0x3,%ebx - 9: R_386_GOTPC _GLOBAL_OFFSET_TABLE_ - d: 6a 00 push $0x0 - f: e8 fc ff ff ff call 10 <__GI_tzset+0x10> - 10: R_386_PLT32 time + 0: 6a 00 push $0x0 + 2: e8 fc ff ff ff call 3 <__GI_tzset+0x3> + 3: R_386_PC32 __GI_time As you see, after the patch it was automatically using faster calling method. So I found one missed optimization by editing 12 files only. There are probably more of these. Please let me know what do you think about this approach. -- vda -------------- next part -------------- A non-text attachment was scrubbed... Name: 6.patch Type: text/x-diff Size: 60797 bytes Desc: not available Url : http://busybox.net/lists/uclibc/attachments/20080412/96bf08c3/attachment-0001.patch From carmelo73 at gmail.com Fri Apr 11 22:35:11 2008 From: carmelo73 at gmail.com (Carmelo Amoroso) Date: Sat, 12 Apr 2008 07:35:11 +0200 Subject: RFC: first stab at getting rid of libc_hidden_proto() forest In-Reply-To: <200804120407.07311.vda.linux@googlemail.com> References: <200804120407.07311.vda.linux@googlemail.com> Message-ID: <48004A0F.4050002@gmail.com> Denys Vlasenko wrote: > Hi, > > I want to make clear that I do not intend to apply this patch > without getting a positive review. I don't want people to > start thinking "omg, vda can commit this %&&$ and mess up > the tree"! > > I won't. It's really an RFC. > > What it does: > > I find the need of having libc_hidden_proto(fprintf) > anywhere you want to use fprintf efficiently (i.e. > to call it directly, not thru GOT/PLT) to be unmaintainable. > Hi, sounds reasonable... > First, it clogs up the source. > agree > Second, it's too easy to forget to do it, and you get > suboptimal code, silently. > agree > Third, sometimes it gets even more ugly: you need to know > _implementation details_ and dance with #defines like this: > > #ifdef __UCLIBC_HAS_XLOCALE__ > libc_hidden_proto(__ctype_b_loc) > #elif __UCLIBC_HAS_CTYPE_TABLES__ > libc_hidden_proto(__ctype_b) > #endif > well, this case could not be a major issue, it can rewritten like this #ifdef __UCLIBC_HAS_XLOCALE__ #define __CTYPE_B __ctype_b_loc #elif __UCLIBC_HAS_CTYPE_TABLES__ #define __CTYPE_B __ctype_b #endif libc_hidden_proto(__CTYPE_B) > Fifth: it needs to be repeated in every .c file where you want > to use e.g. ctype.h functions! > agree > Obvious solution of adding libc_hidden_proto's to .h files > does not work so well since we'd like to not pollute them with > machinery which doesn't belong to public interface. > but we could scrub public *h at install time by removing all occurences of libc_hidden_proto producing a sort of sanitized libc headers, in the same way kernel does. > In the attached patch, I chose to create a "master include file" > which includes almost all other headers; and then marks > all exported functions(variables) with libc_hidden_proto. > The file is called uClibc_libc.h. > I don't like this approach since I usually prefer explicitely including all specific headers are areally need, no less, no more, instead of a master include header. This is my opinion. I agree with you about the needs of consistently using libc_hidden_proto, but I'd try to find another solution. Anyway, being this a big change, I'd like to hear other opinions and comment. Mike, Jocke, Bernds, Peter others... what do you think ? Cheers, Carmelo From Joakim.Tjernlund at transmode.se Sat Apr 12 06:36:59 2008 From: Joakim.Tjernlund at transmode.se (Joakim Tjernlund) Date: Sat, 12 Apr 2008 15:36:59 +0200 Subject: RFC: first stab at getting rid of libc_hidden_proto() forest In-Reply-To: <48004A0F.4050002@gmail.com> References: <200804120407.07311.vda.linux@googlemail.com> <48004A0F.4050002@gmail.com> Message-ID: <030501c89ca2$48926d90$d9b748b0$@Tjernlund@transmode.se> > -----Original Message----- > From: uclibc-bounces at uclibc.org [mailto:uclibc-bounces at uclibc.org] On Behalf Of Carmelo Amoroso > Sent: den 12 april 2008 07:35 > To: Denys Vlasenko > Cc: Peter S. Mazinger; uclibc at uclibc.org > Subject: Re: RFC: first stab at getting rid of libc_hidden_proto() forest > > Denys Vlasenko wrote: > > Hi, > > > > I want to make clear that I do not intend to apply this patch > > without getting a positive review. I don't want people to > > start thinking "omg, vda can commit this %&&$ and mess up > > the tree"! > > > > I won't. It's really an RFC. > > > > What it does: > > > > I find the need of having libc_hidden_proto(fprintf) > > anywhere you want to use fprintf efficiently (i.e. > > to call it directly, not thru GOT/PLT) to be unmaintainable. > > > Hi, > sounds reasonable... > > First, it clogs up the source. > > > agree > > Second, it's too easy to forget to do it, and you get > > suboptimal code, silently. > > > agree > > Third, sometimes it gets even more ugly: you need to know > > _implementation details_ and dance with #defines like this: > > > > #ifdef __UCLIBC_HAS_XLOCALE__ > > libc_hidden_proto(__ctype_b_loc) > > #elif __UCLIBC_HAS_CTYPE_TABLES__ > > libc_hidden_proto(__ctype_b) > > #endif > > > well, this case could not be a major issue, > it can rewritten like this > > #ifdef __UCLIBC_HAS_XLOCALE__ > #define __CTYPE_B __ctype_b_loc > #elif __UCLIBC_HAS_CTYPE_TABLES__ > #define __CTYPE_B __ctype_b > #endif > > libc_hidden_proto(__CTYPE_B) > > > > Fifth: it needs to be repeated in every .c file where you want > > to use e.g. ctype.h functions! > > > agree > > > Obvious solution of adding libc_hidden_proto's to .h files > > does not work so well since we'd like to not pollute them with > > machinery which doesn't belong to public interface. > > > but we could scrub public *h at install time by removing > all occurences of libc_hidden_proto producing a sort of > sanitized libc headers, in the same way kernel does. > > > In the attached patch, I chose to create a "master include file" > > which includes almost all other headers; and then marks > > all exported functions(variables) with libc_hidden_proto. > > The file is called uClibc_libc.h. > > > I don't like this approach since I usually prefer explicitely > including all specific headers are areally need, no less, no more, > instead of a master include header. yes, and development will hurt too as most of uClibc will need to rebuild when adding some new feature. > > This is my opinion. I agree with you about the needs of consistently > using libc_hidden_proto, but I'd try to find another solution. > > Anyway, being this a big change, I'd like to hear other opinions > and comment. > Mike, Jocke, Bernds, Peter others... what do you think ? Scrubbing headers like Linux do is the best. There will probably be other things in there too that would benefit from such scrubbing. Jocke From vda.linux at googlemail.com Sat Apr 12 06:38:03 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sat, 12 Apr 2008 15:38:03 +0200 Subject: RFC: first stab at getting rid of libc_hidden_proto() forest In-Reply-To: <48004A0F.4050002@gmail.com> References: <200804120407.07311.vda.linux@googlemail.com> <48004A0F.4050002@gmail.com> Message-ID: <200804121538.03527.vda.linux@googlemail.com> On Saturday 12 April 2008 07:35, Carmelo Amoroso wrote: > > I find the need of having libc_hidden_proto(fprintf) > > anywhere you want to use fprintf efficiently (i.e. > > to call it directly, not thru GOT/PLT) to be unmaintainable. > > > Hi, > sounds reasonable... > > First, it clogs up the source. > > > agree > > Second, it's too easy to forget to do it, and you get > > suboptimal code, silently. > > > agree > > Third, sometimes it gets even more ugly: you need to know > > _implementation details_ and dance with #defines like this: > > > > #ifdef __UCLIBC_HAS_XLOCALE__ > > libc_hidden_proto(__ctype_b_loc) > > #elif __UCLIBC_HAS_CTYPE_TABLES__ > > libc_hidden_proto(__ctype_b) > > #endif > > > well, this case could not be a major issue, > it can rewritten like this > > #ifdef __UCLIBC_HAS_XLOCALE__ > #define __CTYPE_B __ctype_b_loc > #elif __UCLIBC_HAS_CTYPE_TABLES__ > #define __CTYPE_B __ctype_b > #endif This adds more unwanted stuff to public headers. > > libc_hidden_proto(__CTYPE_B) > > > Fifth: it needs to be repeated in every .c file where you want > > to use e.g. ctype.h functions! > > > agree > > > Obvious solution of adding libc_hidden_proto's to .h files > > does not work so well since we'd like to not pollute them with > > machinery which doesn't belong to public interface. > > > but we could scrub public *h at install time by removing > all occurences of libc_hidden_proto producing a sort of > sanitized libc headers, in the same way kernel does. > > > In the attached patch, I chose to create a "master include file" > > which includes almost all other headers; and then marks > > all exported functions(variables) with libc_hidden_proto. > > The file is called uClibc_libc.h. > > I don't like this approach since I usually prefer explicitely > including all specific headers are areally need, no less, no more, > instead of a master include header. > > This is my opinion. I agree with you about the needs of consistently > using libc_hidden_proto, but I'd try to find another solution. How about having one "internal" header for each public one? internal/stdio.h would look like this: #include libc_hidden_proto(printf) libc_hidden_proto(sprintf) libc_hidden_proto(vfprintf) ... with #ifdefs etc if some functions are not always present. uclibc .c files would #include instead of > Anyway, being this a big change, I'd like to hear other opinions > and comment. > Mike, Jocke, Bernds, Peter others... what do you think ? -- vda From bernds_cb1 at t-online.de Sat Apr 12 09:05:18 2008 From: bernds_cb1 at t-online.de (Bernd Schmidt) Date: Sat, 12 Apr 2008 18:05:18 +0200 Subject: RFC: first stab at getting rid of libc_hidden_proto() forest In-Reply-To: <48004A0F.4050002@gmail.com> References: <200804120407.07311.vda.linux@googlemail.com> <48004A0F.4050002@gmail.com> Message-ID: <4800DDBE.3090205@t-online.de> Carmelo Amoroso wrote: > Anyway, being this a big change, I'd like to hear other opinions > and comment. > Mike, Jocke, Bernds, Peter others... what do you think ? I agree that the current method is borderline insane. Since we import libc-symbols.h from glibc - what do they do, and do we have good a reason to be different? Bernd -- This footer brought to you by insane German lawmakers. Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif From vda.linux at googlemail.com Sat Apr 12 10:33:37 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sat, 12 Apr 2008 19:33:37 +0200 Subject: RFC: first stab at getting rid of libc_hidden_proto() forest In-Reply-To: <030501c89ca2$48926d90$d9b748b0$@Tjernlund@transmode.se> References: <200804120407.07311.vda.linux@googlemail.com> <48004A0F.4050002@gmail.com> <030501c89ca2$48926d90$d9b748b0$@Tjernlund@transmode.se> Message-ID: <200804121933.37678.vda.linux@googlemail.com> On Saturday 12 April 2008 15:36, Joakim Tjernlund wrote: > > > Obvious solution of adding libc_hidden_proto's to .h files > > > does not work so well since we'd like to not pollute them with > > > machinery which doesn't belong to public interface. > > > > > but we could scrub public *h at install time by removing > > all occurences of libc_hidden_proto producing a sort of > > sanitized libc headers, in the same way kernel does. BTW: simply removing every line which starts with "libc_hidden_proto(" string will not work so nice: #ifdef __UCLIBC_HAS_XLOCALE__ libc_hidden_proto(__ctype_b_loc) #elif __UCLIBC_HAS_CTYPE_TABLES__ libc_hidden_proto(__ctype_b) #endif will turn into #ifdef __UCLIBC_HAS_XLOCALE__ #elif __UCLIBC_HAS_CTYPE_TABLES__ #endif Scrubbing needs to be more clever than that. > > > In the attached patch, I chose to create a "master include file" > > > which includes almost all other headers; and then marks > > > all exported functions(variables) with libc_hidden_proto. > > > The file is called uClibc_libc.h. > > > > > I don't like this approach since I usually prefer explicitely > > including all specific headers are areally need, no less, no more, > > instead of a master include header. > > yes, and development will hurt too as most of uClibc will need to rebuild > when adding some new feature. How ofter do you change public headers? I believe most changes go into implementation of the libc interface, not in interface. > > This is my opinion. I agree with you about the needs of consistently > > using libc_hidden_proto, but I'd try to find another solution. > > > > Anyway, being this a big change, I'd like to hear other opinions > > and comment. > > Mike, Jocke, Bernds, Peter others... what do you think ? > > Scrubbing headers like Linux do is the best. There will probably be other > things in there too that would benefit from such scrubbing. Sounds reasonable. What method do you prefer? #ifdef blocks with a special #define which are removed by scrubber script? E.g.: #ifdef UCLIBC_INTERNAL ...yadda yadda... #endif Magic comment? Scrubber script will just delete it and everything below till the end of file: /* *** UCLIBC_INTERNAL *** */ ...yadda yadda... Other method I didn't think about? -- vda From Joakim.Tjernlund at transmode.se Sat Apr 12 12:22:57 2008 From: Joakim.Tjernlund at transmode.se (Joakim Tjernlund) Date: Sat, 12 Apr 2008 21:22:57 +0200 Subject: RFC: first stab at getting rid of libc_hidden_proto() forest In-Reply-To: <200804121933.37678.vda.linux@googlemail.com> References: <200804120407.07311.vda.linux@googlemail.com> <48004A0F.4050002@gmail.com> <030501c89ca2$48926d90$d9b748b0$@Tjernlund@transmode.se> <200804121933.37678.vda.linux@googlemail.com> Message-ID: <034301c89cd2$9d823300$d8869900$@Tjernlund@transmode.se> > -----Original Message----- > From: Denys Vlasenko [mailto:vda.linux at googlemail.com] > Sent: den 12 april 2008 19:34 > To: Joakim Tjernlund > Cc: carmelo73 at gmail.com; 'Peter S. Mazinger'; uclibc at uclibc.org > Subject: Re: RFC: first stab at getting rid of libc_hidden_proto() forest > > On Saturday 12 April 2008 15:36, Joakim Tjernlund wrote: > > > > Obvious solution of adding libc_hidden_proto's to .h files > > > > does not work so well since we'd like to not pollute them with > > > > machinery which doesn't belong to public interface. > > > > > > > but we could scrub public *h at install time by removing > > > all occurences of libc_hidden_proto producing a sort of > > > sanitized libc headers, in the same way kernel does. > > BTW: simply removing every line which starts with "libc_hidden_proto(" > string will not work so nice: > > #ifdef __UCLIBC_HAS_XLOCALE__ > libc_hidden_proto(__ctype_b_loc) > #elif __UCLIBC_HAS_CTYPE_TABLES__ > libc_hidden_proto(__ctype_b) > #endif > > will turn into > > #ifdef __UCLIBC_HAS_XLOCALE__ > #elif __UCLIBC_HAS_CTYPE_TABLES__ > #endif > > Scrubbing needs to be more clever than that. > > > > > In the attached patch, I chose to create a "master include file" > > > > which includes almost all other headers; and then marks > > > > all exported functions(variables) with libc_hidden_proto. > > > > The file is called uClibc_libc.h. > > > > > > > I don't like this approach since I usually prefer explicitely > > > including all specific headers are areally need, no less, no more, > > > instead of a master include header. > > > > yes, and development will hurt too as most of uClibc will need to rebuild > > when adding some new feature. > > How ofter do you change public headers? I believe most changes go into > implementation of the libc interface, not in interface. Maybe, was just a quick comment. > > > > This is my opinion. I agree with you about the needs of consistently > > > using libc_hidden_proto, but I'd try to find another solution. > > > > > > Anyway, being this a big change, I'd like to hear other opinions > > > and comment. > > > Mike, Jocke, Bernds, Peter others... what do you think ? > > > > Scrubbing headers like Linux do is the best. There will probably be other > > things in there too that would benefit from such scrubbing. > > Sounds reasonable. What method do you prefer? > > #ifdef blocks with a special #define which are removed by scrubber script? > E.g.: > > #ifdef UCLIBC_INTERNAL > ...yadda yadda... > #endif This one, I belive the kernel does it this way to. Hopefully we can take the scrubbing procedure from there. I really hope Mike can chim in here, I belive he the expert around here on such things. Jocke From m.b.lankhorst at gmail.com Sun Apr 13 20:06:18 2008 From: m.b.lankhorst at gmail.com (Maarten Lankhorst) Date: Sun, 13 Apr 2008 20:06:18 -0700 Subject: RFC: [PATCH] Make -static builds work again without crashing Message-ID: Hi all, After some experimenting I came to the conclusion that the minimum app that won't crash with gcc -static is printf("%.0d", 0); which is essentially a noop printf. So my patch calls that before calling main. Looking for feedback on the patch. Cheers, Maarten -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: fix_static.txt Url: http://busybox.net/lists/uclibc/attachments/20080413/a3a0ef28/attachment.txt From drow at false.org Sun Apr 13 20:13:11 2008 From: drow at false.org (Daniel Jacobowitz) Date: Sun, 13 Apr 2008 23:13:11 -0400 Subject: RFC: first stab at getting rid of libc_hidden_proto() forest In-Reply-To: <4800DDBE.3090205@t-online.de> References: <200804120407.07311.vda.linux@googlemail.com> <48004A0F.4050002@gmail.com> <4800DDBE.3090205@t-online.de> Message-ID: <20080414031311.GA31348@caradoc.them.org> On Sat, Apr 12, 2008 at 06:05:18PM +0200, Bernd Schmidt wrote: > Carmelo Amoroso wrote: > > Anyway, being this a big change, I'd like to hear other opinions > > and comment. > > Mike, Jocke, Bernds, Peter others... what do you think ? > > I agree that the current method is borderline insane. > > Since we import libc-symbols.h from glibc - what do they do, and do we > have good a reason to be different? There's a second header in include/ that uses #include_next. An advantage of using a single header like vda suggested is that you could use PCH for it... -- Daniel Jacobowitz CodeSourcery From mpfj at mimc.co.uk Mon Apr 14 04:27:46 2008 From: mpfj at mimc.co.uk (Mark Jackson) Date: Mon, 14 Apr 2008 12:27:46 +0100 Subject: Decimal floating point support Message-ID: <48033FB2.20007@mimc.co.uk> I am using the Atmel buildroot distro for the Atmel NGW100 dev kit, and I have everything up and running as expected. What I would like to know is ... how can I add decimal floating point support to uclibc ? I understand that gcc now supports decimal floating point (dfp), but it's missing from uclibc itself. Can anyone point me in the right direction ? Thanks for any help, Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/uclibc/attachments/20080414/5cefa75b/attachment.htm From vda.linux at googlemail.com Mon Apr 14 04:55:11 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Mon, 14 Apr 2008 13:55:11 +0200 Subject: RFC: [PATCH] Make -static builds work again without crashing In-Reply-To: References: Message-ID: <200804141355.11959.vda.linux@googlemail.com> On Monday 14 April 2008 05:06, Maarten Lankhorst wrote: > Hi all, > > After some experimenting I came to the conclusion that the minimum app > that won't crash with gcc -static is printf("%.0d", 0); which is > essentially a noop printf. So my patch calls that before calling main. > > Looking for feedback on the patch. ?! Ths will force stdio to be linked it into every application. How about fixing the problem instead of papering over it? I think the possible reason is that _stdio_init is a weak symbol: extern void weak_function _stdio_init(void) attribute_hidden; and here we check that it was linked in, only if it was, we run it: /* * Initialize stdio here. In the static library case, this will * be bypassed if not needed because of the weak alias above. * Thus we get a nice size savings because the stdio functions * won't be pulled into the final static binary unless used. */ if (likely(_stdio_init != NULL)) _stdio_init(); But current gcc assumes (and it's allowed by C standard) that function address is never NULL. So it optimizes away this if(), and calls _stdio_init() unconditionally. If it indeed is NULL, we crash. -- vda From m.b.lankhorst at gmail.com Mon Apr 14 10:11:20 2008 From: m.b.lankhorst at gmail.com (Maarten Lankhorst) Date: Mon, 14 Apr 2008 10:11:20 -0700 Subject: RFC: [PATCH] Make -static builds work again without crashing In-Reply-To: References: <200804141355.11959.vda.linux@googlemail.com> Message-ID: Hello Denys, 2008/4/14, Denys Vlasenko : > On Monday 14 April 2008 05:06, Maarten Lankhorst wrote: > > Hi all, > > > > After some experimenting I came to the conclusion that the minimum app > > that won't crash with gcc -static is printf("%.0d", 0); which is > > essentially a noop printf. So my patch calls that before calling main. > > > > Looking for feedback on the patch. > > > ?! > > Ths will force stdio to be linked it into every application. > > How about fixing the problem instead of papering over it? > > I think the possible reason is that _stdio_init is a weak symbol: > > extern void weak_function _stdio_init(void) attribute_hidden; > > and here we check that it was linked in, only if it was, we run it: > > /* > * Initialize stdio here. In the static library case, this will > * be bypassed if not needed because of the weak alias above. > * Thus we get a nice size savings because the stdio functions > * won't be pulled into the final static binary unless used. > */ > if (likely(_stdio_init != NULL)) > _stdio_init(); > > But current gcc assumes (and it's allowed by C standard) that function > address is never NULL. So it optimizes away this if(), and calls > _stdio_init() unconditionally. If it indeed is NULL, we crash. I don't think this is the issue here, if I remove the call to _stdio_init call in __uClibc_init it will still crash. Cheers, Maarten. From vda.linux at googlemail.com Mon Apr 14 10:47:05 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Mon, 14 Apr 2008 19:47:05 +0200 Subject: RFC: [PATCH] Make -static builds work again without crashing In-Reply-To: References: Message-ID: <200804141947.05094.vda.linux@googlemail.com> On Monday 14 April 2008 19:11, Maarten Lankhorst wrote: > > > After some experimenting I came to the conclusion that the minimum app > > > that won't crash with gcc -static is printf("%.0d", 0); which is > > > essentially a noop printf. So my patch calls that before calling main. > > > > > > Looking for feedback on the patch. > > > > > > ?! > > > > Ths will force stdio to be linked it into every application. > > > > How about fixing the problem instead of papering over it? > > > > I think the possible reason is that _stdio_init is a weak symbol: > > > > extern void weak_function _stdio_init(void) attribute_hidden; > > > > and here we check that it was linked in, only if it was, we run it: > > > > /* > > * Initialize stdio here. In the static library case, this will > > * be bypassed if not needed because of the weak alias above. > > * Thus we get a nice size savings because the stdio functions > > * won't be pulled into the final static binary unless used. > > */ > > if (likely(_stdio_init != NULL)) > > _stdio_init(); > > > > But current gcc assumes (and it's allowed by C standard) that function > > address is never NULL. So it optimizes away this if(), and calls > > _stdio_init() unconditionally. If it indeed is NULL, we crash. > > I don't think this is the issue here, if I remove the call to > _stdio_init call in __uClibc_init it will still crash. Just adding bogus printf is still not a solution. Where it crashes? -- vda From tp at fonz.de Fri Apr 18 03:28:06 2008 From: tp at fonz.de (Tobias Poschwatta) Date: Fri, 18 Apr 2008 12:28:06 +0200 Subject: mmap64 undefined on arm oabi Message-ID: <20080418102806.GC21579@kiwi> Hi, the 'pure thumb' patch seems to be missing the mmap64 label for the OABI case: http://www.uclibc.org/cgi-bin/viewcvs.cgi/trunk/uClibc/libc/sysdeps/linux/arm/mmap64.S?rev=21498&r1=13912&r2=21498&diff_format=h # readelf -s libc.so.0 | grep mmap64 923: 00000000 0 FUNC GLOBAL DEFAULT UND mmap64 Following patch fixed it here. BR, Tobias --- uClibc/libc/sysdeps/linux/arm/mmap64.S.orig 2008-04-18 12:06:09.000000000 +0200 +++ uClibc/libc/sysdeps/linux/arm/mmap64.S 2008-04-18 12:06:33.000000000 +0200 @@ -104,6 +104,7 @@ b __syscall_error #endif #else /* !__ARM_EABI__ */ +mmap64: stmfd sp!, {r4, r5, lr} ldr r5, [sp, $16] ldr r4, [sp, $12] From daniel at zuster.org Sat Apr 19 07:03:09 2008 From: daniel at zuster.org (Daniel Dunbar) Date: Sat, 19 Apr 2008 07:03:09 -0700 (PDT) Subject: Bug report: strtol conversion Message-ID: <918039.7407.qm@web54603.mail.re2.yahoo.com> var YAHOO = {'Shortcuts' : {}}; YAHOO.Shortcuts.hasSensitiveText = false; YAHOO.Shortcuts.sensitivityType = []; YAHOO.Shortcuts.doUlt = false; YAHOO.Shortcuts.location = "us"; YAHOO.Shortcuts.document_id = 0; YAHOO.Shortcuts.document_type = ""; YAHOO.Shortcuts.document_title = "Bug report: strtol conversion"; YAHOO.Shortcuts.document_publish_date = ""; YAHOO.Shortcuts.document_author = "daniel at zuster.org"; YAHOO.Shortcuts.document_url = ""; YAHOO.Shortcuts.document_tags = ""; YAHOO.Shortcuts.annotationSet = { }; Hi, I believe I have found a bug in the current uclibc implementation of strtol (and friends). An example failing program is: assert(strtol("+2``2`4", 0, 10) == 2); The problem is that uclibc is treating the characters '`' as the digit 9. The bug is in the vicinity of stdlib.c:561 (and 712), in the digit computation: -- digit = (((Wuchar)(*str - '0')) <= 9) ? (*str - '0') : (((*str) >= 'A') ? (((0x20|(*str)) - 'a' + 10)) /* WARNING: assumes ascii. */ : 40); -- I do not know what the preferred fix is, but I have verified that the following code at least correctly computes digits for base 10. -- digit = (((Wuchar)(*str - '0')) <= 9) ? (*str - '0') : (((0x20|(*str)) >= 'A') ? (((0x20|(*str)) - 'a' + 10)) /* WARNING: assumes ascii. */ : 40); -- - Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/uclibc/attachments/20080419/0995f0e8/attachment.htm From carmelo73 at gmail.com Sat Apr 19 12:18:09 2008 From: carmelo73 at gmail.com (Carmelo Amoroso) Date: Sat, 19 Apr 2008 21:18:09 +0200 Subject: RFC: [PATCH] Make -static builds work again without crashing In-Reply-To: References: Message-ID: <480A4571.10900@gmail.com> Maarten Lankhorst wrote: > Hi all, > > After some experimenting I came to the conclusion that the minimum app > that won't crash with gcc -static is printf("%.0d", 0); which is > essentially a noop printf. So my patch calls that before calling main. > > Looking for feedback on the patch. > > Cheers, > Maarten > > > ------------------------------------------------------------------------ > > Index: libc/misc/internals/__uClibc_main.c > =================================================================== > --- a/libc/misc/internals/__uClibc_main.c (revision 21727) > +++ b/libc/misc/internals/__uClibc_main.c (working copy) > @@ -393,6 +393,10 @@ > if (likely(__h_errno_location!=NULL)) > *(__h_errno_location()) = 0; > > +#ifndef SHARED > + printf("%.0d",0); > +#endif > + > /* > * Finally, invoke application's main and then exit. > */ > ??? what kind of fix is it ??? Obviously this will be never added !!! I suggest to start debugging to see where it craches, and if you can, provide a real patch. Anyway, I did not experience problem with uclibc-nptl branch on sh4 when statically linked. Regards, Carmelo > > ------------------------------------------------------------------------ > > _______________________________________________ > uClibc mailing list > uClibc at uclibc.org > http://busybox.net/cgi-bin/mailman/listinfo/uclibc From carmelo73 at gmail.com Sat Apr 19 12:22:27 2008 From: carmelo73 at gmail.com (Carmelo Amoroso) Date: Sat, 19 Apr 2008 21:22:27 +0200 Subject: NPTL merge: almost ready to start Message-ID: <480A4673.40501@gmail.com> Hi All, just to inform all of you that I have successfully tested the nptl branch on sh4 after my latest trunk->branch merge. I'd like to check something else, then, asap, I'd like to start merging the branch->trunk so that finally we'll complete a so long still pending work. Please be patient due to my others duties with my work, but this is one of my top priorities in the next months. Best regards, Carmelo From carmelo73 at gmail.com Sat Apr 19 23:09:43 2008 From: carmelo73 at gmail.com (Carmelo Amoroso) Date: Sun, 20 Apr 2008 08:09:43 +0200 Subject: Issues on linuxthreads Message-ID: <480ADE27.1010603@gmail.com> Hi All, recently there have been reported several issues on libpthread segfaulting while running simple application. It has been discovered that users were using linuxthreads implementation instead of (stable ?) linuxthreads.old. I don't know what is the current status of linuxthreadsde developmnet, neither I remember who is doing the development. I don't have currently any time for investigating on this beinf NPTL my target implementation, but as a general rule, at least until somebody will provide a patch for those problems, I'd suggest to all users to *use linuxthreads.old* library. Anyway, solving the linuxthreads bug is something to be dobe as well. Cheers, Carmelo From mike.rosset at gmail.com Sun Apr 20 17:40:37 2008 From: mike.rosset at gmail.com (zio) Date: Sun, 20 Apr 2008 17:40:37 -0700 (PDT) Subject: uArch Message-ID: <16776094.post@talk.nabble.com> Hello all, just wanted to post a quick message. we are looking for feedback on uarch a micro linux distro. its basically a port of archlinux to uclibc and its moving along quite well you can find more information here http://code.google.com/p/uarch/ uArch any feedback would be helpful Regards, Mike Rosset -- View this message in context: http://www.nabble.com/uArch-tp16776094p16776094.html Sent from the uClibc mailing list archive at Nabble.com. From xrinoscar at yahoo.com.sg Sun Apr 20 21:18:12 2008 From: xrinoscar at yahoo.com.sg (xrin oscar) Date: Mon, 21 Apr 2008 12:18:12 +0800 (SGT) Subject: installation question? Message-ID: <351303.89502.qm@web76103.mail.sg1.yahoo.com> Hi, 1) I am using RHEL 5. During install, the installer complain about not able to find /usr/src/linux. This is because RHEL 5 does not have this directory. How to solve this problem?? 2) a pre-compiled uClibc development system. I follow the instruction to download the root_fs image but cannot be mount to the system. what does this mount command trying to perform ??? and where to find this root_fs_i386 folder. * Download root_fs_i386.bz2 from uclibc.org * bunzip2 root_fs_i386.bz2 * mkdir root_fs * su root * mount -o loop root_fs_i386 root_fs * chroot root_fs /bin/su - Hope someone can help to explain it. Thanks. Xrin. ______________________________________________________________________ Search, browse and book your hotels and flights through Yahoo! Travel. http://sg.travel.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/uclibc/attachments/20080421/f5d176b5/attachment.htm From xrinoscar at yahoo.com.sg Sun Apr 20 22:43:53 2008 From: xrinoscar at yahoo.com.sg (xrin oscar) Date: Mon, 21 Apr 2008 13:43:53 +0800 (SGT) Subject: uClibc compiler without stropts.h Message-ID: <647751.37976.qm@web76102.mail.sg1.yahoo.com> Hi, is there any reason for leaving out?stropts.h file in uclibc compiler's include folder?? regards. ______________________________________________________________________ Search, browse and book your hotels and flights through Yahoo! Travel. http://sg.travel.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/uclibc/attachments/20080421/f63a2f32/attachment.htm From vda.linux at googlemail.com Sun Apr 20 22:56:12 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Mon, 21 Apr 2008 07:56:12 +0200 Subject: installation question? In-Reply-To: <351303.89502.qm@web76103.mail.sg1.yahoo.com> References: <351303.89502.qm@web76103.mail.sg1.yahoo.com> Message-ID: <200804210756.12043.vda.linux@googlemail.com> On Monday 21 April 2008 06:18, xrin oscar wrote: > Hi, > 1) > I am using RHEL 5. > During install, the installer complain about not able to find /usr/src/linux. > This is because RHEL 5 does not have this directory. > How to solve this problem?? I do not understand the question. Please describe in more details what you are doing. -- vda From vda.linux at googlemail.com Sun Apr 20 22:56:41 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Mon, 21 Apr 2008 07:56:41 +0200 Subject: uClibc compiler without stropts.h In-Reply-To: <647751.37976.qm@web76102.mail.sg1.yahoo.com> References: <647751.37976.qm@web76102.mail.sg1.yahoo.com> Message-ID: <200804210756.41352.vda.linux@googlemail.com> On Monday 21 April 2008 07:43, xrin oscar wrote: > Hi, > is there any reason for leaving out?stropts.h file in > uclibc compiler's include folder?? uclibc is not a compiler. -- vda From hans-christian.egtvedt at atmel.com Sun Apr 20 23:14:33 2008 From: hans-christian.egtvedt at atmel.com (Hans-Christian Egtvedt) Date: Mon, 21 Apr 2008 08:14:33 +0200 Subject: installation question? In-Reply-To: <200804210756.12043.vda.linux@googlemail.com> References: <351303.89502.qm@web76103.mail.sg1.yahoo.com> <200804210756.12043.vda.linux@googlemail.com> Message-ID: <1208758473.21860.1.camel@localhost> On Mon, 2008-04-21 at 07:56 +0200, Denys Vlasenko wrote: > On Monday 21 April 2008 06:18, xrin oscar wrote: > > Hi, > > 1) > > I am using RHEL 5. > > During install, the installer complain about not able to find /usr/src/linux. > > This is because RHEL 5 does not have this directory. > > How to solve this problem?? > You must specify where you kernel headers are installed, this is done in kconfig system. I.e. the KERNEL_HEADERS variable in .config. -- With kind regards, Hans-Christian Egtvedt, Applications Engineer From xrinoscar at yahoo.com.sg Mon Apr 21 00:18:55 2008 From: xrinoscar at yahoo.com.sg (xrin oscar) Date: Mon, 21 Apr 2008 15:18:55 +0800 (SGT) Subject: installation question? Message-ID: <373093.98017.qm@web76105.mail.sg1.yahoo.com> Hi, I have specify the path to /usr/src/kernel and perform the following but is seeing errors @localhost uClibc-0.9.28.3]$ make CROSS=arm-linux- make: arm-linux-gcc: Command not found make: arm-linux-gcc: Command not found what can i do about it?? regards, Xrin. On Mon, 2008-04-21 at 07:56 +0200, Denys Vlasenko wrote: > On Monday 21 April 2008 06:18, xrin oscar wrote: > > Hi, > > 1) > > I am using RHEL 5. > > During install, the installer complain about not able to find /usr/src/linux. > > This is because RHEL 5 does not have this directory. > > How to solve this problem?? > You must specify where you kernel headers are installed, this is done in kconfig system. I.e. the KERNEL_HEADERS variable in .config. -- With kind regards, Hans-Christian Egtvedt, Applications Engineer ______________________________________________________________________ Search, browse and book your hotels and flights through Yahoo! Travel. http://sg.travel.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/uclibc/attachments/20080421/091b0faa/attachment.htm From xrinoscar at yahoo.com.sg Mon Apr 21 00:23:57 2008 From: xrinoscar at yahoo.com.sg (xrin oscar) Date: Mon, 21 Apr 2008 15:23:57 +0800 (SGT) Subject: how to install and use pre-compiled uClibc Message-ID: <168386.27335.qm@web76108.mail.sg1.yahoo.com> Hi, for a pre-compiled uClibc development system. ? I follow the instruction to download the root_fs image but cannot be mount to the system (Distribution RHEL5). what does this mount command trying to perform and how can i?get it to mount to root_fs_i386 folder. I wanted to test compiling codes with uclibc. step-by-step instructions * Download root_fs_i386.bz2 from uclibc.org * bunzip2 root_fs_i386.bz2 * mkdir root_fs * su root * mount -o loop root_fs_i386 root_fs * chroot root_fs /bin/su - thanks and regards, Xrin. ______________________________________________________________________ Search, browse and book your hotels and flights through Yahoo! Travel. http://sg.travel.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/uclibc/attachments/20080421/c67b332a/attachment.htm From raj.khem at gmail.com Mon Apr 21 00:33:06 2008 From: raj.khem at gmail.com (Khem Raj) Date: Mon, 21 Apr 2008 00:33:06 -0700 Subject: PATCH: ARM INTERNAL_SYSCALL cleanup Message-ID: <1208763186.2711.6.camel@isis> Hi There was some duplication when defining INTERNAL_SYSCALL macro for ARM. I have tried to clean this up with attached patch. Tested on ARM EABI and ARM OABI. Deleted commented out code too. OK for trunk ? Thanks -Khem Signed-off-by: Khem Raj Index: libc/sysdeps/linux/arm/bits/syscalls.h =================================================================== --- libc/sysdeps/linux/arm/bits/syscalls.h (revision 21775) +++ libc/sysdeps/linux/arm/bits/syscalls.h (working copy) @@ -106,100 +106,55 @@ #define INTERNAL_SYSCALL_DECL(err) do { } while (0) #undef INTERNAL_SYSCALL -#if defined(__ARM_EABI__) #if !defined(__thumb__) -#define INTERNAL_SYSCALL(name, err, nr, args...) \ - ({unsigned int __sys_result; \ - { \ - register int _a1 __asm__ ("r0"), _nr __asm__ ("r7"); \ - LOAD_ARGS_##nr (args) \ - _nr = SYS_ify(name); \ - __asm__ volatile ("swi 0x0 @ syscall " #name \ - : "=r" (_a1) \ - : "r" (_nr) ASM_ARGS_##nr \ - : "memory"); \ - __sys_result = _a1; \ - } \ - (int) __sys_result; }) -#else /* !defined(__thumb__) */ -/* So hide the use of r7 from the compiler, this would be a lot - * easier but for the fact that the syscalls can exceed 255. - * For the moment the LOAD_ARG_7 is sacrificed. - */ -#define INTERNAL_SYSCALL(name, err, nr, args...) \ - ({ unsigned int __sys_result; \ - { \ - register int _a1 asm ("a1"); \ - LOAD_ARGS_##nr (args) \ - register int _v3 asm ("v3") = (int) (SYS_ify(name)); \ - asm volatile ("push {r7}\n" \ - "\tmov r7, v3\n" \ - "\tswi 0 @ syscall " #name "\n" \ - "\tpop {r7}" \ - : "=r" (_a1) \ - : "r" (_v3) ASM_ARGS_##nr \ - : "memory"); \ - __sys_result = _a1; \ - } \ - (int) __sys_result; }) -#endif /*!defined(__thumb__)*/ -#else /* !defined(__ARM_EABI__) */ -#if !defined(__thumb__) +#if defined(__ARM_EABI__) #define INTERNAL_SYSCALL(name, err, nr, args...) \ - ({ unsigned int __sys_result; \ + ({unsigned int __sys_result; \ { \ - register int _a1 __asm__ ("a1"); \ + register int _a1 __asm__ ("r0"), _nr __asm__ ("r7"); \ LOAD_ARGS_##nr (args) \ - __asm__ volatile ("swi %1 @ syscall " #name \ + _nr = SYS_ify(name); \ + __asm__ volatile ("swi 0x0 @ syscall " #name \ : "=r" (_a1) \ - : "i" (SYS_ify(name)) ASM_ARGS_##nr \ + : "r" (_nr) ASM_ARGS_##nr \ : "memory"); \ __sys_result = _a1; \ } \ (int) __sys_result; }) -#else -#if 0 -/* This doesn't work because GCC uses r7 as a frame pointer in - * some cases and doesn't notice that the _r7 value changes - * it, resulting in mysterious crashes after the SWI. - */ +#else /* defined(__ARM_EABI__) */ + #define INTERNAL_SYSCALL(name, err, nr, args...) \ ({ unsigned int __sys_result; \ { \ register int _a1 __asm__ ("a1"); \ LOAD_ARGS_##nr (args) \ - register int _r7 __asm__ ("r7") = (int) (SYS_ify(name)); \ - __asm__ volatile ("swi 0 @ syscall " #name \ + __asm__ volatile ("swi %1 @ syscall " #name \ : "=r" (_a1) \ - : "r" (_r7) ASM_ARGS_##nr \ + : "i" (SYS_ify(name)) ASM_ARGS_##nr \ : "memory"); \ __sys_result = _a1; \ } \ (int) __sys_result; }) -#else -/* So hide the use of r7 from the compiler, this would be a lot - * easier but for the fact that the syscalls can exceed 255. - * For the moment the LOAD_ARG_7 is sacrificed. - */ +#endif +#else /* !defined(__thumb__) */ + #define INTERNAL_SYSCALL(name, err, nr, args...) \ ({ unsigned int __sys_result; \ - { \ - register int _a1 __asm__ ("a1"); \ - LOAD_ARGS_##nr (args) \ - register int _v3 __asm__ ("v3") = (int) (SYS_ify(name)); \ - __asm__ volatile ("push {r7}\n" \ - "\tmov r7, v3\n" \ - "\tswi 0 @ syscall " #name "\n" \ - "\tpop {r7}" \ - : "=r" (_a1) \ - : "r" (_v3) ASM_ARGS_##nr \ - : "memory"); \ - __sys_result = _a1; \ - } \ - (int) __sys_result; }) -#endif -#endif -#endif /* !defined(__ARM_EABI__) */ + { \ + register int _a1 asm ("a1"); \ + LOAD_ARGS_##nr (args) \ + register int _v3 asm ("v3") = (int) (SYS_ify(name)); \ + asm volatile ("push {r7}\n" \ + "\tmov r7, v3\n" \ + "\tswi 0 @ syscall " #name "\n" \ + "\tpop {r7}" \ + : "=r" (_a1) \ + : "r" (_v3) ASM_ARGS_##nr \ + : "memory"); \ + __sys_result = _a1; \ + } \ + (int) __sys_result; }) +#endif /*!defined(__thumb__)*/ #undef INTERNAL_SYSCALL_ERROR_P #define INTERNAL_SYSCALL_ERROR_P(val, err) \ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://busybox.net/lists/uclibc/attachments/20080421/bfc7fdf8/attachment-0001.pgp From hans-christian.egtvedt at atmel.com Mon Apr 21 00:38:02 2008 From: hans-christian.egtvedt at atmel.com (Hans-Christian Egtvedt) Date: Mon, 21 Apr 2008 09:38:02 +0200 Subject: installation question? In-Reply-To: <373093.98017.qm@web76105.mail.sg1.yahoo.com> References: <373093.98017.qm@web76105.mail.sg1.yahoo.com> Message-ID: <1208763482.30109.0.camel@localhost> On Mon, 2008-04-21 at 15:18 +0800, xrin oscar wrote: > Hi, > > I have specify the path to /usr/src/kernel and perform the following > but is seeing errors > > @localhost uClibc-0.9.28.3]$ make CROSS=arm-linux- > make: arm-linux-gcc: Command not found > make: arm-linux-gcc: Command not found > > what can i do about it?? > Install an ARM cross compiler. -- With kind regards, Hans-Christian Egtvedt, Applications Engineer From xrinoscar at yahoo.com.sg Mon Apr 21 00:56:28 2008 From: xrinoscar at yahoo.com.sg (xrin oscar) Date: Mon, 21 Apr 2008 15:56:28 +0800 (SGT) Subject: installation question? Message-ID: <968127.55029.qm@web76108.mail.sg1.yahoo.com> Hi, I have downloaded the http://www.uclibc.org/toolchains.html?and follow the instruction to build?the uClibc toolchain. But when it comes to run 'make' the following occurs. what should i do?? how should i resolve the issue? thanks and regards, Xrin. ------------------------------------------------------------------------------------------------------------ __________________________________________________________________ Tired of visiting multiple sites for showtimes? Yahoo! Movies is all you need http://sg.movies.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/uclibc/attachments/20080421/d00fb463/attachment.htm From ricard.wanderlof at axis.com Mon Apr 21 00:29:27 2008 From: ricard.wanderlof at axis.com (Ricard Wanderlof) Date: Mon, 21 Apr 2008 09:29:27 +0200 (CEST) Subject: installation question? In-Reply-To: <373093.98017.qm@web76105.mail.sg1.yahoo.com> References: <373093.98017.qm@web76105.mail.sg1.yahoo.com> Message-ID: On Mon, 21 Apr 2008, xrin oscar wrote: > Hi, > > I have specify the path to /usr/src/kernel and perform the following > but is seeing errors > > @localhost uClibc-0.9.28.3]$ make CROSS=arm-linux- > make: arm-linux-gcc: Command not found > make: arm-linux-gcc: Command not found > > what can i do about it?? Seems like you don't have an ARM target compiler in your PATH. Have you tried using buildroot (www.buildroot.org) to make the whole toolchain + uclibc package? Seems like you are having problems getting everything together. /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 xrinoscar at yahoo.com.sg Mon Apr 21 01:21:02 2008 From: xrinoscar at yahoo.com.sg (xrin oscar) Date: Mon, 21 Apr 2008 16:21:02 +0800 (SGT) Subject: compile error with ether_addr.o Message-ID: <879865.98591.qm@web76113.mail.sg1.yahoo.com> Hi, when run 'make' the following appears. How can i resolve it? @localhost uClibc-0.9.28.3]$make CROSS=armv5l-linux- ../../include/asm/posix_types.h:10:error: redefinition of typedef '__kernel_ino_t' ../../include/bits/kernel_types.h:11:error: redefinition of typedef '__kernel_ino_t' was here ../../include/asm/posix_types.h:11:error: redefinition of typedef '__kernel_mode_t' ../../include/bits/kernel_types.h:12:error:?previous declaration of?'__kernel_mode_t' make[1]: ***[ether_addr.o] Error 1 make[1]: Leaving directory '/root_fs/uClibc-0.9.28.3/libc/inet' thanks and regards, Xrin __________________________________________________________________ Yahoo! Singapore Answers Real people. Real questions. Real answers. Share what you know at http://answers.yahoo.com.sg -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/uclibc/attachments/20080421/e38dcf23/attachment.htm From peter.kjellerstedt at axis.com Mon Apr 21 00:57:48 2008 From: peter.kjellerstedt at axis.com (Peter Kjellerstedt) Date: Mon, 21 Apr 2008 09:57:48 +0200 Subject: uClibc compiler without stropts.h References: <647751.37976.qm@web76102.mail.sg1.yahoo.com> <200804210756.41352.vda.linux@googlemail.com> Message-ID: <50BF37ECE4954A4BA18C08D0C2CF88CB0411EDAF@exmail1.se.axis.com> > -----Original Message----- > From: uclibc-bounces at uclibc.org [mailto:uclibc-bounces at uclibc.org] On > Behalf Of Denys Vlasenko > Sent: den 21 april 2008 07:57 > To: uclibc at uclibc.org > Subject: Re: uClibc compiler without stropts.h > > On Monday 21 April 2008 07:43, xrin oscar wrote: > > Hi, > > is there any reason for leaving out?stropts.h file in > > uclibc compiler's include folder?? > > uclibc is not a compiler. > -- > vda The reason there is no stropts.h in uClibc is because uClibc does not support STREAMs and thus there is no reason to provide it as it would be of no use anyway. //Peter From xrinoscar at yahoo.com.sg Mon Apr 21 02:04:28 2008 From: xrinoscar at yahoo.com.sg (xrin oscar) Date: Mon, 21 Apr 2008 17:04:28 +0800 (SGT) Subject: compile error with ether_addr.o Message-ID: <58084.85654.qm@web76105.mail.sg1.yahoo.com> Hi, the same typedef was define twice. one is in posix_types.h and one is in kernel_types.h how to make sure that these 2 files don't conflict with each other?? ================================================================================ Hi, ? when run 'make' the following appears. How can i resolve it? ? ? @localhost uClibc-0.9.28.3]$make CROSS=armv5l-linux- ? ../../include/asm/posix_types.h:10:error: redefinition of typedef '__kernel_ino_t' ../../include/bits/kernel_types.h:11:error: redefinition of typedef '__kernel_ino_t' was here ../../include/asm/posix_types.h:11:error: redefinition of typedef '__kernel_mode_t' ../../include/bits/kernel_types.h:12:error:?previous declaration of?'__kernel_mode_t' ? make[1]: ***[ether_addr.o] Error 1 make[1]: Leaving directory '/root_fs/uClibc-0.9.28.3/libc/inet' ? ? thanks and regards, Xrin ________________________________ Live Chat NOW! Love in 1 Click! __________________________________________________________________ Tired of visiting multiple sites for showtimes? Yahoo! Movies is all you need http://sg.movies.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/uclibc/attachments/20080421/6b3d0da2/attachment.htm From timo.teras at iki.fi Mon Apr 21 02:33:59 2008 From: timo.teras at iki.fi (=?ISO-8859-1?Q?Timo_Ter=E4s?=) Date: Mon, 21 Apr 2008 12:33:59 +0300 Subject: [PATCH] splice, vmsplice and tee for i386 Message-ID: <480C5F87.3060707@iki.fi> Hi, splice et al for i386. Against svn trunk. Cheers, Timo -------------- next part -------------- A non-text attachment was scrubbed... Name: uclibc-splice.diff Type: text/x-patch Size: 3839 bytes Desc: not available Url : http://busybox.net/lists/uclibc/attachments/20080421/b6ce1cad/attachment-0001.bin From rep.dot.nop at gmail.com Mon Apr 21 05:21:13 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Mon, 21 Apr 2008 14:21:13 +0200 Subject: [PATCH] splice, vmsplice and tee for i386 In-Reply-To: <480C5F87.3060707@iki.fi> References: <480C5F87.3060707@iki.fi> Message-ID: <20080421122113.GC18155@mx.loc> On Mon, Apr 21, 2008 at 12:33:59PM +0300, Timo Ter?s wrote: >Hi, > >splice et al for i386. Against svn trunk. Ah, yes. We should also see if using some of the new syscalls help busybox. I'll apply this patch in a few days unless i hear something controversial. thanks and cheers, Bernhard From filippo.arcidiacono at st.com Mon Apr 21 07:34:43 2008 From: filippo.arcidiacono at st.com (Filippo ARCIDIACONO) Date: Mon, 21 Apr 2008 16:34:43 +0200 Subject: 'locale' command. Message-ID: <007201c8a3bc$d7029930$838182a4@st.com> Hi all, The following patch add the 'locale' command into the uClibc utilities. The patch applies to the latest trunk revision. Any comment are welcome. Best Regards, Filippo. This patch provide the first version of 'locale' command, it has been included into the utilities commands. Signed-off-by: Filippo Arcidiacono Index: utils/Makefile.in =================================================================== --- utils/Makefile.in (revision 21732) +++ utils/Makefile.in (working copy) @@ -25,6 +25,8 @@ CFLAGS-readelf := $(CFLAGS-utils-shared) +CFLAGS-locale := $(CFLAGS-utils) + BUILD_CFLAGS-utils := -include $(top_srcdir)include/elf.h BUILD_CFLAGS-utils-common := $(CFLAGS-utils-common) @@ -51,15 +53,17 @@ endif utils_ICONV_OBJ = +utils_LOCALE_OBJ = ifeq ($(UCLIBC_HAS_LOCALE),y) utils_ICONV_OBJ := $(utils_OUT)/iconv +utils_LOCALE_OBJ := $(utils_OUT)/locale endif utils_OBJ := $(patsubst %,$(utils_OUT)/%,$(utils_OBJ)) hostutils_OBJ := $(patsubst %,%.host,$(utils_OBJ)) -utils: $(utils_OBJ) $(utils_ICONV_OBJ) +utils: $(utils_OBJ) $(utils_ICONV_OBJ) $(utils_LOCALE_OBJ) # NOTE: We build the utils AFTER we have a uClibc-targeted toolchain. @@ -69,6 +73,9 @@ $(utils_OUT)/iconv: $(top_srcdir)libc/misc/wchar/wchar.c | $(libc) $(compile.u) +$(utils_OUT)/locale: $(top_srcdir)extra/locale/programs/locale.c | $(libc) + $(compile.u) + hostutils: $(hostutils_OBJ) $(hostutils_OBJ): $(utils_OUT)/%.host : $(utils_DIR)/%.c @@ -86,9 +93,10 @@ endif ifeq ($(UCLIBC_HAS_LOCALE),y) $(INSTALL) -m 755 $(utils_OUT)/iconv $(PREFIX)$(RUNTIME_PREFIX)usr/bin/iconv + $(INSTALL) -m 755 $(utils_OUT)/locale $(PREFIX)$(RUNTIME_PREFIX)usr/bin/locale endif objclean-y += utils_clean utils_clean: - $(RM) $(utils_OUT)/{ldconfig,ldd,readelf,iconv,*.host} + $(RM) $(utils_OUT)/{ldconfig,ldd,readelf,iconv,locale,*.host} Index: include/langinfo.h =================================================================== --- include/langinfo.h (revision 21732) +++ include/langinfo.h (working copy) @@ -354,7 +354,6 @@ _NL_CTYPE_EXTRA_MAP_12, _NL_CTYPE_EXTRA_MAP_13, _NL_CTYPE_EXTRA_MAP_14, - _NL_NUM_LC_CTYPE, #else /* 0 */ _NL_CTYPE_OUTDIGIT0_MB = _NL_ITEM (__LC_CTYPE, 0), _NL_CTYPE_OUTDIGIT1_MB, @@ -370,6 +369,7 @@ CODESET = _NL_CTYPE_CODESET_NAME, #define CODESET CODESET #endif /* 0 */ + _NL_NUM_LC_CTYPE, /* LC_MONETARY category: formatting of monetary quantities. These items each correspond to a member of `struct lconv', Index: extra/locale/programs/locale.c =================================================================== --- extra/locale/programs/locale.c (revision 0) +++ extra/locale/programs/locale.c (revision 0) @@ -0,0 +1,466 @@ +/* + * + * Copyright (c) 2008 STMicroelectronics Ltd + * Filippo Arcidiacono (filippo.arcidiacono at st.com) + * + * Licensed under the LGPL v2.1, see the file COPYING.LIB in this tarball. + * + * A 'locale' command implementation for uClibc. + * + */ + + +#include +#include +#include +#include +#include + +typedef struct { + unsigned char idx_name; + char dot_cs; /* 0 if no codeset specified */ + char cs; + unsigned char lc_ctype_row; + unsigned char lc_numeric_row; + unsigned char lc_monetary_row; + unsigned char lc_time_row; + unsigned char lc_collate_row; + unsigned char lc_messages_row; +} locale_entry; + +/* Need to include this before locale.h and xlocale.h! */ +#include + +#undef CODESET_LIST +#define CODESET_LIST (__locale_mmap->codeset_list) +#include +#define LOCALE_NAMES (__locale_mmap->locale_names5) +#define LOCALES (__locale_mmap->locales) +#define LOCALE_AT_MODIFIERS (__locale_mmap->locale_at_modifiers) +#define CATEGORY_NAMES (__locale_mmap->lc_names) + +#define GET_CODESET_NAME(N) (CODESET_LIST + *(CODESET_LIST + N - 3)) +#define GET_LOCALE_ENTRY(R) (locale_entry *)(LOCALES + (__LOCALE_DATA_WIDTH_LOCALES * R)) +#define GET_CATEGORY_NAME(X) (CATEGORY_NAMES + *(CATEGORY_NAMES + X)) +#define GET_LOCALE_NAME(I) (const char *)(LOCALE_NAMES + 5 * (I - 1)) + +static const char utf8[] = "UTF-8"; +static const char ascii[] = "ASCII"; + +/* If set print the name of the category. */ +static int show_category_name = 0; + +/* If set print the name of the item. */ +static int show_keyword_name = 0; + +/* If set print the usage command. */ +static int show_usage = 0; + +/* Print names of all available locales. */ +static int do_all = 0; + +/* Print names of all available character maps. */ +static int do_charmaps = 0; + +static int remaining = 0; + +/* We can map the types of the entries into a few categories. */ +enum value_type +{ + none, + string, + stringarray, + byte, + bytearray, + word, + stringlist, + wordarray, + wstring, + wstringarray, + wstringlist +}; + +/* Definition of the data structure which represents a category and its + items. */ +struct category +{ + int cat_id; + const char *name; + size_t number; + struct cat_item + { + int item_id; + const char *name; + enum { std, opt } status; + enum value_type value_type; + int min; + int max; + } *item_desc; +}; + +/* Simple helper macro. */ +#define NELEMS(arr) ((sizeof (arr)) / (sizeof (arr[0]))) + +/* For some tricky stuff. */ +#define NO_PAREN(Item, More...) Item, ## More + +/* We have all categories defined in `categories.def'. Now construct + the description and data structure used for all categories. */ +#define DEFINE_ELEMENT(Item, More...) { Item, ## More }, +#define DEFINE_CATEGORY(category, name, items, postload) \ + static struct cat_item category##_desc[] = \ + { \ + NO_PAREN items \ + }; + +#include "categories.def" +#undef DEFINE_CATEGORY + +static struct category category[] = + { +#define DEFINE_CATEGORY(category, name, items, postload) \ + [category] = { _NL_NUM_##category, name, NELEMS (category##_desc), \ + category##_desc }, +#include "categories.def" +#undef DEFINE_CATEGORY + }; +#define NCATEGORIES NELEMS (category) + +static void usage(const char *name); +static void usage(const char *name) +{ + const char *s; + + s = basename(name); + fprintf(stderr, + "Usage: %s [-ck] [--category-name] [--keyword-name] [--help] NAME\n" + "or: %s [OPTION...] [-a|-m] [--all-locales] [--charmaps] \n", s, s); +} + +static int argp_parse(int argc, char *argv[]); +static int argp_parse(int argc, char *argv[]) +{ + static const struct option long_options[] = + { + {"all-locales", no_argument, NULL, 'a'}, + {"charmaps", no_argument, NULL, 'm'}, + {"category-name", no_argument, NULL, 'c'}, + {"keyword-name", no_argument, NULL, 'k'}, + {"help", no_argument, NULL, 'h'}, + {NULL, 0, NULL, 0 } + }; + int c; + char *progname; + + progname = *argv; + while ((c = getopt_long (argc, argv, "amckh", long_options, NULL)) >= 0) + switch (c) + { + case 'a': + do_all = 1; + break; + case 'c': + show_category_name = 1; + break; + case 'm': + do_charmaps = 1; + break; + case 'k': + show_keyword_name = 1; + break; + case 'h': + show_usage = 1; + break; + case '?': + fprintf (stderr, "Unknown option.\n"); + usage(progname); + return 1; + + default: + fprintf (stderr, "This should never happen!\n"); + return 1; + } + + remaining = optind; + + return 0; +} + +static unsigned const char * find_at(char c); +static unsigned const char * find_at(char c) +{ + const unsigned char *q; + + q = LOCALE_AT_MODIFIERS; + do { + if (q[1] == c) { + return (unsigned const char *)q+2; + } + q += 2 + *q; + } while (*q); + + return NULL; +} + +static void find_locale_string(locale_entry *loc_rec, char *loc) +{ + char at = 0; + unsigned char idx; + uint16_t dotcs, cs; + + idx = loc_rec->idx_name; + if (!idx) { + *loc++ = 'C'; /* jump the first locale (C) */ + *loc = '\0'; + } + else { + dotcs = (uint16_t) loc_rec->dot_cs; + cs = (uint16_t) loc_rec->cs;; + loc = strncpy(loc, GET_LOCALE_NAME(idx), 5); + + if (loc[2] == '_') { + sprintf(loc, "%5.5s%c%s\0", loc, (dotcs != 0) ? '.' : ' ', + (cs == 1) ? ascii : ((cs == 2) ? utf8 : GET_CODESET_NAME(cs))); + } else { + at = loc[2]; + loc[2] = '_'; + sprintf(loc, "%5.5s%c%s@%s\0", loc, (dotcs != 0) ? '.' : ' ', + (cs == 1) ? ascii : ((cs == 2) ? utf8 : GET_CODESET_NAME(cs)), + find_at(at)); + } + } +} + +static void list_locale(void); +static void list_locale() +{ + char loc[40]; + uint16_t n = 0; + locale_entry *locales = (locale_entry *)LOCALES; + + do { + find_locale_string(locales, loc); + printf("%s\n", loc); + ++n; + locales++; + } while (n < __LOCALE_DATA_NUM_LOCALES); +} + +static void list_charmaps(void); +static void list_charmaps() +{ + unsigned const char *cl; + + cl = CODESET_LIST; + do { + printf("%s\n", CODESET_LIST + *cl); + } while (*++cl); + +} + +static void print_item (struct cat_item *item); +static void print_item (struct cat_item *item) +{ + switch (item->value_type) + { + case string: + if (show_keyword_name) + printf ("%s=\"", item->name); + fputs (nl_langinfo (item->item_id) ? : "", stdout); + if (show_keyword_name) + putchar ('"'); + putchar ('\n'); + break; + case stringarray: + { + int cnt; + const char *val; + + if (show_keyword_name) + printf ("%s=\"", item->name); + + for (cnt = 0; cnt < item->max - 1; ++cnt) + { + val = nl_langinfo (item->item_id + cnt); + if (val != NULL) + fputs (val, stdout); + putchar (';'); + } + + val = nl_langinfo (item->item_id + cnt); + if (val != NULL) + fputs (val, stdout); + + if (show_keyword_name) + putchar ('"'); + putchar ('\n'); + } + break; + case stringlist: + { + int first = 1; + const char *val = nl_langinfo (item->item_id) ? : ""; + int cnt; + + if (show_keyword_name) + printf ("%s=", item->name); + + for (cnt = 0; cnt < item->max && *val != '\0'; ++cnt) + { + printf ("%s%s%s%s", first ? "" : ";", + show_keyword_name ? "\"" : "", val, + show_keyword_name ? "\"" : ""); + val = strchr (val, '\0') + 1; + first = 0; + } + putchar ('\n'); + } + break; + case byte: + { + const char *val = nl_langinfo (item->item_id); + + if (show_keyword_name) + printf ("%s=", item->name); + + if (val != NULL) + printf ("%d", *val == '\177' ? -1 : *val); + putchar ('\n'); + } + break; + case bytearray: + { + const char *val = nl_langinfo (item->item_id); + int cnt = val ? strlen (val) : 0; + + if (show_keyword_name) + printf ("%s=", item->name); + + while (cnt > 1) + { + printf ("%d;", *val == '\177' ? -1 : *val); + --cnt; + ++val; + } + + printf ("%d\n", cnt == 0 || *val == '\177' ? -1 : *val); + } + break; + case word: + { + union { unsigned int word; char *string; } val; + val.string = nl_langinfo (item->item_id); + if (show_keyword_name) + printf ("%s=", item->name); + + printf ("%d\n", val.word); + } + break; + case wstring: + case wstringarray: + case wstringlist: + /* We don't print wide character information since the same + information is available in a multibyte string. */ + default: + break; + + } +} + +/* Show the information request for NAME. */ +static void show_info(const char *name); +static void show_info(const char *name) +{ + size_t cat_no, item_no; + const unsigned char *cat_name; + + /* Now all categories in an unspecified order. */ + for (cat_no = 0; cat_no < __LC_ALL; ++cat_no) { + cat_name = GET_CATEGORY_NAME(cat_no); + if (strcmp (name, (const char *)cat_name) == 0) { + if (show_category_name) + printf("%s\n", name); + + for (item_no = 0; item_no < category[cat_no].number; ++item_no) + print_item (&category[cat_no].item_desc[item_no]); + + return; + } + + for (item_no = 0; item_no < category[cat_no].number; ++item_no) + if (strcmp (name, category[cat_no].item_desc[item_no].name) == 0) { + if (show_category_name != 0) + puts (category[cat_no].name); + + print_item (&category[cat_no].item_desc[item_no]); + return; + } + } +} + +static void show_locale_vars(void); +static void show_locale_vars() +{ + size_t cat_no; + int row; /* locale row */ + const char *lcall = getenv ("LC_ALL"); + const char *lang = getenv ("LANG") ? : ""; + unsigned char *cur_loc = __global_locale->cur_locale + 1; + char loc_name[40]; + locale_entry *locales; + + /* LANG has to be the first value. */ + printf ("LANG=%s\n", lang); + + /* Now all categories in an unspecified order. */ + for (cat_no = 0; cat_no < __LC_ALL; ++cat_no) { + row = (((int)(*cur_loc & 0x7f)) << 7) + (cur_loc[1] & 0x7f); +/* assert(row < __LOCALE_DATA_NUM_LOCALES); */ + + locales = GET_LOCALE_ENTRY(row); + find_locale_string(locales, loc_name); + printf("%s=%s\n", GET_CATEGORY_NAME(cat_no), loc_name); + + cur_loc += 2; + } + + /* The last is the LC_ALL value. */ + printf ("LC_ALL=%s\n", lcall ? : ""); +} + +int +main (int argc, char *argv[]) +{ + /* Parse and process arguments. */ + if (argp_parse(argc, argv)) + return 1; + + if (do_all) { + list_locale(); + exit (EXIT_SUCCESS); + } + + if (do_charmaps) { + list_charmaps(); + exit (EXIT_SUCCESS); + } + + if (show_usage) { + usage(*argv); + exit (EXIT_SUCCESS); + } + + /* If no real argument is given we have to print the contents of the + current locale definition variables. These are LANG and the LC_*. */ + if (remaining == argc && show_category_name == 0 && show_keyword_name == 0) { + show_locale_vars (); + exit (EXIT_SUCCESS); + } + + /* Process all given names. */ + while (remaining < argc) + show_info (argv[remaining++]); + + exit (EXIT_SUCCESS); + +} Index: extra/locale/programs/categories.def =================================================================== --- extra/locale/programs/categories.def (revision 0) +++ extra/locale/programs/categories.def (revision 0) @@ -0,0 +1,357 @@ +/* + * + * Copyright (c) 2008 STMicroelectronics Ltd + * Filippo Arcidiacono (filippo.arcidiacono at st.com) + * + * Licensed under the LGPL v2.1, see the file COPYING.LIB in this tarball. + * + * Taken from glibc 2.6 + * + */ + + +/* Definition of all available locale categories and their items. -*- C -*- + + These definitions are used by the 'locale' the program. + + The general format of the descriptions is like this: + + DEFINE_CATEGORY (ID, name, ( items ), setlocale-postload) + + where items itself is an array of entries in the form + + { ID, name, standard, value-type, min, max } + + The usage of the load, check, output functions depends on the individual + program code which loads this file. + + The various value types for the items are `string', `stringarray', `byte' + `bytearray', and `word'. These cover all possible values in the current + locale definitions. `min' and `max' can be individually used again. */ + +#ifndef NO_POSTLOAD +#define NO_POSTLOAD NULL +#endif + +#if 0 +DEFINE_CATEGORY +( + LC_COLLATE, "LC_COLLATE", + ( + DEFINE_ELEMENT (_NL_COLLATE_NRULES, "collate-nrules", std, word) + DEFINE_ELEMENT (_NL_COLLATE_RULESETS, "collate-rulesets", std, string) + DEFINE_ELEMENT (_NL_COLLATE_TABLEMB, "collate-tablemb", std, wstring) + DEFINE_ELEMENT (_NL_COLLATE_WEIGHTMB, "collate-weightmb", std, wstring) + DEFINE_ELEMENT (_NL_COLLATE_EXTRAMB, "collate-extramb", std, wstring) + DEFINE_ELEMENT (_NL_COLLATE_INDIRECTMB, "collate-indirectmb", std, wstring) + DEFINE_ELEMENT (_NL_COLLATE_TABLEWC, "collate-tablewc", std, wstring) + DEFINE_ELEMENT (_NL_COLLATE_WEIGHTWC, "collate-weightwc", std, wstring) + DEFINE_ELEMENT (_NL_COLLATE_EXTRAWC, "collate-extrawc", std, wstring) + DEFINE_ELEMENT (_NL_COLLATE_INDIRECTWC, "collate-indirectwc", std, wstring) + DEFINE_ELEMENT (_NL_COLLATE_SYMB_HASH_SIZEMB, "collate-symb-hash-sizemb", std, word) + DEFINE_ELEMENT (_NL_COLLATE_SYMB_TABLEMB, "collate-symb-tablemb", std, wstring) + DEFINE_ELEMENT (_NL_COLLATE_SYMB_EXTRAMB, "collate-symb-extramb", std, wstring) + DEFINE_ELEMENT (_NL_COLLATE_COLLSEQMB, "collate-collseqmb", std, wstring) + DEFINE_ELEMENT (_NL_COLLATE_COLLSEQWC, "collate-collseqwc", std, wstring) + DEFINE_ELEMENT (_NL_COLLATE_CODESET, "collate-codeset", std, string) + ), NO_POSTLOAD) +#endif + + +/* The actual definition of ctype is meaningless here. It is hard coded in + the code because it has to be handled very specially. Only the names of + the functions and the value types are important. */ +DEFINE_CATEGORY +( + LC_CTYPE, "LC_CTYPE", + ( +#if 0 + DEFINE_ELEMENT (_NL_CTYPE_CLASS, "ctype-class", std, wstring) + DEFINE_ELEMENT (_NL_CTYPE_TOUPPER, "ctype-toupper", std, wstring) + DEFINE_ELEMENT (_NL_CTYPE_TOLOWER, "ctype-tolower", std, wstring) + DEFINE_ELEMENT (_NL_CTYPE_CLASS32, "ctype-class32", std, wstring) + DEFINE_ELEMENT (_NL_CTYPE_CLASS_NAMES, "ctype-class-names", std, stringlist, 10, 32) + DEFINE_ELEMENT (_NL_CTYPE_MAP_NAMES, "ctype-map-names", std, stringlist, 2, 32) + DEFINE_ELEMENT (_NL_CTYPE_WIDTH, "ctype-width", std, bytearray) + DEFINE_ELEMENT (_NL_CTYPE_MB_CUR_MAX, "ctype-mb-cur-max", std, word) + DEFINE_ELEMENT (_NL_CTYPE_CODESET_NAME, "charmap", std, string) + DEFINE_ELEMENT (_NL_CTYPE_TOUPPER32, "ctype-toupper32", std, wstring) + DEFINE_ELEMENT (_NL_CTYPE_TOLOWER32, "ctype-tolower32", std, wstring) + DEFINE_ELEMENT (_NL_CTYPE_CLASS_OFFSET, "ctype-class-offset", std, word) + DEFINE_ELEMENT (_NL_CTYPE_MAP_OFFSET, "ctype-map-offset", std, word) + DEFINE_ELEMENT (_NL_CTYPE_INDIGITS_MB_LEN, "ctype-indigits_mb-len", std, word) + DEFINE_ELEMENT (_NL_CTYPE_INDIGITS0_MB, "ctype-indigits0_mb", std, string) + DEFINE_ELEMENT (_NL_CTYPE_INDIGITS1_MB, "ctype-indigits1_mb", std, string) + DEFINE_ELEMENT (_NL_CTYPE_INDIGITS2_MB, "ctype-indigits2_mb", std, string) + DEFINE_ELEMENT (_NL_CTYPE_INDIGITS3_MB, "ctype-indigits3_mb", std, string) + DEFINE_ELEMENT (_NL_CTYPE_INDIGITS4_MB, "ctype-indigits4_mb", std, string) + DEFINE_ELEMENT (_NL_CTYPE_INDIGITS5_MB, "ctype-indigits5_mb", std, string) + DEFINE_ELEMENT (_NL_CTYPE_INDIGITS6_MB, "ctype-indigits6_mb", std, string) + DEFINE_ELEMENT (_NL_CTYPE_INDIGITS7_MB, "ctype-indigits7_mb", std, string) + DEFINE_ELEMENT (_NL_CTYPE_INDIGITS8_MB, "ctype-indigits8_mb", std, string) + DEFINE_ELEMENT (_NL_CTYPE_INDIGITS9_MB, "ctype-indigits9_mb", std, string) + DEFINE_ELEMENT (_NL_CTYPE_INDIGITS_