From seh at zee2.com Tue Jul 1 09:16:48 2003 From: seh at zee2.com (Stuart Hughes) Date: Sat Jul 19 08:54:51 2003 Subject: [uClibc]busybox ps garbled characters References: Message-ID: <3F013560.7C687520@zee2.com> Hi All, Turns out the problem was indeed my fault, I'd inadvertently linked against one library and ran against another. This was due to my build setup which (sometimes) uses GCC_EXEC_PREFIX to modify where gcc looks for headers and libs (some things were in the wrong place). Thanks to everyone for their help. Regards, Stuart joe@cityofsanmateo.org wrote: > > i dont know if its the same problem but i ran into a broken ps when i had mismatched > libraries, ie i only replaced uClibc.so with a newer one and left the others the same > i fixed it by moving over a complete set of freshly compiled libs > > i hope this helps > > --joe > > Stuart Hughes > Sent by: uclibc-bounces@uclibc.org ??? T:? > > 06/20/2003 07:53 AM P?????X???????? ??d?? true" onMouseOut="window.status=''" PRIVATE> > > > > Hi all, > > I get garbled characters when I run ps (busybox) with uclibc: > > # > ps > PID Uid Stat > Command > 1 root S . > ..o* > 2 _??+ S From siim at pld.ttu.ee Tue Jul 1 18:11:19 2003 From: siim at pld.ttu.ee (Siim Vahtre) Date: Sat Jul 19 08:54:51 2003 Subject: [uClibc] uClibc 0.9.20 released In-Reply-To: <20030701005633.GB22360@codepoet.org> References: <20030701005633.GB22360@codepoet.org> Message-ID: On Mon, 30 Jun 2003, Erik Andersen wrote: > uClibc 0.9.20 released Hi. A small typo: Webpage "http://www.uclibc.org/" shows news "30 June 2003, uClibc 0.9.20 Released" and inside the announcement there is link to download "source code for this release" which points to "uClibc-0.9.19.tar.bz2" instead of v0.9.20. From giulioo at pobox.com Tue Jul 1 19:07:41 2003 From: giulioo at pobox.com (Giulio Orsero) Date: Sat Jul 19 08:54:51 2003 Subject: [uClibc] uClibc 0.9.20 released In-Reply-To: <20030701005633.GB22360@codepoet.org> References: <20030701005633.GB22360@codepoet.org> Message-ID: <20030701160741.71923127E6@mail.golden.dom> On Mon, 30 Jun 2003 18:56:33 -0600, Erik Andersen wrote: >uClibc 0.9.20 released I still have _llseek problem on kernel 2.2 See http://www.uclibc.org/lists/uclibc/2003-April/008363.html for details -- giulioo@pobox.com From andersen at codepoet.org Tue Jul 1 12:11:43 2003 From: andersen at codepoet.org (Erik Andersen) Date: Sat Jul 19 08:54:51 2003 Subject: [uClibc] uClibc 0.9.20 released In-Reply-To: References: <20030701005633.GB22360@codepoet.org> Message-ID: <20030701171143.GA30600@codepoet.org> On Tue Jul 01, 2003 at 05:11:19PM +0300, Siim Vahtre wrote: > On Mon, 30 Jun 2003, Erik Andersen wrote: > > > uClibc 0.9.20 released > > Hi. > > A small typo: > > Webpage "http://www.uclibc.org/" shows news "30 June 2003, > uClibc 0.9.20 Released" and inside the announcement there > is link to download "source code for this release" which > points to "uClibc-0.9.19.tar.bz2" instead of v0.9.20. Thanks. The danger of cut and paste.... Fixed now, -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- From dave-gnus at bfnet.com Tue Jul 1 12:40:05 2003 From: dave-gnus at bfnet.com (David Wuertele) Date: Sat Jul 19 08:54:51 2003 Subject: [uClibc] syslimits.h: no include path in which to find limits.h Message-ID: When I use buildroot to build a mipsel toolchan and root fs, everything compiles fine until I get to gcc_target: /home/dave/C/perforce/source/deschutes/buildroot-M14.0-X225/build_mipsel/staging_dir/bin/mipsel-uclibc-gcc -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -isystem ./include -I. -I. -I/home/dave/C/perforce/source/deschutes/buildroot-M14.0-X225/toolchain_build_mipsel/gcc-3.2.3/gcc -I/home/dave/C/perforce/source/deschutes/buildroot-M14.0-X225/toolchain_build_mipsel/gcc-3.2.3/gcc/. -I/home/dave/C/perforce/source/deschutes/buildroot-M14.0-X225/toolchain_build_mipsel/gcc-3.2.3/gcc/config -I/home/dave/C/perforce/source/deschutes/buildroot-M14.0-X225/toolchain_build_mipsel/gcc-3.2.3/gcc/../include -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions \ -c /home/dave/C/perforce/source/deschutes/buildroot-M14.0-X225/toolchain_build_mipsel/gcc-3.2.3/gcc/crtstuff.c -DCRT_BEGIN \ -o crtbegin.o In file included from include/limits.h:11, from /home/dave/C/perforce/source/deschutes/buildroot-M14.0-X225/toolchain_build_mipsel/gcc-3.2.3/gcc/tsystem.h:84, from /home/dave/C/perforce/source/deschutes/buildroot-M14.0-X225/toolchain_build_mipsel/gcc-3.2.3/gcc/crtstuff.c:62: /home/dave/C/perforce/source/deschutes/buildroot-M14.0-X225/build_mipsel/staging_dir/lib/gcc-lib/mipsel-linux/3.2.3/include/syslimits.h:7:25: no include path in which to find limits.h /home/dave/C/perforce/source/deschutes/buildroot-M14.0-X225/toolchain_build_mipsel/gcc-3.2.3/gcc/crtstuff.c:195: warning: `__EH_FRAME_BEGIN__' defined but not used make[2]: *** [crtbegin.o] Error 1 make[2]: Leaving directory `/home/dave/C/perforce/source/deschutes/buildroot-M14.0-X225/build_mipsel/gcc-target/gcc' make[1]: *** [all-gcc] Error 2 make[1]: Leaving directory `/home/dave/C/perforce/source/deschutes/buildroot-M14.0-X225/build_mipsel/gcc-target' make: *** [/home/dave/C/perforce/source/deschutes/buildroot-M14.0-X225/build_mipsel/gcc-target/.compiled] Error 2 I have made sure that my gcc versions are the same in the uclibc_toolchain.mk file and in the gcc_target.mk file. Both are using gcc-3.2.3. I have Surfed The Fine Web, and I've found mention of this problem before, but not in the same context. The best advice I found was to make sure the toolchain gcc version matched the target gcc version, which I have already done. Does anyone in buildroot land have a solution to this one? Thanks, Dave From sm5iuf at telia.com Tue Jul 1 22:37:17 2003 From: sm5iuf at telia.com (Gunnar Isaksson) Date: Sat Jul 19 08:54:51 2003 Subject: [uClibc] uClibc compiler wrapper and the Makefile based toolchain gives different result Message-ID: <200307012137.17274.sm5iuf@telia.com> Dear Sirs, I have used the uClibc compiler wrappers with good results and got a a very small Linux image with uClibc, Busybox, Tinylogin, inetd, telnetd ... The kernel is patched with Ingo Molnars O(1) patches, preemptive and lowlatency in order to get soft realtime properties. This will go into a test aircraft for experimenting with navigation algorithms. (Purely for research) The problem: When I use the Makefile based toolchain and compile everything the Linux image builds without a hitch. However telnetd no longer works. Busybox works ok though. The problems seems to have something to do with the networking stuff. I have scripts to make my compilations and the only difference is that I in the first case use the compiler wrapper and in the second case the makefile based toolchain for gcc-3.3. I've also tried gcc-3.2.x with the same result. I get the same behaivour on Slackware-9.0 as well as Mandrake-9.1. It looks like uClibc behaives differently used as a wrapper compared to beeing used in the toolchain. I would rather use the toolchain since this gives me a real crosscompiler and I will not have to consider what Linux distro I'm using. I would appreciate any pointers that could resolve this issue. //Gunnar Isaksson PS I work for the Swedish company Saab Bofors Dynamics. The company is rather diversified but it's main products are missiles or technologies associated closely with missiles. We also have research contracts in diversified areas and I myself work with with these. It's not like we will use Linux in some smart weapons. Linux and uClinux is just very convinient when doing research and collecting data from flight tests. DS From dpforos at yahoo.com Tue Jul 1 13:42:54 2003 From: dpforos at yahoo.com (Daniel Pezoa) Date: Sat Jul 19 08:54:51 2003 Subject: [uClibc] uClibc Mozilla Message-ID: <20030701194254.5254.qmail@web11207.mail.yahoo.com> Hello uClibc Community I'am new to Uclibc. I want to compile mozilla for the use in a Freevix, one small linux distribution booteable from network, wich is compiled with uClibc. My first problem is, i don't found all the info needed for setting my uClibc development environment, i try the following: 1) I download the file: http://www.uclibc.org/downloads/uClibc-0.9.19.tar.gz 2) I run the command: make menuconfig /* And select some options that i don't remember */ make clean make make install /* All that work ok */ 3) To compile programs with uClibc, i run: export PATH=/usr/i386-linux-uclibc/bin:$PATH and then just run './configure' and 'make' as usual. Is that the right way to compile with uClibc, i think some other settings are needed to compile for uClibc environment. Your comments, url, ... are welcome, because i need your help. My second attempt is really very different, i download that file: http://www.uclibc.org/downloads/root_fs-i386.bz2 Next i don't found the info about what to make with it, i search in many places, an my steps are ... : bzip2 -d root_fs-i386.bz2 mkdir mnt // for mount the filesystem // For resize the file system e2fsck -f root_fs-i386 resize2fs root_fs-i386 2500000 // Now the size is ok to add mozilla :-) mount -o loop root_fs-i386 mnt // I copy and extract mozilla sourcecode chroot mnt I don't know if i need more to work with my uClibc environment, some environment variables, modify some files or run some another commands, your experience and comments are welcome :-) I don't set any environment variable and run any nother command after the chroot mnt. If i need to do some changes please let me know it. I go to mozilla directory and attempt to configure with ./configure it require perl, and i add the perl uClibc compiled found in the freevix distribution. (perl ok). Now i need gtk, and gtk require glib, atk, pango, and glib require pkgconfig (it compile ok) and require iconv() implementation i attempt to compile libiconv-1.8 ./configure // I think it run ok make // It send one error The last lines of the output are: make[1]: Entering directory `/libiconv-1.8/src' /bin/sh ../libtool --mode=link gcc iconv_no_i18n.o ../lib/libiconv.la -o iconv_no_i18n gcc iconv_no_i18n.o -o .libs/iconv_no_i18n ../lib/.libs/libiconv.so -Wl,--rpath -Wl,/usr/local/lib iconv_no_i18n.o: In function `main': /libiconv-1.8/src/iconv.c:247: the 'setlocale' function supports only C|POSIX locales ../lib/.libs/libiconv.so: undefined reference to `_IO_getc' collect2: ld returned 1 exit status make[1]: *** [iconv_no_i18n] Error 1 make[1]: Leaving directory `/libiconv-1.8/src' make: *** [all] Error 2 [root@tvmovil libiconv-1.8]# I appreciate your comments, sugestion, please don't be brief in your responses, i'am very new to that uClibc world and need to understand it. Good luck and my congratulations for your work, to the uClibc community! Daniel Pezoa __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com From uclibc at lacklustre.net Tue Jul 1 17:40:37 2003 From: uclibc at lacklustre.net (Michael Ryan) Date: Sat Jul 19 08:54:51 2003 Subject: [uClibc] Problems with IO.so in perl Message-ID: <20030701164037.6288dd26.uclibc@lacklustre.net> Greetings, I'm brand new to the list, but I've been using uClibc for a while. I've been trying to get perl to compile, and after finally getting it to [using the buildroot scripts], it seems that IO.so has some unresolved symbols. I figured this must have been a problem with my personal compilation, but I downloaded the new rootfs image to-day and it seems to have the same problem. I also tried to execute ldd on the shared object in question and it seems to be compiled statically, while on my workstation [also Perl 5.8.0], it is dynamically linked to glibc 2.3.1. My workstation is running Debian Unstable, by the way. Here's a transcript: [root@moonbeam root]# perl -mIO::Socket perl: symbol 'Perl_croak': can't resolve symbol [repeat 15 more times] perl: symbol 'Perl_PerlIO_fileno': can't resolve symbol [repeat 3 more times] perl: symbol 'PL_markstack_ptr': can't resolve symbol [repeat 29 more times] perl: symbol 'PL_stack_base': can't resolve symbol [repeat 54 more times] perl: symbol 'PL_stack_sp': can't resolve symbol [repeat 29 more times] perl: symbol 'Perl_sv_2io': can't resolve symbol [repeat 10 more times] perl: symbol 'Perl_newSV': can't resolve symbol [repeat once] perl: symbol 'Perl_sv_2mortal': can't resolve symbol [repeat 3 more times] perl: symbol 'PerlIO_getpos': can't resolve symbol perl: symbol 'PL_sv_undef': can't resolve symbol [repeat 4 more times] perl: symbol 'PerlIO_setpos': can't resolve symbol perl: symbol 'Perl_sv_newmortal': can't resolve symbol [repeat 8 more times] perl: symbol 'Perl_sv_setpvn': can't resolve symbol [repeat 4 more times] perl: symbol 'Perl_sv_setiv': can't resolve symbol [repeat 10 more times] perl: symbol 'PerlIO_tmpfile': can't resolve symbol perl: symbol 'Perl_newGVgen': can't resolve symbol perl: symbol 'Perl_hv_delete': can't resolve symbol perl: symbol 'Perl_do_open': can't resolve symbol perl: symbol 'Perl_newRV': can't resolve symbol perl: symbol 'Perl_gv_stashpv': can't resolve symbol perl: symbol 'Perl_sv_bless': can't resolve symbol perl: symbol 'Perl_sv_free': can't resolve symbol [repeat once] perl: symbol 'Perl_sv_2pv_nolen': can't resolve symbol perl: symbol 'Perl_newSViv': can't resolve symbol [repeat 13 more times] perl: symbol 'Perl_sv_2iv': can't resolve symbol [repeat 4 more times] perl: symbol 'PL_op': can't resolve symbol [repeat 3 more times] perl: symbol 'PL_curpad': can't resolve symbol [repeat 3 more times] perl: symbol 'PerlIO_ungetc': can't resolve symbol [repeat 4 more times] perl: symbol 'Perl_PerlIO_error': can't resolve symbol perl: symbol 'Perl_PerlIO_clearerr': can't resolve symbol perl: symbol 'Perl_PerlIO_flush': can't resolve symbol perl: symbol 'Perl_newXS': can't resolve symbol [repeat 13 more times] perl: symbol 'Perl_sv_setpv': can't resolve symbol [repeat once] perl: symbol 'Perl_gv_stashpvn': can't resolve symbol [repeat once] perl: symbol 'Perl_newCONSTSUB': can't resolve symbol [repeat 11 more times] perl: symbol 'PL_sv_yes': can't resolve symbol perl: symbol 'Perl_sv_2pv_flags': can't resolve symbol [repeat once] perl: symbol 'Perl_form': can't resolve symbol [repeat once] perl: symbol 'Perl_get_sv': can't resolve symbol [repeat once] Can't load '/usr/lib/perl/5.8.0/i386-linux/auto/IO/IO.so' for module IO: Unable to resolve symbol at /usr/lib/perl/5.8.0/i386-linux/XSLoader.pm line 83. at /usr/lib/perl/5.8.0/i386-linux/IO.pm line 9 Compilation failed in require at /usr/lib/perl/5.8.0/i386-linux/IO/Handle.pm line 256. BEGIN failed--compilation aborted at /usr/lib/perl/5.8.0/i386-linux/IO/Handle.pm line 256. Compilation failed in require at /usr/lib/perl/5.8.0/i386-linux/IO/Socket.pm line 11. BEGIN failed--compilation aborted at /usr/lib/perl/5.8.0/i386-linux/IO/Socket.pm line 11. Compilation failed in require. BEGIN failed--compilation aborted. [root@moonbeam root]# ldd /usr/lib/perl/5.8.0/i386-linux/auto/IO/IO.so not a dynamic executable [root@moonbeam root] Any ideas would be greatly appreciated. Thanks. -- Michael Ryan Lacklustre Networking michael@lacklustre.net http://www.lacklustre.net/ -- Michael Ryan Lacklustre Networking michael@lacklustre.net http://www.lacklustre.net/ From Calilonhuang at bj.t2-design.com Wed Jul 2 09:40:51 2003 From: Calilonhuang at bj.t2-design.com (Calilonhuang) Date: Sat Jul 19 08:54:51 2003 Subject: [uClibc] Can ftpd tftpd openssh etc compiled through uclibc ? Message-ID: SSB3YW50IHRvIGJ1aWxkIG9uZSBvZiB0aGVtIHVuZGVyIG1pcHMgdXNpbmcgdWNsaWJjLg0KSSBm aW5kIG9wZW5zc2ggaXMgbGlzdGVkIGluIHdvcmtpbmcgbGlzdC4gQnV0IEkgY2FuJ3QgY29tcGls ZSBpdCBzdWNjZXNzZnVsbHku From h_happy at 263.net Wed Jul 2 11:40:36 2003 From: h_happy at 263.net (Calilon) Date: Sat Jul 19 08:54:51 2003 Subject: [uClibc] Can ftpd tftpd openssh etc compiled through uclibc ? Message-ID: From andersen at codepoet.org Tue Jul 1 22:04:49 2003 From: andersen at codepoet.org (Erik Andersen) Date: Sat Jul 19 08:54:51 2003 Subject: [uClibc] Can ftpd tftpd openssh etc compiled through uclibc ? In-Reply-To: References: Message-ID: <20030702030449.GA4339@codepoet.org> On Wed Jul 02, 2003 at 10:40:36AM +0800, Calilon wrote: > _______________________________________________ > uClibc mailing list > uClibc@uclibc.org > http://uclibc.org/mailman/listinfo/uclibc Thanks for sharing, -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- From andersen at codepoet.org Tue Jul 1 22:21:36 2003 From: andersen at codepoet.org (Erik Andersen) Date: Sat Jul 19 08:54:51 2003 Subject: [uClibc] Can ftpd tftpd openssh etc compiled through uclibc ? In-Reply-To: References: Message-ID: <20030702032136.GB4339@codepoet.org> On Wed Jul 02, 2003 at 08:40:51AM +0800, Calilonhuang wrote: > I want to build one of them under mips using uclibc. > I find openssh is listed in working list. But I can't compile it successfully. It works. I have compiled openssh with uClibc on mips using uClibc 0.9.20. Therefore, since you did not provide a proper problem report, I have to assume you did something wrong. -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- From seh at zee2.com Wed Jul 2 16:50:41 2003 From: seh at zee2.com (Stuart Hughes) Date: Sat Jul 19 08:54:51 2003 Subject: [uClibc] installing more that one toolchain Message-ID: <3F02F141.95A071BE@zee2.com> Greetings, Not sure if I've goofed up here, but I'm trying to install 2 cross compilers (mipsel and powerpc) but I'm finding that the later install overwrites files from the earlier one. This seems to be because /-linux>/lib is a symlink to /lib in the toolchains I've built (from the script on uclibc.org). Is this a known limitation, or did I just mess up on my toolchain build ?? Regards, Stuart From dpforos at yahoo.com Wed Jul 2 08:56:15 2003 From: dpforos at yahoo.com (Daniel Pezoa) Date: Sat Jul 19 08:54:51 2003 Subject: [uClibc] help in compile uclibc gtk Message-ID: <20030702145615.21121.qmail@web11202.mail.yahoo.com> Hello I see gtk in the list of what can be compiled with uclibc. But it require glib, pango, atk, pkgconfig, libiconv. And i can't compile libiconv-1.8 It send me that error: ../lib/.libs/libiconv.so: undefined reference to `_IO_getc' collect2: ld returned 1 exit status make[1]: *** [iconv_no_i18n] Error 1 make[1]: Leaving directory `/libiconv-1.8/src' make: *** [all] Error 2 [root@tvmovil libiconv-1.8]# Can you help me with it. I set my root-fs_i386 with this steps: bzip -d root-fs_i386.bz2 mkdir mnt mount -o loop root-fs_i386 mnt chroot mnt then i do ./configure make What is the way to compile gtk, please let me know the steps you use to make it compile, i need that library. Daniel Pezoa __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com From ps.m at gmx.net Wed Jul 2 18:10:08 2003 From: ps.m at gmx.net (Peter S. Mazinger) Date: Sat Jul 19 08:54:51 2003 Subject: [uClibc] uClibc-0.9.20 and ldd coredump Message-ID: Hello! The changelog of 0.9.20 says, that the problem with ldd coredumping if ran against non-executables is solved. Attached are the outputs of strace ldd /lib/libc.so.0 (native environment) for: ulimit -c 0 (ldd.0) ulimit -c 128 (ldd.1) I have to mention that I am using a grsecurity enabled kernel (mainly the PaX options - http://pageexec.virtualave.net - are relevant for this case). Although I've got earlier the answer that PaX/grsecurity has problems with uClibc (true for uClibc < 0.9.18, reported by me), I am using grsecurity since uClibc-0.9.19 natively on x86 and there are no problems (only the ones present also on a glibc system ;-). Peter -- Peter S. Mazinger ID: 0xA5F059F2 NIC: IXUYHSKQLI Key fingerprint = 92A4 31E1 56BC 3D5A 2D08 BB6E C389 975E A5F0 59F2 -------------- next part -------------- execve("/usr/bin/ldd", ["ldd", "/lib/libc.so.0"], [/* 18 vars */]) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0) = 0x246ee000 readlink("/lib/ld-uClibc.so.0", "ld-uClibc-0.9.20.so", 1024) = 19 open("/lib/libc.so.0", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\240\345"..., 4096) = 4096 old_mmap(NULL, 278528, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x246ef000 old_mmap(0x246ef000, 256583, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x246ef000 old_mmap(0x2472e000, 7564, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x3e000) = 0x2472e000 old_mmap(0x24730000, 11692, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x24730000 close(3) = 0 ioctl(0, SNDCTL_TMR_TIMEBASE, {B38400 opost isig icanon echo ...}) = 0 ioctl(1, SNDCTL_TMR_TIMEBASE, {B38400 opost isig icanon echo ...}) = 0 brk(0x804d924) = 0x804d924 brk(0x804e000) = 0x804e000 brk(0x804f000) = 0x804f000 brk(0x8050000) = 0x8050000 open("/lib/libc.so.0", O_RDONLY) = 3 ioctl(3, SNDCTL_TMR_TIMEBASE, 0x58b4f878) = -1 ENOTTY (Inappropriate ioctl for device) fstat(3, {st_mode=S_IFREG|0755, st_size=263084, ...}) = 0 old_mmap(NULL, 263084, PROT_READ|PROT_WRITE, MAP_PRIVATE, 3, 0) = 0x24733000 brk(0x8051000) = 0x8051000 brk(0x8052000) = 0x8052000 stat("/lib/ld-uClibc.so.0", {st_mode=S_IFREG|0755, st_size=16068, ...}) = 0 fork() = 5188 --- SIGCHLD (Child exited) --- wait4(5188, [WIFSIGNALED(s) && WTERMSIG(s) == SIGSEGV && WCOREDUMP(s)], 0, NULL) = 5188 _exit(0) = ? -------------- next part -------------- execve("/usr/bin/ldd", ["ldd", "/lib/libc.so.0"], [/* 18 vars */]) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0) = 0x2a630000 readlink("/lib/ld-uClibc.so.0", "ld-uClibc-0.9.20.so", 1024) = 19 open("/lib/libc.so.0", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\240\345"..., 4096) = 4096 old_mmap(NULL, 278528, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2a631000 old_mmap(0x2a631000, 256583, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x2a631000 old_mmap(0x2a670000, 7564, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x3e000) = 0x2a670000 old_mmap(0x2a672000, 11692, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2a672000 close(3) = 0 ioctl(0, SNDCTL_TMR_TIMEBASE, {B38400 opost isig icanon echo ...}) = 0 ioctl(1, SNDCTL_TMR_TIMEBASE, {B38400 opost isig icanon echo ...}) = 0 brk(0x804d924) = 0x804d924 brk(0x804e000) = 0x804e000 brk(0x804f000) = 0x804f000 brk(0x8050000) = 0x8050000 open("/lib/libc.so.0", O_RDONLY) = 3 ioctl(3, SNDCTL_TMR_TIMEBASE, 0x5cdf11b8) = -1 ENOTTY (Inappropriate ioctl for device) fstat(3, {st_mode=S_IFREG|0755, st_size=263084, ...}) = 0 old_mmap(NULL, 263084, PROT_READ|PROT_WRITE, MAP_PRIVATE, 3, 0) = 0x2a675000 brk(0x8051000) = 0x8051000 brk(0x8052000) = 0x8052000 stat("/lib/ld-uClibc.so.0", {st_mode=S_IFREG|0755, st_size=16068, ...}) = 0 fork() = 5178 --- SIGCHLD (Child exited) --- wait4(5178, [WIFSIGNALED(s) && WTERMSIG(s) == SIGSEGV], 0, NULL) = 5178 _exit(0) = ? From mjn3 at codepoet.org Wed Jul 2 10:57:04 2003 From: mjn3 at codepoet.org (Manuel Novoa III) Date: Sat Jul 19 08:54:51 2003 Subject: [uClibc] uClibc Mozilla In-Reply-To: <20030701194254.5254.qmail@web11207.mail.yahoo.com> References: <20030701194254.5254.qmail@web11207.mail.yahoo.com> Message-ID: <20030702155704.GA10257@codepoet.org> On Tue, Jul 01, 2003 at 12:42:54PM -0700, Daniel Pezoa wrote: > I'am new to Uclibc. > > I want to compile mozilla for the use in a Freevix, > one small linux distribution booteable from network, > wich is compiled with uClibc. If you are new to uClibc, then you _might_ want to try something less ambitious than building mozilla and all the necessary dependencies. > i attempt to compile libiconv-1.8 > > ./configure // I think it run ok > make // It send one error > > The last lines of the output are: > > make[1]: Entering directory `/libiconv-1.8/src' > /bin/sh ../libtool --mode=link gcc iconv_no_i18n.o > ../lib/libiconv.la > -o iconv_no_i18n > gcc iconv_no_i18n.o -o .libs/iconv_no_i18n > ../lib/.libs/libiconv.so > -Wl,--rpath -Wl,/usr/local/lib > iconv_no_i18n.o: In function `main': > /libiconv-1.8/src/iconv.c:247: the 'setlocale' > function supports only > C|POSIX locales > ../lib/.libs/libiconv.so: undefined reference to > `_IO_getc' > collect2: ld returned 1 exit status > make[1]: *** [iconv_no_i18n] Error 1 > make[1]: Leaving directory `/libiconv-1.8/src' > make: *** [all] Error 2 > [root@tvmovil libiconv-1.8]# It looks like somehow you built libiconv using the glibc headers. The _IO_getc function is invoked by the getc macro in glibc, while uClibc has an entirely different stdio implementation. > I appreciate your comments, sugestion, please don't be > brief in your responses, i'am very new to that uClibc > world and need to understand it. Expect to spend a lot of time getting up to speed. Browse the mailing list archives at uclibc.org. Look at Erik's buildroot stuff (there's a link on the uclibc home page) for examples of how to build libraries and applications using uClibc. Manuel From seh at zee2.com Wed Jul 2 18:12:18 2003 From: seh at zee2.com (Stuart Hughes) Date: Sat Jul 19 08:54:51 2003 Subject: [uClibc] time.h Message-ID: <3F030462.279B120A@zee2.com> Greetings, I had a problem with struct tm in time.h when compiling with a c++ compiler (mipsel-uclibc-g++). If a declaration is: struct tm; (uninitialised) The compiler complains and fails: .cpp:line: structure `timeStruct' with uninitialized const members Looking at glibc they have a slight difference. I've attached a patch that changes the uclibc file to be like glibc, and this stops the error. Regards, Stuart -------------- next part -------------- --- time.h.orig Wed Jul 2 16:52:57 2003 +++ time.h Wed Jul 2 16:54:45 2003 @@ -130,10 +130,10 @@ #ifdef __UCLIBC_HAS_TM_EXTENSIONS__ # ifdef __USE_BSD long int tm_gmtoff; /* Seconds east of UTC. */ - __const char tm_zone[8]; /* Timezone abbreviation. */ + __const char *tm_zone; /* Timezone abbreviation. */ # else long int __tm_gmtoff; /* Seconds east of UTC. */ - __const char __tm_zone[8];/* Timezone abbreviation. */ + __const char *__tm_zone; /* Timezone abbreviation. */ # endif #endif /* __UCLIBC_HAS_TM_EXTENSIONS__ */ }; From mjn3 at codepoet.org Wed Jul 2 11:30:55 2003 From: mjn3 at codepoet.org (Manuel Novoa III) Date: Sat Jul 19 08:54:51 2003 Subject: [uClibc] time.h In-Reply-To: <3F030462.279B120A@zee2.com> References: <3F030462.279B120A@zee2.com> Message-ID: <20030702163055.GA10726@codepoet.org> On Wed, Jul 02, 2003 at 05:12:18PM +0100, Stuart Hughes wrote: > Greetings, > > I had a problem with struct tm in time.h when compiling with a c++ > compiler (mipsel-uclibc-g++). > If a declaration is: struct tm; (uninitialised) > > The compiler complains and fails: > > .cpp:line: structure > `timeStruct' with uninitialized const members > > Looking at glibc they have a slight difference. I've attached a patch > that changes the uclibc file to be like glibc, and this stops the error. > > Regards, Stuart > --- time.h.orig Wed Jul 2 16:52:57 2003 > +++ time.h Wed Jul 2 16:54:45 2003 > @@ -130,10 +130,10 @@ > #ifdef __UCLIBC_HAS_TM_EXTENSIONS__ > # ifdef __USE_BSD > long int tm_gmtoff; /* Seconds east of UTC. */ > - __const char tm_zone[8]; /* Timezone abbreviation. */ > + __const char *tm_zone; /* Timezone abbreviation. */ > # else > long int __tm_gmtoff; /* Seconds east of UTC. */ > - __const char __tm_zone[8];/* Timezone abbreviation. */ > + __const char *__tm_zone; /* Timezone abbreviation. */ > # endif > #endif /* __UCLIBC_HAS_TM_EXTENSIONS__ */ > }; Your patch isn't going work, since the uClibc time code expects to store the timezone in the struct itself. You'll wind up with overwrites and invalid memory accesses. I suppose to get around this I'll have to add a seperate data field and initialize a __const char *__tm_zone member to point to the internal data array. I was trying to avoid doing that, and wasn't counting on such nit-picky compilers. Oh well... For the time being, you could try removing the __const qualifier on the tm_zone[8] members. Manuel From geetham at india.hp.com Wed Jul 2 19:28:18 2003 From: geetham at india.hp.com (Geetha Manjunath) Date: Sat Jul 19 08:54:51 2003 Subject: [uClibc]python 2.2.2 Message-ID: <3F02D6EA.B04B3E89@india.hp.com> Hello Rob, I am trying to compile Python 2.1 with uclibc... facing linking problems.. I saw your posting on thsi subject. Can you kindly let me know the configure options you used for python and uclibs? I thought may be missing some features.. Or is it something to do with the Python version?? I would appreciate any help here. thanks and regards Geetha PS: These linking problems come in only when i execute python (dynamically linked). some of these are : _dl_nloaded, _dl_profile, __libc_stack_end and so on... From andersen at codepoet.org Wed Jul 2 11:34:12 2003 From: andersen at codepoet.org (Erik Andersen) Date: Sat Jul 19 08:54:51 2003 Subject: [uClibc] installing more that one toolchain In-Reply-To: <3F02F141.95A071BE@zee2.com> References: <3F02F141.95A071BE@zee2.com> Message-ID: <20030702163411.GA11041@codepoet.org> On Wed Jul 02, 2003 at 03:50:41PM +0100, Stuart Hughes wrote: > Greetings, > > Not sure if I've goofed up here, but I'm trying to install 2 cross > compilers (mipsel and powerpc) but I'm finding that the later install > overwrites files from the earlier one. This seems to be because > /-linux>/lib is a symlink to /lib in the > toolchains I've built (from the script on uclibc.org). > > Is this a known limitation, or did I just mess up on my toolchain build > ?? It is very possible I made a mistake. I do that on occasion despite popular opinion to the contrary... Patches to fix the problem are warmly welcome, -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- From andersen at codepoet.org Wed Jul 2 12:07:36 2003 From: andersen at codepoet.org (Erik Andersen) Date: Sat Jul 19 08:54:51 2003 Subject: [uClibc] uClibc-0.9.20 and ldd coredump In-Reply-To: References: Message-ID: <20030702170736.GB11041@codepoet.org> On Wed Jul 02, 2003 at 05:10:08PM +0200, Peter S. Mazinger wrote: > Hello! > > The changelog of 0.9.20 says, that the problem with ldd coredumping > if ran against non-executables is solved. > Attached are the outputs of strace ldd /lib/libc.so.0 (native environment) > for: > ulimit -c 0 (ldd.0) > ulimit -c 128 (ldd.1) > > I have to mention that I am using a grsecurity enabled kernel (mainly the > PaX options - http://pageexec.virtualave.net - are relevant for this > case). > Although I've got earlier the answer that PaX/grsecurity has problems with > uClibc (true for uClibc < 0.9.18, reported by me), I am using grsecurity > since uClibc-0.9.19 natively on x86 and there are no problems (only the > ones present also on a glibc system ;-). You have reported this several times now. Each time with straces of ldd doing its thing. And each time I have looked at the straces and I have not seen any evidence of coredumping or other problems.... Next time, pass the -f option to strace so we can also see what the child process is doing. And perhaps running ltrace (also with the -f option) may provide additional clues.... Anyway, I just took a close look and I think the problem is that I was trying to exec things like shared libraries and such. I just changed ldd to only exec elf type ET_EXEC files. Hopefully that should fix up the problem you are seeing. -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- From dpforos at yahoo.com Wed Jul 2 12:02:42 2003 From: dpforos at yahoo.com (Daniel Pezoa) Date: Sat Jul 19 08:54:51 2003 Subject: [uClibc] uClibc Mozilla In-Reply-To: <20030702155704.GA10257@codepoet.org> Message-ID: <20030702180242.35523.qmail@web11203.mail.yahoo.com> Hello Manuel > Look at Erik's > buildroot > stuff (there's a link on the uclibc home page) for > examples of > how to build libraries and applications using > uClibc. Sorry for my bad search features, i can't find that link, i search in the Homepage and FAQ. And if i browse here: http://uclibc.org/cgi-bin/cvsweb/buildroot/ i don't know where to go for the samples, i search but i don't found the samples, if you can post the url of some sample. I will be very happy. I'am confused for the following info, i think the samples can help in solve my problems > It looks like somehow you built libiconv using the > glibc headers. > The _IO_getc function is invoked by the getc macro > in glibc, while > uClibc has an entirely different stdio > implementation. I should make something wrong in my settings causing the attempt of usage of the glibc, can you explain me how you set your root_fs-i386. I make the following. bzip2 -d root_fs-i386.bz2 mkdir mnt e2fsck -f root_fs-i386 // check filesystem resize2fs root_fs-i386 2500000 // resize filesystem mount -o loop root_fs-i386 mnt cp libiconv-1.8.tar.bz2 mnt chroot mnt tar -jxf libiconv-1.8.tar.bz2 cd libiconv-1.8 ./configure make Is that ok, or i need to do another step omitted. I see in some search in google some call ( sh --login ), i don't know if it or another step is required for this. If you find my steps correct please let me know it, otherwise you can rectify it. If i run it with ssh, or inside xwindow, it could affect my results. Thanks for share, your help is very usefull for me. Daniel Pezoa --- Manuel Novoa III wrote: > On Tue, Jul 01, 2003 at 12:42:54PM -0700, Daniel > Pezoa wrote: > > I'am new to Uclibc. > > > > I want to compile mozilla for the use in a > Freevix, > > one small linux distribution booteable from > network, > > wich is compiled with uClibc. > > If you are new to uClibc, then you _might_ want to > try something > less ambitious than building mozilla and all the > necessary > dependencies. > > > i attempt to compile libiconv-1.8 > > > > ./configure // I think it run ok > > make // It send one error > > > > The last lines of the output are: > > > > make[1]: Entering directory `/libiconv-1.8/src' > > /bin/sh ../libtool --mode=link gcc > iconv_no_i18n.o > > ../lib/libiconv.la > > -o iconv_no_i18n > > gcc iconv_no_i18n.o -o .libs/iconv_no_i18n > > ../lib/.libs/libiconv.so > > -Wl,--rpath -Wl,/usr/local/lib > > iconv_no_i18n.o: In function `main': > > /libiconv-1.8/src/iconv.c:247: the 'setlocale' > > function supports only > > C|POSIX locales > > ../lib/.libs/libiconv.so: undefined reference to > > `_IO_getc' > > collect2: ld returned 1 exit status > > make[1]: *** [iconv_no_i18n] Error 1 > > make[1]: Leaving directory `/libiconv-1.8/src' > > make: *** [all] Error 2 > > [root@tvmovil libiconv-1.8]# > > It looks like somehow you built libiconv using the > glibc headers. > The _IO_getc function is invoked by the getc macro > in glibc, while > uClibc has an entirely different stdio > implementation. > > > I appreciate your comments, sugestion, please > don't be > > brief in your responses, i'am very new to that > uClibc > > world and need to understand it. > > Expect to spend a lot of time getting up to speed. > Browse the > mailing list archives at uclibc.org. Look at Erik's > buildroot > stuff (there's a link on the uclibc home page) for > examples of > how to build libraries and applications using > uClibc. > > Manuel __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com From mjn3 at codepoet.org Wed Jul 2 13:16:04 2003 From: mjn3 at codepoet.org (Manuel Novoa III) Date: Sat Jul 19 08:54:51 2003 Subject: [uClibc] uClibc Mozilla In-Reply-To: <20030702180242.35523.qmail@web11203.mail.yahoo.com> References: <20030702155704.GA10257@codepoet.org> <20030702180242.35523.qmail@web11203.mail.yahoo.com> Message-ID: <20030702181604.GA12503@codepoet.org> On Wed, Jul 02, 2003 at 11:02:42AM -0700, Daniel Pezoa wrote: > Sorry for my bad search features, i can't find that > link, i search in the Homepage and FAQ. And if i > browse here: > > http://uclibc.org/cgi-bin/cvsweb/buildroot/ That's it. > i don't know where to go for the samples, i search but > i don't found the samples, if you can post the url of > some sample. I will be very happy. Look at the various make/*.mk files in buildroot. > I'am confused for the following info, i think the > samples can help in solve my problems > > > It looks like somehow you built libiconv using the > > glibc headers. > > The _IO_getc function is invoked by the getc macro > > in glibc, while > > uClibc has an entirely different stdio > > implementation. > > I should make something wrong in my settings causing > the attempt of usage of the glibc, can you explain me > how you set your root_fs-i386. I make the following. > > bzip2 -d root_fs-i386.bz2 > mkdir mnt > e2fsck -f root_fs-i386 // check filesystem > resize2fs root_fs-i386 2500000 // resize filesystem > mount -o loop root_fs-i386 mnt > cp libiconv-1.8.tar.bz2 mnt > chroot mnt > tar -jxf libiconv-1.8.tar.bz2 > cd libiconv-1.8 > ./configure > make That should work. If it doesn't, try looking at the preprocessor output (gcc -E) to see why _IO_getc is being referenced. Manuel From seh at zee2.com Wed Jul 2 20:22:38 2003 From: seh at zee2.com (Stuart Hughes) Date: Sat Jul 19 08:54:51 2003 Subject: [uClibc] time.h References: <3F030462.279B120A@zee2.com> <20030702163055.GA10726@codepoet.org> Message-ID: <3F0322EE.23A7F6D7@zee2.com> Manuel Novoa III wrote: > > On Wed, Jul 02, 2003 at 05:12:18PM +0100, Stuart Hughes wrote: > > Greetings, > > > > I had a problem with struct tm in time.h when compiling with a c++ > > compiler (mipsel-uclibc-g++). > > If a declaration is: struct tm; (uninitialised) > > [snip] > Your patch isn't going work, since the uClibc time code expects to > store the timezone in the struct itself. You'll wind up with > overwrites and invalid memory accesses. > Thought that may be the case. > I suppose to get around this I'll have to add a seperate data field > and initialize a __const char *__tm_zone member to point to the internal > data array. I was trying to avoid doing that, and wasn't counting on > such nit-picky compilers. Oh well... > > For the time being, you could try removing the __const qualifier on the > tm_zone[8] members. Yes, that fixes it too. Regards, Stuart From chris at txrx.org Wed Jul 2 20:14:51 2003 From: chris at txrx.org (Chris Brookes) Date: Sat Jul 19 08:54:51 2003 Subject: [uClibc] xfree86 4.3 tip and tvtime-0.9.8.5 problem Message-ID: <1057173261.582.53.camel@bit> Hi, I had a current CVS version of XFree86 4.3 compiled under the 0.9.19 development environment, with only minor changes to ceil and float errors, if I remember correctly. I might also have added -lcrypt to solve the dlopen linking problem. Anyway, just thought I'd mentioned that the same source tree failed to compile underthe new 0.9.20 image, stopping reporting undefined references to dlopen. The fix was to add -ldl as a link option... in my host.def I use a line like: #define DefaultGcc2i386Opt -O4 -fno-strength-reduce -march=i586 -mcpu=i586 -mmmx -lcrypt -ldl Don't know if that's the RIGHT way to do it, but I end up with a compiled and working X. :-) Anyway I'm trying to compile tvtime (http://tvtime.sf.net) .. apart from it's use of wordexp() which I get around by removing the function that uses it and just returning a normal value (that hack will work for now)... it then fails reporting several undefined refernces to rpl_malloc .. the code just has malloc() calls it in at the lines where the undefined references are. I looked through the archives and saw some mention of an rpl_malloc patch, and then an rpl workaround being removed... ?? Chris From wpl at cc4.ckitc.edu.tw Thu Jul 3 11:37:52 2003 From: wpl at cc4.ckitc.edu.tw (teacher &) Date: Sat Jul 19 08:54:51 2003 Subject: [uClibc] Can uClibc work with ipfwadm-2.3.0 ? Message-ID: <20030703023752.M58248@www.ckitc.edu.tw> Dear all, I am new to this discussion forum, but I have started using uClibc (0.9.5) for transplanting some applications from my x86 PC to a ARM7TDMI SBC running with uClinux 2.0.38. I am encoutering a problem with cross-compiling ipfwadm-2.3.0 with the uClibc mentioned above. In order to simplify the problem, the included header part of the code was kept intact, while the main functional part was replaced as follows: ======================================= #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include <---added according to the suggestion of www.xos.nl #include #include main() { exit(0); } ========================================= The purpose of doing this is simply to understand if the header files conflict with each other. As a result, it seems that doesn't like , e.g. will include which seems to conflict with . is not happy with either. So my questions are: 1. Is my understanding meaningful? 2. Can any version of uClibc work with ipfwadm-2.3.0 ? or 3. Can or work with ? 4. Has anyone ever cross-compiled ipfwadm-2.3.0 for uClinuc-based ARM7-TDMI? Thanks, Wen-Ping Lai Dept. of Management Information Systems TAIWAN wpl@mail.ckitc.edu.tw From andersen at codepoet.org Thu Jul 3 01:02:51 2003 From: andersen at codepoet.org (Erik Andersen) Date: Sat Jul 19 08:54:51 2003 Subject: [uClibc] Can ftpd tftpd openssh etc compiled through uclibc ? In-Reply-To: References: <20030702032136.GB4339@codepoet.org> Message-ID: <20030703060251.GA24158@codepoet.org> On Thu Jul 03, 2003 at 01:35:18PM +0800, Calilonhuang wrote: > I've using 0.9.19. gcc 3.2.3. > It told me it can't find some .h files. "It told me it can't find some .h files." is an absolutely worthless problem report. A useful report would actually include a cut and paste showing the gcc command and the actual error message. -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- From andersen at codepoet.org Thu Jul 3 01:08:34 2003 From: andersen at codepoet.org (Erik Andersen) Date: Sat Jul 19 08:54:51 2003 Subject: [uClibc] Can uClibc work with ipfwadm-2.3.0 ? In-Reply-To: <20030703023752.M58248@www.ckitc.edu.tw> References: <20030703023752.M58248@www.ckitc.edu.tw> Message-ID: <20030703060834.GB24158@codepoet.org> On Thu Jul 03, 2003 at 10:37:52AM +0800, teacher & wrote: > Dear all, > > I am new to this discussion forum, but I have started using > uClibc (0.9.5) for transplanting some applications from my x86 PC > to a ARM7TDMI SBC running with uClinux 2.0.38. > > I am encoutering a problem with cross-compiling ipfwadm-2.3.0 > with the uClibc mentioned above. In order to simplify the problem, > the included header part of the code was kept intact, while > the main functional part was replaced as follows: > > ======================================= > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include <---added according to the suggestion of Using linux kernel headers directly within a userspace application (i.e. #include ) is illegal. Therefore, ipfwadm-2.3.0 as shipped, is completely broken. Look at http://ftp.debian.org/debian/pool/main/i/ipfwadm/ipfwadm_2.3.0-4.diff.gz for an example showing how to fix ipfwadm-2.3.0 so it works with both glibc and uClibc. -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- From Calilonhuang at bj.t2-design.com Thu Jul 3 14:35:18 2003 From: Calilonhuang at bj.t2-design.com (Calilonhuang) Date: Sat Jul 19 08:54:51 2003 Subject: [uClibc] Can ftpd tftpd openssh etc compiled through uclibc ? In-Reply-To: <20030702032136.GB4339@codepoet.org> Message-ID: I've using 0.9.19. gcc 3.2.3. It told me it can't find some .h files. When I use uclibc compile dhcp & udhcp. It'll seach all .h in uclibc's include automaticly. I only change CC= $(MYPATH)\uclibc\bin\mipsel-uclibc-gcc That's all right. I needn't change CFLAG. Need I to make other changes to openssh's Makefile? Because these .h is in uclibc's include, xxx-uclibc-gcc can't find them. :( I don't think I need to add -I$(uclibcpath) -I$(uclibcpath) /bits -I$(uclibcpath) .......... to CFLAG Re: [uClibc] Can ftpd tftpd openssh etc compiled through uclibc ? On Wed Jul 02, 2003 at 08:40:51AM +0800, Calilonhuang wrote: > I want to build one of them under mips using uclibc. > I find openssh is listed in working list. But I can't compile it successfully. It works. I have compiled openssh with uClibc on mips using uClibc 0.9.20. Therefore, since you did not provide a proper problem report, I have to assume you did something wrong. -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- From andersen at codepoet.org Thu Jul 3 01:20:20 2003 From: andersen at codepoet.org (Erik Andersen) Date: Sat Jul 19 08:54:51 2003 Subject: [uClibc] xfree86 4.3 tip and tvtime-0.9.8.5 problem In-Reply-To: <1057173261.582.53.camel@bit> References: <1057173261.582.53.camel@bit> Message-ID: <20030703062020.GC24158@codepoet.org> On Wed Jul 02, 2003 at 02:14:22PM -0500, Chris Brookes wrote: > Hi, > > I had a current CVS version of XFree86 4.3 compiled under the 0.9.19 > development environment, with only minor changes to ceil and float > errors, if I remember correctly. I might also have added -lcrypt to > solve the dlopen linking problem. Anyway, just thought I'd mentioned > that the same source tree failed to compile underthe new 0.9.20 image, > stopping reporting undefined references to dlopen. The fix was to add > -ldl as a link option... in my host.def I use a line like: > > #define DefaultGcc2i386Opt -O4 -fno-strength-reduce -march=i586 > -mcpu=i586 -mmmx -lcrypt -ldl > > Don't know if that's the RIGHT way to do it, but I end up with a > compiled and working X. :-) You did just fine... :-) > Anyway I'm trying to compile tvtime (http://tvtime.sf.net) .. apart from > it's use of wordexp() which I get around by removing the function that > uses it and just returning a normal value (that hack will work for > now)... it then fails reporting several undefined refernces to > rpl_malloc .. the code just has malloc() calls it in at the lines where > the undefined references are. > > I looked through the archives and saw some mention of an rpl_malloc > patch, and then an rpl workaround being removed... ?? rpl_malloc is an abomination that was introduced by autoconf's broken AC_FUNC_MALLOC macro, which redefines malloc to rpl_malloc if it does not detect glibc's brain damaged return-a-valid-pointer-for-malloc(0) behavior, which we do not do because doing so is not required by the relevant standards and doing so is Incredibly Stupid(tm). Very very few applications actually rely on getting a usable pointer from a malloc(0) and most of those rely on this because they are buggy. Furthermore, many applications add the broken AC_FUNC_MALLOC macro to their configure.in, but fail to supply an implementation of rpl_malloc for when the test fails. Others do implement rpl_malloc (as the autoconf makers intended). So I had to remove my attempt at a workaround from uClibc... So, in short, your tvtime application is broken since it uses the AC_FUNC_MALLOC autoconf macro without supplying an implementation of rpl_malloc. Chances are about 99.999% that you should just remove the broken AC_FUNC_MALLOC macro from configure.in. But if they in fact depend on getting a usable pointer for malloc(0), then here is a trivial implementation: void *rpl_malloc (size_t __size) { if (__size == 0) { __size++; } return malloc(__size); } -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- From andrew.dennison at motec.com.au Thu Jul 3 18:52:05 2003 From: andrew.dennison at motec.com.au (Andrew Dennison) Date: Sat Jul 19 08:54:51 2003 Subject: [uClibc] idiot proofing development system images? In-Reply-To: <20030702155704.GA10257@codepoet.org> Message-ID: <003601c34137$ff0a2ed0$4000a8c0@ANDREWDT3> I just stupidly tried to experiment with the i386 development system images on a box with a 2.2 kernel. Unfortunately as the image is built with large file support this means that I had rather cryptic problems, and it took a while to work out what I had done wrong... May I suggest that there is a note on the web site to point out that a 2.4 kernel is required for the images to work? I built a buildroot image without large file support and I can chroot into that without any problems so I got there in the end... Andrew From andersen at codepoet.org Thu Jul 3 03:11:35 2003 From: andersen at codepoet.org (Erik Andersen) Date: Sat Jul 19 08:54:51 2003 Subject: [uClibc] idiot proofing development system images? In-Reply-To: <003601c34137$ff0a2ed0$4000a8c0@ANDREWDT3> References: <20030702155704.GA10257@codepoet.org> <003601c34137$ff0a2ed0$4000a8c0@ANDREWDT3> Message-ID: <20030703081134.GA25776@codepoet.org> On Thu Jul 03, 2003 at 05:52:05PM +1000, Andrew Dennison wrote: > I just stupidly tried to experiment with the i386 development system images > on a box with a 2.2 kernel. Unfortunately as the image is built with large > file support this means that I had rather cryptic problems, and it took a > while to work out what I had done wrong... > > May I suggest that there is a note on the web site to point out that a 2.4 > kernel is required for the images to work? > > I built a buildroot image without large file support and I can chroot into > that without any problems so I got there in the end... oops. ATTENTION ALL: the development system images are built with 2.4.x kernels and large file support enabled! -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- From tero at paravant.fi Thu Jul 3 15:23:33 2003 From: tero at paravant.fi (=?ISO-8859-15?Q?Tero_Lyytik=E4inen?=) Date: Sat Jul 19 08:54:51 2003 Subject: [uClibc] Problems with IO.so in perl In-Reply-To: <20030701164037.6288dd26.uclibc@lacklustre.net> References: <20030701164037.6288dd26.uclibc@lacklustre.net> Message-ID: On Tue, 1 Jul 2003, Michael Ryan wrote: > I also tried to execute ldd on the shared object in question and it > seems to be compiled statically, while on my workstation [also Perl > 5.8.0], it is dynamically linked to glibc 2.3.1. My workstation is > running Debian Unstable, by the way. > I got a similar situation with perl and the problem was that the perl executable was statistically linked to libdl. (Actually it was statistically linked to everything but libc) So I just moved away the libdl.a file, recompiled perl and then ldd reported perl was dynamically linked to libdl! So I really don't know why this happens but my suggestion is to move all the relevant .a files temporarily away, recompile and then your perl and it's modules should be dynamically linked. I have previously encountered similar problems, like 'gcc -o test test.c' generating static executables. The location of the library files seems to cause this...? From andersen at codepoet.org Thu Jul 3 05:42:49 2003 From: andersen at codepoet.org (Erik Andersen) Date: Sat Jul 19 08:54:51 2003 Subject: [uClibc]Possible problem with soft-float on powerpc In-Reply-To: <3E7442B7.9070103@allot.com> References: <3E7442B7.9070103@allot.com> Message-ID: <20030703104249.GA5302@dillweed.codepoet.org> On Sun Mar 16, 2003 at 11:24:07AM +0200, Felix Radensky wrote: > Maybe the problem is in FP() macro definition in > libc/sysdeps/linux/powerpc/setjmp.S and > libc/sysdeps/linux/powerpc/__longjmp.S > > #ifdef __UCLIBC_HAS_FLOATS__ [-------snip--------] > which should be defined as > > if defined __UCLIBC_HAS_FLOATS__ && ! defined __UCLIBC_HAS_SOFT_FLOAT__ Thanks! You are absolutely correct! Sorry I didn't see this email before. I was just digging through my old mail and noticed this one... This problem is now (finally) fixed, -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- From andersen at codepoet.org Thu Jul 3 05:43:47 2003 From: andersen at codepoet.org (Erik Andersen) Date: Sat Jul 19 08:54:51 2003 Subject: [uClibc]PowerPC without FPU In-Reply-To: <1052113768.883.4.camel@kool> References: <1052113768.883.4.camel@kool> Message-ID: <20030703104347.GB5302@dillweed.codepoet.org> On Mon May 05, 2003 at 07:49:28AM +0200, Rasmus Rohde wrote: > It seems to me there is a small bug in the checking for FPU availability > in the PowerPC part of the code: > > In the dir uClibc/libc/sysdeps/linux we have the following checks on > arm: > > arm/__longjmp.S:#if defined __UCLIBC_HAS_FLOATS__ && ! defined > __UCLIBC_HAS_SOFT_FLOAT__ > arm/setjmp.S:#if defined __UCLIBC_HAS_FLOATS__ && ! defined > __UCLIBC_HAS_SOFT_FLOAT__ > > But on PowerPC there is no check for __UCLIBC_HAS_SOFT_FLOAT__: > > powerpc/__longjmp.S:#ifdef __UCLIBC_HAS_FLOATS__ > powerpc/setjmp.S:#ifdef __UCLIBC_HAS_FLOATS__ > > Shouldn't the PowerPC have the same check? Yup. Sorry I didn't see / respond to your email before... This problem is fixed now. -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- From os2doc at bellsouth.net Fri Jul 4 00:45:17 2003 From: os2doc at bellsouth.net (Michael Rowley) Date: Sat Jul 19 08:54:51 2003 Subject: [uClibc] 0.9.20 compile problem Message-ID: <1057275894.13673.2.camel@larafin.walker-rowley.net> Hello All, I am having a compile problem with 0.9.20, using redhat 9.0 as host, kernel 2.4.20, gcc 3.2.2. I get the following error when trying to compile. make[2]: Entering directory `/home/michael/lightweight Linux/uClibc/ldso/ldso' echo "const char *_dl_progname=\""ld-uClibc.so.0"\";" > ldso.h echo "#include \"i386/elfinterp.c\"" >> ldso.h gcc -Wall -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -mpreferred-stack-boundary=2 -falign-jumps=0 -falign-loops=0 -Os -march=i586 -fno-builtin -nostdinc -D_LIBC -I../../include -I. -I/usr/lib/gcc-lib/i386-redhat-linux/3.2.2/include -DNDEBUG -fPIC -I. -I./i386 -I../libdl -c i386/resolve.S -o i386/resolve.o strip -x -R .note -R .comment i386/resolve.o gcc -Wall -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -mpreferred-stack-boundary=2 -falign-jumps=0 -falign-loops=0 -Os -march=i586 -fno-builtin -nostdinc -D_LIBC -I../../include -I. -I/usr/lib/gcc-lib/i386-redhat-linux/3.2.2/include -DNDEBUG -fPIC -DUCLIBC_TARGET_PREFIX=\"/\" -DUCLIBC_DEVEL_PREFIX=\""/usr/i386-linux-uclibc"\" -DUCLIBC_BUILD_DIR=\"/home/michael/lightweight Linux/uClibc\" -I. -I./i386 -I../libdl -c ldso.c -o ldso.o gcc: cannot specify -o with -c or -S and multiple compilations make[2]: *** [ldso.o] Error 1 make[2]: Leaving directory `/home/michael/lightweight Linux/uClibc/ldso/ldso' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/michael/lightweight Linux/uClibc/ldso' make: *** [_dir_ldso] Error 2 [root@larafin uClibc]# I apologize, but I am fairly inexperienced with make, and usually can manage it. I am not sure how to fix this problem though. Any help? I checked the mail list archives, but found no reference to the problem. Michael. From dpforos at yahoo.com Thu Jul 3 18:03:14 2003 From: dpforos at yahoo.com (Daniel Pezoa) Date: Sat Jul 19 08:54:51 2003 Subject: [uClibc] uclibc question :-) Message-ID: <20030704000314.71587.qmail@web11201.mail.yahoo.com> Hello :-) What is the function of linuxrc link to executable in the root_fs-i386, if i launch that link it start one session of logging, that i can easily solve with user root and without password. The steps for start using root_fs-i386 should be: mount -o loop root_fs-i386 mnt chroot mnt linuxrc And then i compile with uclibc, is that correct ? Or i need to set the path of uclibc ... , i'am confused with this, because when i try to compile libiconv-1.8 it print one referebce to glibc: undefined reference to '_IO_getc' What is the way to solve the problem when one program don't compile with uclibc, modify the Makefile?, modify the source code?, kill me :-) ? Good luck Daniel Pezoa __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com From tecneeq at gmx.net Fri Jul 4 04:05:29 2003 From: tecneeq at gmx.net (Karsten Kruse) Date: Sat Jul 19 08:54:51 2003 Subject: [uClibc] uclibc question :-) In-Reply-To: <20030704000314.71587.qmail@web11201.mail.yahoo.com> References: <20030704000314.71587.qmail@web11201.mail.yahoo.com> Message-ID: On Thu, 3 Jul 2003, Daniel Pezoa wrote: > What is the function of linuxrc link to executable in > the root_fs-i386 Read this: http://lxr.linux.no/source/Documentation/initrd.txt > The steps for start using root_fs-i386 should be: > mount -o loop root_fs-i386 mnt > chroot mnt > linuxrc Not exactly: mkdir mnt mount -t ext2 -o loop root_fs-i386 mnt chroot mnt /bin/sh Thats all. But what i do is this: mkdir mnt mount -t ext2 -o loop root_fs-i386 mnt mount --bind /proc mnt/proc mount --bind /free/space mnt/mnt chroot mnt /bin/bash > And then i compile with uclibc, is that correct ? Yes. > Or i need to set the path of uclibc ... , i'am > confused with this, because when i try to compile > libiconv-1.8 it print one referebce to glibc: > undefined reference to '_IO_getc' > What is the way to solve the problem when one program > don't compile with uclibc, modify the Makefile?, > modify the source code?, kill me :-) ? I never saw that Problem, here are my steps: - Get and unpack libiconv-1.7.tar.gz - ./configure --prefix=/usr --disable-nls - make - make install or make DESTDIR=/somewhere install Karsten -- Homepage, Mac68k, A/UX-Links und Shorties: www.tecneeq.de () Linux/NetBSD-Anleitungen, Forum und Chat: www.newbie-net.de <\/> _/\_ When you are in it up to your ears, keep your mouth shut. From tecneeq at gmx.net Fri Jul 4 05:14:52 2003 From: tecneeq at gmx.net (Karsten Kruse) Date: Sat Jul 19 08:54:51 2003 Subject: [uClibc] libdl-0.9.20.so not found Message-ID: Hi, i try to compile Openssh with the 0.9.20-dev-system. This was the plan (worked with the previous dev-system): - rm everything wich has todo with Openssl or Openssh - compile openssl-0.9.7b.tar.gz: CFLAGS="-DOPENSSL_NO_KRB5 -DOPENSSL_NO_IDEA \ -DOPENSSL_NO_MDC2 -DOPENSSL_NO_RC5" ./Configure linux-elf --prefix=/usr --openssldir=/usr/lib/ssl -ldl \ zlib-dynamic no-threads shared no-idea no-mdc2 no-rc5 make all build-shared make install make DESTDIR=target_dir install - compile openssh-3.6.1p2.tar.gz: ./configure --prefix=/usr --disable-lastlog --disable-utmp \ --disable-utmpx --disable-wtmp --disable-wtmpx \ --without-x --disable-nls make make DESTDIR=target_dir install With the new dev-system Openssh's configure stops: configure: error: *** Can't find recent OpenSSL libcrypto (see config.log for details) *** This is from config.log: configure:9483: gcc -o conftest -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I/usr/local/ssl/include -L/usr/local/ssl/lib conftest.c -lutil -lz -lcrypto >&5 /usr/lib/gcc-lib/i386-linux/3.3/../../../../i386-linux/bin/ld: warning: libdl.so.0, needed by /usr/lib/gcc-lib/i386-linux/3.3/../../../libcrypto.so, not found (try using -rpath or -rpath-link) /usr/lib/gcc-lib/i386-linux/3.3/../../../libcrypto.so: undefined reference to `dlerror' /usr/lib/gcc-lib/i386-linux/3.3/../../../libcrypto.so: undefined reference to `dlclose' /usr/lib/gcc-lib/i386-linux/3.3/../../../libcrypto.so: undefined reference to `dlopen' /usr/lib/gcc-lib/i386-linux/3.3/../../../libcrypto.so: undefined reference to `dlsym' collect2: ld returned 1 exit status ldd libcrypto.so.0.9.7 says: ldd /usr/lib/libcrypto.so.0.9.7 libdl.so.0 => /lib/libdl.so.0 (0x00000000) libc.so.0 => /lib/libc.so.0 (0x00000000) /lib/ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x00000000) Thanks for any help or hints :). Karsten -- Homepage, Mac68k, A/UX-Links und Shorties: www.tecneeq.de () Linux/NetBSD-Anleitungen, Forum und Chat: www.newbie-net.de <\/> _/\_ When you are in it up to your ears, keep your mouth shut. From tom at ceisystems.com Fri Jul 4 04:22:51 2003 From: tom at ceisystems.com (tom@ceisystems.com) Date: Sat Jul 19 08:54:51 2003 Subject: [uClibc] uclibc question :-) Message-ID: <6D31D5429FA6884CBE9ECAB6C9B5E6A907E08B@intel-srvr.patcameron.ne.mediaone.net> Hello all, You might also want to `mount --bind /dev mnt/dev`. This will help when you try to compile nice packages like Perl, etc. It also makes life much less confusing and obfuscated when you're flipping from chroot'ed environment to real system. :-P One thing you _should_ know, going into this, is that the buildroot system is targeted at developers and people that are comfortable with compiling sources, etc. This means that if you are not familiar with Makefiles, Configure scripts, compilers, linkers, cross-compilers, or any of the other terms that are frequently thrown around in development groups, you may want to consider doing some reading before attempting to dive right in. I would say, feel free to ask any (previously unanswered/unposted) question you like. Chances are, though, that most of the questions you will have while getting started may be found by using the Google search on the main uClibc page. That will prove to be an invaluable resource for you. Good luck, Thomas Cameron CEI Systems, Inc. -----Original Message----- From: Karsten Kruse [mailto:tecneeq@gmx.net] Sent: Thursday, July 03, 2003 9:05 PM To: Daniel Pezoa Cc: uclibc Subject: Re: [uClibc] uclibc question :-) On Thu, 3 Jul 2003, Daniel Pezoa wrote: > What is the function of linuxrc link to executable in > the root_fs-i386 Read this: http://lxr.linux.no/source/Documentation/initrd.txt > The steps for start using root_fs-i386 should be: > mount -o loop root_fs-i386 mnt > chroot mnt > linuxrc Not exactly: mkdir mnt mount -t ext2 -o loop root_fs-i386 mnt chroot mnt /bin/sh Thats all. But what i do is this: mkdir mnt mount -t ext2 -o loop root_fs-i386 mnt mount --bind /proc mnt/proc mount --bind /free/space mnt/mnt chroot mnt /bin/bash > And then i compile with uclibc, is that correct ? Yes. > Or i need to set the path of uclibc ... , i'am > confused with this, because when i try to compile libiconv-1.8 it > print one referebce to glibc: > undefined reference to '_IO_getc' > What is the way to solve the problem when one program > don't compile with uclibc, modify the Makefile?, > modify the source code?, kill me :-) ? I never saw that Problem, here are my steps: - Get and unpack libiconv-1.7.tar.gz - ./configure --prefix=/usr --disable-nls - make - make install or make DESTDIR=/somewhere install Karsten -- Homepage, Mac68k, A/UX-Links und Shorties: www.tecneeq.de () Linux/NetBSD-Anleitungen, Forum und Chat: www.newbie-net.de <\/> _/\_ When you are in it up to your ears, keep your mouth shut. _______________________________________________ uClibc mailing list uClibc@uclibc.org http://uclibc.org/mailman/listinfo/uclibc From seh at zee2.com Fri Jul 4 10:59:43 2003 From: seh at zee2.com (Stuart Hughes) Date: Sat Jul 19 08:54:51 2003 Subject: [uClibc] gcc-3.2 uclibc toolchain failure Message-ID: <3F0541FF.F53B8DCD@zee2.com> Greetings, I've been trying to build the latest cvs version of toolchain/gcc-3.2, but it fails on gcc-final. with many multiply defined symbols, the last is: libgcc/./_make_df.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:1342: first defined here libgcc/./dp-bit.o: In function `__truncdfsf2': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:1356: multiple definition of `__truncdfsf2' libgcc/./_df_to_sf.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:1356: first defined here collect2: ld returned 1 exit status make[3]: *** [libgcc_s.so] Error 1 make[3]: Leaving directory `/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/g I've attached the build full build messages. Anyone seen this before and know a fix ?? Regards, Stuart -------------- next part -------------- cat /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-3.2/gcc/libgcc-std.ver /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-3.2/gcc/config/libgcc-glibc.ver | sed -e "/^[ ]*#/d" -e 's/^%\(if\|else\|elif\|endif\|define\)/#\1/' \ | /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/xgcc -B/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/ -B/usr/local/uclibc/mipsel-linux/gcc-3.2/mipsel-linux/bin/ -B/usr/local/uclibc/mipsel-linux/gcc-3.2/mipsel-linux/lib/ -isystem /usr/local/uclibc/mipsel-linux/gcc-3.2/mipsel-linux/include -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-3.2/gcc -I/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-3.2/gcc/. -I/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-3.2/gcc/config -I/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-3.2/gcc/../include -E -xassembler-with-cpp -; \ } | gawk -f /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-3.2/gcc/mkmap-symver.awk > libgcc/./tmp-libgcc.map mv libgcc/./tmp-libgcc.map libgcc/./libgcc.map /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/xgcc -B/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/ -B/usr/local/uclibc/mipsel-linux/gcc-3.2/mipsel-linux/bin/ -B/usr/local/uclibc/mipsel-linux/gcc-3.2/mipsel-linux/lib/ -isystem /usr/local/uclibc/mipsel-linux/gcc-3.2/mipsel-linux/include -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -shared -nodefaultlibs -Wl,--soname=libgcc_s.so.0.9.9 -Wl,--version-script=libgcc/./libgcc.map -o libgcc_s.so.0.9.9 libgcc/./_muldi3.o libgcc/./_negdi2.o libgcc/./_lshrdi3.o libgcc/./_ashldi3.o libgcc/./_ashrdi3.o libgcc/./_ffsdi2.o libgcc/./_clz.o libgcc/./_cmpdi2.o libgcc/./_ucmpdi2.o libgcc/./_floatdidf.o libgcc/./_floatdisf.o libgcc/./_fixunsdfsi.o libgcc/./_fixunssfsi.o libgcc/./_fixunsdfdi.o libgcc/./_fixdfdi.o libgcc/./_fixunssfdi.o libgcc/./_fixsfdi.o libgcc/./_fixxfdi.o libgcc/./_fixunsxfdi.o libgcc/./_floatdixf.o libgcc/./_fixunsxfsi.o libgcc/./_fixtfdi.o libgcc/./_fixunstfdi.o libgcc/./_floatditf.o libgcc/./_clear_cache.o libgcc/./_trampoline.o libgcc/./__main.o libgcc/./_exit.o libgcc/./_absvsi2.o libgcc/./_absvdi2.o libgcc/./_addvsi3.o libgcc/./_addvdi3.o libgcc/./_subvsi3.o libgcc/./_subvdi3.o libgcc/./_mulvsi3.o libgcc/./_mulvdi3.o libgcc/./_negvsi2.o libgcc/./_negvdi2.o libgcc/./_ctors.o libgcc/./_divdi3.o libgcc/./_moddi3.o libgcc/./_udivdi3.o libgcc/./_umoddi3.o libgcc/./_udiv_w_sdiv.o libgcc/./_udivmoddi4.o libgcc/./_pack_sf.o libgcc/./_unpack_sf.o libgcc/./_addsub_sf.o libgcc/./_mul_sf.o libgcc/./_div_sf.o libgcc/./_fpcmp_parts_sf.o libgcc/./_compare_sf.o libgcc/./_eq_sf.o libgcc/./_ne_sf.o libgcc/./_gt_sf.o libgcc/./_ge_sf.o libgcc/./_lt_sf.o libgcc/./_le_sf.o libgcc/./_unord_sf.o libgcc/./_si_to_sf.o libgcc/./_sf_to_si.o libgcc/./_negate_sf.o libgcc/./_make_sf.o libgcc/./_sf_to_df.o libgcc/./_thenan_sf.o libgcc/./_sf_to_usi.o libgcc/./_usi_to_sf.o libgcc/./_pack_df.o libgcc/./_unpack_df.o libgcc/./_addsub_df.o libgcc/./_mul_df.o libgcc/./_div_df.o libgcc/./_fpcmp_parts_df.o libgcc/./_compare_df.o libgcc/./_eq_df.o libgcc/./_ne_df.o libgcc/./_gt_df.o libgcc/./_ge_df.o libgcc/./_lt_df.o libgcc/./_le_df.o libgcc/./_unord_df.o libgcc/./_si_to_df.o libgcc/./_df_to_si.o libgcc/./_negate_df.o libgcc/./_make_df.o libgcc/./_df_to_sf.o libgcc/./_thenan_df.o libgcc/./_df_to_usi.o libgcc/./_usi_to_df.o libgcc/./fp-bit.o libgcc/./dp-bit.o libgcc/./unwind-dw2.o libgcc/./unwind-dw2-fde-glibc.o libgcc/./unwind-sjlj.o -lc && rm -f libgcc_s.so && ln -s libgcc_s.so.0.9.9 libgcc_s.so libgcc/./fp-bit.o: In function `__pack_f': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:183: multiple definition of `__thenan_sf' libgcc/./_thenan_sf.o(.rodata+0x0): first defined here libgcc/./fp-bit.o: In function `__pack_f': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:183: multiple definition of `__pack_f' libgcc/./_pack_sf.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:183: first defined here libgcc/./fp-bit.o: In function `__unpack_f': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:309: multiple definition of `__unpack_f' libgcc/./_unpack_sf.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:309: first defined here libgcc/./fp-bit.o: In function `__addsf3': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:543: multiple definition of `__addsf3' libgcc/./_addsub_sf.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:543: first defined here libgcc/./fp-bit.o: In function `__subsf3': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:563: multiple definition of `__subsf3' libgcc/./_addsub_sf.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:563: first defined here libgcc/./fp-bit.o: In function `__mulsf3': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:757: multiple definition of `__mulsf3' libgcc/./_mul_sf.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:757: first defined here libgcc/./fp-bit.o: In function `__divsf3': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:868: multiple definition of `__divsf3' libgcc/./_div_sf.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:868: first defined here libgcc/./fp-bit.o: In function `__fpcmp_parts_f': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:895: multiple definition of `__fpcmp_parts_f' libgcc/./_fpcmp_parts_sf.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:895: first defined here libgcc/./fp-bit.o: In function `__cmpsf2': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:974: multiple definition of `__cmpsf2' libgcc/./_compare_sf.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:974: first defined here libgcc/./fp-bit.o: In function `__eqsf2': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:996: multiple definition of `__eqsf2' libgcc/./_eq_sf.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:996: first defined here libgcc/./fp-bit.o: In function `__nesf2': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:1017: multiple definition of `__nesf2' libgcc/./_ne_sf.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:1017: first defined here libgcc/./fp-bit.o: In function `__gtsf2': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:1038: multiple definition of `__gtsf2' libgcc/./_gt_sf.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:1038: first defined here libgcc/./fp-bit.o: In function `__gesf2': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:1059: multiple definition of `__gesf2' libgcc/./_ge_sf.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:1059: first defined here libgcc/./fp-bit.o: In function `__ltsf2': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:1079: multiple definition of `__ltsf2' libgcc/./_lt_sf.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:1079: first defined here libgcc/./fp-bit.o: In function `__lesf2': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:1100: multiple definition of `__lesf2' libgcc/./_le_sf.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:1100: first defined here libgcc/./fp-bit.o: In function `__unordsf2': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:1121: multiple definition of `__unordsf2' libgcc/./_unord_sf.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:1121: first defined here libgcc/./fp-bit.o: In function `__floatsisf': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:1141: multiple definition of `__floatsisf' libgcc/./_si_to_sf.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:1141: first defined here libgcc/./fp-bit.o: In function `__floatunsisf': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:1179: multiple definition of `__floatunsisf' libgcc/./_usi_to_sf.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:1179: first defined here libgcc/./fp-bit.o: In function `__fixsfsi': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:1211: multiple definition of `__fixsfsi' libgcc/./_sf_to_si.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:1211: first defined here libgcc/./fp-bit.o: In function `__negsf2': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:1279: multiple definition of `__negsf2' libgcc/./_negate_sf.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:1279: first defined here libgcc/./fp-bit.o: In function `__make_fp': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:1299: multiple definition of `__make_fp' libgcc/./_make_sf.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:1299: first defined here libgcc/./fp-bit.o: In function `__extendsfdf2': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:1320: multiple definition of `__extendsfdf2' libgcc/./_sf_to_df.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:1320: first defined here libgcc/./dp-bit.o: In function `__pack_d': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:183: multiple definition of `__thenan_df' libgcc/./_thenan_df.o(.rodata+0x0): first defined here libgcc/./dp-bit.o: In function `__pack_d': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:183: multiple definition of `__pack_d' libgcc/./_pack_df.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:183: first defined here libgcc/./dp-bit.o: In function `__unpack_d': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:309: multiple definition of `__unpack_d' libgcc/./_unpack_df.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:309: first defined here libgcc/./dp-bit.o: In function `__adddf3': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:543: multiple definition of `__adddf3' libgcc/./_addsub_df.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:543: first defined here libgcc/./dp-bit.o: In function `__subdf3': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:563: multiple definition of `__subdf3' libgcc/./_addsub_df.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:563: first defined here libgcc/./dp-bit.o: In function `__muldf3': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:757: multiple definition of `__muldf3' libgcc/./_mul_df.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:757: first defined here libgcc/./dp-bit.o: In function `__divdf3': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:868: multiple definition of `__divdf3' libgcc/./_div_df.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:868: first defined here libgcc/./dp-bit.o: In function `__fpcmp_parts_d': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:895: multiple definition of `__fpcmp_parts_d' libgcc/./_fpcmp_parts_df.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:895: first defined here libgcc/./dp-bit.o: In function `__cmpdf2': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:974: multiple definition of `__cmpdf2' libgcc/./_compare_df.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:974: first defined here libgcc/./dp-bit.o: In function `__eqdf2': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:996: multiple definition of `__eqdf2' libgcc/./_eq_df.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:996: first defined here libgcc/./dp-bit.o: In function `__nedf2': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:1017: multiple definition of `__nedf2' libgcc/./_ne_df.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:1017: first defined here libgcc/./dp-bit.o: In function `__gtdf2': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:1038: multiple definition of `__gtdf2' libgcc/./_gt_df.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:1038: first defined here libgcc/./dp-bit.o: In function `__gedf2': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:1059: multiple definition of `__gedf2' libgcc/./_ge_df.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:1059: first defined here libgcc/./dp-bit.o: In function `__ltdf2': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:1079: multiple definition of `__ltdf2' libgcc/./_lt_df.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:1079: first defined here libgcc/./dp-bit.o: In function `__ledf2': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:1100: multiple definition of `__ledf2' libgcc/./_le_df.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:1100: first defined here libgcc/./dp-bit.o: In function `__unorddf2': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:1121: multiple definition of `__unorddf2' libgcc/./_unord_df.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:1121: first defined here libgcc/./dp-bit.o: In function `__floatsidf': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:1141: multiple definition of `__floatsidf' libgcc/./_si_to_df.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:1141: first defined here libgcc/./dp-bit.o: In function `__floatunsidf': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:1179: multiple definition of `__floatunsidf' libgcc/./_usi_to_df.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:1179: first defined here libgcc/./dp-bit.o: In function `__fixdfsi': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:1211: multiple definition of `__fixdfsi' libgcc/./_df_to_si.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:1211: first defined here libgcc/./dp-bit.o: In function `__negdf2': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:1279: multiple definition of `__negdf2' libgcc/./_negate_df.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:1279: first defined here libgcc/./dp-bit.o: In function `__make_dp': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:1342: multiple definition of `__make_dp' libgcc/./_make_df.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:1342: first defined here libgcc/./dp-bit.o: In function `__truncdfsf2': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:1356: multiple definition of `__truncdfsf2' libgcc/./_df_to_sf.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:1356: first defined here collect2: ld returned 1 exit status make[3]: *** [libgcc_s.so] Error 1 make[3]: Leaving directory `/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc' make[2]: *** [stmp-multilib] Error 2 make[2]: Leaving directory `/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc' make[1]: *** [all-gcc] Error 2 make[1]: Leaving directory `/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final' make: *** [/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/.compiled] Error 2 From christian_michon at yahoo.fr Fri Jul 4 12:53:27 2003 From: christian_michon at yahoo.fr (=?iso-8859-1?q?Christian=20MICHON?=) Date: Sat Jul 19 08:54:52 2003 Subject: [uClibc] help in compile uclibc gtk In-Reply-To: <20030702145615.21121.qmail@web11202.mail.yahoo.com> Message-ID: <20030704095327.79450.qmail@web11102.mail.yahoo.com> --- Daniel Pezoa a ?crit : > Hello > > I see gtk in the list of what can be compiled with > uclibc. > > But it require glib, pango, atk, pkgconfig, libiconv. > I think I reported gtk-1.2.10 (the old gnome toolkit). gtk-2.x.x is quite bloated compared to uclibc concept, no ? If your application can survive on the old toolkit, don't use version 2.x.x. Christian ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en fran?ais ! Yahoo! Mail : http://fr.mail.yahoo.com From cdweng at netrd.iii.org.tw Fri Jul 4 20:34:40 2003 From: cdweng at netrd.iii.org.tw (=?big5?B?r86n07lG?=) Date: Sat Jul 19 08:54:52 2003 Subject: [uClibc] Problem with pthread_create....!! Message-ID: <1d9b01c34220$41c545a0$e53d5c8c@iii.org.tw> hi,all: I got a problem when used pthread_create function call in my arm-uclinux kernel 2.0.38. The pthread_create had no return and all threads were freeze at the time. Could any body give me a hint for how to reslove this problem......? My uclibc is version 0.9.20. B.R. ==================================================== Chih-Da Weng Network Communication Laboratory, Institute for Information Industry. 5FL., 116, Sec. 2, Nan-King E. Rd., Taipei 104,Taiwan, R.O.C. TEL:886-2--2564-3588 ext. 220 FAX: 886-2-2564-3775 E-mail: cdweng@netrd.iii.org.tw -------------- next part -------------- An HTML attachment was scrubbed... URL: http://uclibc.org/lists/uclibc/attachments/20030704/c43e5535/attachment.htm From dpforos at yahoo.com Fri Jul 4 08:30:39 2003 From: dpforos at yahoo.com (Daniel Pezoa) Date: Sat Jul 19 08:54:52 2003 Subject: [uClibc] uclibc question :-) In-Reply-To: Message-ID: <20030704143039.84628.qmail@web11207.mail.yahoo.com> Hello Karsten Kruse Thanks, your post help me a lot! I now have the libiconv-1.7 compiled ok My problem is because i use the 1.8 versión, but i really don't require 1.8, 1.7 is quite well. Good luck Daniel Pezoa --- Karsten Kruse wrote: > > On Thu, 3 Jul 2003, Daniel Pezoa wrote: > > > What is the function of linuxrc link to executable > in > > the root_fs-i386 > > Read this: > http://lxr.linux.no/source/Documentation/initrd.txt > > > The steps for start using root_fs-i386 should be: > > mount -o loop root_fs-i386 mnt > > chroot mnt > > linuxrc > > Not exactly: > mkdir mnt > mount -t ext2 -o loop root_fs-i386 mnt > chroot mnt /bin/sh > > Thats all. But what i do is this: > mkdir mnt > mount -t ext2 -o loop root_fs-i386 mnt > mount --bind /proc mnt/proc > mount --bind /free/space mnt/mnt > chroot mnt /bin/bash > > > And then i compile with uclibc, is that correct ? > > Yes. > > > Or i need to set the path of uclibc ... , i'am > > confused with this, because when i try to compile > > libiconv-1.8 it print one referebce to glibc: > > > undefined reference to '_IO_getc' > > > What is the way to solve the problem when one > program > > don't compile with uclibc, modify the Makefile?, > > modify the source code?, kill me :-) ? > > I never saw that Problem, here are my steps: > > - Get and unpack libiconv-1.7.tar.gz > - ./configure --prefix=/usr --disable-nls > - make > - make install or make DESTDIR=/somewhere install > > Karsten > > -- > Homepage, Mac68k, A/UX-Links und Shorties: > www.tecneeq.de > () Linux/NetBSD-Anleitungen, Forum und Chat: > www.newbie-net.de > <\/> > _/\_ When you are in it up to your ears, keep > your mouth shut. __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com From terjekv at math.uio.no Sat Jul 5 01:03:46 2003 From: terjekv at math.uio.no (Terje Kvernes) Date: Sat Jul 19 08:54:52 2003 Subject: [uClibc] pcmcia modules error. Message-ID: hm, is this a known issue when using the buildroot? mkdir -p /var/tmp/buildroot/build_i386/root/etc/default cp -f /var/tmp/buildroot/build_i386/pcmcia-cs-3.2.4/etc/pcmcia /var/tmp/buildroot/build_i386/root/etc/default/ cp -f /var/tmp/buildroot/build_i386/pcmcia-cs-3.2.4/etc/rc.pcmcia /var/tmp/buildroot/build_i386/root/etc/init.d/S30pcmcia rm -rf /var/tmp/buildroot/build_i386/root/etc/pcmcia/cis chmod a+x /var/tmp/buildroot/build_i386/root/etc/init.d/S30pcmcia chmod -R u+w /var/tmp/buildroot/build_i386/root/etc/pcmcia/* make: *** No rule to make target `/var/tmp/buildroot/build_i386/root/lib/modules', needed by `/var/tmp/buildroot/build_i386/pcmcia-cs-3.2.4/.modules.dep'. Stop. I have the following targets set: [x200 /var/tmp/buildroot] # grep ^TARGETS+ Makefile TARGETS+=uclibc_toolchain TARGETS+=system-linux TARGETS+=busybox tinylogin TARGETS+=zlib openssl openssh TARGETS+=coreutils findutils bash make diffutils patch sed TARGETS+=ed flex bison file gawk tar grep gcc_target TARGETS+=ncurses-headers zlib-headers openssl-headers TARGETS+=m4 autoconf automake libtool TARGETS+=perl TARGETS+=gdb strace TARGETS+=iptables hostap wtools dhcp_relay bridge TARGETS+=iproute2 netsnmp TARGETS+=ext2root since I have no big need for hostap, wtools, dhcp_relay, bridge and netsnmp I just removed them and the compile finished fine. -- Terje From dpforos at yahoo.com Fri Jul 4 16:44:39 2003 From: dpforos at yahoo.com (Daniel Pezoa) Date: Sat Jul 19 08:54:52 2003 Subject: [uClibc] uclibc libIDL Message-ID: <20030704224439.94620.qmail@web11201.mail.yahoo.com> Hello I need help comipiling libIDL 0.6.8 at the end i have that output: /parser.y:2070: dereferencing pointer to incomplete type ./parser.y:2070: dereferencing pointer to incomplete type ./parser.y:2070: dereferencing pointer to incomplete type ./parser.y:2075: dereferencing pointer to incomplete type ./parser.y: In function `IDL_queue_new_ident_comment': ./parser.y:2091: warning: assignment makes pointer from integer without a cast make: *** [parser.lo] Error 1 [root@tvmovil libIDL-0.6.8]# If any have compiled it or another version, or have one idea about the problem, please give your help. Good luck. Daniel Pezoa __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com From os2doc at bellsouth.net Sat Jul 5 05:30:12 2003 From: os2doc at bellsouth.net (Michael Rowley) Date: Sat Jul 19 08:54:52 2003 Subject: [uClibc] compile perl-5.8.0 with uclibc Message-ID: <1057379400.20882.2.camel@larafin.walker-rowley.net> Hello! Problems compiling perl5.8.0. I am not using buildroot, just compiling with a modified path as per the uclibc install file, and it has worked well to now, but I can't get perl to compile. I applied the patch I found in the archives for perl, but it didn't help. I get the following error: cc -o miniperl \ miniperlmain.o opmini.o libperl.a libperl.a(pp.o)(.text+0x170a): In function `Perl_pp_pow': : undefined reference to `pow' libperl.a(pp.o)(.text+0x54d9): In function `Perl_pp_sin': : undefined reference to `sin' libperl.a(pp.o)(.text+0x55e5): In function `Perl_pp_cos': : undefined reference to `cos' libperl.a(pp.o)(.text+0x58c5): In function `Perl_pp_exp': : undefined reference to `exp' libperl.a(pp.o)(.text+0x5a07): In function `Perl_pp_log': : undefined reference to `log' collect2: ld returned 1 exit status make: *** [miniperl] Error 1 Any ideas/assistance? I need perl for my system to work... :( M. From andersen at codepoet.org Sat Jul 5 12:32:54 2003 From: andersen at codepoet.org (Erik Andersen) Date: Sat Jul 19 08:54:52 2003 Subject: [uClibc] compile perl-5.8.0 with uclibc In-Reply-To: <1057379400.20882.2.camel@larafin.walker-rowley.net> References: <1057379400.20882.2.camel@larafin.walker-rowley.net> Message-ID: <20030705173254.GA19604@codepoet.org> On Sat Jul 05, 2003 at 12:30:00AM -0400, Michael Rowley wrote: > Hello! > > Problems compiling perl5.8.0. I am not using buildroot, just compiling > with a modified path as per the uclibc install file, and it has worked > well to now, but I can't get perl to compile. I applied the patch I > found in the archives for perl, but it didn't help. I get the following > error: > > cc -o miniperl \ > miniperlmain.o opmini.o libperl.a > libperl.a(pp.o)(.text+0x170a): In function `Perl_pp_pow': > : undefined reference to `pow' > libperl.a(pp.o)(.text+0x54d9): In function `Perl_pp_sin': > : undefined reference to `sin' > libperl.a(pp.o)(.text+0x55e5): In function `Perl_pp_cos': > : undefined reference to `cos' > libperl.a(pp.o)(.text+0x58c5): In function `Perl_pp_exp': > : undefined reference to `exp' > libperl.a(pp.o)(.text+0x5a07): In function `Perl_pp_log': > : undefined reference to `log' > collect2: ld returned 1 exit status > make: *** [miniperl] Error 1 > > Any ideas/assistance? I need perl for my system to work... :( As a guess, it looks like you have failed to link with libm. Tried adding -lm? -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- From os2doc at bellsouth.net Mon Jul 7 02:37:28 2003 From: os2doc at bellsouth.net (Michael Rowley) Date: Sat Jul 19 08:54:52 2003 Subject: [uClibc] compile perl-5.8.0 with uclibc In-Reply-To: <20030705173254.GA19604@codepoet.org> References: <1057379400.20882.2.camel@larafin.walker-rowley.net> <20030705173254.GA19604@codepoet.org> Message-ID: <1057541812.26829.4.camel@larafin.walker-rowley.net> On Sat, 2003-07-05 at 13:32, Erik Andersen wrote: > On Sat Jul 05, 2003 at 12:30:00AM -0400, Michael Rowley wrote: > > Hello! > > > > Problems compiling perl5.8.0. I am not using buildroot, just compiling > > with a modified path as per the uclibc install file, and it has worked > > well to now, but I can't get perl to compile. I applied the patch I > > found in the archives for perl, but it didn't help. I get the following > > error: > > > > cc -o miniperl \ > > miniperlmain.o opmini.o libperl.a > > libperl.a(pp.o)(.text+0x170a): In function `Perl_pp_pow': > > : undefined reference to `pow' > > libperl.a(pp.o)(.text+0x54d9): In function `Perl_pp_sin': > > : undefined reference to `sin' > > libperl.a(pp.o)(.text+0x55e5): In function `Perl_pp_cos': > > : undefined reference to `cos' > > libperl.a(pp.o)(.text+0x58c5): In function `Perl_pp_exp': > > : undefined reference to `exp' > > libperl.a(pp.o)(.text+0x5a07): In function `Perl_pp_log': > > : undefined reference to `log' > > collect2: ld returned 1 exit status > > make: *** [miniperl] Error 1 > > > > Any ideas/assistance? I need perl for my system to work... :( > > As a guess, it looks like you have failed to link with libm. > Tried adding -lm? > > -Erik No, as stupid as this sounds, it was a problem with the path to where the code was.... I had a directory with a space, and the perl config script read it as 2 files... Changed the path, fixed the problem. One of those that makes you want to bang your head against the keyboard... :| Michael. From os2doc at bellsouth.net Mon Jul 7 02:46:49 2003 From: os2doc at bellsouth.net (Michael Rowley) Date: Sat Jul 19 08:54:52 2003 Subject: [uClibc] buildroot, and User Mode Linux Message-ID: <1057542378.26829.16.camel@larafin.walker-rowley.net> Hmm, For all the times I have been told to RTFM, now I wish I could. I am having some trouble with build root avaliable from the CSV site. There is a paucity of documentation. The readme seemed to imply that it would build UMlinux ( the final step in the instructions is to type ./UMlinux to check out the progress... ) Well, I couldn't find where UMlinux (or any other similar UML executable) was made during the compile, so I went to user-mode-linux.sourceforge.net and downloaded the RPM. It doesn't match my kernel (2.4.20-18.9, redhat 9.0), but got user_mode_linux-2.4.19.5um-0.i386.rpm and installed it, but now I am getting the following error when trying to load the root)fs made with buildroot Initializing RT netlink socket Kernel panic: outer trampoline didn't exit with SIGKILL Now, I am not sure if I have the right version, or the most recent, this one is dated Linux version 2.4.19-5um (jdike@uml.karaya.com) (gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-81)) #2 Mon Sep 16 15:41:15 EDT 2002 I hate being a pain, but any pointers to helpful information? I have done a google search for buildroot, and UML documentation, howto's and manual pages, but come up blank... With my luck this is another stupid mistake... Michael. From robm at flipturn.org Sun Jul 6 23:25:47 2003 From: robm at flipturn.org (Rob McMullen) Date: Sat Jul 19 08:54:52 2003 Subject: [uClibc] XEmacs success Message-ID: Finally got XEmacs working with uClibc and X11 under a uClibc-as-the-root-libc system: the trick is to use uClibc's malloc instead of configure's default that selects a malloc implementation included in XEmacs. Trigger this with the --with-system-malloc flag to configure. Also, due to the ld.so issues of shared libraries not able to load other shared libraries, I have to start XEmacs with: LD_PRELOAD=/usr/X11R6/lib/libXrender.so xemacs I leave out some bells and whistles here, but the configure command that I used should get you started: CC="gcc -Wl,-rpath-link=/usr/lib,-rpath-link=/lib" ./configure \ --with-widgets=athena --with-dialogs=athena --with-scrollbars=lucid \ --with-menubars=lucid --with-gif=yes --without-tiff --with-jpeg \ --without-xface --without-gpm --with-sound=native \ --with-database=gnudbm --with-system-malloc --prefix=/usr \ --with-ncurses --with-msw=no --mail-locking=flock \ --with-site-lisp=yes --with-site-modules=yes Rob From terjekv at math.uio.no Mon Jul 7 06:03:38 2003 From: terjekv at math.uio.no (Terje Kvernes) Date: Sat Jul 19 08:54:52 2003 Subject: [uClibc] XEmacs success In-Reply-To: (Rob McMullen's message of "Sun, 06 Jul 2003 22:25:47 -0400") References: Message-ID: Rob McMullen writes: > Finally got XEmacs working with uClibc and X11 under a > uClibc-as-the-root-libc system: the trick is to use uClibc's malloc > instead of configure's default that selects a malloc implementation > included in XEmacs. Trigger this with the --with-system-malloc flag > to configure. rather cute actually. :-) how large is the emacs binary and the full emacs tree? [ ... ] -- Terje From peter.kjellerstedt at axis.com Mon Jul 7 17:08:42 2003 From: peter.kjellerstedt at axis.com (Peter Kjellerstedt) Date: Sat Jul 19 08:54:52 2003 Subject: [uClibc] CRIS port Message-ID: > -----Original Message----- > From: Erik Andersen [mailto:andersen@codepoet.org] > Sent: 30 June 2003 19:35 > To: Simon Posnjak > Cc: uclibc@uclibc.org > Subject: Re: [uClibc] CRIS port > > On Mon Jun 30, 2003 at 05:59:36PM +0200, Simon Posnjak wrote: > > Hi all, > > > > Can somebody pleas tell me what is the status of CRIS port > > of uclibc. (Is it stable, is anybody working on it, anybody > > using it, etc). Thanks! > > It should be working. > > -Erik We have a number of updates for the CRIS architecture in our internal CVS that have not yet been applied to the official uClibc repository. They will be, eventually. As for working on it and using it: Yes, very much so. //Peter Kjellerstedt Axis Communications AB From kleine-budde at gmx.de Mon Jul 7 21:53:16 2003 From: kleine-budde at gmx.de (Marc Kleine-Budde) Date: Sat Jul 19 08:54:52 2003 Subject: [uClibc] CRIS port In-Reply-To: References: Message-ID: <20030707185316.GA11380@timberwolf.dyndns.org> Hello! On Mon, Jul 07, 2003 at 04:08:42PM +0200, Peter Kjellerstedt wrote: > > > Can somebody pleas tell me what is the status of CRIS port > > > of uclibc. (Is it stable, is anybody working on it, anybody > > > using it, etc). Thanks! > > It should be working. Hm - here uClibc-0.9.20 doesn't even compile out of the box. I'm using binutils 2.13.2.1, gcc 3.2.3 with the fixes and patches from buildroot. cris-uclibc-linux-gcc -Wall -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -Os -mlinux -fno-builtin -nostdinc -D_LIBC -I../../include -I. -I/home/frogger/ptxdist/xchain-cris/lib/gcc-lib/cris-uclibc-linux/3.2.3/include -DNDEBUG -fpic -mlinux -DUCLIBC_TARGET_PREFIX=\"/\" -DUCLIBC_DEVEL_PREFIX=\""/home/frogger/ptxdist/xchain-cris/cris-uclibc-linux"\" -DUCLIBC_BUILD_DIR=\"/home/frogger/projects/ptxdist/ptxdist-cris/build/uClibc-0.9.20\" -I. -I./cris -I../libdl -c ldso.c -o ldso.o In file included from ../../include/sys/syscall.h:23, from cris/ld_syscalls.h:7, from ld_syscall.h:6, from ldso.c:108: ../../include/bits/syscalls.h:9:26: bits/syscall.h: No such file or directory In file included from ldso.c:108: ld_syscall.h: In function `_dl_exit': ld_syscall.h:47: `__NR_exit' undeclared (first use in this function) ld_syscall.h:47: (Each undeclared identifier is reported only once ld_syscall.h:47: for each function it appears in.) ld_syscall.h: In function `_dl_close': [many missing __NR_s deleted] ld_syscall.h:155: `__NR_readlink' undeclared (first use in this function) In file included from linuxelf.h:6, from ldso.c:109: cris/ld_sysdep.h:55:35: warning: multi-line string literals are deprecated In file included from ldso.c:159: cris/boot1_arch.h:5:5: warning: multi-line string literals are deprecated after some random hacking and stumbling over another 'bug' [1] it compiles at least. I had no time to test it on the cris itself......See attached diff. Using buildroot, with the uClibc snapshot I get even more strage errors: /tmp/buildroot/build_cris/staging_dir/bin/cris-uclibc-gcc -Wall -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -Os -mlinux -fno-builtin -nostdinc -D_LIBC -I../../include -I. -I/tmp/buildroot/build_cris/staging_dir/lib/gcc-lib/cris-linux/3.3/include -DNDEBUG -fpic -mlinux -DUCLIBC_TARGET_PREFIX=\"/\" -DUCLIBC_DEVEL_PREFIX=\""/tmp/buildroot/build_cris/staging_dir"\" -DUCLIBC_BUILD_DIR=\"/tmp/buildroot/build_cris/uClibc\" -I. -I./cris -I../libdl -c ldso.c -o ldso.o In file included from ../../include/sys/syscall.h:23, from cris/ld_syscalls.h:7, from ld_syscall.h:6, from ldso.c:108: ../../include/bits/syscalls.h:9:26: bits/syscall.h: No such file or directory In file included from ldso.c:108: ld_syscall.h: In function `_dl_exit': ld_syscall.h:47: error: `__NR_exit' undeclared (first use in this function) ld_syscall.h:47: error: (Each undeclared identifier is reported only once ld_syscall.h:47: error: for each function it appears in.) ld_syscall.h: In function `_dl_close': ld_syscall.h:51: error: `__NR_close' undeclared (first use in this function) [many missing __NRs deleted] ld_syscall.h: In function `_dl_readlink': ld_syscall.h:155: error: `__NR_readlink' undeclared (first use in this function) In file included from linuxelf.h:6, from ldso.c:109: cris/ld_sysdep.h:55:35: missing terminating " character In file included from linuxelf.h:6, from ldso.c:109: cris/ld_sysdep.h: At top level: cris/ld_sysdep.h:56: error: parse error before "$r8" cris/ld_sysdep.h:56: warning: type defaults to `int' in declaration of `$r8' cris/ld_sysdep.h:56: error: stray '\' in program cris/ld_sysdep.h:56: warning: type defaults to `int' in declaration of `$srp' cris/ld_sysdep.h:56: error: parse error before "n" cris/ld_sysdep.h:56: error: stray '\' in program cris/ld_sysdep.h:57: error: stray '\' in program cris/ld_sysdep.h:57: error: stray '\' in program cris/ld_sysdep.h:58: error: stray '\' in program cris/ld_sysdep.h:58: error: stray '\' in program cris/ld_sysdep.h:58:107: missing terminating " character cris/ld_sysdep.h:66: warning: `struct elf_resolve' declared inside parameter list cris/ld_sysdep.h:66: warning: its scope is only this definition or declaration, which is probably not what you want In file included from ldso.c:159: cris/boot1_arch.h:5:5: missing terminating " character In file included from ldso.c:159: cris/boot1_arch.h:7: error: request for member `globl' in something not a structure or union cris/boot1_arch.h:7: error: parse error before "_dl_boot" cris/boot1_arch.h:8: error: syntax error at '@' token cris/boot1_arch.h:14:1: missing terminating " character In file included from ldso.h:2, from ldso.c:160: cris/elfinterp.c:102: error: conflicting types for `_dl_linux_resolver' cris/ld_sysdep.h:66: error: previous declaration of `_dl_linux_resolver' cris/elfinterp.c: In function `_dl_linux_resolver': cris/elfinterp.c:122: error: `_dl_progname' undeclared (first use in this function) In file included from ldso.h:2, from ldso.c:160: cris/elfinterp.c: In function `_dl_parse_lazy_relocation_information': cris/elfinterp.c:201: error: `_dl_progname' undeclared (first use in this function) In file included from ldso.h:2, from ldso.c:160: cris/elfinterp.c: In function `_dl_parse_relocation_information': cris/elfinterp.c:265: error: `_dl_progname' undeclared (first use in this function) In file included from ldso.h:2, from ldso.c:160: cris/elfinterp.c: In function `_dl_parse_copy_information': cris/elfinterp.c:378: error: `_dl_progname' undeclared (first use in this function) ldso.c: In function `_dl_boot2': ldso.c:598: error: `_dl_progname' undeclared (first use in this function) ldso.c:635: error: parse error before ';' token ldso.c:652: error: redeclaration of `goof' ldso.c:204: error: `goof' previously declared here ldso.c:723: error: `ppnt' undeclared (first use in this function) ldso.c:724: warning: value computed is not used ldso.c: In function `_dl_fixup': ldso.c:1322: error: `_dl_progname' undeclared (first use in this function) In file included from ldso.c:1399: readelflib1.c: In function `_dl_load_elf_shared_library': readelflib1.c:380: error: `_dl_progname' undeclared (first use in this function) In file included from ldso.c:1399: readelflib1.c: In function `_dl_malloc': readelflib1.c:776: error: `_dl_progname' undeclared (first use in this function) ld_string.h: At top level: ldso.c:158: warning: `_dl_get_ready_to_run' declared `static' but never defined regards - Marc [1] http://sources.redhat.com/ml/libc-alpha/2002-06/msg00006.html -- #!/bin/sh set - `type $0` 'tr "[a-zA-Z]" "[n-za-mN-ZA-M]"';while [ "$2" != "" ];do \ shift;done; echo 'frq -a -rc '`echo "$0"| $1 `'>$UBZR/.`rpub signature|'`\ echo $1|$1`'`;rpub "Jr ner fvtangher bs obet. Erfvfgnapr vf shgvyr!"'|$1|sh -------------- next part -------------- diff -ur uClibc-0.9.20.orig/include/features.h /home/frogger/ptxdist/ptxdist-cris/build/uClibc-0.9.20/include/features.h --- uClibc-0.9.20.orig/include/features.h Mon Feb 17 15:16:14 2003 +++ /home/frogger/ptxdist/ptxdist-cris/build/uClibc-0.9.20/include/features.h Mon Jul 7 20:08:14 2003 @@ -386,10 +386,15 @@ # define weak_const_function __attribute__ ((weak, __const__)) /* Tacking on "\n\t#" to the section name makes gcc put it's bogus * section attributes on what looks like a comment to the assembler. */ +# ifdef GNU_CRIS +# define __as_app_line "#APP\n" +# else +# define __as_app_line "" +# endif # define link_warning(symbol, msg) \ asm (".section " ".gnu.warning." #symbol "\n\t.previous"); \ static const char __evoke_link_warning_##symbol[] \ - __attribute__ ((unused, section (".gnu.warning." #symbol "\n\t#"))) = msg; + __attribute__ ((unused, section (".gnu.warning." #symbol "\n" __as_app_line "\t#"))) = msg; #else /* !defined __HAVE_ELF__ */ # define strong_alias(name, aliasname) _strong_alias (name, aliasname) # define weak_alias(name, aliasname) _strong_alias (name, aliasname) diff -ur uClibc-0.9.20.orig/ldso/ldso/cris/elfinterp.c /home/frogger/ptxdist/ptxdist-cris/build/uClibc-0.9.20/ldso/ldso/cris/elfinterp.c --- uClibc-0.9.20.orig/ldso/ldso/cris/elfinterp.c Tue Nov 5 19:21:00 2002 +++ /home/frogger/ptxdist/ptxdist-cris/build/uClibc-0.9.20/ldso/ldso/cris/elfinterp.c Mon Jul 7 20:08:14 2003 @@ -33,6 +33,10 @@ * SUCH DAMAGE. */ +#ifndef _dl_debug_file +#define _dl_debug_file 2 +#endif + /* Support for the LD_DEBUG variable. */ #if defined (__SUPPORT_LD_DEBUG__) static const char *_dl_reltypes_tab[] = { diff -ur uClibc-0.9.20.orig/ldso/ldso/ldso.c /home/frogger/ptxdist/ptxdist-cris/build/uClibc-0.9.20/ldso/ldso/ldso.c --- uClibc-0.9.20.orig/ldso/ldso/ldso.c Thu Jun 19 00:42:23 2003 +++ /home/frogger/ptxdist/ptxdist-cris/build/uClibc-0.9.20/ldso/ldso/ldso.c Mon Jul 7 20:08:14 2003 @@ -105,6 +105,7 @@ * application. */ +#include #include "ld_syscall.h" #include "linuxelf.h" #include "ld_hash.h" diff -ur uClibc-0.9.20.orig/ldso/libdl/dlib.c /home/frogger/ptxdist/ptxdist-cris/build/uClibc-0.9.20/ldso/libdl/dlib.c --- uClibc-0.9.20.orig/ldso/libdl/dlib.c Fri Jun 27 13:45:12 2003 +++ /home/frogger/ptxdist/ptxdist-cris/build/uClibc-0.9.20/ldso/libdl/dlib.c Mon Jul 7 20:08:14 2003 @@ -4,6 +4,7 @@ * Functions required for dlopen et. al. */ +#include #include #include #include "dlfcn.h" diff -ur uClibc-0.9.20.orig/libc/inet/socketcalls.c /home/frogger/ptxdist/ptxdist-cris/build/uClibc-0.9.20/libc/inet/socketcalls.c --- uClibc-0.9.20.orig/libc/inet/socketcalls.c Sun Jul 7 09:27:42 2002 +++ /home/frogger/ptxdist/ptxdist-cris/build/uClibc-0.9.20/libc/inet/socketcalls.c Mon Jul 7 20:08:14 2003 @@ -1,4 +1,5 @@ #define __FORCE_GLIBC +#include #include #include #include diff -ur uClibc-0.9.20.orig/libc/misc/sysvipc/msgq.c /home/frogger/ptxdist/ptxdist-cris/build/uClibc-0.9.20/libc/misc/sysvipc/msgq.c --- uClibc-0.9.20.orig/libc/misc/sysvipc/msgq.c Thu May 30 02:41:03 2002 +++ /home/frogger/ptxdist/ptxdist-cris/build/uClibc-0.9.20/libc/misc/sysvipc/msgq.c Mon Jul 7 20:08:14 2003 @@ -1,3 +1,4 @@ +#include #include #include #include "ipc.h" diff -ur uClibc-0.9.20.orig/libc/misc/sysvipc/sem.c /home/frogger/ptxdist/ptxdist-cris/build/uClibc-0.9.20/libc/misc/sysvipc/sem.c --- uClibc-0.9.20.orig/libc/misc/sysvipc/sem.c Sun Aug 25 02:08:23 2002 +++ /home/frogger/ptxdist/ptxdist-cris/build/uClibc-0.9.20/libc/misc/sysvipc/sem.c Mon Jul 7 20:08:14 2003 @@ -17,6 +17,7 @@ write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. */ +#include #include #include #include "ipc.h" diff -ur uClibc-0.9.20.orig/libc/misc/sysvipc/shm.c /home/frogger/ptxdist/ptxdist-cris/build/uClibc-0.9.20/libc/misc/sysvipc/shm.c --- uClibc-0.9.20.orig/libc/misc/sysvipc/shm.c Thu May 30 02:41:03 2002 +++ /home/frogger/ptxdist/ptxdist-cris/build/uClibc-0.9.20/libc/misc/sysvipc/shm.c Mon Jul 7 20:08:14 2003 @@ -17,6 +17,7 @@ write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. */ +#include #include #include #include diff -ur uClibc-0.9.20.orig/libc/sysdeps/linux/common/_exit.c /home/frogger/ptxdist/ptxdist-cris/build/uClibc-0.9.20/libc/sysdeps/linux/common/_exit.c --- uClibc-0.9.20.orig/libc/sysdeps/linux/common/_exit.c Mon Jul 22 19:11:58 2002 +++ /home/frogger/ptxdist/ptxdist-cris/build/uClibc-0.9.20/libc/sysdeps/linux/common/_exit.c Mon Jul 7 20:08:14 2003 @@ -21,6 +21,7 @@ */ #define _GNU_SOURCE +#include #include #include #include diff -ur uClibc-0.9.20.orig/libc/sysdeps/linux/common/create_module.c /home/frogger/ptxdist/ptxdist-cris/build/uClibc-0.9.20/libc/sysdeps/linux/common/create_module.c --- uClibc-0.9.20.orig/libc/sysdeps/linux/common/create_module.c Fri Nov 15 15:06:43 2002 +++ /home/frogger/ptxdist/ptxdist-cris/build/uClibc-0.9.20/libc/sysdeps/linux/common/create_module.c Mon Jul 7 20:08:14 2003 @@ -20,6 +20,7 @@ * Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ +#include #include #include #include diff -ur uClibc-0.9.20.orig/libc/sysdeps/linux/common/getdents.c /home/frogger/ptxdist/ptxdist-cris/build/uClibc-0.9.20/libc/sysdeps/linux/common/getdents.c --- uClibc-0.9.20.orig/libc/sysdeps/linux/common/getdents.c Mon Feb 10 22:15:20 2003 +++ /home/frogger/ptxdist/ptxdist-cris/build/uClibc-0.9.20/libc/sysdeps/linux/common/getdents.c Mon Jul 7 20:08:14 2003 @@ -16,6 +16,7 @@ Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. */ +#include #include #include #include diff -ur uClibc-0.9.20.orig/libc/sysdeps/linux/common/sync.c /home/frogger/ptxdist/ptxdist-cris/build/uClibc-0.9.20/libc/sysdeps/linux/common/sync.c --- uClibc-0.9.20.orig/libc/sysdeps/linux/common/sync.c Mon Jul 22 19:11:58 2002 +++ /home/frogger/ptxdist/ptxdist-cris/build/uClibc-0.9.20/libc/sysdeps/linux/common/sync.c Mon Jul 7 20:08:14 2003 @@ -21,6 +21,7 @@ */ #define _GNU_SOURCE +#include #include #include #include diff -ur uClibc-0.9.20.orig/libc/sysdeps/linux/common/syscalls.c /home/frogger/ptxdist/ptxdist-cris/build/uClibc-0.9.20/libc/sysdeps/linux/common/syscalls.c --- uClibc-0.9.20.orig/libc/sysdeps/linux/common/syscalls.c Fri Jun 27 09:36:43 2003 +++ /home/frogger/ptxdist/ptxdist-cris/build/uClibc-0.9.20/libc/sysdeps/linux/common/syscalls.c Mon Jul 7 20:08:14 2003 @@ -32,6 +32,7 @@ # undef __USE_FILE_OFFSET64 #endif +#include #include #include #include diff -ur uClibc-0.9.20.orig/libc/sysdeps/linux/cris/bits/syscalls.h /home/frogger/ptxdist/ptxdist-cris/build/uClibc-0.9.20/libc/sysdeps/linux/cris/bits/syscalls.h --- uClibc-0.9.20.orig/libc/sysdeps/linux/cris/bits/syscalls.h Fri Sep 20 17:17:16 2002 +++ /home/frogger/ptxdist/ptxdist-cris/build/uClibc-0.9.20/libc/sysdeps/linux/cris/bits/syscalls.h Mon Jul 7 20:23:14 2003 @@ -6,7 +6,7 @@ #endif /* Include the __NR_ definitions. */ -#include +/*#include */ #if 0 #ifndef __set_errno From simon at activetools.si Mon Jul 7 20:20:08 2003 From: simon at activetools.si (Simon Posnjak) Date: Sat Jul 19 08:54:52 2003 Subject: [uClibc] CRIS port In-Reply-To: <20030707185316.GA11380@timberwolf.dyndns.org> References: <20030707185316.GA11380@timberwolf.dyndns.org> Message-ID: <1057605543.5308.14.camel@klada.dyndns.org> Na 1057603996, 2003-07-07 ob 20:53, je Marc Kleine-Budde napisal(a): > I'm using binutils 2.13.2.1, gcc 3.2.3 with the fixes and patches from > buildroot. Is this tool chain stable? > cris-uclibc-linux-gcc -Wall -Wstrict-prototypes -Wno-trigraphs > -fno-strict-aliasing -Os -mlinux -fno-builtin -nostdinc -D_LIBC > -I../../include -I. > -I/home/frogger/ptxdist/xchain-cris/lib/gcc-lib/cris-uclibc-linux/3.2.3/include > -DNDEBUG -fpic -mlinux -DUCLIBC_TARGET_PREFIX=\"/\" > -DUCLIBC_DEVEL_PREFIX=\""/home/frogger/ptxdist/xchain-cris/cris-uclibc-linux"\" > -DUCLIBC_BUILD_DIR=\"/home/frogger/projects/ptxdist/ptxdist-cris/build/uClibc-0.9.20\" > -I. -I./cris -I../libdl -c ldso.c -o ldso.o > In file included from ../../include/sys/syscall.h:23, > from cris/ld_syscalls.h:7, > from ld_syscall.h:6, > from ldso.c:108: > ../../include/bits/syscalls.h:9:26: bits/syscall.h: No such file or > directory This will fix the error (found it going throu CVS logs): diff -uNr uClibc-0.9.20-orig/libc/sysdeps/linux/cris/bits/syscalls.h uClibc-0.9.20/libc/sysdeps/linux/cris/bits/syscalls.h --- uClibc-0.9.20-orig/libc/sysdeps/linux/cris/bits/syscalls.h 2002-09-20 17:17:16.000000000 +0200 +++ uClibc-0.9.20/libc/sysdeps/linux/cris/bits/syscalls.h 2003-07-04 11:46:06.000000000 +0200 @@ -6,7 +6,7 @@ #endif /* Include the __NR_ definitions. */ -#include +#include #if 0 #ifndef __set_errno > after some random hacking and stumbling over another 'bug' [1] it > compiles > at least. I had no time to test it on the cris itself......See attached > diff. I also found and fixed this little bug. And also a lot of missing #if defind in ldso/ldso/cris/elfinterp.c (debugging). Peter is there any chance that we could get your version of uClibc (or patches for mainstram) which works. (The one I hacked up seams to have some probles - after kernel boot system hangs - I'm just preparing to have a look whats going on) Regards Simon From kleine-budde at gmx.de Mon Jul 7 23:13:47 2003 From: kleine-budde at gmx.de (Marc Kleine-Budde) Date: Sat Jul 19 08:54:52 2003 Subject: [uClibc] CRIS port In-Reply-To: <1057605543.5308.14.camel@klada.dyndns.org> References: <20030707185316.GA11380@timberwolf.dyndns.org> <1057605543.5308.14.camel@klada.dyndns.org> Message-ID: <20030707201347.GA23298@timberwolf.dyndns.org> Hi On Mon, Jul 07, 2003 at 09:19:03PM +0200, Simon Posnjak wrote: > Na 1057603996, 2003-07-07 ob 20:53, je Marc Kleine-Budde napisal(a): > > I'm using binutils 2.13.2.1, gcc 3.2.3 with the fixes and patches from > > buildroot. > Is this tool chain stable? with this toolchain it's possible to compile glibc-2.2.5 (with some fixes). and we (a colleague actually) managed to get a glibc based system running....but we haven't tried the uClibc based jet.... > This will fix the error (found it going throu CVS logs): thanks regards - marc -- #!/bin/sh set - `type $0` 'tr "[a-zA-Z]" "[n-za-mN-ZA-M]"';while [ "$2" != "" ];do \ shift;done; echo 'frq -a -rc '`echo "$0"| $1 `'>$UBZR/.`rpub signature|'`\ echo $1|$1`'`;rpub "Jr ner fvtangher bs obet. Erfvfgnapr vf shgvyr!"'|$1|sh From simon at activetools.si Mon Jul 7 22:33:22 2003 From: simon at activetools.si (Simon Posnjak) Date: Sat Jul 19 08:54:52 2003 Subject: [uClibc] CRIS port In-Reply-To: <1057605543.5308.14.camel@klada.dyndns.org> References: <20030707185316.GA11380@timberwolf.dyndns.org> <1057605543.5308.14.camel@klada.dyndns.org> Message-ID: <1057613557.5308.31.camel@klada.dyndns.org> Na 1057605543, 2003-07-07 ob 21:19, je Simon Posnjak napisal(a): > Peter is there any chance that we could get your version of uClibc (or > patches for mainstram) which works. (The one I hacked up seams to have > some probles - after kernel boot system hangs - I'm just preparing to > have a look whats going on) Did some digging and discovered that dynamic linker dos not work at all. [First I compiled may distribution dynamical and nothing worked, then I complied init staticly and it worked (init that is, nothing else)]. ldd for dynamicaly linked init shows: [root@l15 tmp]# cris-uclibc-ldd init libc.so.0 => /work/buildroot/build/stage/lib/libc.so.0 (0x00000000) <---- /lib//ld-uClibc.so.0 => /lib//ld-uClibc.so.0 (0x00000000) [root@l15 tmp]# Is this correct (the first line)? If not any idea what is cosing it. init was compiled as(gcc_cris is a wrapper which is used by Axis to compile with uclibc): gcc_cris -mlinux -muclibc=/work/buildroot/build/stage/ -o init init.c and all so as: cris-uclibc-gcc -mlinux -isystem /usr/local/cris/lib/gcc-lib/cris/2.96/include -o init init.c THX, simon From vapier at gentoo.org Mon Jul 7 20:18:30 2003 From: vapier at gentoo.org (Mike Frysinger) Date: Sat Jul 19 08:54:52 2003 Subject: [uClibc] substr -g CFLAGS Message-ID: <200307071918.35489.vapier@gentoo.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 in some Makefiles you can find this code: SAFEFLAGS := $(subst -g,,$(CFLAGS)) which is all fine and dandy except for when CFLAGS contains a string that has '-g' in it ... specifically, i hit a case where gcc stores it's include files in /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/include/ ... when uclibc went to compile, gcc received '-I/usr/lib/gcc-lib/i686-pc-linuxnu/3.2.3/include' causing it to fail (because it couldnt locate stddef.h in this case). any thoughts on this ? one way of 'fixing' it would be to change the code to: SAFEFLAGS := $(subst -g ,, $(CFLAGS) ) notice the crazy usage of spaces ... ive attached an example Makefile to further illustrate my point ... - -mike -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iQIVAwUBPwn/y0FjO5/oN/WBAQKDpQ/+J+0V4+BUFrLKadlAJYJ39zpEQiT0kNQ4 TiIHbDojuiA/0p0tW4HHZIU3WcMCqU3DEHFEtJxcJGrGyGAjMv910ZiL1BgYqQC5 Vn2Yw86znf/GmpL0DNe67BBwqC6K1QyTr5S4sGFzlYNegxeLBbm4Kmd0NKZmBW7f dAszrZNmIBKcTjdhOraaTK/MhRiVokDO1iQAjywD7g7Nr29xEuaT7MfoDpgd6k8d peVoVr1kEkXdLE/3OjWjEMoymqg8J+KJZDBg1X8VCG3R0jYv3SltS05VQllxt6sB AjzrpkagOECg/7mdyscQ+ajGBbhRtofr4UpELNYXLm5QUN0dg0D4azilaBsbZ+Ck Fb3LKH+u28O9w1/CgEWkP7zV9+SscOGwl3t7QfZkHZtTKpDs/5KtJiUfzC7bFqAk RwUDTQDj7zT6pHVJDCXCZz3CFhvj68mKqfQnshJPqkX/gggi6eynrmpvN1PNDtBH TAgXXafkBS2UMERNjhVaZBAYNwp4L4H4glDfCLFow7/h0hVlznP10q5+ybak2y2+ yLj5GWezoPvXrHspLghyrz7TOFB8ivckiMhcnD1XtUYHLNI78le5e9gYq9W3zY1P u1LN0qOKJComXwzsHL0bwSTb/rKrnbIA1naMcbpLEyiO9QlErlRfhI7+NvMkNp4S NWUtdmmOCTg= =EYZd -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile Type: text/x-makefile Size: 425 bytes Desc: not available Url : http://uclibc.org/lists/uclibc/attachments/20030707/efb410be/Makefile.bin From dpforos at yahoo.com Mon Jul 7 18:42:00 2003 From: dpforos at yahoo.com (Daniel Pezoa) Date: Sat Jul 19 08:54:52 2003 Subject: [uClibc] Web Browser Uclibc Message-ID: <20030708004200.74996.qmail@web11201.mail.yahoo.com> Hello uClibc Community I want to have one graphical web browser uClibc compiled for my x86 box. If any have succesfully compiled any graphical web browser and can share the experience, i will be happy with it. Good luck! Daniel Pezoa __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com From uclibc at lacklustre.net Mon Jul 7 18:51:37 2003 From: uclibc at lacklustre.net (Michael Ryan) Date: Sat Jul 19 08:54:52 2003 Subject: [uClibc] Web Browser Uclibc In-Reply-To: <20030708004200.74996.qmail@web11201.mail.yahoo.com> References: <20030708004200.74996.qmail@web11201.mail.yahoo.com> Message-ID: <20030707175137.20f35ad9.uclibc@lacklustre.net> I haven't tried to compile it, but take a look at Dillo. It would probably work. http://www.dillo.org/ Best of luck. On Mon, 7 Jul 2003 17:42:00 -0700 (PDT) Daniel Pezoa wrote: > Hello uClibc Community > > I want to have one graphical web browser uClibc > compiled for my x86 box. If any have succesfully > compiled any graphical web browser and can share the > experience, i will be happy with it. > > Good luck! > > Daniel Pezoa > > > __________________________________ > Do you Yahoo!? > SBC Yahoo! DSL - Now only $29.95 per month! > http://sbc.yahoo.com > _______________________________________________ > uClibc mailing list > uClibc@uclibc.org > http://uclibc.org/mailman/listinfo/uclibc > -- Michael Ryan Lacklustre Networking michael@lacklustre.net http://www.lacklustre.net/ From alex at king.net.nz Tue Jul 8 14:05:51 2003 From: alex at king.net.nz (Alex King) Date: Sat Jul 19 08:54:52 2003 Subject: [uClibc] Web Browser Uclibc In-Reply-To: <20030708004200.74996.qmail@web11201.mail.yahoo.com> References: <20030708004200.74996.qmail@web11201.mail.yahoo.com> Message-ID: <20030708010550.GA12343@king.net.nz> I sucessfully compiled/run links which runs in a graphical mode directly on the linux framebuffer (http://atrey.karlin.mff.cuni.cz/~clock/twibright/links/) It doesn't display all images (GIFs I suspect). compiles to 2.7M, depends on png and jpeg libs which I compiled sucessfully also, and on gpm for mouse. On Mon, Jul 07, 2003 at 05:42:00PM -0700, Daniel Pezoa wrote: > Hello uClibc Community > > I want to have one graphical web browser uClibc > compiled for my x86 box. If any have succesfully > compiled any graphical web browser and can share the > experience, i will be happy with it. > > Good luck! > > Daniel Pezoa > > > __________________________________ > Do you Yahoo!? > SBC Yahoo! DSL - Now only $29.95 per month! > http://sbc.yahoo.com > _______________________________________________ > uClibc mailing list > uClibc@uclibc.org > http://uclibc.org/mailman/listinfo/uclibc From ibe at dcl.info.waseda.ac.jp Tue Jul 8 18:18:05 2003 From: ibe at dcl.info.waseda.ac.jp (ibe@dcl.info.waseda.ac.jp) Date: Sat Jul 19 08:54:52 2003 Subject: [uClibc]can't resolve symbol. Message-ID: <41672.202.232.97.131.1057652285.squirrel@mail2.dcl.info.waseda.ac.jp> Hi all, I am finally succesfully build uClibc with a powerpc gcc cross compiler. (I use 2.4.18 in Montavista linux PE3.0.) But I have some trouble when using some command like ls, mount or other. # ls ls: can't resolve symbol '__eqdf2' ls: can't resolve symbol '__floatsidf' ls: can't resolve symbol '__ltdf2' ls: can't resolve symbol '__adddf3' ls: can't resolve symbol '__fixdfsi' ls: can't resolve symbol '__negdf2' ls: can't resolve symbol '__divdf3' ls: can't resolve symbol '__muldf3' ls: can't resolve symbol '__truncdfsf2' ls: can't resolve symbol '__nedf2' ls: can't resolve symbol '__gedf2' ls: can't resolve symbol '__subdf3' bin dev proc usr boot etc linuxrc sbin # I think this problem is due to .config of uClibc. So, I try to enable libgcc option in "make menuconfig" of uClibc. General Library Settings ---> Add unresolved libgcc symbols to uClibc Y In this time, Although, my kernel stop after this message while booting. "Freeing unused kernel memory : 56k init" I found a hint in a log of make. ppc_8xx-ld -s -shared --warn-common --warn-once -z combreloc -soname=libc.so.0 -o libuClibc-0.9.19.so \ --whole-archive ./tmp/libgcc-need.a libc.a \ ..//libc/misc/internals/interp.o --no-whole-archive \ -init __uClibc_init /opt/hardhat/devkit/ppc/8xx/lib/gcc-lib/powerpc-hardhat-linux/3.2.1/libgcc.a and I tried to remove -s option and remake uClibc, then I make sure of symbol of libuClibc-0.9.19.so. $ nm libuClibc-0.9.19.so a part of result : 00000898 t __adddf3 00000af0 t __divdf3 00000d6c t __eqdf2 00000a40 t __fixdfsi 00001a08 t __floatsidf 00000f74 t __gedf2 00001050 t __ltdf2 00001114 t __muldf3 00001580 t __nedf2 0000160c t __negdf2 00000904 t __subdf3 000009cc t __truncdfsf2 All symbol type of libgcc is 't'(symbol is local). Although, my libgcc-need.a has a global symbol as below. $ nm libgcc-need.a _addsub_df.oS: 00000384 T __adddf3 ... Why does all symbol type of libgcc in libuClibc-0.9.19.so change into local? From slarty2 at ntlworld.com Tue Jul 8 11:11:29 2003 From: slarty2 at ntlworld.com (Mark Robson) Date: Sat Jul 19 08:54:52 2003 Subject: [uClibc] Web Browser Uclibc In-Reply-To: <20030708004200.74996.qmail@web11201.mail.yahoo.com> References: <20030708004200.74996.qmail@web11201.mail.yahoo.com> Message-ID: <20030708091130.RSCO4771.mta02-svc.ntlworld.com@there> > I want to have one graphical web browser uClibc > compiled for my x86 box. If any have succesfully > compiled any graphical web browser and can share the > experience, i will be happy with it. I also built the graphical console version of "links" using svgalib. The main problem is that the way it stores its fonts is hideously inefficient and hence I had to remove a lot of fonts to fit it on a floppy. It also needs libjpeg which I didn't quite have space for, but it works fine without it (just doesn't display jpegs) Mark From ibe at dcl.info.waseda.ac.jp Tue Jul 8 19:30:12 2003 From: ibe at dcl.info.waseda.ac.jp (ibe@dcl.info.waseda.ac.jp) Date: Sat Jul 19 08:54:52 2003 Subject: [uClibc]can't resolve symbol. In-Reply-To: <41672.202.232.97.131.1057652285.squirrel@mail2.dcl.info.waseda.ac.jp> References: <41672.202.232.97.131.1057652285.squirrel@mail2.dcl.info.waseda.ac.jp> Message-ID: <45070.202.232.97.131.1057656612.squirrel@mail2.dcl.info.waseda.ac.jp> Hi, By the way, what is .oS? Is it as same as .o? My libgcc.a has some .oS. $ nm libgcc.a _addsub_df.oS: 00000384 T __adddf3 U __pack_d 000003f0 T __subdf3 U __thenan_df U __unpack_d 00000004 t _fpadd_parts _ashldi3.oS: 00000000 T __ashldi3 _df_to_sf.oS: U __make_fp 00000000 T __truncdfsf2 U __unpack_d _df_to_si.oS: 00000000 T __fixdfsi U __lshrdi3 U __unpack_d _div_df.oS: 00000000 T __divdf3 U __pack_d U __thenan_df U __unpack_d 0000006c t _fpdiv_parts _eq_df.oS: 00000000 T __eqdf2 U __fpcmp_parts_d U __unpack_d _fpcmp_parts_df.oS: 00000000 T __fpcmp_parts_d _ge_df.oS: U __fpcmp_parts_d 00000000 T __gedf2 U __unpack_d _lshrdi3.oS: 00000000 T __lshrdi3 _lt_df.oS: U __fpcmp_parts_d 00000000 T __ltdf2 U __unpack_d _make_sf.oS: 00000000 T __make_fp U __pack_f _mul_df.oS: 00000000 T __muldf3 U __pack_d U __thenan_df U __unpack_d 00000070 t _fpmul_parts _ne_df.oS: U __fpcmp_parts_d 00000000 T __nedf2 U __unpack_d _negate_df.oS: 00000000 T __negdf2 U __pack_d U __unpack_d _pack_df.oS: U __ashldi3 U __lshrdi3 00000000 T __pack_d _pack_sf.oS: 00000000 T __pack_f _si_to_df.oS: 00000000 T __floatsidf U __pack_d _thenan_df.oS: 00000000 R __thenan_df _unpack_df.oS: 00000000 T __unpack_d I am Sorry to boring question. From ps.m at gmx.net Tue Jul 8 17:55:23 2003 From: ps.m at gmx.net (Peter S. Mazinger) Date: Sat Jul 19 08:54:52 2003 Subject: [uClibc] ldd and cvs20030708 Message-ID: Hello! The change for ldd in cvs solves the ldd coredump ran against dynamic libraries, it returns "not a dynamic executable". glibc's ldd returns the dynamic loader /lib/ld-linux.so.2 I have checked strings libuClibc-0.9.20.so, the loader is there as /lib/ld-uClibc.so.0. Well, I do not know, which is the correct behaviour, so take it only as a status report. Thanks, Peter -- Peter S. Mazinger ID: 0xA5F059F2 NIC: IXUYHSKQLI Key fingerprint = 92A4 31E1 56BC 3D5A 2D08 BB6E C389 975E A5F0 59F2 From dpforos at yahoo.com Tue Jul 8 11:21:18 2003 From: dpforos at yahoo.com (Daniel Pezoa) Date: Sat Jul 19 08:54:52 2003 Subject: [uClibc] Web Browser Uclibc In-Reply-To: <20030707175137.20f35ad9.uclibc@lacklustre.net> Message-ID: <20030708172118.13377.qmail@web11208.mail.yahoo.com> Thanks it compile! For the moment i need to make some corrections, because it attempt to create some .dillo directory in my read only ram filesystem. And next it abort the execution. Good luck! Daniel Pezoa --- Michael Ryan wrote: > I haven't tried to compile it, but take a look at > Dillo. It would probably work. http://www.dillo.org/ > > Best of luck. > > On Mon, 7 Jul 2003 17:42:00 -0700 (PDT) > Daniel Pezoa wrote: > > > Hello uClibc Community > > > > I want to have one graphical web browser uClibc > > compiled for my x86 box. If any have succesfully > > compiled any graphical web browser and can share > the > > experience, i will be happy with it. > > > > Good luck! > > > > Daniel Pezoa > > > > > > __________________________________ > > Do you Yahoo!? > > SBC Yahoo! DSL - Now only $29.95 per month! > > http://sbc.yahoo.com > > _______________________________________________ > > uClibc mailing list > > uClibc@uclibc.org > > http://uclibc.org/mailman/listinfo/uclibc > > > > > -- > Michael Ryan > Lacklustre Networking > > michael@lacklustre.net > http://www.lacklustre.net/ > _______________________________________________ > uClibc mailing list > uClibc@uclibc.org > http://uclibc.org/mailman/listinfo/uclibc __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com From mad at citynet.net.ar Tue Jul 8 18:02:33 2003 From: mad at citynet.net.ar (Mariano Drzazga) Date: Sat Jul 19 08:54:52 2003 Subject: [uClibc] upnp-igd compling against uclibc Message-ID: <003c01c3458b$ded09c50$0101a8c0@citynet2.com> Hi, I get the following error when I try to compile the upnpsdk-1.0.4 sources using uClibc. I'm using uClibc 0.9.20 (I chroot into the 150MB ext2 filesystem that I downloaded form www.uclibc.org Any suggestions would be appreciated. Thanks in advance Mariano Drzazga. make[2]: Entering directory `/home/upnpsdk-1.0.4/src/upnpdom' g++ -fpic -Wall -D_REENTRANT -O2 -DNO_DEBUG -DINCLUDE_CLIENT_APIS -DINCLUDE_DEVICE_APIS -c -I ../../inc/upnpdom -I ../inc domCif.cpp In file included from ../../inc/upnpdom/iostream.h:31, from domCif.cpp:40: ../../inc/upnpdom/backward_warning.h:32:2: warning: #warning This file includes at least one deprecated or antiquated header. Please consider using one of the 32 headers found in section 17.4.1.2 of the C++ standard. Examples include substituting the header for the header for C++ includes, or instead of the deprecated header . To disable this warning use -Wno-deprecated. In file included from domCif.cpp:40: ../../inc/upnpdom/iostream.h:32:20: iostream: No such file or directory In file included from domCif.cpp:40: ../../inc/upnpdom/iostream.h:34: error: `iostream' not declared ../../inc/upnpdom/iostream.h:35: error: `ostream' not declared ../../inc/upnpdom/iostream.h:36: error: `istream' not declared ../../inc/upnpdom/iostream.h:37: error: `ios' not declared ../../inc/upnpdom/iostream.h:38: error: `streambuf' not declared ../../inc/upnpdom/iostream.h:40: error: `cout' not declared From tom at ceisystems.com Tue Jul 8 17:45:16 2003 From: tom at ceisystems.com (tom@ceisystems.com) Date: Sat Jul 19 08:54:52 2003 Subject: [uClibc] upnp-igd compling against uclibc Message-ID: <6D31D5429FA6884CBE9ECAB6C9B5E6A907E08F@intel-srvr.patcameron.ne.mediaone.net> Mariano, I believe it has been posted here that streams are not supported under uClibc. I do not know if they are in the works for a later release, or if there is even a desire to get them to work. My suggestion would be to attempt to statically compile the uPNP libraries against the standard Glibc, and see where that gets you. Good luck, Thomas Cameron CEI Systems, Inc. -----Original Message----- From: Mariano Drzazga [mailto:mad@citynet.net.ar] Sent: Tuesday, July 08, 2003 4:03 PM To: uclibc@uclibc.org Subject: [uClibc] upnp-igd compling against uclibc Hi, I get the following error when I try to compile the upnpsdk-1.0.4 sources using uClibc. I'm using uClibc 0.9.20 (I chroot into the 150MB ext2 filesystem that I downloaded form www.uclibc.org Any suggestions would be appreciated. Thanks in advance Mariano Drzazga. make[2]: Entering directory `/home/upnpsdk-1.0.4/src/upnpdom' g++ -fpic -Wall -D_REENTRANT -O2 -DNO_DEBUG -DINCLUDE_CLIENT_APIS -DINCLUDE_DEVICE_APIS -c -I ../../inc/upnpdom -I ../inc domCif.cpp In file included from ../../inc/upnpdom/iostream.h:31, from domCif.cpp:40: ../../inc/upnpdom/backward_warning.h:32:2: warning: #warning This file includes at least one deprecated or antiquated header. Please consider using one of the 32 headers found in section 17.4.1.2 of the C++ standard. Examples include substituting the header for the header for C++ includes, or instead of the deprecated header . To disable this warning use -Wno-deprecated. In file included from domCif.cpp:40: ../../inc/upnpdom/iostream.h:32:20: iostream: No such file or directory In file included from domCif.cpp:40: ../../inc/upnpdom/iostream.h:34: error: `iostream' not declared ../../inc/upnpdom/iostream.h:35: error: `ostream' not declared ../../inc/upnpdom/iostream.h:36: error: `istream' not declared ../../inc/upnpdom/iostream.h:37: error: `ios' not declared ../../inc/upnpdom/iostream.h:38: error: `streambuf' not declared ../../inc/upnpdom/iostream.h:40: error: `cout' not declared _______________________________________________ uClibc mailing list uClibc@uclibc.org http://uclibc.org/mailman/listinfo/uclibc From mjn3 at codepoet.org Tue Jul 8 16:00:26 2003 From: mjn3 at codepoet.org (Manuel Novoa III) Date: Sat Jul 19 08:54:52 2003 Subject: [uClibc] upnp-igd compling against uclibc In-Reply-To: <6D31D5429FA6884CBE9ECAB6C9B5E6A907E08F@intel-srvr.patcameron.ne.mediaone.net> References: <6D31D5429FA6884CBE9ECAB6C9B5E6A907E08F@intel-srvr.patcameron.ne.mediaone.net> Message-ID: <20030708210026.GA23105@codepoet.org> Tom, On Tue, Jul 08, 2003 at 04:45:16PM -0400, tom@ceisystems.com wrote: > Mariano, > I believe it has been posted here that streams are not supported > under uClibc. I do not know if they are in the works for a later > release, or if there is even a desire to get them to work. My > suggestion would be to attempt to statically compile the uPNP libraries > against the standard Glibc, and see where that gets you. You're confusing the STREAMS functions prototyped in strotps.h with standard C++ streams. uClibc doesn't support stropts.h and the associated STREAMS functions. However, a uClibc version of libstd++ (say from buildroot) should support C++ streams. Manuel From f.callaghan at ieee.org Tue Jul 8 18:10:11 2003 From: f.callaghan at ieee.org (Frank R Callaghan) Date: Sat Jul 19 08:54:52 2003 Subject: [uClibc] system call segfault! Message-ID: <200307081710.11423.f.callaghan@ieee.org> Hi All I'm using uClibc.0.9.19, 2.4.19 + jffs2(from cvs) + busybox-0.60.5 + rtai I have been trying to track down a problem with my embedded prog segfaulting and found that with only system("ps -ax"); SegFaults ! (gdb) run Starting program: /myapp/test1 Running ps (no debugging symbols found)...(no debugging symbols found)... Program received signal SIGSEGV, Segmentation fault. 0x40013cd0 in _dl_envp () from /usr/i386-linux-uclibc/lib/libc.so.0 PID TTY Uid Size State Command 1 root 468 S init 2 root 0 S [keventd] 3 root 0 S [ksoftirqd_CPU0] 4 root 0 S [kswapd] 5 root 0 S [bdflush] 6 root 0 S [kupdated] 7 root 0 S [mtdblockd] 11 root 0 S [kjournald] 50 root 0 S [rpciod] 54 root 0 S [kjournald] 86 ttyS1 root 496 S -sh 161 ttyS1 root 3756 S gdb test1 162 ttyS1 root 348 T /myapp/test1 163 ttyS1 root 492 S sh -c ps -ax 164 ttyS1 root 460 R ps -ax (gdb) bt #0 0x40013cd0 in _dl_envp () from /usr/i386-linux-uclibc/lib/libc.so.0 #1 0x4003da79 in system () from /usr/i386-linux-uclibc/lib/libc.so.0 #2 0x0804844b in main () #3 0x40017624 in __uClibc_start_main () from /usr/i386-linux-uclibc/lib/libc.so.0 #4 0x08048424 in _start () (gdb) Any help greatly appreciated, TIA, Frank. From andersen at codepoet.org Tue Jul 8 16:32:19 2003 From: andersen at codepoet.org (Erik Andersen) Date: Sat Jul 19 08:54:52 2003 Subject: [uClibc]can't resolve symbol. In-Reply-To: <45070.202.232.97.131.1057656612.squirrel@mail2.dcl.info.waseda.ac.jp> References: <41672.202.232.97.131.1057652285.squirrel@mail2.dcl.info.waseda.ac.jp> <45070.202.232.97.131.1057656612.squirrel@mail2.dcl.info.waseda.ac.jp> Message-ID: <20030708213219.GA23791@codepoet.org> On Tue Jul 08, 2003 at 06:30:12PM +0900, ibe@dcl.info.waseda.ac.jp wrote: > Hi, > > By the way, what is .oS? > Is it as same as .o? > My libgcc.a has some .oS. ".oS" is the convention used by some GNU packages such as glibc for object files that were compiled as PIC code. -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- From ibe at dcl.info.waseda.ac.jp Wed Jul 9 08:49:27 2003 From: ibe at dcl.info.waseda.ac.jp (ibe@dcl.info.waseda.ac.jp) Date: Sat Jul 19 08:54:52 2003 Subject: [uClibc]can't resolve symbol. Message-ID: <1144.133.9.91.177.1057704567.squirrel@mail2.dcl.info.waseda.ac.jp> Thanks, Erik. > > Hi, > > > > By the way, what is .oS? > > Is it as same as .o? > > My libgcc.a has some .oS. > > ".oS" is the convention used by some GNU packages such as > glibc for object files that were compiled as PIC code. > > -Erik By the way, Do you know why my symbol of libgcc can not be linked successfully? Is it concerned with .oS object? When I link symbol of libgcc to libuClibc-0.9.19.so, some symbol change its type. For example, In a libgcc.a -> 00000384 T __adddf3 In a libuClibc-0.9.19.so -> 00000898 t __adddf3 So It cause this problem when I use ls or something, # ls ls: can't resolve symbol '__adddf3' Link script is below, ppc_8xx-ld -s -shared --warn-common --warn-once -z combreloc -soname=libc.so.0 -o libuClibc-0.9.19.so \ --whole-archive ./tmp/libgcc-need.a libc.a \ ..//libc/misc/internals/interp.o --no-whole-archive \ -init __uClibc_init /opt/hardhat/devkit/ppc/8xx/lib/gcc-lib/powerpc-hardhat-linux/3.2.1/ libgcc.a //////////////////////////////////////////////// WASEDA UNIVERSITY Department of Information and Computer Science Ubiquitous & Distributed computing Lab. Hiroaki Ibe E-mail:ibe@dcl.info.waseda.ac.jp /////////////////////////////////////////////// From tom at ceisystems.com Tue Jul 8 20:21:58 2003 From: tom at ceisystems.com (tom@ceisystems.com) Date: Sat Jul 19 08:54:52 2003 Subject: [uClibc] upnp-igd compling against uclibc Message-ID: <6D31D5429FA6884CBE9ECAB6C9B5E6A907E090@intel-srvr.patcameron.ne.mediaone.net> Whoops, you're right. My mistake. Perhaps _I_ should re-read the archives. -----Original Message----- From: Manuel Novoa III [mailto:mjn3@codepoet.org] Sent: Tuesday, July 08, 2003 5:00 PM To: Thomas Cameron Cc: mad@citynet.net.ar; uclibc@uclibc.org Subject: Re: [uClibc] upnp-igd compling against uclibc Tom, On Tue, Jul 08, 2003 at 04:45:16PM -0400, tom@ceisystems.com wrote: > Mariano, > I believe it has been posted here that streams are not supported > under uClibc. I do not know if they are in the works for a later > release, or if there is even a desire to get them to work. My > suggestion would be to attempt to statically compile the uPNP > libraries against the standard Glibc, and see where that gets you. You're confusing the STREAMS functions prototyped in strotps.h with standard C++ streams. uClibc doesn't support stropts.h and the associated STREAMS functions. However, a uClibc version of libstd++ (say from buildroot) should support C++ streams. Manuel From seh at zee2.com Wed Jul 9 14:04:53 2003 From: seh at zee2.com (Stuart Hughes) Date: Sat Jul 19 08:54:52 2003 Subject: [uClibc]can't resolve symbol. References: <1144.133.9.91.177.1057704567.squirrel@mail2.dcl.info.waseda.ac.jp> Message-ID: <3F0C04E5.1FC4EF24@zee2.com> ibe@dcl.info.waseda.ac.jp wrote: > > Thanks, Erik. > > > > Hi, > > > > > > By the way, what is .oS? > > > Is it as same as .o? > > > My libgcc.a has some .oS. > > > > ".oS" is the convention used by some GNU packages such as > > glibc for object files that were compiled as PIC code. > > > > -Erik > > By the way, Do you know why my symbol of libgcc can not be linked > successfully? > Is it concerned with .oS object? > > When I link symbol of libgcc to libuClibc-0.9.19.so, > some symbol change its type. > For example, > > In a libgcc.a -> > 00000384 T __adddf3 > > In a libuClibc-0.9.19.so -> > 00000898 t __adddf3 > > So It cause this problem when I use ls or something, > > # ls > ls: can't resolve symbol '__adddf3' > > Link script is below, > > ppc_8xx-ld -s -shared --warn-common --warn-once -z combreloc > -soname=libc.so.0 -o libuClibc-0.9.19.so \ > --whole-archive ./tmp/libgcc-need.a libc.a \ > ..//libc/misc/internals/interp.o --no-whole-archive \ > -init __uClibc_init > /opt/hardhat/devkit/ppc/8xx/lib/gcc-lib/powerpc-hardhat-linux/3.2.1/ > libgcc.a > I see the same problem on powerpc 8xx too. The work-around was to set: # UCLIBC_HAS_FLOATS is not set in the uclibc configuration. This is not a proper solution though as I can't work out why/how when busybox links it resolves __adddf3 and friends, but on the target when it runs, these symbols get reported as unresolved. Note I had wondered whether the linker should be using the shared libgcc_s library, but looking at the specs file for gcc, the default is to use the static libgcc and libgcc_eh libraries. Regards, Stuart From joerg.rensing at siemens.com Tue Jul 8 13:11:32 2003 From: joerg.rensing at siemens.com (Rensing Joerg ICM Bocholt) Date: Sat Jul 19 08:54:52 2003 Subject: [uClibc]uclibc buildroot woes Message-ID: <07A65A7D0D6CD311B0F900A0C99AFFF50B4FD101@bchk006a.bch.siemens.de> I really don't know if I'm to late for this patch, but I added the following lines to gcc_target.mk and the build of binutils and gcc works fine. <> ...................................................... Mit freundlichem Gruss / kind regards Joerg Rensing Siemens AG > Information and Communication Products > Communication Devices ICM CP RD SD2 > Frankenstr. 2 (Geb?ude 2401/4te Etage) > 46395 Bocholt > Phone: +49-2871-91-3341 > Fax: +49-2871-91-63341 > Mail: Mailto:joerg.rensing@siemens.com > -------------- next part -------------- A non-text attachment was scrubbed... Name: gcc_target.mk.diff Type: application/octet-stream Size: 852 bytes Desc: not available Url : http://uclibc.org/lists/uclibc/attachments/20030708/c864d492/gcc_target.mk.obj From thomas.betker at siemens.com Wed Jul 9 16:41:10 2003 From: thomas.betker at siemens.com (Betker Thomas ICM CP RD SD 1) Date: Sat Jul 19 08:54:52 2003 Subject: [uClibc] Problems with pthreads / MIPS Message-ID: Hi all: We are experiencing a lot of problems with pthreads on a MIPS/MMU platform. Most tests were originally done with uclibc-0.9.12 (as provided by a third party), but were rechecked with a current CVS snapshot. We are using a 2.4.17 Linux kernel here. A. pthread_create() hangs (sometimes, not always - say 50%), i.e., the call won't return. [This one was not rechecked with uclibc-0.9.20 yet.] B. exit() hangs (always), if you have created any threads. The process doesn't terminate, not even the thread that called exit(). C. sigwait() doesn't work at all. If there is no signal, the call returns anyway, indicating a signal 0 (which doesn't exist). If there is a signal, it may be lost (not seen by any thread, which happens most of the time), or it may be received by a thread not waiting for it. D. The 'kill ' command usually kills the thread with the given , but not the whole process; i.e., the other threads may live on. Does anybody else have the same problems, or is it just me? And more important, is there anything I could do about it? Any ideas? I tried to run my test programs on a i386 platform (kernel 2.4.19), and everything worked as it should. The only exception was D., which occurs on i386 as well, but it's rather A. to C. I am concerned about. Best regards, Thomas Betker From joel at wmi.com Wed Jul 9 14:32:57 2003 From: joel at wmi.com (Joel Coltoff) Date: Sat Jul 19 08:54:52 2003 Subject: [uClibc] Question on floating point exceptions Message-ID: Hi, We are using uclibc-0.9.19 on a MIPS 32355. This is a fixed point processor so we end up using the Algorithmics Floating Emulator. I'm trying to catch (or detect) floating point exceptions. I have no problem generating them but my programs always exit. The first thing I noticed is that there is no fenv.h file in /usr include. The file .../bits/fenv.h is there but that is not the one you include. What do I need to do to either catch a SIGFPE or use functions like feclearexcept() and fetestexcept()? This may be obvious but these past few weeks I've needed lots of smacks in the head to see even the painfully obvious. Thanks. -- Joel Coltoff We don't see things as they are, we see them as we are. -- Anais Nin From f.callaghan at ieee.org Wed Jul 9 14:39:48 2003 From: f.callaghan at ieee.org (Frank R Callaghan) Date: Sat Jul 19 08:54:52 2003 Subject: [uClibc] system call segfault! In-Reply-To: <200307081710.11423.f.callaghan@ieee.org> References: <200307081710.11423.f.callaghan@ieee.org> Message-ID: <200307091339.48824.f.callaghan@ieee.org> Fixed, just downloaded 0.9.20 built, installed and the system() problem dissapeared ! Thanks Guys. On Tuesday 08 July 2003 05:10 pm, Frank R Callaghan wrote: > Hi All > > I'm using uClibc.0.9.19, 2.4.19 + jffs2(from cvs) + busybox-0.60.5 + rtai > > I have been trying to track down a problem with my embedded prog > segfaulting and found that with only system("ps -ax"); SegFaults ! > > (gdb) run > Starting program: /myapp/test1 > Running ps > (no debugging symbols found)...(no debugging symbols found)... > Program received signal SIGSEGV, Segmentation fault. > 0x40013cd0 in _dl_envp () from /usr/i386-linux-uclibc/lib/libc.so.0 > PID TTY Uid Size State Command > 1 root 468 S init > 2 root 0 S [keventd] > 3 root 0 S [ksoftirqd_CPU0] > 4 root 0 S [kswapd] > 5 root 0 S [bdflush] > 6 root 0 S [kupdated] > 7 root 0 S [mtdblockd] > 11 root 0 S [kjournald] > 50 root 0 S [rpciod] > 54 root 0 S [kjournald] > 86 ttyS1 root 496 S -sh > 161 ttyS1 root 3756 S gdb test1 > 162 ttyS1 root 348 T /myapp/test1 > 163 ttyS1 root 492 S sh -c ps -ax > 164 ttyS1 root 460 R ps -ax > (gdb) bt > #0 0x40013cd0 in _dl_envp () from /usr/i386-linux-uclibc/lib/libc.so.0 > #1 0x4003da79 in system () from /usr/i386-linux-uclibc/lib/libc.so.0 > #2 0x0804844b in main () > #3 0x40017624 in __uClibc_start_main () > from /usr/i386-linux-uclibc/lib/libc.so.0 > #4 0x08048424 in _start () > (gdb) > > Any help greatly appreciated, > > TIA, > Frank. > > > > > > > > > _______________________________________________ > uClibc mailing list > uClibc@uclibc.org > http://uclibc.org/mailman/listinfo/uclibc From tom at ceisystems.com Wed Jul 9 17:10:13 2003 From: tom at ceisystems.com (tom@ceisystems.com) Date: Sat Jul 19 08:54:52 2003 Subject: [uClibc]uclibc buildroot woes Message-ID: <6D31D5429FA6884CBE9ECAB6C9B5E6A9445D@intel-srvr.patcameron.ne.mediaone.net> Gute abend, I appologise for my German, I have not spoken it in many years. Anyway, I think the best solution to this problem would be to use a variable, much like we do for "--target", and "--host" variables. This would allow people using other arch.'s to build the utils without having to modify the .mk files. As an example, this patch would make it impossible to compile gcc_target on, say, an ARM system, or even a PPC. Perhaps, we should add a variable into the main Makefile that contains our current architecture, much like in the Linux kernel compilation. Just my .02DM, Thomas Cameron CEI Systems, Inc. -----Original Message----- From: Rensing Joerg ICM Bocholt [mailto:joerg.rensing@siemens.com] Sent: Tuesday, July 08, 2003 6:12 AM To: uclibc@uclibc.org Subject: [uClibc]uclibc buildroot woes I really don't know if I'm to late for this patch, but I added the following lines to gcc_target.mk and the build of binutils and gcc works fine. <> ...................................................... Mit freundlichem Gruss / kind regards Joerg Rensing Siemens AG > Information and Communication Products > Communication Devices ICM CP RD SD2 > Frankenstr. 2 (Geb?ude 2401/4te Etage) > 46395 Bocholt > Phone: +49-2871-91-3341 > Fax: +49-2871-91-63341 > Mail: Mailto:joerg.rensing@siemens.com > From mrakes at vivato.net Wed Jul 9 19:20:11 2003 From: mrakes at vivato.net (Mark Rakes) Date: Sat Jul 19 08:54:52 2003 Subject: [uClibc] buildroot + uClibc + xscale??? Message-ID: Greetings. I'm trying to build a buildroot-uClibc toolchain for an xscale platform. I know this came up at least once in the past (see http://www.uclibc.org/lists/uclibc/2003-June/008696.html), but with no resolution that I can discover. From top-of-CVS buildroot, change ARCH to arm, and with the uClibc.config below, I get the same results Patrick did: make -C ldso make[2]: Entering directory `/home/mrakes/cvs/buildroot/build_arm/uClibc/ldso' make -C ldso; make[3]: Entering directory `/home/mrakes/cvs/buildroot/build_arm/uClibc/ldso/ldso' echo "const char *_dl_progname=\""ld-uClibc.so.0"\";" > ldso.h echo "#include \"arm/elfinterp.c\"" >> ldso.h /home/mrakes/cvs/buildroot/build_arm/staging_dir/bin/arm-uclibc-gcc -Wall -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fstrict-aliasing -Os -march=xscale -fno-builtin -nostdinc -D_LIBC -I../../include -I. -I/home/mrakes/cvs/buildroot/build_arm/staging_dir/lib/gcc-lib/arm- linux/3.3/include -DNDEBUG -fPIC -I. -I./arm -I../libdl -c arm/resolve.S -o arm/resolve.o cc1: error: bad value (xscale) for -march= switch make[3]: *** [arm/resolve.o] Error 1 I know I get "farther" if I change the cpu line in the uclibc Makefile to "-mcpu=xscale -mtune=xscale", but that breaks later on with some "unsupported instruction" errors. has anyone got this to build this before? Any hints? Is it so obvious I can't see it? I've also included the gcc "dumpspecs" from the cross compiler in case that will help somebody diagnose as well... thanks, -mark rakes ======================================================================== === uClibc.config # # Automatically generated make config: don't edit # # # Target Architecture Features and Options # HAVE_ELF=y # ADD_LIBGCC_FUNCTIONS is not set # CONFIG_GENERIC_ARM is not set # CONFIG_ARM7TDMI is not set # CONFIG_STRONGARM is not set CONFIG_XSCALE=y UCLIBC_HAS_MMU=y UCLIBC_HAS_FLOATS=y HAS_FPU=y DO_C99_MATH=y WARNINGS="-Wall" KERNEL_SOURCE="/home/mrakes/cvs/buildroot/build_arm/linux" C_SYMBOL_PREFIX="" HAVE_DOT_CONFIG=y # # General Library Settings # DOPIC=y HAVE_SHARED=y BUILD_UCLIBC_LDSO=y LDSO_LDD_SUPPORT=y UCLIBC_CTOR_DTOR=y # UCLIBC_PROFILING is not set UCLIBC_HAS_THREADS=y PTHREADS_DEBUG_SUPPORT=y UCLIBC_HAS_LFS=y # MALLOC is not set MALLOC_930716=y UCLIBC_DYNAMIC_ATEXIT=y HAS_SHADOW=y UCLIBC_HAS_REGEX=y UNIX98PTY_ONLY=y ASSUME_DEVPTS=y # # Networking Support # # UCLIBC_HAS_IPV6 is not set UCLIBC_HAS_RPC=y # UCLIBC_HAS_FULL_RPC is not set # # String and Stdio Support # UCLIBC_HAS_WCHAR=y # UCLIBC_HAS_LOCALE is not set # USE_OLD_VFPRINTF is not set # # Library Installation Options # SHARED_LIB_LOADER_PATH="/lib" DEVEL_PREFIX="/home/mrakes/cvs/buildroot/build_arm/staging_dir" SYSTEM_DEVEL_PREFIX="/home/mrakes/cvs/buildroot/build_arm/staging_dir" DEVEL_TOOL_PREFIX="/home/mrakes/cvs/buildroot/build_arm/staging_dir/usr" # # uClibc hacking options # # DODEBUG is not set # DOASSERTS is not set # SUPPORT_LD_DEBUG is not set # SUPPORT_LD_DEBUG_EARLY is not set ======================================================================== ============== jethro/home/mrakes/cvs/buildroot> ./build_arm/staging_dir/bin/arm-uclibc-gcc -dumpspecs *asm: %{mbig-endian:-EB} %{mlittle-endian:-EL} %{mcpu=*:-mcpu=%*} %{march=*:-march=%*} %{mapcs-*:-mapcs-%*} %(subtarget_asm_float_spec) %{mthumb-interwork:-mthumb-interwork} %(subtarget_extra_asm_spec) *asm_debug: %{gstabs*:--gstabs}%{!gstabs*:%{g*:--gdwarf2}} *asm_final: *asm_options: %a %Y %{c:%W{o*}%{!o*:-o %w%b%O}}%{!c:-o %d%w%u%O} *invoke_as: %{!S:-o %{|!pipe:%g.s} | as %(asm_options) %{!pipe:%g.s} %A } *cpp: %(cpp_cpu_arch) %(subtarget_cpp_spec) %{mapcs-32:%{mapcs-26: %e-mapcs-26 and -mapcs-32 may not be used together}} %{msoft-float:%{mhard-float: %e-msoft-float and -mhard_float may not be used together}} %{mbig-endian:%{mlittle-endian: %e-mbig-endian and -mlittle-endian may not be used together}} *cpp_options: %(cpp_unique_options) %1 %{m*} %{std*} %{ansi} %{W*&pedantic*} %{w} %{f*} %{O*} %{undef} *cpp_debug_options: %{d*} *cpp_unique_options: %{C:%{!E:%eGNU C does not support -C without using -E}} %{CC:%{!E:%eGNU C does not support -CC without using -E}} %{!Q:-quiet} %{nostdinc*} %{C} %{CC} %{v} %{I*} %{P} %I %{MD:-MD %{!o:%b.d}%{o*:%.d%*}} %{MMD:-MMD %{!o:%b.d}%{o*:%.d%*}} %{M} %{MM} %{MF*} %{MG} %{MP} %{MQ*} %{MT*} %{!E:%{!M:%{!MM:%{MD|MMD:%{o*:-MQ %*}}}}} %{!no-gcc:-D__GNUC__=%v1 -D__GNUC_MINOR__=%v2 -D__GNUC_PATCHLEVEL__=%v3} %{!undef:%{!ansi:%{!std=*:%p}%{std=gnu*:%p}} %P} %{trigraphs} %{remap} %{g3:-dD} %{H} %C %{D*&U*&A*} %{i*} %Z %i %{E|M|MM:%W{o*}} *trad_capable_cpp: cc1 -E %{traditional|ftraditional|traditional-cpp:-traditional-cpp} *cc1: %{profile:-p} *cc1_options: %{pg:%{fomit-frame-pointer:%e-pg and -fomit-frame-pointer are incompatible}} %1 %{!Q:-quiet} -dumpbase %B %{d*} %{m*} %{a*} -auxbase%{c|S:%{o*:-strip %*}%{!o*: %b}}%{!c:%{!S: %b}} %{g*} %{O*} %{W*&pedantic*} %{w} %{std*} %{ansi} %{v:-version} %{pg:-p} %{p} %{f*} %{undef} %{Qn:-fno-ident} %{--help:--help} %{--target-help:--target-help} %{!fsyntax-only:%{S:%W{o*}%{!o*:-o %b.s}}} %{fsyntax-only:-o %j} %{-param*} *cc1plus: *link_gcc_c_sequence: %G %L %G *endfile: %{!shared:crtend.o%s} %{shared:crtendS.o%s} crtn.o%s *link: %{h*} %{version:-v} %{b} %{Wl,*:%*} %{static:-Bstatic} %{shared:-shared} %{symbolic:-Bsymbolic} %{rdynamic:-export-dynamic} %{!dynamic-linker: -dynamic-linker /lib/ld-uClibc.so.0} -X %{mbig-endian:-EB} -m armelf_linux -p *lib: %{pthread:-lpthread} %{shared:-lc} %{!shared:%{profile:-lc_p}%{!profile:-lc}} *libgcc: %{msoft-float:-lfloat} -lgcc *startfile: %{!shared: %{pg:gcrt1.o%s} %{!pg:%{p:gcrt1.o%s} %{!p:%{profile:gcrt1.o%s} %{!profile:crt1.o%s}}}} crti.o%s %{!shared:crtbegin.o%s} %{shared:crtbeginS.o%s} *switches_need_spaces: *predefines: *cross_compile: 1 *version: 3.3 *multilib: . ; *multilib_defaults: marm mlittle-endian mhard-float mapcs-32 mno-thumb-interwork *multilib_extra: *multilib_matches: *multilib_exclusions: *multilib_options: *linker: collect2 *link_libgcc: %D *md_exec_prefix: *md_startfile_prefix: *md_startfile_prefix_1: *startfile_prefix_spec: *cpp_cpu_arch: %{march=arm2:-D__ARM_ARCH_2__} %{march=arm250:-D__ARM_ARCH_2__} %{march=arm3:-D__ARM_ARCH_2__} %{march=arm6:-D__ARM_ARCH_3__} %{march=arm600:-D__ARM_ARCH_3__} %{march=arm610:-D__ARM_ARCH_3__} %{march=arm7:-D__ARM_ARCH_3__} %{march=arm700:-D__ARM_ARCH_3__} %{march=arm710:-D__ARM_ARCH_3__} %{march=arm720:-D__ARM_ARCH_3__} %{march=arm7100:-D__ARM_ARCH_3__} %{march=arm7500:-D__ARM_ARCH_3__} %{march=arm7500fe:-D__ARM_ARCH_3__} %{march=arm7m:-D__ARM_ARCH_3M__} %{march=arm7dm:-D__ARM_ARCH_3M__} %{march=arm7dmi:-D__ARM_ARCH_3M__} %{march=arm7tdmi:-D__ARM_ARCH_4T__} %{march=arm8:-D__ARM_ARCH_4__} %{march=arm810:-D__ARM_ARCH_4__} %{march=arm9:-D__ARM_ARCH_4T__} %{march=arm920:-D__ARM_ARCH_4__} %{march=arm920t:-D__ARM_ARCH_4T__} %{march=arm9tdmi:-D__ARM_ARCH_4T__} %{march=strongarm:-D__ARM_ARCH_4__} %{march=strongarm110:-D__ARM_ARCH_4__} %{march=strongarm1100:-D__ARM_ARCH_4__} %{march=xscale:-D__ARM_ARCH_5TE__} %{march=xscale:-D__XSCALE__} %{march=armv2:-D__ARM_ARCH_2__} %{march=armv2a:-D__ARM_ARCH_2__} %{march=armv3:-D__ARM_ARCH_3__} %{march=armv3m:-D__ARM_ARCH_3M__} %{march=armv4:-D__ARM_ARCH_4__} %{march=armv4t:-D__ARM_ARCH_4T__} %{march=armv5:-D__ARM_ARCH_5__} %{march=armv5t:-D__ARM_ARCH_5T__} %{march=armv5e:-D__ARM_ARCH_5E__} %{march=armv5te:-D__ARM_ARCH_5TE__} %{!march=*: %{mcpu=arm2:-D__ARM_ARCH_2__} %{mcpu=arm250:-D__ARM_ARCH_2__} %{mcpu=arm3:-D__ARM_ARCH_2__} %{mcpu=arm6:-D__ARM_ARCH_3__} %{mcpu=arm600:-D__ARM_ARCH_3__} %{mcpu=arm610:-D__ARM_ARCH_3__} %{mcpu=arm7:-D__ARM_ARCH_3__} %{mcpu=arm700:-D__ARM_ARCH_3__} %{mcpu=arm710:-D__ARM_ARCH_3__} %{mcpu=arm720:-D__ARM_ARCH_3__} %{mcpu=arm7100:-D__ARM_ARCH_3__} %{mcpu=arm7500:-D__ARM_ARCH_3__} %{mcpu=arm7500fe:-D__ARM_ARCH_3__} %{mcpu=arm7m:-D__ARM_ARCH_3M__} %{mcpu=arm7dm:-D__ARM_ARCH_3M__} %{mcpu=arm7dmi:-D__ARM_ARCH_3M__} %{mcpu=arm7tdmi:-D__ARM_ARCH_4T__} %{mcpu=arm8:-D__ARM_ARCH_4__} %{mcpu=arm810:-D__ARM_ARCH_4__} %{mcpu=arm9:-D__ARM_ARCH_4T__} %{mcpu=arm920:-D__ARM_ARCH_4__} %{mcpu=arm920t:-D__ARM_ARCH_4T__} %{mcpu=arm9tdmi:-D__ARM_ARCH_4T__} %{mcpu=strongarm:-D__ARM_ARCH_4__} %{mcpu=strongarm110:-D__ARM_ARCH_4__} %{mcpu=strongarm1100:-D__ARM_ARCH_4__} %{mcpu=xscale:-D__ARM_ARCH_5TE__} %{mcpu=xscale:-D__XSCALE__} %{!mcpu*:%(cpp_cpu_arch_default)}} *cpp_cpu_arch_default: -D__ARM_ARCH_4T__ *subtarget_cpp_spec: %{posix:-D_POSIX_SOURCE} %{fPIC:-D__PIC__ -D__pic__} %{fpic:-D__PIC__ -D__pic__} *subtarget_extra_asm_spec: *subtarget_asm_float_spec: %{mapcs-float:-mfloat} %{msoft-float:-mno-fpu} *link_command: %{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S: %(linker) %l %X %{o*} %{A} %{d} %{e*} %{m} %{N} %{n} %{r} %{s} %{t} %{u*} %{x} %{z} %{Z} %{!A:%{!nostdlib:%{!nostartfiles:%S}}} %{static:} %{L*} %(link_libgcc) %o %{!nostdlib:%{!nodefaultlibs:%(link_gcc_c_sequence)}} %{!A:%{!nostdlib:%{!nostartfiles:%E}}} %{T*} }}}}}} From robin.gilks at tait.co.nz Thu Jul 10 17:50:00 2003 From: robin.gilks at tait.co.nz (Robin Gilks) Date: Sat Jul 19 08:54:52 2003 Subject: [uClibc] Interesting buildroot problem Message-ID: <3F0CF078.7030702@tait.co.nz> Greetings An interesting problem has arisen with the building of a cross target gdb (i.e. hosted on i386 to debug a powerpc) in that whenever I try to make gdb with the -C switch to make, the readline library doesn't work. I get an executable that runs but doesn't accept user input!! Building gdb by hand and copying the libreadline.a file across and it links OK so its definitely within the readline sub-tree!! I've appended the make file gdbhost.mk that fails and also another makefile that creates a simple initrd root file system - a bit easier than cramfs etc when first starting out!! ========================= gdbhost.mk ====================== ############################################################# # # gdbhost - gdb running on the host but aimed at target!! # ############################################################# # Use other GDB values from gdb.mk GDBHOST_DIR:=$(TOOL_BUILD_DIR)/gdb-5.3 # make a new directory in our toolchain tree $(GDBHOST_DIR): mkdir -p $(GDBHOST_DIR) $(DL_DIR)/$(GDB_SOURCE): $(WGET) -P $(DL_DIR) $(GDB_SITE)/$(GDB_SOURCE) $(GDBHOST_DIR)/.unpacked: $(DL_DIR)/$(GDB_SOURCE) $(GDB_PATCH) gunzip -c $(DL_DIR)/$(GDB_SOURCE) | tar -C $(TOOL_BUILD_DIR) -xvf - cat $(GDB_PATCH) | patch -p1 -d $(GDBHOST_DIR) touch $(GDBHOST_DIR)/.unpacked $(GDBHOST_DIR)/.configured: $(GDBHOST_DIR)/.unpacked (cd $(GDBHOST_DIR); rm -rf config.cache; \ CC=$(HOSTCC) \ ./configure \ --target=$(GNU_TARGET_NAME) \ --host=$(GNU_HOST_NAME) \ --prefix=$(STAGING_DIR) \ --enable-readline \ ); touch $(GDBHOST_DIR)/.configured # note the hack with the cd to gdb directory due to a bug in readline Makefile $(GDBHOST_DIR)/gdb/gdb: $(GDBHOST_DIR)/.configured cd $(GDBHOST_DIR); $(MAKE) CC=$(HOSTCC) $(STAGING_DIR)/$(GNU_TARGET_NAME)/bin/gdb: $(GDBHOST_DIR)/gdb/gdb cd $(GDBHOST_DIR); $(MAKE) CC=$(HOSTCC) install rm -rf $(GDBHOST_DIR)/info $(GDBHOST_DIR)/man $(GDBHOST_DIR)/share/doc \ $(GDBHOST_DIR)/share/locale mkdir -p $(STAGING_DIR)/usr/bin; set -e; \ if [ -x $(STAGING_DIR)/bin/$(ARCH)-linux-gdb ] ; then \ (cd $(STAGING_DIR)/$(GNU_TARGET_NAME)/bin; \ ln -fs ../../bin/$(ARCH)-linux-gdb gdb; \ ); \ (cd $(STAGING_DIR)/usr/bin; \ ln -fs ../../bin/$(ARCH)-linux-gdb gdb; \ ); \ fi; \ gdbhost: $(STAGING_DIR)/$(GNU_TARGET_NAME)/bin/gdb gdbhost-clean: $(MAKE) -C $(GDBHOST_DIR) clean gdbhost-dirclean: rm -rf $(GDBHOST_DIR) ========================= gdbhost.mk ====================== ========================= initrd.mk ======================= ############################################################# # # make an initrd image - assumes all the tools are available # ############################################################# # this comes from the u-boot project!! MKIMAGE=/usr/local/bin/mkimage MNTPOINT:=$(STAGING_DIR)/mnt $(MNTPOINT): mkdir -p $(MNTPOINT) ############################################################# # # Build the ramfs root filesystem image # ############################################################# initrd.gz: $(TARGET_DIR) $(MNTPOINT) dd if=/dev/zero of=initrd bs=1024 count=2048 /sbin/mkfs.ext2 -F -m0 -b 1024 initrd sudo mount -o loop initrd $(MNTPOINT) echo cp -R $(TARGET_DIR)/root $(MNTPOINT) cp -R $(TARGET_DIR)/* $(MNTPOINT) sudo umount $(MNTPOINT) gzip -9 -c initrd > initrd.gz rm -f initrd initrd: initrd.u-boot initrd.gz $(MKIMAGE) -n 'Simple Ramdisk Image' \ -A ppc -O linux -T ramdisk -C gzip \ -d initrd.gz initrd.u-boot rm -f initrd.gz ========================= initrd.mk ======================= -- Robin Gilks Senior Design Engineer Phone: (+64)(3) 357 1569 Tait Electronics Fax : (+64)(3) 359 4632 PO Box 1645 Christchurch Email : robin.gilks@tait.co.nz New Zealand From uclibc at vanriel.xs4all.nl Thu Jul 10 10:09:58 2003 From: uclibc at vanriel.xs4all.nl (Henri van Riel) Date: Sat Jul 19 08:54:52 2003 Subject: [uClibc] What libraries are used for what symbols? Message-ID: <1932955840.20030710090958@vanriel.xs4all.nl> Hello, I'm compiling a package with uClibc. Compilation is successful except for the following warnings: pptpctrl.c: In function `pptp_handle_ctrl_connection': pptpctrl.c:258: warning: implicit declaration of function `time' ctrlpacket.c: In function `deal_start_ctrl_conn': ctrlpacket.c:371: warning: implicit declaration of function `bzero' inststr.c: In function `inststr': inststr.c:46: warning: implicit declaration of function `strlcpy' Then when I ldd the object I get the following output: # ldd pptpd libc.so.0 => /usr/i386-linux-uclibc/lib/libc.so.0 /usr/i386-linux-uclibc/lib/ld-uClibc.so.0 => /usr/i386-linux-uclibc/lib/ld-uClibc.so.0 How do I find out why it needs libc? What symbols cause this linkage against libc? I tried nm and readelf and strace and a few other tools but nothing tells me which symbol in in which library... Can anyone help? -- Best regards, Henri mailto:uclibc@vanriel.xs4all.nl From kleine-budde at gmx.de Thu Jul 10 11:34:40 2003 From: kleine-budde at gmx.de (Marc Kleine-Budde) Date: Sat Jul 19 08:54:52 2003 Subject: [uClibc] buildroot + uClibc + xscale??? In-Reply-To: References: Message-ID: <20030710083440.GA25283@timberwolf.dyndns.org> Hi! On Wed, Jul 09, 2003 at 06:20:11PM -0700, Mark Rakes wrote: > # CONFIG_GENERIC_ARM is not set > # CONFIG_ARM7TDMI is not set > # CONFIG_STRONGARM is not set > CONFIG_XSCALE=y According yo the gcc-3.3 manual [1], the valid -march= switches are: armv2, armv2a, armv3, armv3m, armv4, armv4t, armv5, armv5t, armv5te A quick workaround is to use GENERIC_ARM as target processor type. The generated code will run on a xscale... hope that helps - marc [1] http://gcc.gnu.org/onlinedocs/gcc-3.3/gcc/ARM-Options.html#ARM%20Options -- #!/bin/sh set - `type $0` 'tr "[a-zA-Z]" "[n-za-mN-ZA-M]"';while [ "$2" != "" ];do \ shift;done; echo 'frq -a -rc '`echo "$0"| $1 `'>$UBZR/.`rpub signature|'`\ echo $1|$1`'`;rpub "Jr ner fvtangher bs obet. Erfvfgnapr vf shgvyr!"'|$1|sh From Gusti at pallas.dk Thu Jul 10 12:52:05 2003 From: Gusti at pallas.dk (Agust Karlsson) Date: Sat Jul 19 08:54:52 2003 Subject: [uClibc] gcc 3.3 toolchain + templates Message-ID: Hi there. I have just installed the uClibc (0.9.20) toolchain with gcc-3.3 but have discovered a problem when compiling my old applications. When I compile with the "plain" gcc-3.3 compiler everything is OK, and it was OK before I upgraded (uClibc 0.9.12 on gcc-3.1). But when I use the toolchain I get an error (see below). I have checked that the include files in the toolchain are identical with the ones in the "plain" gcc. Hope that someone can guide my out of my misery. Gusti Here is the listing: g++ -c -Wall -I../lib -o ph.o ph.cpp In file included from /usr/local/uclibc-9.20/include/c++/vector:68, from ../lib/bookkeeper.h:22, from ../lib/dbmessage.h:10, from ../lib/tmmessage.h:12, from ph.h:28, from ph.cpp:14: /usr/local/uclibc-9.20/include/c++/bits/stl_alloc.h:382: error: parse error before `;' token /usr/local/uclibc-9.20/include/c++/bits/stl_alloc.h:452: error: syntax error before `<' token /usr/local/uclibc-9.20/include/c++/bits/stl_alloc.h:452: error: `__threads' was not declared in this scope /usr/local/uclibc-9.20/include/c++/bits/stl_alloc.h:452: error: `__inst' was not declared in this scope /usr/local/uclibc-9.20/include/c++/bits/stl_alloc.h:452: error: template argument 1 is invalid /usr/local/uclibc-9.20/include/c++/bits/stl_alloc.h:452: error: template argument 2 is invalid ph.cpp: In member function `void cPH::Go()': ph.cpp:72: warning: unused variable `termios ts' /usr/local/uclibc-9.20/include/c++/bits/stl_alloc.h: In static member function `static void* std::__default_alloc_template<__threads, __inst>::allocate(unsigned int) [with bool __threads = true, int __inst = 0] ': /usr/local/uclibc-9.20/include/c++/bits/stl_alloc.h:232: instantiated from `static _Tp* std::__simple_alloc<_Tp, _Alloc>::allocate(unsigned int) [with _Tp = Bookkeeper::Duty, _Alloc = std::__default_alloc_template]' /usr/local/uclibc-9.20/include/c++/bits/stl_vector.h:127: instantiated from `_Tp* std::_Vector_alloc_base<_Tp, _Allocator, true>::_M_allocate(unsigned int) [with _Tp = Bookkeeper::Duty, _Allocator = std::allocator]' /usr/local/uclibc-9.20/include/c++/bits/stl_vector.h:156: instantiated from `std::_Vector_base<_Tp, _Alloc>::_Vector_base(unsigned int, typename std::_Vector_alloc_base<_Tp, _Alloc, std::_Alloc_traits<_Tp, _Allocator>::_S_instanceless>::allocator_type&) [with _Tp = Bookkeeper::Duty, _Alloc = std::allocator]' /usr/local/uclibc-9.20/include/c++/bits/stl_vector.h:266: instantiated from `std::vector<_Tp, _Alloc>::vector(const std::vector<_Tp, _Alloc>&) [with _Tp = Bookkeeper::Duty, _Alloc = std::allocator]' ../lib/bookkeeper.h:524: instantiated from here /usr/local/uclibc-9.20/include/c++/bits/stl_alloc.h:397: error: `__atomic_add' undeclared (first use this function) /usr/local/uclibc-9.20/include/c++/bits/stl_alloc.h:397: error: (Each undeclared identifier is reported only once for each function it appears in.) make: *** [ph.o] Error 1 --------------------------- and the ouput from g++ -v Reading specs from /usr/local/uclibc-9.20/i386-linux/bin/../lib/gcc-lib/i386-linux/3.3/specs Configured with: /Elan/LogiTux/gcc-3.3/build_i386/gcc-3.3/configure --target=i386-linux --prefix=/usr/local/uclibc-9.20 --exec-prefix=/usr/local/uclibc-9.20 --bindir=/usr/local/uclibc-9.20/bin --sbindir=/usr/local/uclibc-9.20/sbin --sysconfdir=/usr/local/uclibc-9.20/etc --datadir=/usr/local/uclibc-9.20/share --localstatedir=/usr/local/uclibc-9.20/var --mandir=/usr/local/uclibc-9.20/man --infodir=/usr/local/uclibc-9.20/info --with-local-prefix=/usr/local/uclibc-9.20/usr/local --libdir=/usr/local/uclibc-9.20/lib --includedir=/usr/local/uclibc-9.20/include --with-gxx-include-dir=/usr/local/uclibc-9.20/include/c++ --oldincludedir=/usr/local/uclibc-9.20/include --enable-shared --enable-target-optspace --disable-nls --with-gnu-ld --disable-__cxa_atexit --enable-languages=c,c++ --program-prefix=i386-uclibc- Thread model: posix gcc version 3.3 -- Agust Karlsson mailto:gusti@pallas.dk Pallas Informatik A/S http://www.pallas.dk Aller?d Stationsvej 2D Tel.: +45 48 10 24 10 DK-3450 Aller?d Fax.: +45 48 10 24 01 From ibe at dcl.info.waseda.ac.jp Thu Jul 10 22:32:09 2003 From: ibe at dcl.info.waseda.ac.jp (ibe@dcl.info.waseda.ac.jp) Date: Sat Jul 19 08:54:52 2003 Subject: [uClibc]can't resolve symbol. In-Reply-To: <3F0C04E5.1FC4EF24@zee2.com> References: <3F0C04E5.1FC4EF24@zee2.com> Message-ID: Thanks, Stuart. > > I see the same problem on powerpc 8xx too. The work-around was to set: > > # UCLIBC_HAS_FLOATS is not set > > in the uclibc configuration. This is not a proper solution though as I > can't work out why/how when busybox links it resolves __adddf3 and > friends, but on the target when it runs, these symbols get reported as > unresolved. But I tried to do such approach, my linux stoped while booting. (after appearing init message. So it can't boot.) Busybox (or libc) use object of libgcc, so if I set # UCLIBC_HAS_FLOATS is not set I think it naturally can't run. Does your linux run properly? or Do you think I forget any important things? If you have other hint, please help me. I am Sorry to bother you. //////////////////////////////////////////////// WASEDA UNIVERSITY Department of Information and Computer Science Ubiquitous & Distributed computing Lab. Hiroaki Ibe E-mail:ibe@dcl.info.waseda.ac.jp ibe@fuji.waseda.jp /////////////////////////////////////////////// From seh at zee2.com Thu Jul 10 15:03:48 2003 From: seh at zee2.com (Stuart Hughes) Date: Sat Jul 19 08:54:52 2003 Subject: [uClibc]can't resolve symbol. References: <3F0C04E5.1FC4EF24@zee2.com> Message-ID: <3F0D6434.F7C96EEE@zee2.com> ibe@dcl.info.waseda.ac.jp wrote: > > Thanks, Stuart. > > > > > I see the same problem on powerpc 8xx too. The work-around was to > set: > > > > # UCLIBC_HAS_FLOATS is not set > > > > in the uclibc configuration. This is not a proper solution though as > I > > can't work out why/how when busybox links it resolves __adddf3 and > > friends, but on the target when it runs, these symbols get reported as > > unresolved. > > But I tried to do such approach, my linux stoped while booting. > (after appearing init message. So it can't boot.) > > Busybox (or libc) use object of libgcc, so if I set > > # UCLIBC_HAS_FLOATS is not set > > I think it naturally can't run. > > Does your linux run properly? > or > Do you think I forget any important things? > > If you have other hint, please help me. > > I am Sorry to bother you. Mine runs okay, but I did change the toolchain build to add --nfp to both binutils an a gcc (using EXTRA_CONFIG_OPTIONS from memory, not sure if that is the right name). Also the toolchain built the uclibc part with -msoft float. Not sure if this is relevant. The most significant other thing I noticed was that originally I was using busybox-0.60 and my system would hang on boot (after mounting the rootfs). Upgrading busybox to the latest version fixed this for me. Hope this helps, Regards, Stuart From seh at zee2.com Thu Jul 10 15:06:11 2003 From: seh at zee2.com (Stuart Hughes) Date: Sat Jul 19 08:54:52 2003 Subject: [uClibc] Problems with pthreads / MIPS References: Message-ID: <3F0D64C3.5115F970@zee2.com> Hi Thomas, I've see similar problems. I've been testing a c++ application with a large number of pthreads, this hangs during initialisation. I've not be able to debug it as I've not be able to build a gdb (host or target) that works correctly with pthreads. Regards, Stuart Betker Thomas ICM CP RD SD 1 wrote: > > Hi all: > > We are experiencing a lot of problems with pthreads on a MIPS/MMU platform. Most tests were originally done with uclibc-0.9.12 (as provided by a third party), but were rechecked with a current CVS snapshot. We are using a 2.4.17 Linux kernel here. > > A. pthread_create() hangs (sometimes, not always - say 50%), i.e., the call won't return. [This one was not rechecked with uclibc-0.9.20 yet.] > > B. exit() hangs (always), if you have created any threads. The process doesn't terminate, not even the thread that called exit(). > > C. sigwait() doesn't work at all. If there is no signal, the call returns anyway, indicating a signal 0 (which doesn't exist). If there is a signal, it may be lost (not seen by any thread, which happens most of the time), or it may be received by a thread not waiting for it. > > D. The 'kill ' command usually kills the thread with the given , but not the whole process; i.e., the other threads may live on. > > Does anybody else have the same problems, or is it just me? And more important, is there anything I could do about it? Any ideas? > > I tried to run my test programs on a i386 platform (kernel 2.4.19), and everything worked as it should. The only exception was D., which occurs on i386 as well, but it's rather A. to C. I am concerned about. > > Best regards, > Thomas Betker > _______________________________________________ > uClibc mailing list > uClibc@uclibc.org > http://uclibc.org/mailman/listinfo/uclibc From dave-gnus at bfnet.com Thu Jul 10 12:53:48 2003 From: dave-gnus at bfnet.com (David Wuertele) Date: Sat Jul 19 08:54:52 2003 Subject: [uClibc] gcc-target on mipsel, buildroot: "no include path in which to find limits.h" Message-ID: Arch: mipsel uclibc: 0.9.20 gcc: 3.2.3 buildroot: CVS snapshot on 12:08PDT, July 1, 2003 Buildroot doesn't succeed in building gcc-target because of the following error: make[2]: Entering directory `/home/dave/buildroot-200307011208/build_mipsel/gcc-target/gcc' (cd intl && make all) make[3]: Entering directory `/home/dave/buildroot-200307011208/build_mipsel/gcc-target/gcc/intl' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/home/dave/buildroot-200307011208/build_mipsel/gcc-target/gcc/intl' /home/dave/buildroot-200307011208/build_mipsel/staging_dir/bin/mipsel-uclibc-gcc -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -isystem ./include -I. -I. -I/home/dave/buildroot-200307011208/toolchain_build_mipsel/gcc-3.2.3/gcc -I/home/dave/buildroot-200307011208/toolchain_build_mipsel/gcc-3.2.3/gcc/. -I/home/dave/buildroot-200307011208/toolchain_build_mipsel/gcc-3.2.3/gcc/config -I/home/dave/buildroot-200307011208/toolchain_build_mipsel/gcc-3.2.3/gcc/../include -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions \ -c /home/dave/buildroot-200307011208/toolchain_build_mipsel/gcc-3.2.3/gcc/crtstuff.c -DCRT_BEGIN \ -o crtbegin.o In file included from include/limits.h:11, from /home/dave/buildroot-200307011208/toolchain_build_mipsel/gcc-3.2.3/gcc/tsystem.h:84, from /home/dave/buildroot-200307011208/toolchain_build_mipsel/gcc-3.2.3/gcc/crtstuff.c:62: /home/dave/buildroot-200307011208/build_mipsel/staging_dir/lib/gcc-lib/mipsel-linux/3.2.3/include/syslimits.h:7:25: no include path in which to find limits.h /home/dave/buildroot-200307011208/toolchain_build_mipsel/gcc-3.2.3/gcc/crtstuff.c:195: warning: `__EH_FRAME_BEGIN__' defined but not used make[2]: *** [crtbegin.o] Error 1 make[2]: Leaving directory `/home/dave/buildroot-200307011208/build_mipsel/gcc-target/gcc' make[1]: *** [all-gcc] Error 2 make[1]: Leaving directory `/home/dave/buildroot-200307011208/build_mipsel/gcc-target' make: *** [/home/dave/buildroot-200307011208/build_mipsel/gcc-target/.compiled] Error 2 Has anyone seen this before? I already STFW, and found some out of date references to similar errors. But they don't seem to apply to gcc-3.2.3. I didn't see any mention of it in the uclibc archives. Suggestions? Thanks, Dave From andersen at codepoet.org Thu Jul 10 15:44:35 2003 From: andersen at codepoet.org (Erik Andersen) Date: Sat Jul 19 08:54:52 2003 Subject: [uClibc] Problems with pthreads / MIPS In-Reply-To: <3F0D64C3.5115F970@zee2.com> References: <3F0D64C3.5115F970@zee2.com> Message-ID: <20030710204435.GA15291@codepoet.org> On Thu Jul 10, 2003 at 02:06:11PM +0100, Stuart Hughes wrote: > Hi Thomas, > > I've see similar problems. I've been testing a c++ application with a > large number of pthreads, this hangs during initialisation. I've not be > able to debug it as I've not be able to build a gdb (host or target) > that works correctly with pthreads. See uClibc/ldso/ldso/ldso.c around line 440, where it says: #warning "Debugging threads on mips won't work till someone fixes this..." At one point sjhill mentioned he would look into this, but until someone addresses that, debugging pthreads on mips won't work. I suspect that on mips, the step of scanning the PT_DYNAMIC dynamic linking information and assigning a struct r_debug when a DT_DEBUG dynamic entry is found, probably needs to occur right before we transfer control to the application. It doesn't work in the current location since, for mips, one needs to do all sorts of relocation processing first. As a quick try, you could try adding something like this right before we transfer control to the application. Does that help? #if defined(__mips__) { elf_phdr *ppnt; int i; ppnt = (elf_phdr *) auxvt[AT_PHDR].a_un.a_ptr; for (i = 0; i < auxvt[AT_PHNUM].a_un.a_val; i++, ppnt++) if (ppnt->p_type == PT_DYNAMIC) { dpnt = (Elf32_Dyn *) ppnt->p_vaddr; while (dpnt->d_tag) { if (dpnt->d_tag == DT_DEBUG) { dpnt->d_un.d_val = (unsigned long) debug_addr; } dpnt++; } } } #endif -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- From uc9394 at hotmail.com Fri Jul 11 19:35:40 2003 From: uc9394 at hotmail.com (Eric) Date: Sat Jul 19 08:54:52 2003 Subject: [uClibc] Which one to use Message-ID: I am now writing a bootloader on arm7tdmi. When I link the files, I got an undefined reference to '_bootstrap' at si.S. I have everything inside the same directory. I got 5 files. extern void main(void); void bootstrap(void) { typedef void(*ENTRY)(void); ENTRY entry_addr; entry_addr = &main; (*entry_addr)(); } ENTRY(main) SECTIONS { .reset : { si.o } .text : {*(.text)} .bss : {*(.bss)} .data : {*(.data)} } int main(int argc, char *argv[]) { unsigned int abc; abc=0; return(0); } .text .align .global _start _start: mov r0,#0xD3 msr cpsr, r0 b _bootstrap Did I make anything wrong? More, I have find two sets of toolchain. One is arm-elf-gcc and the other is arm-linux-gcc. Which one should I use when I want to compile a bootloader? Thanks, Eric From harilal at blueshift.com Sun Jul 13 17:06:08 2003 From: harilal at blueshift.com (Harilal S.B.) Date: Sat Jul 19 08:54:52 2003 Subject: [uClibc] error in installing uClibc Message-ID: <90B3181C75A07740BAF743AD0E84803C405D8A@exchange.chennai.blueshift.com> Hello, I am getting the error given below if try to call make path is correct . please help me out for solving this With Regards Harilal [root@rnd2 uClibc-0.9.18]# make rm -f include/asm; The path '/usr/src/linux/include/asm' doesn't exist. I bet you didn't set KERNEL_SOURCE, TARGET_ARCH or UCLIBC_HAS_MMU correctly when you configured uClibc. Please fix these settings. make: *** [headers] Error 1 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://uclibc.org/lists/uclibc/attachments/20030713/15417d90/attachment.htm From uclibc at lacklustre.net Sun Jul 13 11:05:03 2003 From: uclibc at lacklustre.net (Michael Ryan) Date: Sat Jul 19 08:54:52 2003 Subject: [uClibc] error in installing uClibc In-Reply-To: <90B3181C75A07740BAF743AD0E84803C405D8A@exchange.chennai.blueshift.com> References: <90B3181C75A07740BAF743AD0E84803C405D8A@exchange.chennai.blueshift.com> Message-ID: <20030713100503.6811dc91.uclibc@lacklustre.net> Edit the makefile to point to the path of your current kernel source. In my case, the makefile looked like this: KERNEL_SOURCE = /usr/src/linux-2.4.21 Then, you should be able to build. On Sun, 13 Jul 2003 16:06:08 +0530 "Harilal S.B." wrote: > > Hello, > > I am getting the error given below if try to call make > path is correct . please help me out for solving this > > With Regards > Harilal > > > [root@rnd2 uClibc-0.9.18]# make > rm -f include/asm; > > The path '/usr/src/linux/include/asm' doesn't exist. > I bet you didn't set KERNEL_SOURCE, TARGET_ARCH or UCLIBC_HAS_MMU > correctly when you configured uClibc. Please fix these settings. > > make: *** [headers] Error 1 > -- Michael Ryan Lacklustre Networking michael@lacklustre.net http://www.lacklustre.net/ From fredrik.johnsson at orestad-linux.net Mon Jul 14 23:38:03 2003 From: fredrik.johnsson at orestad-linux.net (Fredrik Johnsson) Date: Sat Jul 19 08:54:52 2003 Subject: [uClibc] TinyX with Xfree 4.3 Message-ID: <3F1314AB.5090502@orestad-linux.se> Hi! A while back some guys said they had tried Xfree86 4.3 without much success. Now i've been occupied with other things and haven't really followed the mailing list and can't seem to find any more info. Has the possibillity for compiling TinyX changed or is to keep on with Xfree86 4.2? / Fredrik Johnsson From christian_michon at yahoo.fr Tue Jul 15 11:42:29 2003 From: christian_michon at yahoo.fr (=?iso-8859-1?q?Christian=20MICHON?=) Date: Sat Jul 19 08:54:52 2003 Subject: [uClibc] TinyX with Xfree 4.3 In-Reply-To: <3F1314AB.5090502@orestad-linux.se> Message-ID: <20030715084229.39662.qmail@web11104.mail.yahoo.com> --- Fredrik Johnsson a ?crit : > Hi! > > A while back some guys said they had tried Xfree86 4.3 without much success. I should count me as one of them... > > Now i've been occupied with other things and haven't really followed the > mailing list and can't seem to find any more info. Me too. Another son, now two months old ;) I hardly find time to fine tune my scripts recently. > > Has the possibillity for compiling TinyX changed or is to keep on with > Xfree86 4.2? Some people recently reported that LD_PRELOAD can be used to force the render library to be read properly by uclibc ld and get the bins to work, finally. I still need some time to confirm/infirm this and update scripts. I still owe Erik long overdue .mk for xfree. Soon to come... By the way, got broadband recently, and got hacked into through wuftpd. As it seems a pretty nasty buffer overflow, do we know yet if such exploits exist with uclibc/busybox ? Christian ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en fran?ais ! Yahoo! Mail : http://fr.mail.yahoo.com From bernie at develer.com Tue Jul 15 23:07:09 2003 From: bernie at develer.com (Bernardo Innocenti) Date: Sat Jul 19 08:54:52 2003 Subject: [uClibc] SPAM[RBL] Re: SPAM[RBL] Re: SPAM[RBL] sys_errlist In-Reply-To: <20030715184136.GA6184@codepoet.org> References: <200307152002.26358.bernie@develer.com> <20030715184136.GA6184@codepoet.org> Message-ID: <200307152207.09701.bernie@develer.com> On Tuesday 15 July 2003 20:41, Erik Andersen wrote: > Using sys_errlist[] requires that I actually populate the entire > array with strings. Once all apps stop using sys_errlist[] there > will be a number of additional options available for efficiently > handling the storage for the various error stings. > > Last time I checked, a whole bunch of apps in uClinx-dist were > still using the sys_errlist[] array... I would suggest taking an approach similar to glibc's handling of multithreaded errno. Something like this: #define sys_errlist (__get_sys_errlist()) const char * const * __get_sys_errlist(void) __THROW { static __sys_errlist; if (unlikely(__sys_errlist == NULL)) __sys_errlist = __load_sys_errlist(); return __sys_errlist; } void __load_sys_errlist(void) { FILE *f; int i; char buf[128]; if (!(__sys_errlist = calloc(sys_nerr, sizeof(char *)))) abort(); if ((f = fopen("/lib/libc_errors.txt", "r"))) for(i = 0; i < sys_nerr; ++i) if (fgets(f, buf, sizeof(buf))) __sys_errlist[i] = strdup(buf); } -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ Please don't send Word attachments - http://www.gnu.org/philosophy/no-word-attachments.html From mjn3 at codepoet.org Wed Jul 16 01:49:42 2003 From: mjn3 at codepoet.org (Manuel Novoa III) Date: Sat Jul 19 08:54:52 2003 Subject: [uClibc] SPAM[RBL] Re: SPAM[RBL] Re: SPAM[RBL] sys_errlist In-Reply-To: <200307152207.09701.bernie@develer.com> References: <200307152002.26358.bernie@develer.com> <20030715184136.GA6184@codepoet.org> <200307152207.09701.bernie@develer.com> Message-ID: <20030716064942.GA5817@codepoet.org> On Tue, Jul 15, 2003 at 10:07:09PM +0200, Bernardo Innocenti wrote: > On Tuesday 15 July 2003 20:41, Erik Andersen wrote: > > > Using sys_errlist[] requires that I actually populate the entire > > array with strings. Once all apps stop using sys_errlist[] there > > will be a number of additional options available for efficiently > > handling the storage for the various error stings. > > > > Last time I checked, a whole bunch of apps in uClinx-dist were > > still using the sys_errlist[] array... > > I would suggest taking an approach similar to glibc's handling > of multithreaded errno. Something like this: > > #define sys_errlist (__get_sys_errlist()) > > const char * const * __get_sys_errlist(void) __THROW > { > static __sys_errlist; > > if (unlikely(__sys_errlist == NULL)) > __sys_errlist = __load_sys_errlist(); > return __sys_errlist; > } > > void __load_sys_errlist(void) > { > FILE *f; > int i; > char buf[128]; > > if (!(__sys_errlist = calloc(sys_nerr, sizeof(char *)))) > abort(); > > if ((f = fopen("/lib/libc_errors.txt", "r"))) > for(i = 0; i < sys_nerr; ++i) > if (fgets(f, buf, sizeof(buf))) > __sys_errlist[i] = strdup(buf); > } I checked the archives for the previous messages in this thread and found that you referenced strerror.c, which I removed from uClibc over a year ago. It last appeared in version 0.9.12. If you're not interested in upgrading to the latest version, you should at least look at the diffs to see what bugs got fixed. Regarding your concerns about the size increase in staticly linked apps due to the system error messages, I'd be happy to add a an option to the current version of uClibc to force strerror (and strsignal for that matter) to omit the actual text messages. Of course, that won't help applications still using sys_errlist[]. But any application still using sys_errlist[] really needs to be updated. If you wanted to store the system error message text in a file and load it dynamically, all you would have to do is replace the function int _susv3_strerror_r(int errnum, char *strerrbuf, size_t buflen) in the current version of uClibc. Well... that _and_ get rid of all the outdated sys_errlist[] cruft in any relevant apps. Currently no uClibc routines use sys_errlist[]. About a year ago, I removed it completely and then reinstated it because of complaints that it was still used in some of the uClinux userland apps. So I put a link warning in place that it was deprecated (in SUSv2) and it would eventually be removed (as it has from SUSv3). In fact, I will probably make it a build-time config option in the next release. If you _still_ wanted to support sys_errlist[] with a scheme like you suggest above, you would need to do a bit more. A failure in opening or reading the file, or in memory allocation, would result in one or more of the table entries being NULL. Last time I looked, at least some of the uClinux userland apps using sys_errlist[] were not prepared for a NULL ptr corresponding to a valid errno. Manuel From bernie at develer.com Wed Jul 16 19:26:03 2003 From: bernie at develer.com (Bernardo Innocenti) Date: Sat Jul 19 08:54:52 2003 Subject: [uClibc] sys_errlist In-Reply-To: <20030716064942.GA5817@codepoet.org> References: <200307152002.26358.bernie@develer.com> <200307152207.09701.bernie@develer.com> <20030716064942.GA5817@codepoet.org> Message-ID: <200307161826.03809.bernie@develer.com> On Wednesday 16 July 2003 08:49, Manuel Novoa III wrote: > I checked the archives for the previous messages in this thread and > found that you referenced strerror.c, which I removed from uClibc > over a year ago. It last appeared in version 0.9.12. If you're not > interested in upgrading to the latest version, you should at least > look at the diffs to see what bugs got fixed. I'm using version 0.9.19 from the latest uClinux distribution. The problem is that for several months I did new imports into our CVS using a stupid way to do the merge: cvs checkout -jUCLINUX:yesterday -jUCLINUX uclinux instead of the correct way: cvs checkout -jUCLINUX_20030515 -jUCLINUX_20030525 uclinux As a result, I have a lot of files in my HEAD branch which should have been removed by the merge. Fixing this requires a long and tedious search all over the source tree so I've not bothered. > Regarding your concerns about the size increase in staticly linked apps > due to the system error messages, I'd be happy to add a an option to > the current version of uClibc to force strerror (and strsignal for > that matter) to omit the actual text messages. Of course, that won't > help applications still using sys_errlist[]. But any application still > using sys_errlist[] really needs to be updated. > > If you wanted to store the system error message text in a file and > load it dynamically, all you would have to do is replace the function > int _susv3_strerror_r(int errnum, char *strerrbuf, size_t buflen) > in the current version of uClibc. Well... that _and_ get rid of all > the outdated sys_errlist[] cruft in any relevant apps. So I'd better fix that instead. Does glibc provide sys_errlist[] to applications? Is it required by any relevant standard? The fact that there are no underscores in the name makes me think that it's not something internal. > Currently no uClibc routines use sys_errlist[]. About a year ago, > I removed it completely and then reinstated it because of complaints > that it was still used in some of the uClinux userland apps. So I put > a link warning in place that it was deprecated (in SUSv2) and it would > eventually be removed (as it has from SUSv3). In fact, I will probably > make it a build-time config option in the next release. Actually, the application where I've noticed this problem - telnetd - does not use sys_errlist[] at all, but all the messages get linked into the binary because of perror(). I'd like to drop this overhead. > If you _still_ wanted to support sys_errlist[] with a scheme like you > suggest above, you would need to do a bit more. A failure in opening > or reading the file, or in memory allocation, would result in one or > more of the table entries being NULL. Last time I looked, at least > some of the uClinux userland apps using sys_errlist[] were not prepared > for a NULL ptr corresponding to a valid errno. Hmmm... if they're just passing to uClinux version of printf(), they should be safe. Otherwise, we could always set all slots to point at an empty string instead of storing NULL into them. -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ Please don't send Word attachments - http://www.gnu.org/philosophy/no-word-attachments.html From mjn3 at codepoet.org Wed Jul 16 12:41:18 2003 From: mjn3 at codepoet.org (Manuel Novoa III) Date: Sat Jul 19 08:54:52 2003 Subject: [uClibc] sys_errlist In-Reply-To: <200307161826.03809.bernie@develer.com> References: <200307152002.26358.bernie@develer.com> <200307152207.09701.bernie@develer.com> <20030716064942.GA5817@codepoet.org> <200307161826.03809.bernie@develer.com> Message-ID: <20030716174118.GA13127@codepoet.org> On Wed, Jul 16, 2003 at 06:26:03PM +0200, Bernardo Innocenti wrote: > On Wednesday 16 July 2003 08:49, Manuel Novoa III wrote: > > If you wanted to store the system error message text in a file and > > load it dynamically, all you would have to do is replace the function > > int _susv3_strerror_r(int errnum, char *strerrbuf, size_t buflen) > > in the current version of uClibc. Well... that _and_ get rid of all > > the outdated sys_errlist[] cruft in any relevant apps. > > So I'd better fix that instead. Does glibc provide sys_errlist[] to > applications? Yes, but current versions issue the following link warning -- : `sys_errlist' is deprecated; use `strerror' or `strerror_r' instead > Is it required by any relevant standard? I thought it appeared as deprecated in SUSv2, but apparently not. I just searched and didn't find a reference. > The fact that > there are no underscores in the name makes me think that it's not > something internal. It still uses an internal version in its strerror_r implementation. > Actually, the application where I've noticed this problem - telnetd - > does not use sys_errlist[] at all, but all the messages get linked into > the binary because of perror(). I'd like to drop this overhead. Everything in uClibc goes through _susv3_strerror_r() now, except for the sys_errlist[] table. As I said, I'll add an option to omit the message text and simply print the errno. > > If you _still_ wanted to support sys_errlist[] with a scheme like you > > suggest above, you would need to do a bit more. A failure in opening > > or reading the file, or in memory allocation, would result in one or > > more of the table entries being NULL. Last time I looked, at least > > some of the uClinux userland apps using sys_errlist[] were not prepared > > for a NULL ptr corresponding to a valid errno. > > Hmmm... if they're just passing to uClinux version of printf(), > they should be safe. I don't recall the usage. > Otherwise, we could always set all slots to point > at an empty string instead of storing NULL into them. A couple of other issues... Some of the errnos for the same error are different on some archs. That is why the internal strerror stuff has to check an index table. So you'd either have to include an index table in the code and share a file with all supported archs, or you'd have to supply a seperate file for each supported arch. One other fun note is that mips has a max errno of 1133. What were they thinking? Also, since many applications that use sys_errlist[] are older, they often declare it themselves. If you were to define sys_errlist as a function returning a pointer to a dynamicly constructed table, you will likely still have to go in and patch a number of userland apps. Manuel From peter.kjellerstedt at axis.com Thu Jul 17 18:19:41 2003 From: peter.kjellerstedt at axis.com (Peter Kjellerstedt) Date: Sat Jul 19 08:54:52 2003 Subject: [uClibc] [PATCH] Uninitialized value used through vsscanf() Message-ID: The attached patch should solve a problem whereby vsscanf() (and thus sscanf()) failed to initialize bufread in the FILE struct that is passed to vfscanf() and which is then later used. The problem occurred if the end of the buffer being parsed has already been reached and a %s format specifier is found. Then it could parse past the end of the buffer, resulting in incorrect return values from vfscanf() and sometimes causing SIGSEGV. The test program below showed the problem. //Peter #include #include #include #define CRAP_SIZE 1 int main(void) { int a; #if 1 char *crap = malloc(CRAP_SIZE); #else char crap[CRAP_SIZE]; /* stack allocation may not trig bug */ #endif memset(crap, 'a', CRAP_SIZE); crap[CRAP_SIZE - 1] = '\0'; /* yields (should be 1): * 2 * ## * when bug triggered */ printf("%d\n", sscanf("1", "%d%s", &a, crap)); printf("crap = #%s#\n", crap); return EXIT_SUCCESS; } <> -------------- next part -------------- A non-text attachment was scrubbed... Name: scanf.patch Type: application/octet-stream Size: 646 bytes Desc: not available Url : http://uclibc.org/lists/uclibc/attachments/20030717/40d76130/scanf.obj From ibe at dcl.info.waseda.ac.jp Fri Jul 18 01:26:42 2003 From: ibe at dcl.info.waseda.ac.jp (ibe@dcl.info.waseda.ac.jp) Date: Sat Jul 19 08:54:52 2003 Subject: [uClibc]can't resolve symbol. In-Reply-To: <1144.133.9.91.177.1057704567.squirrel@mail2.dcl.info.waseda.ac.jp> References: <1144.133.9.91.177.1057704567.squirrel@mail2.dcl.info.waseda.ac.jp> Message-ID: Hi, all. > I have some trouble when using some command like > ls, mount or other > > # ls > ls: can't resolve symbol '__eqdf2' > ls: can't resolve symbol '__floatsidf' > ls: can't resolve symbol '__ltdf2' > ls: can't resolve symbol '__adddf3' > ls: can't resolve symbol '__fixdfsi' > ls: can't resolve symbol '__negdf2' > ls: can't resolve symbol '__divdf3' > ls: can't resolve symbol '__muldf3' > ls: can't resolve symbol '__truncdfsf2' > ls: can't resolve symbol '__nedf2' > ls: can't resolve symbol '__gedf2' > ls: can't resolve symbol '__subdf3' > bin dev proc usr > boot etc linuxrc sbin > # Finally, I found the solution this problem. In a Makefile, there is some script below, $(LD) $(LDFLAGS) $(VERSION_SCRIPT) -soname=$(SHARED_MAJORNAME) -o $(SHARED_FULLNAME) \ --whole-archive $(LIBGCC_NEED) $(LIBNAME) \ $(TOPDIR)/libc/misc/internals/interp.o --no-whole-archive \ -init __uClibc_init $(LIBGCC) They turn into below in my environment, > ppc_8xx-ld -s -shared --warn-common --warn-once -z combreloc > -soname=libc.so.0 -o libuClibc-0.9.19.so \ > --whole-archive ./tmp/libgcc-need.a libc.a \ > ..//libc/misc/internals/interp.o --no-whole-archive \ > -init __uClibc_init > /opt/hardhat/devkit/ppc/8xx/lib/gcc-lib/powerpc-hardhat-linux/3.2.1/ > libgcc.a Perhaps, there is s bug in the GCC linker that causes the libgcc library to be included twice if there is a -whole-archive -no-whole-archive sequence passed to the linker without any libraries specified in between. So My fix was to remove final $(LIBGCC). Although, I wouder why this script repeat to link some objects of libgcc again? And in the man of ld, --whole-archive For each archive mentioned on the command line after the --whole-archive option, include every object file in the archive in the link, rather than searching the archive for the required object files. This is normally used to turn an archive file into a shared library, forcing every object to be included in the resulting shared library. This option may be used more than once. If I don't use --whole-archive option, How does gcc know which object is required object files? //////////////////////////////////////////////// WASEDA UNIVERSITY Department of Information and Computer Science Ubiquitous & Distributed computing Lab. Hiroaki Ibe E-mail:ibe@dcl.info.waseda.ac.jp /////////////////////////////////////////////// From mjn3 at codepoet.org Thu Jul 17 11:12:15 2003 From: mjn3 at codepoet.org (Manuel Novoa III) Date: Sat Jul 19 08:54:52 2003 Subject: [uClibc] Re: [PATCH] Uninitialized value used through vsscanf() In-Reply-To: References: Message-ID: <20030717161215.GA24848@codepoet.org> On Thu, Jul 17, 2003 at 05:19:41PM +0200, Peter Kjellerstedt wrote: > The attached patch should solve a problem whereby vsscanf() > (and thus sscanf()) failed to initialize bufread in the > FILE struct that is passed to vfscanf() and which is then > later used. Thanks. Applied. You should know that there are several other bugs in the current vfscanf() implementation. I'm just about finished a new version which fixes the ones I've found, as well as adds optional positional arg support (required by SUSv3) as well as some other configurable features. It will be in the cvs before the end of July. Manuel From fredrik.johnsson at orestad-linux.se Thu Jul 17 17:58:21 2003 From: fredrik.johnsson at orestad-linux.se (Fredrik Johnsson) Date: Sat Jul 19 08:54:52 2003 Subject: [uClibc] TinyX with Xfree 4.3 In-Reply-To: <20030715084229.39662.qmail@web11104.mail.yahoo.com> References: <20030715084229.39662.qmail@web11104.mail.yahoo.com> Message-ID: <3F16B98D.6050709@orestad-linux.se> Christian MICHON wrote: >--- Fredrik Johnsson a ?crit : > > >>Hi! >> >>A while back some guys said they had tried Xfree86 4.3 without much success. >> >> > >I should count me as one of them... > > > >>Now i've been occupied with other things and haven't really followed the >>mailing list and can't seem to find any more info. >> >> > > > Hi all! I'm now getting around to actually compiling TinyX and matchbox. Since I only got on erespons eon the matter I'm assuming there is no working solution for Xfree86 4.3 nad will go along with 4.2. But I could try with complete 4.3 for uclibc is that possible) and then when I or someone else finds a solution use the tinyX >Me too. Another son, now two months old ;) >I hardly find time to fine tune my scripts recently. > > > >>Has the possibillity for compiling TinyX changed or is to keep on with >>Xfree86 4.2? >> >> > >Some people recently reported that LD_PRELOAD can be used to force the >render library to be read properly by uclibc ld and get the bins to work, >finally. I still need some time to confirm/infirm this and update >scripts. > >I still owe Erik long overdue .mk for xfree. Soon to come... > >By the way, got broadband recently, and got hacked into through wuftpd. >As it seems a pretty nasty buffer overflow, do we know yet if such >exploits exist with uclibc/busybox ? > >Christian > > >___________________________________________________________ >Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en fran?ais ! >Yahoo! Mail : http://fr.mail.yahoo.com >_______________________________________________ >uClibc mailing list >uClibc@uclibc.org >http://uclibc.org/mailman/listinfo/uclibc > > From jrigby at metrowerks.com Mon Jul 21 13:06:41 2003 From: jrigby at metrowerks.com (John Rigby) Date: Mon Jul 21 13:19:26 2003 Subject: [uClibc] uclibc on mmufull m68k Message-ID: <3F1C2BB1.3050907@metrowerks.com> Anyone running uClibc on mmufull m68k linux like old macs, NeXT and SUN 3 boxes? From andersen at codepoet.org Mon Jul 21 14:27:47 2003 From: andersen at codepoet.org (Erik Andersen) Date: Mon Jul 21 13:27:56 2003 Subject: [uClibc] uclibc on mmufull m68k In-Reply-To: <3F1C2BB1.3050907@metrowerks.com> References: <3F1C2BB1.3050907@metrowerks.com> Message-ID: <20030721192747.GB22605@codepoet.org> On Mon Jul 21, 2003 at 12:06:41PM -0600, John Rigby wrote: > Anyone running uClibc on mmufull m68k linux like old macs, NeXT and SUN > 3 boxes? Around a year or so ago I was briefly given access to an old mac and made uClibc compile and run at that time. But I suspect that work has not kept up with the latest and greatest, so there may be a bit or arch specific work still needed. -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- From robert.searle at tait.co.nz Tue Jul 22 13:33:41 2003 From: robert.searle at tait.co.nz (searler) Date: Mon Jul 21 18:34:20 2003 Subject: [uClibc] compile of buildroot fails for i386 default target Message-ID: <3F1C8665.4050208@tait.co.nz> I checked out buildroot according to the instructions and changed the uclibs from snapshot and tinylogin from snapshot defines to false. I typed make and eventually the make fails with the messages cc1: unrecognized option `-auxbase' cc1: output filename specified twice I tried this a few days ago and everything worked (used daily snapshots that time). I have tried make clean and reverting the Makefile to the check-out default but nothing fixes the problem now. Any ideas where my environment might be going astray? Mandrake 9.1 distribution gcc -v Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2.2/specs Configured with: ../configure --prefix=/usr --libdir=/usr/lib --with-slibdir=/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --enable-long-long --enable-__cxa_atexit --enable-languages=c,c++,ada,f77,objc,java --host=i586-mandrake-linux-gnu --with-system-zlib Thread model: posix gcc version 3.2.2 (Mandrake Linux 9.1 3.2.2-3mdk) make -v GNU Make 3.80 Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ls -l /usr/src/linux lrwxrwxrwx 1 root root 22 Jul 21 09:43 /usr/src/linux -> /usr/src/linux-2.4.21// -------------- next part -------------- which: no mkfs.jffs2 in (/usr/X11R6/bin:/usr/local/bin:/bin:/usr/bin:/usr/games:/home/searler/bin) PATH=/home/packages/buildroot/build_i386/staging_dir/bin:/bin:/sbin:/usr/bin:/usr/sbin CC=gcc \ AR_FOR_TARGET=/home/packages/buildroot/build_i386/staging_dir/bin/i386-uclibc-ar RANLIB_FOR_TARGET=/home/packages/buildroot/build_i386/staging_dir/bin/i386-uclibc-ranlib \ LD_FOR_TARGET=/home/packages/buildroot/build_i386/staging_dir/bin/i386-uclibc-ld NM_FOR_TARGET=/home/packages/buildroot/build_i386/staging_dir/bin/i386-uclibc-nm \ CC_FOR_TARGET=/home/packages/buildroot/build_i386/staging_dir/bin/i386-uclibc-gcc make -C /home/packages/buildroot/toolchain_build_i386/gcc-final make[1]: Entering directory `/home/packages/buildroot/toolchain_build_i386/gcc-final' make[2]: Entering directory `/home/packages/buildroot/toolchain_build_i386/gcc-final/libiberty' make[3]: Entering directory `/home/packages/buildroot/toolchain_build_i386/gcc-final/libiberty/testsuite' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/home/packages/buildroot/toolchain_build_i386/gcc-final/libiberty/testsuite' make[2]: Leaving directory `/home/packages/buildroot/toolchain_build_i386/gcc-final/libiberty' make[2]: Entering directory `/home/packages/buildroot/toolchain_build_i386/gcc-final/gcc' (cd intl && make all) make[3]: Entering directory `/home/packages/buildroot/toolchain_build_i386/gcc-final/gcc/intl' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/home/packages/buildroot/toolchain_build_i386/gcc-final/gcc/intl' make GCC_FOR_TARGET="/home/packages/buildroot/toolchain_build_i386/gcc-final/gcc/xgcc -B/home/packages/buildroot/toolchain_build_i386/gcc-final/gcc/ -B/home/packages/buildroot/build_i386/staging_dir/i386-linux/bin/ -B/home/packages/buildroot/build_i386/staging_dir/i386-linux/lib/ -isystem /home/packages/buildroot/build_i386/staging_dir/i386-linux/include" \ BUILD_PREFIX="" BUILD_PREFIX_1="loser-" \ AR_FOR_TARGET="i386-uclibc-ar" \ AR_CREATE_FOR_TARGET="i386-uclibc-ar rc" \ AR_FLAGS_FOR_TARGET="" \ CFLAGS="-g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long " \ RANLIB_FOR_TARGET="i386-uclibc-ranlib" \ RANLIB_TEST_FOR_TARGET="[ -f i386-uclibc-ranlib ] || ( [ "i586-pc-linux-gnu" = "i386-pc-linux-gnu" ] && [ -f /usr/bin/ranlib -o -f /bin/ranlib ] )" \ NM_FOR_TARGET="/home/packages/buildroot/build_i386/staging_dir/i386-linux/bin/nm" AWK="gawk" \ LIBGCC2_CFLAGS="-O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc" \ INCLUDES="-I. -I. -I/home/packages/buildroot/toolchain_build_i386/gcc-3.3/gcc -I/home/packages/buildroot/toolchain_build_i386/gcc-3.3/gcc/. -I/home/packages/buildroot/toolchain_build_i386/gcc-3.3/gcc/config -I/home/packages/buildroot/toolchain_build_i386/gcc-3.3/gcc/../include" \ CONFIG_H="tconfig.h " MACHMODE_H="machmode.h machmode.def /home/packages/buildroot/toolchain_build_i386/gcc-3.3/gcc/config/i386/i386-modes.def" \ LIB1ASMSRC='' \ MAKEOVERRIDES= \ -f libgcc.mk all make[3]: Entering directory `/home/packages/buildroot/toolchain_build_i386/gcc-final/gcc' for d in libgcc; do \ if [ -d $d ]; then true; else /bin/sh /home/packages/buildroot/toolchain_build_i386/gcc-3.3/gcc/mkinstalldirs $d; fi; \ done if [ -f stmp-dirs ]; then true; else touch stmp-dirs; fi make[3]: Leaving directory `/home/packages/buildroot/toolchain_build_i386/gcc-final/gcc' (SHLIB_LINK='/home/packages/buildroot/toolchain_build_i386/gcc-final/gcc/xgcc -B/home/packages/buildroot/toolchain_build_i386/gcc-final/gcc/ -B/home/packages/buildroot/build_i386/staging_dir/i386-linux/bin/ -B/home/packages/buildroot/build_i386/staging_dir/i386-linux/lib/ -isystem /home/packages/buildroot/build_i386/staging_dir/i386-linux/include -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -shared -nodefaultlibs -Wl,--soname=@shlib_so_name@.so.0.9.9 -Wl,--version-script=@shlib_map_file@ -o @shlib_dir@@shlib_so_name@.so.0.9.9 @multilib_flags@ @shlib_objs@ -lc && rm -f @shlib_base_name@.so && ln -s @shlib_dir@@shlib_so_name@.so.0.9.9 @shlib_base_name@.so' \ SHLIB_MULTILIB=''; \ gcc -c -g -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -DHAVE_CONFIG_H -DSTANDARD_STARTFILE_PREFIX=\"../../../\" -DSTANDARD_EXEC_PREFIX=\"/home/packages/buildroot/build_i386/staging_dir/lib/gcc-lib/\" -DDEFAULT_TARGET_VERSION=\"3.3\" -DDEFAULT_TARGET_MACHINE=\"i386-linux\" -DSTANDARD_BINDIR_PREFIX=\"/home/packages/buildroot/build_i386/staging_dir/bin/\" -DTOOLDIR_BASE_PREFIX=\"../../../../\" `test "X${SHLIB_LINK}" = "X" || test "yes" != "yes" || echo "-DENABLE_SHARED_LIBGCC"` `test "X${SHLIB_MULTILIB}" = "X" || echo "-DNO_SHARED_LIBGCC_MULTILIB"` \ -I. -I. -I/home/packages/buildroot/toolchain_build_i386/gcc-3.3/gcc -I/home/packages/buildroot/toolchain_build_i386/gcc-3.3/gcc/. -I/home/packages/buildroot/toolchain_build_i386/gcc-3.3/gcc/config -I/home/packages/buildroot/toolchain_build_i386/gcc-3.3/gcc/../include /home/packages/buildroot/toolchain_build_i386/gcc-3.3/gcc/cp/g++spec.c) cc1: unrecognized option `-auxbase' cc1: output filename specified twice make[2]: *** [g++spec.o] Error 1 make[2]: Leaving directory `/home/packages/buildroot/toolchain_build_i386/gcc-final/gcc' make[1]: *** [all-gcc] Error 2 make[1]: Leaving directory `/home/packages/buildroot/toolchain_build_i386/gcc-final' make: *** [/home/packages/buildroot/toolchain_build_i386/gcc-final/.compiled] Error 2 From werkt at csh.rit.edu Tue Jul 22 01:43:39 2003 From: werkt at csh.rit.edu (George Gensure) Date: Mon Jul 21 22:45:46 2003 Subject: [uClibc] libstdc++ Message-ID: <3F1CC0FB.4020302@csh.rit.edu> I've seen hints and snatches of recommendations for this, but can anyone tell me exactly the config options and sources needed to build libstdc++ under uclibc? I've had no success even getting libstdc++ to build within the gcc sources. Anyone have any suggestions? -George From rmcmullen at broadq.com Tue Jul 22 01:33:41 2003 From: rmcmullen at broadq.com (Rob McMullen) Date: Mon Jul 21 23:02:59 2003 Subject: [uClibc] TinyX with Xfree 4.3 In-Reply-To: <3F1314AB.5090502@orestad-linux.se> References: <3F1314AB.5090502@orestad-linux.se> Message-ID: With uClibc-0.9.20, I got XFree 4.3 working with no changes to its source code. I am using the ebuild scripts from a Gentoo install, so I can't help with .mk file, but... Here's my xc/config/cf/host.def if it helps. It assumes you have freetype and other stuff installed, so you'll have to do some commenting out of stuff... Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: host.def Type: application/octet-stream Size: 4915 bytes Desc: not available Url : http://uclibc.org/lists/uclibc/attachments/20030722/48a83067/host.obj -------------- next part -------------- At Mon, 14 Jul 2003 22:38:03 +0200, Fredrik Johnsson wrote: > > Hi! > > A while back some guys said they had tried Xfree86 4.3 without much success. > > Now i've been occupied with other things and haven't really followed the > mailing list and can't seem to find any more info. > > Has the possibillity for compiling TinyX changed or is to keep on with > Xfree86 4.2? > > > > / Fredrik Johnsson > > > _______________________________________________ > uClibc mailing list > uClibc@uclibc.org > http://uclibc.org/mailman/listinfo/uclibc > From andersen at codepoet.org Tue Jul 22 00:03:45 2003 From: andersen at codepoet.org (Erik Andersen) Date: Mon Jul 21 23:03:54 2003 Subject: [uClibc] libstdc++ In-Reply-To: <3F1CC0FB.4020302@csh.rit.edu> References: <3F1CC0FB.4020302@csh.rit.edu> Message-ID: <20030722050345.GA26526@codepoet.org> On Tue Jul 22, 2003 at 12:43:39AM -0400, George Gensure wrote: > I've seen hints and snatches of recommendations for this, but can anyone > tell me exactly the config options and sources needed to build libstdc++ > under uclibc? I've had no success even getting libstdc++ to build > within the gcc sources. Anyone have any suggestions? http://uclibc.org/cgi-bin/cvsweb/toolchain/ -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- From jsun at junsun.net Wed Jul 23 11:24:52 2003 From: jsun at junsun.net (Jun Sun) Date: Wed Jul 23 11:24:23 2003 Subject: [uClibc] size difference between uclibc and glibc Message-ID: <20030723172452.GB6588@gateway.junsun.net> Can someone give an idea on what size difference it gives if I switch to use uclibc instead of glibc? Also, probably a dumb question, the applications should have the same size no matter what C library you are using, correct? If the later is true, it seems if your system has more applications then one would have less movtivation to use uclibc. Size reduction seems to be the most bragging about point of uclibc. This questions probably should be on FAQ. :) Also, are there other benefits to switch to uclibc? Thanks in advance. Jun From andersen at codepoet.org Wed Jul 23 13:56:14 2003 From: andersen at codepoet.org (Erik Andersen) Date: Wed Jul 23 12:56:27 2003 Subject: [uClibc] size difference between uclibc and glibc In-Reply-To: <20030723172452.GB6588@gateway.junsun.net> References: <20030723172452.GB6588@gateway.junsun.net> Message-ID: <20030723185614.GA12226@codepoet.org> On Wed Jul 23, 2003 at 10:24:52AM -0700, Jun Sun wrote: > > Can someone give an idea on what size difference it gives if I > switch to use uclibc instead of glibc? Also, probably a dumb question, > the applications should have the same size no matter what C library > you are using, correct? There are a number of places where we do not inline functions, or where we use more compact preprocessor defines causing application programs to also be smaller and use less memory. > If the later is true, it seems if your system has more applications then one > would have less movtivation to use uclibc. > > Size reduction seems to be the most bragging about point of uclibc. > This questions probably should be on FAQ. :) Please feel free to provide any additions you think best.... http://uclibc.org/FAQ.html > Also, are there other benefits to switch to uclibc? yes -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- From jsun at junsun.net Wed Jul 23 15:39:03 2003 From: jsun at junsun.net (Jun Sun) Date: Wed Jul 23 15:38:46 2003 Subject: [uClibc] size difference between uclibc and glibc In-Reply-To: <20030723185614.GA12226@codepoet.org> References: <20030723172452.GB6588@gateway.junsun.net> <20030723185614.GA12226@codepoet.org> Message-ID: <20030723213903.GA7338@gateway.junsun.net> On Wed, Jul 23, 2003 at 12:56:14PM -0600, Erik Andersen wrote: > On Wed Jul 23, 2003 at 10:24:52AM -0700, Jun Sun wrote: > > > > Can someone give an idea on what size difference it gives if I > > switch to use uclibc instead of glibc? Also, probably a dumb question, > > the applications should have the same size no matter what C library > > you are using, correct? > > There are a number of places where we do not inline functions, > or where we use more compact preprocessor defines causing > application programs to also be smaller and use less memory. > Thanks. > > If the later is true, it seems if your system has more applications then one > > would have less movtivation to use uclibc. > > > > Size reduction seems to be the most bragging about point of uclibc. > > This questions probably should be on FAQ. :) > > Please feel free to provide any additions you think best.... > http://uclibc.org/FAQ.html > Will do after I get permissions from the people who sent me data. > > Also, are there other benefits to switch to uclibc? > > yes > Care to elaborate more? And yes, I looked at the FAQ and the answer is not there. :) Jun From deanm at earthlink.net Wed Jul 23 19:55:23 2003 From: deanm at earthlink.net (Dean Matsen) Date: Wed Jul 23 19:58:03 2003 Subject: [uClibc] Noted problem with vsnprintf() in 0.9.20 Message-ID: <3F1F3C8B.5090103@earthlink.net> Hope this is not a repeat posting, but I didn't see any search engine to search the archives... In version 0.9.20, I noticed that my telnetd (from netkit-telnet-0.17, using a recent buildroot) server was locking up. The problem, it turns out (I THINK), is that telnetd puts some non-printable characters in the format strings. This causes vsnprintf() to return -1, and ultimately causes telnetd to infinite loop (said loop is obviously intended to wait until the buffer is flushed, not until the vsnprintf call works...). For example, telnetd declares a format string like this: static unsigned char doopt[] = { IAC, DO, '%', 'c', 0 }; and then tries to do char c; vsnprintf ( buffer, maxsize, (char *)doopt, c ); (where IAC = 255 and DO = 253, the offending control characters) For now, I modified the code to use a "%c" and pass the control character as a parameter, ie: vsnprintf ( buffer, maxsize, "%c%c%c", IAC, DO, c ); (which makes more sense anyway, but hey, this is THE telnetd code, right? so who am I to propose that someone fix it?). Anyway, depending on the goals of uClibc, I recommend that vsnprintf NOT fail in this case, since it pertains to a very prominent daemon program! Regards, Dean From mjn3 at codepoet.org Wed Jul 23 22:02:28 2003 From: mjn3 at codepoet.org (Manuel Novoa III) Date: Wed Jul 23 21:02:36 2003 Subject: [uClibc] Noted problem with vsnprintf() in 0.9.20 In-Reply-To: <3F1F3C8B.5090103@earthlink.net> References: <3F1F3C8B.5090103@earthlink.net> Message-ID: <20030724030228.GA15191@codepoet.org> Hello, On Wed, Jul 23, 2003 at 06:55:23PM -0700, Dean Matsen wrote: > Hope this is not a repeat posting, but I didn't see > any search engine to search the archives... Coincidentally, I just posted something on this to the uClinux list. http://mailman.uclinux.org/pipermail/uclinux-dev/2003-July/019647.html > In version 0.9.20, I noticed that my telnetd (from > netkit-telnet-0.17, using a recent buildroot) server was > locking up. > > The problem, it turns out (I THINK), is that telnetd > puts some non-printable characters in the format strings. Yes. See below. > This causes vsnprintf() to return -1, and ultimately > causes telnetd to infinite loop (said loop is obviously > intended to wait until the buffer is flushed, not until > the vsnprintf call works...). Sigh.. No one ever checks return values on *printf()... > For example, telnetd declares a format string like this: > > static unsigned char doopt[] = { IAC, DO, '%', 'c', 0 }; > > and then tries to do > > char c; > > vsnprintf ( buffer, maxsize, (char *)doopt, c ); > > (where IAC = 255 and DO = 253, the offending control > characters) Regarding format strings for the *printf functions, ANSI/ISO C99 standard (and C89 too) states The format shall be a multibyte character sequence, beginning and ending in its initial shift state. This is also true of the format strings for the *scanf and strftime functions. The codeset for the C locale in uClibc is ASCII. Any char with a value outside the range of 0-0x7f is treated as an invalid multibyte sequence since there is no associated wchar_t mapping. This is actually less restrictive than it could be, as ASCII is a superset of the portable C codeset. > For now, I modified the code to use a "%c" and pass the > control character as a parameter, ie: > > vsnprintf ( buffer, maxsize, "%c%c%c", IAC, DO, c ); That's fine. According to the standard, %c and %s simply treat their data as bytes. Multibyte considerations don't come into play. Of course, using vsnprintf to assign 4 bytes in a buffer is pretty inefficient... > (which makes more sense anyway, but hey, this is THE > telnetd code, right? so who am I to propose that someone > fix it?). Why not? It is broken. The restrictions on format strings have been around since C89 at least. Even if uClibc can be configured to not check in the C locale, wouldn't you rather fix it in the app now than have the app mysteriously fail when run in some UTF-8 codeset locale for instance? > Anyway, depending on the goals of uClibc, I recommend > that vsnprintf NOT fail in this case, since it pertains > to a very prominent daemon program! As I mentioned in my post to the uClinux list, I will probably make checking the format string when in the C locale a uClibc configuration option, since there are so many broken programs out there. However, format strings have to be checked in locales using other codesets. So this is just postponing the inevitable fixing of the app itself. I do not intend my code in uClibc to be as 'tolerant' of standards violations as glibc is; at least not be default. Bad format strings are (potential) application _bugs_ and need to be found and fixed. The same could be said for allowing signed chars with negative values to be accepted by the ctype functions. glibc allows this to support 'old broken programs'. In the next uClibc release, such support will be configurable, since by allowing this you can never be sure if the value passed was supposed to be ((unsigned char)(-1)) or -1, which is EOF in most libc implementations. (And yes, I've even considered making the value of EOF configurable... just to see what breaks.) Manuel From deanm at earthlink.net Wed Jul 23 22:17:06 2003 From: deanm at earthlink.net (Dean Matsen) Date: Wed Jul 23 22:14:36 2003 Subject: [uClibc] Noted problem with vsnprintf() in 0.9.20 In-Reply-To: <20030724030228.GA15191@codepoet.org> References: <3F1F3C8B.5090103@earthlink.net> <20030724030228.GA15191@codepoet.org> Message-ID: <3F1F5DC2.1010703@earthlink.net> Manuel Novoa III wrote: >Hello, > >On Wed, Jul 23, 2003 at 06:55:23PM -0700, Dean Matsen wrote: > > >>Hope this is not a repeat posting, but I didn't see >>any search engine to search the archives... >> >> > >Coincidentally, I just posted something on this to the uClinux list. > >http://mailman.uclinux.org/pipermail/uclinux-dev/2003-July/019647.html > > I sent a message to webmaster @ codepoet.net to maybe add a search capability using htdig or something... >As I mentioned in my post to the uClinux list, I will probably make >checking the format string when in the C locale a uClibc configuration >option, since there are so many broken programs out there. However, >format strings have to be checked in locales using other codesets. >So this is just postponing the inevitable fixing of the app itself. > >I do not intend my code in uClibc to be as 'tolerant' of standards >violations as glibc is; at least not be default. Bad format strings >are (potential) application _bugs_ and need to be found and fixed. >The same could be said for allowing signed chars with negative values >to be accepted by the ctype functions. glibc allows this to support >'old broken programs'. In the next uClibc release, such support will >be configurable, since by allowing this you can never be sure if >the value passed was supposed to be ((unsigned char)(-1)) or -1, >which is EOF in most libc implementations. (And yes, I've even >considered making the value of EOF configurable... just to see what >breaks.) > >Manuel > > Ok, well the version of telnetd in question comes from the uClibc buildroot extracted a couple of days ago from the uclibc.org cvsweb server. Specificaly, I went to http://www.uclibc.org/cgi-bin/cvsweb/buildroot/ and then clicked on "download tarball". It seems like the buildroot available from the uclibc.org web server ought to be compatible with uclibc itself, right? I don't keep up on the minutia in the ANSI C standards, but I understand what you mean on the multibyte stuff... So I guess I agree that the telnetd should be changed, not vsnprintf(). I have enclosed a patch to make it easy for any interested source maintainers (I hope this list server allows that -- we'll find out). The patch is to be applied immediately following, and in the same manner as, the existing "netkittelnet.patch" file in buildroot/sources/ . Thanks Dean -------------- next part -------------- A non-text attachment was scrubbed... Name: dm-telnetd-vsnprintf.patch.gz Type: application/x-gzip Size: 548 bytes Desc: not available Url : http://uclibc.org/lists/uclibc/attachments/20030723/96af2e2d/dm-telnetd-vsnprintf.patch.bin From mjn3 at codepoet.org Wed Jul 23 23:23:20 2003 From: mjn3 at codepoet.org (Manuel Novoa III) Date: Wed Jul 23 22:23:28 2003 Subject: [uClibc] Noted problem with vsnprintf() in 0.9.20 In-Reply-To: <3F1F5DC2.1010703@earthlink.net> References: <3F1F3C8B.5090103@earthlink.net> <20030724030228.GA15191@codepoet.org> <3F1F5DC2.1010703@earthlink.net> Message-ID: <20030724042320.GA16171@codepoet.org> On Wed, Jul 23, 2003 at 09:17:06PM -0700, Dean Matsen wrote: > Ok, well the version of telnetd in question comes from the uClibc buildroot > extracted a couple of days ago from the uclibc.org cvsweb server. > Specificaly, > I went to http://www.uclibc.org/cgi-bin/cvsweb/buildroot/ and then clicked > on "download tarball". It seems like the buildroot available from the > uclibc.org web server ought to be compatible with uclibc itself, right? It probably was never caught before because I'm not currently checking the multibyte validity of the format strings unless uClibc is built with wide char support. Manuel From tom at ceisystems.com Thu Jul 24 02:22:19 2003 From: tom at ceisystems.com (tom@ceisystems.com) Date: Wed Jul 23 23:22:56 2003 Subject: [uClibc] Speed issues with Perl/Webmin? Message-ID: <6D31D5429FA6884CBE9ECAB6C9B5E6A907E0A2@intel-srvr.patcameron.ne.mediaone.net> Hello all, I have a half-way on-topic question for everyone. Well, a couple, really. First off, is anyone using Perl & webmin on a uClibc-based system? If so, what is the speed like? I'm seeing the miniserv.pl process taking up almost no CPU, 1.4% of memory, and some extremely slow speeds. I think it has something to do with the caching of images, etc. but I have no real idea. Anyway, when I run this in a chrooted environment on my dev. system, all is well. Well, as well as well could be. As soon as the packages are dropped onto my target machine (Via C3/533), it crawls. Should I be using Perl's malloc functions? What about the PerlIO features, will they gain me any benefits? My second question pertains more to the Perl side of things. What experiences have people had with stripping perl up? I have gone through files removing the the PerlDOC and comment garbage, but that obviously only slims things down so far. Has anyone else found places to cut corners to get the size to a more tollerable level? Thanks for you help, Thomas Cameron CEI Systems, Inc. From andersen at codepoet.org Thu Jul 24 00:52:07 2003 From: andersen at codepoet.org (Erik Andersen) Date: Wed Jul 23 23:52:16 2003 Subject: [uClibc] Noted problem with vsnprintf() in 0.9.20 In-Reply-To: <3F1F5DC2.1010703@earthlink.net> References: <3F1F3C8B.5090103@earthlink.net> <20030724030228.GA15191@codepoet.org> <3F1F5DC2.1010703@earthlink.net> Message-ID: <20030724055206.GA16646@codepoet.org> On Wed Jul 23, 2003 at 09:17:06PM -0700, Dean Matsen wrote: > I sent a message to webmaster @ codepoet.net to maybe add a search > capability > using htdig or something... webmaster@codepoet.org is me. And I find visiting google works rather nicely... :-) I've also added your telnet patch to buildroot. -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- From jsun at junsun.net Thu Jul 24 12:01:21 2003 From: jsun at junsun.net (Jun Sun) Date: Thu Jul 24 12:01:10 2003 Subject: [uClibc] size difference between uclibc and glibc In-Reply-To: <20030723185614.GA12226@codepoet.org> References: <20030723172452.GB6588@gateway.junsun.net> <20030723185614.GA12226@codepoet.org> Message-ID: <20030724180121.GA11952@gateway.junsun.net> On Wed, Jul 23, 2003 at 12:56:14PM -0600, Erik Andersen wrote: > On Wed Jul 23, 2003 at 10:24:52AM -0700, Jun Sun wrote: > > > > Can someone give an idea on what size difference it gives if I > > switch to use uclibc instead of glibc? Also, probably a dumb question, > > the applications should have the same size no matter what C library > > you are using, correct? > > There are a number of places where we do not inline functions, > or where we use more compact preprocessor defines causing > application programs to also be smaller and use less memory. > > > If the later is true, it seems if your system has more applications then one > > would have less movtivation to use uclibc. > > > > Size reduction seems to be the most bragging about point of uclibc. > > This questions probably should be on FAQ. :) > > Please feel free to provide any additions you think best.... > http://uclibc.org/FAQ.html > Here is one item I think should go to FAQ: Q: What is the size difference between uclibc and glibc? A: [Joseph Chiu]"My glibc shared libraries on MIPS total up to about 10.9 MB. (Add another 9 MB for locale support.) uClibc's shared libraries add up to a whopping 608 KB." Different CPU architectures should see different numbers. RISC CPUs should see numbers in about the same range while i386 might numbers a little over half of those. Jun From Amit.Lubovsky at infineon.com Fri Jul 25 03:09:27 2003 From: Amit.Lubovsky at infineon.com (Amit.Lubovsky@infineon.com) Date: Thu Jul 24 18:09:53 2003 Subject: [uClibc] zebra - uClinux Message-ID: Hi, I work with uClinux-dist-20030305 and uClibc-0.9.19 on a custom board with a mips5kc. I have compiled zebra succesfully but couldn't compile vtysh. I have seen that the port doesn't even include the Makefile for this utility. can anyone advise about that ?, Is the readline library working with uClibc ?, and how can you add it ? Thanks, Amit. From thomas.huld at jrc.it Fri Jul 25 10:19:54 2003 From: thomas.huld at jrc.it (Thomas Huld) Date: Fri Jul 25 01:20:34 2003 Subject: [uClibc] A simple uClibc-based system with an old linux kernel? Message-ID: <200307250919.54677.Thomas.Huld@jrc.it> Ciao Tutti, Is there any way of making the uClibc development system (compiled with buildroot) work to produce binaries that will work under an older linux kernel (2.0.3x)? I would like to run such a system on a modern linux machine (2.4.21), but using it to produce a small system with uClibc, busybox and tinylogin running under an old kernel (to save space). I've tried but I have run into problems. An out-of-the-box development system (the downloadable root_fs-i386) produces binaries that don't run at all under linux 2.0.34 (it complains about getcwd() not being implemented). I then tried to substitute all the linux includes in the /usr/include subdirectories with the include files from the 2.0.34 kernel. After a bit of tweaking I could get uClibc, busybox and tinylogin to compile. Then I can actually boot the old linux system and some things work. BUT: the system is somewhat rickety. For instance: when busybox is called with a not-implemented applet name it exits with the error message, but this causes the underlying (busybox) ash shell to crash as well! I've narrowed the problem down to a call to the builtin va_end. Does this mean that it is the compiler that produces code not compatible with linux-2.0.34? I tried to build the toolchain with the older gcc-2.95.x, but the result was the same. In short: HELP!! I would really like to build a very small system based on uClibc and a kernel that doesn't take up too much space. Can it be done in this way? Do I need an even older gcc or something? Alternatively, (this is getting off-topic): does anybody have a link to information about how to pare down a 2.4 kernel to the absolute minimum? TIA Thomas -------------------------------------------------- Thomas Huld Joint Research Centre of the European Commission T.P. 450 I-21023 Ispra, Italy phone: +39 0332785273 e-mail: Thomas.Huld@jrc.it -------------------------------------------------- From tom at ceisystems.com Fri Jul 25 12:56:10 2003 From: tom at ceisystems.com (tom@ceisystems.com) Date: Fri Jul 25 09:56:49 2003 Subject: [uClibc] A simple uClibc-based system with an old linux kernel? Message-ID: <6D31D5429FA6884CBE9ECAB6C9B5E6A907E0A7@intel-srvr.patcameron.ne.mediaone.net> Thomas, There is no longer any support for the 2.0.xx kernel series. Your best bet would be to move to a supported kernel, rather than try to work things back to a point where they operate with that series. Addtionally, there have been many improvements made in the kernel since the 2.0.xx series, so it makes sense to leave it behind anyway. Thomas Cameron CEI Systems, Inc. -----Original Message----- From: Thomas Huld [mailto:thomas.huld@jrc.it] Sent: Friday, July 25, 2003 3:20 AM To: uclibc@uclibc.org Subject: [uClibc] A simple uClibc-based system with an old linux kernel? Ciao Tutti, Is there any way of making the uClibc development system (compiled with buildroot) work to produce binaries that will work under an older linux kernel (2.0.3x)? I would like to run such a system on a modern linux machine (2.4.21), but using it to produce a small system with uClibc, busybox and tinylogin running under an old kernel (to save space). I've tried but I have run into problems. An out-of-the-box development system (the downloadable root_fs-i386) produces binaries that don't run at all under linux 2.0.34 (it complains about getcwd() not being implemented). I then tried to substitute all the linux includes in the /usr/include subdirectories with the include files from the 2.0.34 kernel. After a bit of tweaking I could get uClibc, busybox and tinylogin to compile. Then I can actually boot the old linux system and some things work. BUT: the system is somewhat rickety. For instance: when busybox is called with a not-implemented applet name it exits with the error message, but this causes the underlying (busybox) ash shell to crash as well! I've narrowed the problem down to a call to the builtin va_end. Does this mean that it is the compiler that produces code not compatible with linux-2.0.34? I tried to build the toolchain with the older gcc-2.95.x, but the result was the same. In short: HELP!! I would really like to build a very small system based on uClibc and a kernel that doesn't take up too much space. Can it be done in this way? Do I need an even older gcc or something? Alternatively, (this is getting off-topic): does anybody have a link to information about how to pare down a 2.4 kernel to the absolute minimum? TIA Thomas -------------------------------------------------- Thomas Huld Joint Research Centre of the European Commission T.P. 450 I-21023 Ispra, Italy phone: +39 0332785273 e-mail: Thomas.Huld@jrc.it -------------------------------------------------- _______________________________________________ uClibc mailing list uClibc@uclibc.org http://uclibc.org/mailman/listinfo/uclibc From andersen at codepoet.org Fri Jul 25 14:05:49 2003 From: andersen at codepoet.org (Erik Andersen) Date: Fri Jul 25 13:05:57 2003 Subject: [uClibc] A simple uClibc-based system with an old linux kernel? In-Reply-To: <6D31D5429FA6884CBE9ECAB6C9B5E6A907E0A7@intel-srvr.patcameron.ne.mediaone.net> References: <6D31D5429FA6884CBE9ECAB6C9B5E6A907E0A7@intel-srvr.patcameron.ne.mediaone.net> Message-ID: <20030725190549.GA2709@codepoet.org> On Fri Jul 25, 2003 at 11:56:10AM -0400, tom@ceisystems.com wrote: > Thomas, > > There is no longer any support for the 2.0.xx kernel series. You are referring to busybox 1.0.0-preX, not to uClibc. uClibc plus busybox 0.60.x works just fine for 2.0.x kernels. -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- From weny at promise.com Fri Jul 25 21:20:41 2003 From: weny at promise.com (Wen Yang) Date: Fri Jul 25 21:21:09 2003 Subject: [uClibc] How to compile Toolchain into a Cross Compiler Message-ID: <003a01c35324$e4b23c40$d20aa8c0@ptu.promise.com> Hi, there, I have successfully compiled the Toolchain gcc on i386. However, can I make it a cross-compiler, which runs on i386, but build the binary for another arch, such as PowerPC? Thanks! Wen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://uclibc.org/lists/uclibc/attachments/20030725/11dfa949/attachment.htm From usjaz at yahoo.com Sat Jul 26 18:48:43 2003 From: usjaz at yahoo.com (James Zhu) Date: Sat Jul 26 19:00:47 2003 Subject: [uClibc] dlopen() on libraries depends on other share libs. Message-ID: <20030727004843.61442.qmail@web14404.mail.yahoo.com> Hi, Erik, I use snmpd to dlopen() my own snmp extension in shared library. It always reports libpthread symbols not found. I know libpthread is already loaded before dlopen is called. (showned by linux strace). I saw the following from your 0.9.20 release post: "There is currently one notable exception. Applications that use dlopen() to load libraries that themselves depend on other libraries, may have weak symbols within those depended-upon libraries resolved incorrectly. This problem is currently being worked on. Other than that, everything seems to now be working as expected.... " I think this is my problem. Is there a fix? Thanks so much. -James --------------------------------- Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software -------------- next part -------------- An HTML attachment was scrubbed... URL: http://uclibc.org/lists/uclibc/attachments/20030726/e26a39ca/attachment.htm From seh at zee2.com Sun Jul 27 08:52:19 2003 From: seh at zee2.com (Stuart Hughes) Date: Sun Jul 27 06:55:32 2003 Subject: [uClibc] building toolchain/gcc-3.2.3 for sh Message-ID: <3F23CB03.C705C2F1@zee2.com> Hi everyone, I've been trying to build the uclibc toolchain for sh-linux, this gets a long way, but fails in gcc-final when configuring gcc-final/sh-linux/libiberty: checking for ANSI C header files... no checking for uintptr_t... no checking whether the C compiler (/usr/src/redhat/BUILD/uclibc-tc-1.0/toolchain/gcc-3.2.3/build_sh/gcc-final/gcc/xgcc -B/usr/src/redhat/BUILD/uclibc-tc-1.0/toolchain/gcc-3.2.3/build_sh/gcc-final/gcc/ -B/opt/Embedix/usr/local/uclibc/sh-linux/gcc-3.2.3//sh-linux/bin/ -B/opt/Embedix/usr/local/uclibc/sh-linux/gcc-3.2.3//sh-linux/lib/ -isystem /opt/Embedix/usr/local/uclibc/sh-linux/gcc-3.2.3//sh-linux/include -g -Os ) works... no configure: error: installation or configuration problem: C compiler cannot create executables. make[1]: *** [configure-target-libiberty] Error 1 If you look in config.log you see: configure:2202: checking whether the C compiler (/usr/src/redhat/BUILD/uclibc-tc-1.0/toolchain/gcc-3.2.3/build_sh/gcc-final/gcc/xgcc -B/usr/src/redhat/BUILD/uclibc-tc-1.0/toolchain/gcc-3.2.3/build_sh/gcc-final/gcc/ -B/opt/Embedix/usr/local/uclibc/sh-linux/gcc-3.2.3//sh-linux/bin/ -B/opt/Embedix/usr/local/uclibc/sh-linux/gcc-3.2.3//sh-linux/lib/ -isystem /opt/Embedix/usr/local/uclibc/sh-linux/gcc-3.2.3//sh-linux/include -g -Os ) works configure:2218: /usr/src/redhat/BUILD/uclibc-tc-1.0/toolchain/gcc-3.2.3/build_sh/gcc-final/gcc/xgcc -B/usr/src/redhat/BUILD/uclibc-tc-1.0/toolchain/gcc-3.2.3/build_sh/gcc-final/gcc/ -B/opt/Embedix/usr/local/uclibc/sh-linux/gcc-3.2.3//sh-linux/bin/ -B/opt/Embedix/usr/local/uclibc/sh-linux/gcc-3.2.3//sh-linux/lib/ -isystem /opt/Embedix/usr/local/uclibc/sh-linux/gcc-3.2.3//sh-linux/include -o conftest -g -Os conftest.c 1>&5 /opt/Embedix/usr/local/uclibc/sh-linux/gcc-3.2.3//sh-linux/lib/libc.so: undefined reference to `__sdivsi3_i4' /opt/Embedix/usr/local/uclibc/sh-linux/gcc-3.2.3//sh-linux/lib/libc.so: undefined reference to `__udivsi3_i4' collect2: ld returned 1 exit status configure: failed program was: #line 2213 "configure" #include "confdefs.h" main(){return(0);} Anyone have a fix for this ??? Regards, Stuart From dfoley at techsol.ca Sun Jul 27 19:38:40 2003 From: dfoley at techsol.ca (Dallas Foley) Date: Sun Jul 27 22:39:34 2003 Subject: [uClibc] POSIX timers Message-ID: <3F247EA0.7050704@techsol.ca> Is there an equivalent to POSIX timers (timer_create, timer_delete, timer_getoverrun) in uClibc for ARM ? From cosma_florin at yahoo.com Tue Jul 29 07:06:41 2003 From: cosma_florin at yahoo.com (Cosma Florin) Date: Tue Jul 29 07:07:00 2003 Subject: [uClibc] cosma_florin@yahoo.com Message-ID: <20030729130641.68083.qmail@web21010.mail.yahoo.com> cosma_florin@yahoo.com --------------------------------- Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software -------------- next part -------------- An HTML attachment was scrubbed... URL: http://uclibc.org/lists/uclibc/attachments/20030729/6fb0646d/attachment.htm From andersen at codepoet.org Tue Jul 29 12:53:18 2003 From: andersen at codepoet.org (Erik Andersen) Date: Tue Jul 29 11:53:27 2003 Subject: [uClibc] building toolchain/gcc-3.2.3 for sh In-Reply-To: <3F23CB03.C705C2F1@zee2.com> References: <3F23CB03.C705C2F1@zee2.com> Message-ID: <20030729175318.GA14193@codepoet.org> On Sun Jul 27, 2003 at 07:52:19AM -0500, Stuart Hughes wrote: > /opt/Embedix/usr/local/uclibc/sh-linux/gcc-3.2.3//sh-linux/include -o > conftest -g -Os conftest.c 1>&5 > /opt/Embedix/usr/local/uclibc/sh-linux/gcc-3.2.3//sh-linux/lib/libc.so: > undefined reference to `__sdivsi3_i4' > /opt/Embedix/usr/local/uclibc/sh-linux/gcc-3.2.3//sh-linux/lib/libc.so: > undefined reference to `__udivsi3_i4' > collect2: ld returned 1 exit status > configure: failed program was: > > #line 2213 "configure" > #include "confdefs.h" > > main(){return(0);} > > > Anyone have a fix for this ??? It looks as if libgcc is not getting linked in.... -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- From mdrzazga at ciudad.com.ar Tue Jul 29 16:21:32 2003 From: mdrzazga at ciudad.com.ar (Mariano Drzazga) Date: Tue Jul 29 12:21:57 2003 Subject: RV: [uClibc] upnp-igd compling against uclibc Message-ID: <002901c355fe$3d0c5b60$0204a8c0@citynet2.com> Hi guys! Finally I could get compiled the upnpd sources against uClibc 0.9.20 But, in the last line of the compiler output i get : /usr/lib/gcc-lib/i386-linux/3.3/../../../libstdc++.a(locale.o): In function `std::locale::global(std::locale const&)': /home/andersen/CVS/buildroot/toolchain_build_i386/gcc-final/i386-linux/l ibstdc++-v3/include/bits/basic_string.h:471: the 'setlocale' function supports only C|POSIX locales Could you tell me if this is an error or a warning, and if it can be "workarrounded"? Thanks again for your responses. Mariano -----Mensaje original----- De: Manuel Novoa III [mailto:mjn3@codepoet.org] Enviado el: Martes, 08 de Julio de 2003 18:00 Para: tom@ceisystems.com CC: mad@citynet.net.ar; uclibc@uclibc.org Asunto: Re: [uClibc] upnp-igd compling against uclibc Tom, On Tue, Jul 08, 2003 at 04:45:16PM -0400, tom@ceisystems.com wrote: > Mariano, > I believe it has been posted here that streams are not supported > under uClibc. I do not know if they are in the works for a later > release, or if there is even a desire to get them to work. My > suggestion would be to attempt to statically compile the uPNP > libraries against the standard Glibc, and see where that gets you. You're confusing the STREAMS functions prototyped in strotps.h with standard C++ streams. uClibc doesn't support stropts.h and the associated STREAMS functions. However, a uClibc version of libstd++ (say from buildroot) should support C++ streams. Manuel From mjn3 at codepoet.org Tue Jul 29 13:26:43 2003 From: mjn3 at codepoet.org (Manuel Novoa III) Date: Tue Jul 29 12:26:50 2003 Subject: RV: [uClibc] upnp-igd compling against uclibc In-Reply-To: <002901c355fe$3d0c5b60$0204a8c0@citynet2.com> References: <002901c355fe$3d0c5b60$0204a8c0@citynet2.com> Message-ID: <20030729182643.GA14732@codepoet.org> On Tue, Jul 29, 2003 at 03:21:32PM -0300, Mariano Drzazga wrote: > But, in the last line of the compiler output i get : > > /usr/lib/gcc-lib/i386-linux/3.3/../../../libstdc++.a(locale.o): In > function `std::locale::global(std::locale const&)': > /home/andersen/CVS/buildroot/toolchain_build_i386/gcc-final/i386-linux/l > ibstdc++-v3/include/bits/basic_string.h:471: the 'setlocale' function > supports only C|POSIX locales > > Could you tell me if this is an error or a warning, and if it can be > "workarrounded"? It is a 'link_warning', and is there to remind you that what you were building calls the setlocale() function and that the version of uClibc you are using was built with support for only the C|POSIX locale. You can ignore it... unless you wanted real locale support. Manuel From narendrasankar at yahoo.com Tue Jul 29 13:42:41 2003 From: narendrasankar at yahoo.com (Narendra Sankar) Date: Tue Jul 29 13:42:57 2003 Subject: [uClibc] nfs-utils and getrpcbyname_r Message-ID: <20030729194241.91833.qmail@web80405.mail.yahoo.com> Hi I am trying to build a mipsel uclibc system with nfs-utils. However when building nfs-utils it complains about not able to find getrpcbyname_r. Has anyone looked at implementing this? Or is there any work arounds for nfs-utils - i.e. is there any way to get getprotobyname_r to use /etc/rpc instead of /etc/services Thanks for any help. Naren Sankar From paul.vangool at rinconnetworks.com Tue Jul 29 14:06:38 2003 From: paul.vangool at rinconnetworks.com (Paul van Gool) Date: Tue Jul 29 14:07:04 2003 Subject: [uClibc] i386-uclibc-g++ problem Message-ID: <20030729200638.GA3091@rinconnetworks.com> Hi, I built the i386 toolchain a while ago and ran into a problem with g++. So I rebuilt with the latest bits today but keep having the same problem. This problem does not happen with glibc. The problem has to do with C++ exceptions. The stack is not properly unwound and it leads to a core. My test prog is: #include class CException { public: CException() { } ~CException() { } }; int main(int argc, char* argv[]) { try { throw CException(); } catch(...) { std::cout << "Caught an exception..." << std::endl; } std::cout << "Exiting program..." << std::endl; return 0; } With a glibc toolchain, running this progs gives: Caught an exception... Exiting program... With a uclibc toolchain: Aborted (core dumped) The stack trace is: (gdb) where #0 0x400b66a4 in kill () from /home/vangool/buildroot/build_i386/staging_dir/lib/libc.so.0 #1 0x400b1812 in raise () from /home/vangool/buildroot/build_i386/staging_dir/lib/libc.so.0 #2 0x400b2ff5 in abort () from /home/vangool/buildroot/build_i386/staging_dir/lib/libc.so.0 #3 0x40080935 in uw_init_context_1 (context=0xbfffe07c, outer_cfa=0x0, outer_ra=0x0) at /home/vangool/buildroot/toolchain_build_i386/gcc-3.3/gcc/unwind-dw2.c:1165 #4 0x40080b17 in _Unwind_RaiseException (exc=0x804e030) at /home/vangool/buildroot/toolchain_build_i386/gcc-3.3/gcc/unwind.inc:84 #5 0x40052901 in __cxa_throw (obj=0x804e030, tinfo=0x4006ed84, dest=0x4006ed84 ) at /home/vangool/buildroot/toolchain_build_i386/gcc-3.3/libstdc++-v3/libsupc++/eh_throw.cc:75 #6 0x080487bb in main () #7 0x400941b3 in __uClibc_start_main () from /home/vangool/buildroot/build_i386/staging_dir/lib/libc.so.0 #8 0x08048710 in _start () Line 1165 in unwind-dw2.c of gcc contains: if (uw_frame_state_for (context, &fs) != _URC_NO_REASON) abort (); Basically this means it can't find stack-unwind info for the function. Anybody seen this before and have a fix for it? Thanks. Paul -- Paul van Gool Rincon Networks paul.vangool@rinconnetworks.com (805)-705-1442 From mdrzazga at ciudad.com.ar Tue Jul 29 16:14:51 2003 From: mdrzazga at ciudad.com.ar (Mariano Drzazga) Date: Tue Jul 29 14:32:16 2003 Subject: RV: [uClibc] upnp-igd compling against uclibc Message-ID: <002801c355fd$503ae630$0204a8c0@citynet2.com> Hi guys! Finally I could get compiled the upnpd sources against uClibc 0.9.20 But, in the last line of the compiler output i get : /usr/lib/gcc-lib/i386-linux/3.3/../../../libstdc++.a(locale.o): In function `std::locale::global(std::locale const&)': /home/andersen/CVS/buildroot/toolchain_build_i386/gcc-final/i386-linux/l ibstdc++-v3/include/bits/basic_string.h:471: the 'setlocale' function supports only C|POSIX locales Could you tell me if this is an error or a warning, and if it can be "workarrounded"? Thanks again for your responses. Mariano -----Mensaje original----- De: Manuel Novoa III [mailto:mjn3@codepoet.org] Enviado el: Martes, 08 de Julio de 2003 18:00 Para: tom@ceisystems.com CC: mad@citynet.net.ar; uclibc@uclibc.org Asunto: Re: [uClibc] upnp-igd compling against uclibc Tom, On Tue, Jul 08, 2003 at 04:45:16PM -0400, tom@ceisystems.com wrote: > Mariano, > I believe it has been posted here that streams are not supported > under uClibc. I do not know if they are in the works for a later > release, or if there is even a desire to get them to work. My > suggestion would be to attempt to statically compile the uPNP > libraries against the standard Glibc, and see where that gets you. You're confusing the STREAMS functions prototyped in strotps.h with standard C++ streams. uClibc doesn't support stropts.h and the associated STREAMS functions. However, a uClibc version of libstd++ (say from buildroot) should support C++ streams. Manuel From spr at netxusa.com Tue Jul 29 19:13:25 2003 From: spr at netxusa.com (Sean P. Robertson) Date: Tue Jul 29 16:13:05 2003 Subject: [uClibc] Installation path help Message-ID: <009901c3561e$a1b49580$23c9a8c0@spr> I am chroot'ed into the root_fs-i386. Into that file system, I have placed a directory called BUILD_DIR into which I would like to install uCLibc , the Linux Kernel, BusyBox, and a few other things specific to my app. In other words, absolutely the minimum that I can install to boot the system and launch an app that I am writing. My question is, how do I need to set the following path settings in order to get uCLibc compiled and installed into BUILD_DIR/lib, BUILD_DIR/usr, etc. and insure that it will still work once BUILD_DIR becomes the root of my filesystem via chroot or an actual boot? ($(DEVEL_PREFIX)/lib) Shared library loader path (/usr/$(TARGET_ARCH)-linux-uclibc) uClibc development environment dir ($(DEVEL_PREFIX)) uClibc development environment system directory ($(DEVEL_PREFIX)/usr) uClibc development environment tool directory I read the Help in Menuconfig and checked the FAQ, but I am still concerned that I will either end up installing uCLib into my live filesystem, or, will have compiled the BUILD_DIR path into the uCLibc installation so that it will not work once I chroot to that directory. Could someone point me in the right direction? Thanks, Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: http://uclibc.org/lists/uclibc/attachments/20030729/6fd23c77/attachment.htm From os2doc at bellsouth.net Tue Jul 29 23:40:21 2003 From: os2doc at bellsouth.net (Michael Rowley) Date: Tue Jul 29 20:40:49 2003 Subject: [uClibc] Error: " No space left on device" with root_fs-i386.tar.bz2 Message-ID: <1059532820.26379.4.camel@larafin> Hey, Using the latest root_fs, but I am having some real problems. I apologize if this is stupid... :( I mount the fs with mount -o loop root_fs-i386 /home/michael/root_fs then chroot into it, copy source code for grub to it, but when I try to configure, I get the above error about half way through the configure... Am I missing somthing? I have tried it with different packages, but get the same error. I had assumed that the root_fs was virtual, so would expand with demand.... yeah, I know what happens when you assume ;q but df shows /home/michael/root_fs-i386 149461 98581 50880 66% /home/michael/root_fs this is after ./configure Any advice? Michael os2doc@bellsouth.net From andersen at codepoet.org Wed Jul 30 01:01:21 2003 From: andersen at codepoet.org (Erik Andersen) Date: Wed Jul 30 00:01:31 2003 Subject: [uClibc] Error: " No space left on device" with root_fs-i386.tar.bz2 In-Reply-To: <1059532820.26379.4.camel@larafin> References: <1059532820.26379.4.camel@larafin> Message-ID: <20030730060121.GA19584@codepoet.org> On Tue Jul 29, 2003 at 10:40:21PM -0400, Michael Rowley wrote: > Hey, > > Using the latest root_fs, but I am having some real problems. I > apologize if this is stupid... :( > > I mount the fs with mount -o loop root_fs-i386 /home/michael/root_fs > > then chroot into it, > > copy source code for grub to it, but when I try to configure, I get the > above error about half way through the configure... Am I missing > somthing? This is not a very large filesystem.... So to compile things you really want to have more space.... You might want to dd the filesystem to a spare partition and use 'resize2fs', or you could use mount -o bind to mount part of your root filesystem inside the loop mounted root_fs-i386. -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- From tom at ceisystems.com Wed Jul 30 10:39:53 2003 From: tom at ceisystems.com (tom@ceisystems.com) Date: Wed Jul 30 07:40:12 2003 Subject: [uClibc] Error: " No space left on device" with root_fs-i386.tar.bz2 Message-ID: <6D31D5429FA6884CBE9ECAB6C9B5E6A907E0AB@intel-srvr.patcameron.ne.mediaone.net> Michael, I find that mounting the image, doing a `cp -a` of everything inside it to a directory, and then chrooting to the new directory works much better. The image file is not meant to be a development environment for anything large, and thus will run out of space very quickly. Good luck, Thomas Cameron CEI Systems -----Original Message----- From: Michael Rowley [mailto:os2doc@bellsouth.net] Sent: Tuesday, July 29, 2003 10:40 PM To: uclibc@uclibc.org Subject: [uClibc] Error: " No space left on device" with root_fs-i386.tar.bz2 Hey, Using the latest root_fs, but I am having some real problems. I apologize if this is stupid... :( I mount the fs with mount -o loop root_fs-i386 /home/michael/root_fs then chroot into it, copy source code for grub to it, but when I try to configure, I get the above error about half way through the configure... Am I missing somthing? I have tried it with different packages, but get the same error. I had assumed that the root_fs was virtual, so would expand with demand.... yeah, I know what happens when you assume ;q but df shows /home/michael/root_fs-i386 149461 98581 50880 66% /home/michael/root_fs this is after ./configure Any advice? Michael os2doc@bellsouth.net _______________________________________________ uClibc mailing list uClibc@uclibc.org http://uclibc.org/mailman/listinfo/uclibc From dave-gnus at bfnet.com Wed Jul 30 11:23:25 2003 From: dave-gnus at bfnet.com (David Wuertele) Date: Wed Jul 30 11:45:22 2003 Subject: [uClibc] libstdc++.so.5 gets installed in $(STAGING_DIR)/lib but not $(TARGET_DIR)/lib Message-ID: I'm using the CVS buildroot from July 1 and uClibc 9.20. From the Makefile: ARCH:=mipsel USE_UCLIBC_TOOLCHAIN:=true GCC_2_95_TOOLCHAIN:=false USE_UCLIBC_SNAPSHOT:=false I need the libstdc++.so but it is not getting installed in build_mipsel/root. I tried groking the makefiles but couldn't figure out whether there is some canonical way to do this. I think could just add the installation step in the uclibc.mk file myself, but I figure it must be in there already...Any clues? Dave From dave-gnus at bfnet.com Wed Jul 30 18:33:54 2003 From: dave-gnus at bfnet.com (David Wuertele) Date: Wed Jul 30 18:34:19 2003 Subject: [uClibc] uClibc 9.20 dlopen() "weak symbols?" Message-ID: I have a problem using uClibc 9.20 which I suspect is a result of the behavior mentioned in the release notes: "Applications that use dlopen() to load libraries that themselves depend on other libraries, may have weak symbols within those depended-upon libraries resolved incorrectly. This problem is currently being worked on. Other than that, everything seems to now be working as expected...." Has any progress been made on this? Are there workarounds (for example, by reverting to uClibc 9.19 or older)? FWIW, I have a c++ app that uses dlopen() to load a library that itself depends on a second library. When a global constructor in the first library is called, it calls a function in the second library. When that second library's function tries to use a global variable (also defined in that second library), the process segfaults. When I make a test program that links to the second library directly at compile time using "-lsecondlib", and I call the function that uses the global variable, it does not segfault. Thanks, Dave From mjn3 at codepoet.org Wed Jul 30 20:09:38 2003 From: mjn3 at codepoet.org (Manuel Novoa III) Date: Wed Jul 30 19:09:47 2003 Subject: [uClibc] uClibc 9.20 dlopen() "weak symbols?" In-Reply-To: References: Message-ID: <20030731010937.GA31333@codepoet.org> On Wed, Jul 30, 2003 at 05:33:54PM -0700, David Wuertele wrote: > I have a problem using uClibc 9.20 which I suspect is a result of the > behavior mentioned in the release notes: > > "Applications that use dlopen() to load libraries that themselves > depend on other libraries, may have weak symbols within those > depended-upon libraries resolved incorrectly. This problem is > currently being worked on. Other than that, everything seems to > now be working as expected...." > > Has any progress been made on this? Are there workarounds (for > example, by reverting to uClibc 9.19 or older)? As far as I know, the problem has always existed. I first found it when testing last August prior to the 0.9.15 release. It hasn't been fixed yet, but is on Erik's list. A couple of possible workarounds... 1) Preloading the libs you may dlopen has been reported to work. 2) For the perl thread support shared lib, I explicitly added -lpthread to the link, and that allowed the perl tests to pass. So, if you only had a small number of libs, that might be a possible approach. 3) You could try using the glibc dynamic loader. I haven't tried it in a long time, but we used to use the system dynamic loader prior to the initial ldso port almost 2 years ago. Manuel From weny at promise.com Wed Jul 30 19:21:16 2003 From: weny at promise.com (Wen Yang) Date: Wed Jul 30 19:21:40 2003 Subject: [uClibc] link problem with toolchain gcc 3.2.1 cross compiler for arm Message-ID: Hello, I have a problem using the arm-uclibc-ld linking a simple hello world program. Can anyone help? Thanks a lot! My testing environment is Pentium 4 running linux kernel 2.4.18 What I have done are: 1. get the toolchain gcc 3.2.1 tarball, and make it compile for arm, and without FPU, and install it to /usr/toolchain_arm. I did the following to make it compile: a. in the root Makefile, I changed ARCH=arm USE_UCLIBC_SNAPSHOT=false EXTRA_GCC_CONFIG_OPTION=--with-cpu=xscale --nfp --without-fp (I also tried --with-cpu=xscale only) b. make binutils c. make gcc_initial, after it unzipped the gcc, Ctrl-C to stop it d. manually add -msoft-float through out gcc-3.2.1 and uClibc-0.9.20 for the CFLAGS for target e. enable the MULTILIB as msoft-float f. make 2. write a simple program hello.c #include int main(int argc, char ** argv) { printf("hello world!\n"); return 0; } 3. /usr/toolchain_arm/bin/arm-uclibc-gcc hello.c -c -o hello.o 4. /usr/toolchain_arm/bin/arm-uclibc-ld -L/usr/toolchain_arm/lib -o hello hello.o -lc it reported the following errors: /usr/toolchain_arm/bin/arm-uclibc-ld: warning: cannot find entry symbol _start: defaulting to 000082a8 /usr/toolchain_arm/lib/libc.so: undefined reference to '__eqdf2' /usr/toolchain_arm/lib/libc.so: undefined reference to '__floatsidf' /usr/toolchain_arm/lib/libc.so: undefined reference to '__ltdf2' /usr/toolchain_arm/lib/libc.so: undefined reference to '__udivsi3' /usr/toolchain_arm/lib/libc.so: undefined reference to '__adddf3' /usr/toolchain_arm/lib/libc.so: undefined reference to '__fixdfsi' /usr/toolchain_arm/lib/libc.so: undefined reference to '__umodsi3' /usr/toolchain_arm/lib/libc.so: undefined reference to '__negdf2' /usr/toolchain_arm/lib/libc.so: undefined reference to '__divdf3' /usr/toolchain_arm/lib/libc.so: undefined reference to '__truncdefsf2' /usr/toolchain_arm/lib/libc.so: undefined reference to '__divsi3' /usr/toolchain_arm/lib/libc.so: undefined reference to '__nedf2' /usr/toolchain_arm/lib/libc.so: undefined reference to '__modsi3' /usr/toolchain_arm/lib/libc.so: undefined reference to '__gedf2' /usr/toolchain_arm/lib/libc.so: undefined reference to '__subdf3' Wen From dave-gnus at bfnet.com Wed Jul 30 20:00:29 2003 From: dave-gnus at bfnet.com (David Wuertele) Date: Wed Jul 30 20:01:13 2003 Subject: [uClibc] Re: uClibc 9.20 dlopen() "weak symbols?" References: <20030731010937.GA31333@codepoet.org> Message-ID: Thanks for the quick info, Manuel! Manuel> 1) Preloading the libs you may dlopen has been reported to work. I'll try this one first. Manuel> 2) For the perl thread support shared lib, I explicitly added Manuel> -lpthread to the link, and that allowed the perl tests to Manuel> pass. So, if you only had a small number of libs, that Manuel> might be a possible approach. My understanding was that if there are no calls into the secondary library from the application, linking the application with -lsecondlib won't affect it. Is that not correct? Manuel> 3) You could try using the glibc dynamic loader. I haven't Manuel> tried it in a long time, but we used to use the system Manuel> dynamic loader prior to the initial ldso port almost 2 Manuel> years ago. I'm not sure I understand... Do you mean that instead of installing ld.so from the uClibc toolchain, I install the one from the glibc toolchain instead? Thanks again, Dave From mjn3 at codepoet.org Wed Jul 30 21:39:49 2003 From: mjn3 at codepoet.org (Manuel Novoa III) Date: Wed Jul 30 20:39:58 2003 Subject: [uClibc] Re: uClibc 9.20 dlopen() "weak symbols?" In-Reply-To: References: <20030731010937.GA31333@codepoet.org> Message-ID: <20030731023949.GA32363@codepoet.org> On Wed, Jul 30, 2003 at 07:00:29PM -0700, David Wuertele wrote: > Thanks for the quick info, Manuel! > > Manuel> 1) Preloading the libs you may dlopen has been reported to work. > > I'll try this one first. > > Manuel> 2) For the perl thread support shared lib, I explicitly added > Manuel> -lpthread to the link, and that allowed the perl tests to > Manuel> pass. So, if you only had a small number of libs, that > Manuel> might be a possible approach. > > My understanding was that if there are no calls into the secondary > library from the application, linking the application with -lsecondlib > won't affect it. Is that not correct? Sorry. I wasn't clear. I didn't add -lpthread to the link line of perl. I added it to the link line for the shared object 'threads.so' that perl dynamicly loads. > Manuel> 3) You could try using the glibc dynamic loader. I haven't > Manuel> tried it in a long time, but we used to use the system > Manuel> dynamic loader prior to the initial ldso port almost 2 > Manuel> years ago. > > I'm not sure I understand... Do you mean that instead of installing > ld.so from the uClibc toolchain, I install the one from the glibc > toolchain instead? I guess I'm more tired than I thought. :-) Ignore #3. I was forgetting that we're talking about dlopen. You'd wind up having to port the newer dynamic linker and libdl to uClibc. That would probably be more work than fixing the dlopen bug. Sorry again for the confusion. Manuel From dave-gnus at bfnet.com Thu Jul 31 17:31:40 2003 From: dave-gnus at bfnet.com (David Wuertele) Date: Thu Jul 31 17:32:04 2003 Subject: [uClibc] shm funkiness Message-ID: I am finding bugs in my apps that use shared memory. To troubleshoot, I tried creating one shared memory zone, then run ipcs: sh-2.05b# ipcs ------ Shared Memory Segments -------- key shmid owner perms bytes nattch status 0x410901a9 0 root 666 0 1702132066 ------ Semaphore Arrays -------- key semid owner perms nsems 0x410901ab 0 root 666 923410464 ------ Message Queues -------- key msqid owner perms used-bytes messages sh-2.05b# The nattch and nsems can't be right. How can I troubleshoot this? My theory is that the apps, uClibc, and the kernel are not using the same header files, and have a different definition for struct shmid_ds. Does this sound possible? Can anyone give me some clues about how to determine whether this is the case? Linux: linux-2.4.18+many patches uClibc: 0.9.20 buildroot: CVS snapshot from July 1 Thanks, Dave From dave-gnus at bfnet.com Thu Jul 31 19:22:25 2003 From: dave-gnus at bfnet.com (David Wuertele) Date: Thu Jul 31 19:23:01 2003 Subject: [uClibc] Re: shm funkiness References: Message-ID: To test why my shm apps are funky, I wrote the following test program: #include #include #include #include #include #include int main(int ac, char **av) { key_t key = atoi(av[1]); int id = shmget (key, 0x1000, IPC_CREAT); fprintf (stderr, "id = %d\n", id); getc(stdin); struct shmid_ds shmid_ds; register int retval = shmctl(id, IPC_STAT, &shmid_ds); if (retval == -1) { perror ("shmctl: shmctl failed"); return 1; } else { fprintf (stderr, "\tshm_perm.uid = %d\n", shmid_ds.shm_perm.uid); fprintf (stderr, "\tshm_perm.gid = %d\n", shmid_ds.shm_perm.gid); fprintf (stderr, "\tshm_perm.cuid = %d\n", shmid_ds.shm_perm.cuid); fprintf (stderr, "\tshm_perm.cgid = %d\n", shmid_ds.shm_perm.cgid); fprintf (stderr, "\tshm_perm.mode = %#o\n", shmid_ds.shm_perm.mode); fprintf (stderr, "\tshm_segsz = %d\n", shmid_ds.shm_segsz); fprintf (stderr, "\tshm_lpid = %d\n", shmid_ds.shm_lpid); fprintf (stderr, "\tshm_cpid = %d\n", shmid_ds.shm_cpid); fprintf (stderr, "\tshm_nattch = %d\n", shmid_ds.shm_nattch); fprintf (stderr, "\tshm_atime = %s", shmid_ds.shm_atime ? ctime(&shmid_ds.shm_atime) : "Not Set\n"); fprintf (stderr, "\tshm_dtime = %s", shmid_ds.shm_dtime ? ctime(&shmid_ds.shm_dtime) : "Not Set\n"); fprintf (stderr, "\tshm_ctime = %s", ctime(&shmid_ds.shm_ctime)); } return 0; } I then logged into my embedded uClibc system using two different telnet sessions so that I could run the program (called "dave") and then run ipcs simultaneously: (telnet session 1) sh-2.05b# dave 1234 id = 131072 --- (telnet session 2) sh-2.05b# ipcs ------ Shared Memory Segments -------- key shmid owner perms bytes nattch status 0x000004d2 131072 root 0 0 0 ------ Semaphore Arrays -------- key semid owner perms nsems ------ Message Queues -------- key msqid owner perms used-bytes messages sh-2.05b# Strange... Why is the bytes field zero? It should read 4096. Next I try running the same program in a third session in an attempt to increase the nattch value, then run ipcs again: (telnet session 3) sh-2.05b# dave 1234 id = 131072 --- (back to telnet session 2) sh-2.05b# ipcs ------ Shared Memory Segments -------- key shmid owner perms bytes nattch status 0x000004d2 131072 root 0 0 1702132066 ------ Semaphore Arrays -------- key semid owner perms nsems ------ Message Queues -------- key msqid owner perms used-bytes messages sh-2.05b# Hmm... Now not only is the bytes field wrong, but the nattch field is WAY wrong! What is going on here? Relevant info: Arch: mipsel Linux: linux-2.4.18+many patches uClibc: 0.9.20 buildroot: CVS snapshot from July 1 util-linux: 2.11z Thanks, Dave From dave-gnus at bfnet.com Thu Jul 31 19:51:28 2003 From: dave-gnus at bfnet.com (David Wuertele) Date: Thu Jul 31 19:51:54 2003 Subject: [uClibc] Re: shm funkiness References: Message-ID: Not to make this conversation too one-sided, but I have improved my test program to demonstrate just how broken shm is on my system. The program, "dave.cpp", is included below my signature. The behavior on my RH9.0 development system is as follows: # ./dave 1234 id = 1776222214 shm_perm.uid = 0 shm_perm.gid = 0 shm_perm.cuid = 0 shm_perm.cgid = 0 shm_perm.mode = 0 shm_segsz = 4096 shm_lpid = 0 shm_cpid = 2690 shm_nattch = 0 shm_atime = Not Set shm_dtime = Not Set shm_ctime = Thu Jul 31 18:37:59 2003 Mapping... shm_perm.uid = 0 shm_perm.gid = 0 shm_perm.cuid = 0 shm_perm.cgid = 0 shm_perm.mode = 0 shm_segsz = 4096 shm_lpid = 2690 shm_cpid = 2690 shm_nattch = 1 shm_atime = Thu Jul 31 18:38:28 2003 shm_dtime = Not Set shm_ctime = Thu Jul 31 18:37:59 2003 Unmapping... shm_perm.uid = 0 shm_perm.gid = 0 shm_perm.cuid = 0 shm_perm.cgid = 0 shm_perm.mode = 0 shm_segsz = 4096 shm_lpid = 2690 shm_cpid = 2690 shm_nattch = 1 shm_atime = Thu Jul 31 18:38:33 2003 shm_dtime = Thu Jul 31 18:38:36 2003 shm_ctime = Thu Jul 31 18:37:59 2003 # This looks fine to me. The output from ipcs on my RH system also looks fine. But on my embedded uClibc system, I get what appears to be random numbers in some of the shmid_ds fields: # dave 2345 id = 32769 shm_perm.uid = 0 shm_perm.gid = 0 shm_perm.cuid = 0 shm_perm.cgid = 0 shm_perm.mode = 0 shm_segsz = 0 shm_lpid = -2146102704 shm_cpid = -2146238464 shm_nattch = 718327808 shm_atime = Fri Dec 31 17:02:00 1999 shm_dtime = Wed Dec 31 17:01:03 1969 shm_ctime = Wed Dec 31 17:00:00 1969 Mapping... shm_perm.uid = 0 shm_perm.gid = 0 shm_perm.cuid = 0 shm_perm.cgid = 0 shm_perm.mode = 0 shm_segsz = 0 shm_lpid = -2123924864 shm_cpid = -2123235327 shm_nattch = -2121486784 shm_atime = Fri Dec 31 17:02:00 1999 shm_dtime = Wed Dec 31 17:01:03 1969 shm_ctime = Wed Dec 31 17:01:03 1969 Unmapping... shm_perm.uid = 0 shm_perm.gid = 0 shm_perm.cuid = 0 shm_perm.cgid = 0 shm_perm.mode = 0 shm_segsz = 946685164 shm_lpid = 63488 shm_cpid = -2146303999 shm_nattch = -2114820576 shm_atime = Fri Dec 31 17:02:00 1999 shm_dtime = Wed Dec 31 17:01:03 1969 shm_ctime = Wed Dec 31 17:01:03 1969 # What gives? Has anybody used System V IPC on uClibc? I must be doing something wrong. Any hints? Thanks, Dave /* dave.cpp: demonstrate simple shmget/shmat functionality */ #include #include #include #include #include #include int main(int ac, char **av) { key_t key = atoi(av[1]); int id = shmget (key, 0x1000, IPC_CREAT); fprintf (stderr, "id = %d\n", id); struct shmid_ds shmid_ds; register int retval = shmctl(id, IPC_STAT, &shmid_ds); if (retval == -1) { perror ("shmctl: shmctl failed"); return 1; } else { fprintf (stderr, "\tshm_perm.uid = %d\n", shmid_ds.shm_perm.uid); fprintf (stderr, "\tshm_perm.gid = %d\n", shmid_ds.shm_perm.gid); fprintf (stderr, "\tshm_perm.cuid = %d\n", shmid_ds.shm_perm.cuid); fprintf (stderr, "\tshm_perm.cgid = %d\n", shmid_ds.shm_perm.cgid); fprintf (stderr, "\tshm_perm.mode = %#o\n", shmid_ds.shm_perm.mode); fprintf (stderr, "\tshm_segsz = %d\n", shmid_ds.shm_segsz); fprintf (stderr, "\tshm_lpid = %d\n", shmid_ds.shm_lpid); fprintf (stderr, "\tshm_cpid = %d\n", shmid_ds.shm_cpid); fprintf (stderr, "\tshm_nattch = %d\n", shmid_ds.shm_nattch); fprintf (stderr, "\tshm_atime = %s", shmid_ds.shm_atime ? ctime(&shmid_ds.shm_atime) : "Not Set\n"); fprintf (stderr, "\tshm_dtime = %s", shmid_ds.shm_dtime ? ctime(&shmid_ds.shm_dtime) : "Not Set\n"); fprintf (stderr, "\tshm_ctime = %s", ctime(&shmid_ds.shm_ctime)); } getc(stdin); fprintf (stderr, "Mapping..."); void *myptr = shmat (id, NULL, 0); if (myptr == (void *)-1) { perror ("shmat: shmat failed"); return 1; } retval = shmctl(id, IPC_STAT, &shmid_ds); if (retval == -1) { perror ("shmctl: shmctl failed"); return 1; } else { fprintf (stderr, "\tshm_perm.uid = %d\n", shmid_ds.shm_perm.uid); fprintf (stderr, "\tshm_perm.gid = %d\n", shmid_ds.shm_perm.gid); fprintf (stderr, "\tshm_perm.cuid = %d\n", shmid_ds.shm_perm.cuid); fprintf (stderr, "\tshm_perm.cgid = %d\n", shmid_ds.shm_perm.cgid); fprintf (stderr, "\tshm_perm.mode = %#o\n", shmid_ds.shm_perm.mode); fprintf (stderr, "\tshm_segsz = %d\n", shmid_ds.shm_segsz); fprintf (stderr, "\tshm_lpid = %d\n", shmid_ds.shm_lpid); fprintf (stderr, "\tshm_cpid = %d\n", shmid_ds.shm_cpid); fprintf (stderr, "\tshm_nattch = %d\n", shmid_ds.shm_nattch); fprintf (stderr, "\tshm_atime = %s", shmid_ds.shm_atime ? ctime(&shmid_ds.shm_atime) : "Not Set\n"); fprintf (stderr, "\tshm_dtime = %s", shmid_ds.shm_dtime ? ctime(&shmid_ds.shm_dtime) : "Not Set\n"); fprintf (stderr, "\tshm_ctime = %s", ctime(&shmid_ds.shm_ctime)); } getc(stdin); fprintf (stderr, "Unmapping..."); shmdt (myptr); retval = shmctl(id, IPC_STAT, &shmid_ds); if (retval == -1) { perror ("shmctl: shmctl failed"); return 1; } else { fprintf (stderr, "\tshm_perm.uid = %d\n", shmid_ds.shm_perm.uid); fprintf (stderr, "\tshm_perm.gid = %d\n", shmid_ds.shm_perm.gid); fprintf (stderr, "\tshm_perm.cuid = %d\n", shmid_ds.shm_perm.cuid); fprintf (stderr, "\tshm_perm.cgid = %d\n", shmid_ds.shm_perm.cgid); fprintf (stderr, "\tshm_perm.mode = %#o\n", shmid_ds.shm_perm.mode); fprintf (stderr, "\tshm_segsz = %d\n", shmid_ds.shm_segsz); fprintf (stderr, "\tshm_lpid = %d\n", shmid_ds.shm_lpid); fprintf (stderr, "\tshm_cpid = %d\n", shmid_ds.shm_cpid); fprintf (stderr, "\tshm_nattch = %d\n", shmid_ds.shm_nattch); fprintf (stderr, "\tshm_atime = %s", shmid_ds.shm_atime ? ctime(&shmid_ds.shm_atime) : "Not Set\n"); fprintf (stderr, "\tshm_dtime = %s", shmid_ds.shm_dtime ? ctime(&shmid_ds.shm_dtime) : "Not Set\n"); fprintf (stderr, "\tshm_ctime = %s", ctime(&shmid_ds.shm_ctime)); } getc(stdin); return 0; } From mjn3 at codepoet.org Thu Jul 31 22:05:10 2003 From: mjn3 at codepoet.org (Manuel Novoa III) Date: Thu Jul 31 21:05:17 2003 Subject: [uClibc] Re: shm funkiness In-Reply-To: References: Message-ID: <20030801030510.GA19601@codepoet.org> On Thu, Jul 31, 2003 at 06:51:28PM -0700, David Wuertele wrote: > What gives? Has anybody used System V IPC on uClibc? I must be doing > something wrong. Any hints? Looks like uClibc include/bits/shm.h file was never modified to work after the glibc header import a long time ago. While the uClibc shm* functions just invoke the syscalls directly, glibc adds padding and does field-by-field assignment to preserve binary compatibility in spite of kernel header changes. It will be fixed. Manuel From dave-gnus at bfnet.com Thu Jul 31 22:11:47 2003 From: dave-gnus at bfnet.com (David Wuertele) Date: Thu Jul 31 22:12:11 2003 Subject: [uClibc] Re: shm funkiness References: <20030801030510.GA19601@codepoet.org> Message-ID: Once again it is Manuel to the rescue! Thanks man! Manuel> Looks like uClibc include/bits/shm.h file was never modified Manuel> to work after the glibc header import a long time ago. While Manuel> the uClibc shm* functions just invoke the syscalls directly, Manuel> glibc adds padding and does field-by-field assignment to Manuel> preserve binary compatibility in spite of kernel header Manuel> changes. It will be fixed. Is this something I can fix myself? If it is something basic I'll do it right away. Dave From mjn3 at codepoet.org Thu Jul 31 23:30:31 2003 From: mjn3 at codepoet.org (Manuel Novoa III) Date: Thu Jul 31 22:30:40 2003 Subject: [uClibc] Re: shm funkiness In-Reply-To: References: <20030801030510.GA19601@codepoet.org> Message-ID: <20030801043031.GA20261@codepoet.org> On Thu, Jul 31, 2003 at 09:11:47PM -0700, David Wuertele wrote: > Once again it is Manuel to the rescue! Thanks man! No problem. Thanks for finding it and supplying a test app. > Is this something I can fix myself? If it is something basic I'll do > it right away. I mentioned it to Erik and he was going to look at it. I'd expect it to be fixed in cvs pretty quickly. Actually for some archs, it should be correct. But, if you want to get a fix in now, all you need to do is supply an an appropriate libc/sysdeps/linux/{arch}/bits/shm.h file, with the struct definitions matching that of the kernel. Just remember that the kernel's idea of the size of pid_t, etc. isn't necessarily what uClibc uses. Ideally we need at some point to write some tests to check the offsets and sizes of various fields in both uClibc and the kernel, and flag any differences. That's assuming of course that we don't switch over to the glibc approach. Manuel From andersen at codepoet.org Tue Jul 1 00:52:13 2003 From: andersen at codepoet.org (Erik Andersen) Date: Mon, 30 Jun 2003 18:52:13 -0600 Subject: [uClibc] build failed on big-endian mips and gcc3.3 In-Reply-To: <20030630235449.54754.qmail@web40007.mail.yahoo.com> References: <20030630235449.54754.qmail@web40007.mail.yahoo.com> Message-ID: <20030701005213.GA22360@codepoet.org> On Mon Jun 30, 2003 at 04:54:49PM -0700, Song Wang wrote: > Hi, > > I tried to build uclibc-0.9.19 on big-endian > mips and gcc3.3, I got the following build error [------------snip-----------------] > In file included from ldso.c:159: > mips/boot1_arch.h:6:5: missing terminating " character This problem is fixed in uclibc-0.9.20. -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- From andersen at codepoet.org Tue Jul 1 00:56:33 2003 From: andersen at codepoet.org (Erik Andersen) Date: Mon, 30 Jun 2003 18:56:33 -0600 Subject: [uClibc] uClibc 0.9.20 released Message-ID: <20030701005633.GB22360@codepoet.org> uClibc 0.9.20 released ----------------------------------------------------------- CodePoet Consulting is pleased to announce the immediate availability of uClibc 0.9.20. his is primarily a bug-fix release. This release remains binary compatible with 0.9.18 and 0.9.19 (as long as you leave the new UCLIBC_HAS_TM_EXTENSIONS option disabled), so you don't have to recompile everything if you don't really feel like it. This release has many small improvements. At this point, most applications that compile and work with glibc will also compile and run with uClibc. Perl and Python even pass all the tests in their test suites. There is currently one notable exception. Applications that use dlopen() to load libraries that themselves depend on other libraries, may have weak symbols within those depended-upon libraries resolved incorrectly. This problem is currently being worked on. Other than that, everything seems to now be working as expected.... Updated development system images for x86, arm, powerpc, and mipsel that are compiled with uClibc 0.9.20 have also been released. The dev systems have been updated to include gcc-3.3, and now include perl 5.8.0 as well. As usual, the uClibc 0.9.20 release can be obtained from: http://www.uclibc.org/downloads/uClibc-0.9.20.tar.bz2 The Changelog for this release is here: http://www.uclibc.org/downloads/Changelog http://www.uclibc.org/downloads/Changelog.full -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- From rinnes at integraonline.com Tue Jul 1 01:17:18 2003 From: rinnes at integraonline.com (bob) Date: Mon, 30 Jun 2003 20:17:18 -0500 Subject: [uClibc] At the risk of sounding ungratious ... Message-ID: <000e01c33f6e$85047480$3201a8c0@xpupstairs> First, congrats on the release, I know it must take an enormous amount of time and effort. I am grateful for all the hard work. Now, the ungratious part :-). Does this mean I could cross compile python or perl to an arm platform or have you not gone that far as of yet? - Bob From seh at zee2.com Tue Jul 1 07:16:48 2003 From: seh at zee2.com (Stuart Hughes) Date: Tue, 01 Jul 2003 08:16:48 +0100 Subject: [uClibc]busybox ps garbled characters References: Message-ID: <3F013560.7C687520@zee2.com> Hi All, Turns out the problem was indeed my fault, I'd inadvertently linked against one library and ran against another. This was due to my build setup which (sometimes) uses GCC_EXEC_PREFIX to modify where gcc looks for headers and libs (some things were in the wrong place). Thanks to everyone for their help. Regards, Stuart joe at cityofsanmateo.org wrote: > > i dont know if its the same problem but i ran into a broken ps when i had mismatched > libraries, ie i only replaced uClibc.so with a newer one and left the others the same > i fixed it by moving over a complete set of freshly compiled libs > > i hope this helps > > --joe > > Stuart Hughes > Sent by: uclibc-bounces at uclibc.org ??? T:? > > 06/20/2003 07:53 AM P?????X???????? ??d?? true" onMouseOut="window.status=''" PRIVATE> > > > > Hi all, > > I get garbled characters when I run ps (busybox) with uclibc: > > # > ps > PID Uid Stat > Command > 1 root S . > ..o* > 2 _??+ S From siim at pld.ttu.ee Tue Jul 1 14:11:19 2003 From: siim at pld.ttu.ee (Siim Vahtre) Date: Tue, 1 Jul 2003 17:11:19 +0300 (EET DST) Subject: [uClibc] uClibc 0.9.20 released In-Reply-To: <20030701005633.GB22360@codepoet.org> References: <20030701005633.GB22360@codepoet.org> Message-ID: On Mon, 30 Jun 2003, Erik Andersen wrote: > uClibc 0.9.20 released Hi. A small typo: Webpage "http://www.uclibc.org/" shows news "30 June 2003, uClibc 0.9.20 Released" and inside the announcement there is link to download "source code for this release" which points to "uClibc-0.9.19.tar.bz2" instead of v0.9.20. From giulioo at pobox.com Tue Jul 1 16:07:41 2003 From: giulioo at pobox.com (Giulio Orsero) Date: Tue, 01 Jul 2003 18:07:41 +0200 Subject: [uClibc] uClibc 0.9.20 released In-Reply-To: <20030701005633.GB22360@codepoet.org> References: <20030701005633.GB22360@codepoet.org> Message-ID: <20030701160741.71923127E6@mail.golden.dom> On Mon, 30 Jun 2003 18:56:33 -0600, Erik Andersen wrote: >uClibc 0.9.20 released I still have _llseek problem on kernel 2.2 See http://www.uclibc.org/lists/uclibc/2003-April/008363.html for details -- giulioo at pobox.com From andersen at codepoet.org Tue Jul 1 17:11:43 2003 From: andersen at codepoet.org (Erik Andersen) Date: Tue, 1 Jul 2003 11:11:43 -0600 Subject: [uClibc] uClibc 0.9.20 released In-Reply-To: References: <20030701005633.GB22360@codepoet.org> Message-ID: <20030701171143.GA30600@codepoet.org> On Tue Jul 01, 2003 at 05:11:19PM +0300, Siim Vahtre wrote: > On Mon, 30 Jun 2003, Erik Andersen wrote: > > > uClibc 0.9.20 released > > Hi. > > A small typo: > > Webpage "http://www.uclibc.org/" shows news "30 June 2003, > uClibc 0.9.20 Released" and inside the announcement there > is link to download "source code for this release" which > points to "uClibc-0.9.19.tar.bz2" instead of v0.9.20. Thanks. The danger of cut and paste.... Fixed now, -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- From dave-gnus at bfnet.com Tue Jul 1 18:40:05 2003 From: dave-gnus at bfnet.com (David Wuertele) Date: Tue, 01 Jul 2003 11:40:05 -0700 Subject: [uClibc] syslimits.h: no include path in which to find limits.h Message-ID: When I use buildroot to build a mipsel toolchan and root fs, everything compiles fine until I get to gcc_target: /home/dave/C/perforce/source/deschutes/buildroot-M14.0-X225/build_mipsel/staging_dir/bin/mipsel-uclibc-gcc -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -isystem ./include -I. -I. -I/home/dave/C/perforce/source/deschutes/buildroot-M14.0-X225/toolchain_build_mipsel/gcc-3.2.3/gcc -I/home/dave/C/perforce/source/deschutes/buildroot-M14.0-X225/toolchain_build_mipsel/gcc-3.2.3/gcc/. -I/home/dave/C/perforce/source/deschutes/buildroot-M14.0-X225/toolchain_build_mipsel/gcc-3.2.3/gcc/config -I/home/dave/C/perforce/source/deschutes/buildroot-M14.0-X225/toolchain_build_mipsel/gcc-3.2.3/gcc/../include -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions \ -c /home/dave/C/perforce/source/deschutes/buildroot-M14.0-X225/toolchain_build_mipsel/gcc-3.2.3/gcc/crtstuff.c -DCRT_BEGIN \ -o crtbegin.o In file included from include/limits.h:11, from /home/dave/C/perforce/source/deschutes/buildroot-M14.0-X225/toolchain_build_mipsel/gcc-3.2.3/gcc/tsystem.h:84, from /home/dave/C/perforce/source/deschutes/buildroot-M14.0-X225/toolchain_build_mipsel/gcc-3.2.3/gcc/crtstuff.c:62: /home/dave/C/perforce/source/deschutes/buildroot-M14.0-X225/build_mipsel/staging_dir/lib/gcc-lib/mipsel-linux/3.2.3/include/syslimits.h:7:25: no include path in which to find limits.h /home/dave/C/perforce/source/deschutes/buildroot-M14.0-X225/toolchain_build_mipsel/gcc-3.2.3/gcc/crtstuff.c:195: warning: `__EH_FRAME_BEGIN__' defined but not used make[2]: *** [crtbegin.o] Error 1 make[2]: Leaving directory `/home/dave/C/perforce/source/deschutes/buildroot-M14.0-X225/build_mipsel/gcc-target/gcc' make[1]: *** [all-gcc] Error 2 make[1]: Leaving directory `/home/dave/C/perforce/source/deschutes/buildroot-M14.0-X225/build_mipsel/gcc-target' make: *** [/home/dave/C/perforce/source/deschutes/buildroot-M14.0-X225/build_mipsel/gcc-target/.compiled] Error 2 I have made sure that my gcc versions are the same in the uclibc_toolchain.mk file and in the gcc_target.mk file. Both are using gcc-3.2.3. I have Surfed The Fine Web, and I've found mention of this problem before, but not in the same context. The best advice I found was to make sure the toolchain gcc version matched the target gcc version, which I have already done. Does anyone in buildroot land have a solution to this one? Thanks, Dave From sm5iuf at telia.com Tue Jul 1 19:37:17 2003 From: sm5iuf at telia.com (Gunnar Isaksson) Date: Tue, 1 Jul 2003 21:37:17 +0200 Subject: [uClibc] uClibc compiler wrapper and the Makefile based toolchain gives different result Message-ID: <200307012137.17274.sm5iuf@telia.com> Dear Sirs, I have used the uClibc compiler wrappers with good results and got a a very small Linux image with uClibc, Busybox, Tinylogin, inetd, telnetd ... The kernel is patched with Ingo Molnars O(1) patches, preemptive and lowlatency in order to get soft realtime properties. This will go into a test aircraft for experimenting with navigation algorithms. (Purely for research) The problem: When I use the Makefile based toolchain and compile everything the Linux image builds without a hitch. However telnetd no longer works. Busybox works ok though. The problems seems to have something to do with the networking stuff. I have scripts to make my compilations and the only difference is that I in the first case use the compiler wrapper and in the second case the makefile based toolchain for gcc-3.3. I've also tried gcc-3.2.x with the same result. I get the same behaivour on Slackware-9.0 as well as Mandrake-9.1. It looks like uClibc behaives differently used as a wrapper compared to beeing used in the toolchain. I would rather use the toolchain since this gives me a real crosscompiler and I will not have to consider what Linux distro I'm using. I would appreciate any pointers that could resolve this issue. //Gunnar Isaksson PS I work for the Swedish company Saab Bofors Dynamics. The company is rather diversified but it's main products are missiles or technologies associated closely with missiles. We also have research contracts in diversified areas and I myself work with with these. It's not like we will use Linux in some smart weapons. Linux and uClinux is just very convinient when doing research and collecting data from flight tests. DS From dpforos at yahoo.com Tue Jul 1 19:42:54 2003 From: dpforos at yahoo.com (Daniel Pezoa) Date: Tue, 1 Jul 2003 12:42:54 -0700 (PDT) Subject: [uClibc] uClibc Mozilla Message-ID: <20030701194254.5254.qmail@web11207.mail.yahoo.com> Hello uClibc Community I'am new to Uclibc. I want to compile mozilla for the use in a Freevix, one small linux distribution booteable from network, wich is compiled with uClibc. My first problem is, i don't found all the info needed for setting my uClibc development environment, i try the following: 1) I download the file: http://www.uclibc.org/downloads/uClibc-0.9.19.tar.gz 2) I run the command: make menuconfig /* And select some options that i don't remember */ make clean make make install /* All that work ok */ 3) To compile programs with uClibc, i run: export PATH=/usr/i386-linux-uclibc/bin:$PATH and then just run './configure' and 'make' as usual. Is that the right way to compile with uClibc, i think some other settings are needed to compile for uClibc environment. Your comments, url, ... are welcome, because i need your help. My second attempt is really very different, i download that file: http://www.uclibc.org/downloads/root_fs-i386.bz2 Next i don't found the info about what to make with it, i search in many places, an my steps are ... : bzip2 -d root_fs-i386.bz2 mkdir mnt // for mount the filesystem // For resize the file system e2fsck -f root_fs-i386 resize2fs root_fs-i386 2500000 // Now the size is ok to add mozilla :-) mount -o loop root_fs-i386 mnt // I copy and extract mozilla sourcecode chroot mnt I don't know if i need more to work with my uClibc environment, some environment variables, modify some files or run some another commands, your experience and comments are welcome :-) I don't set any environment variable and run any nother command after the chroot mnt. If i need to do some changes please let me know it. I go to mozilla directory and attempt to configure with ./configure it require perl, and i add the perl uClibc compiled found in the freevix distribution. (perl ok). Now i need gtk, and gtk require glib, atk, pango, and glib require pkgconfig (it compile ok) and require iconv() implementation i attempt to compile libiconv-1.8 ./configure // I think it run ok make // It send one error The last lines of the output are: make[1]: Entering directory `/libiconv-1.8/src' /bin/sh ../libtool --mode=link gcc iconv_no_i18n.o ../lib/libiconv.la -o iconv_no_i18n gcc iconv_no_i18n.o -o .libs/iconv_no_i18n ../lib/.libs/libiconv.so -Wl,--rpath -Wl,/usr/local/lib iconv_no_i18n.o: In function `main': /libiconv-1.8/src/iconv.c:247: the 'setlocale' function supports only C|POSIX locales ../lib/.libs/libiconv.so: undefined reference to `_IO_getc' collect2: ld returned 1 exit status make[1]: *** [iconv_no_i18n] Error 1 make[1]: Leaving directory `/libiconv-1.8/src' make: *** [all] Error 2 [root at tvmovil libiconv-1.8]# I appreciate your comments, sugestion, please don't be brief in your responses, i'am very new to that uClibc world and need to understand it. Good luck and my congratulations for your work, to the uClibc community! Daniel Pezoa __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com From uclibc at lacklustre.net Tue Jul 1 23:40:37 2003 From: uclibc at lacklustre.net (Michael Ryan) Date: Tue, 01 Jul 2003 16:40:37 -0700 Subject: [uClibc] Problems with IO.so in perl Message-ID: <20030701164037.6288dd26.uclibc@lacklustre.net> Greetings, I'm brand new to the list, but I've been using uClibc for a while. I've been trying to get perl to compile, and after finally getting it to [using the buildroot scripts], it seems that IO.so has some unresolved symbols. I figured this must have been a problem with my personal compilation, but I downloaded the new rootfs image to-day and it seems to have the same problem. I also tried to execute ldd on the shared object in question and it seems to be compiled statically, while on my workstation [also Perl 5.8.0], it is dynamically linked to glibc 2.3.1. My workstation is running Debian Unstable, by the way. Here's a transcript: [root at moonbeam root]# perl -mIO::Socket perl: symbol 'Perl_croak': can't resolve symbol [repeat 15 more times] perl: symbol 'Perl_PerlIO_fileno': can't resolve symbol [repeat 3 more times] perl: symbol 'PL_markstack_ptr': can't resolve symbol [repeat 29 more times] perl: symbol 'PL_stack_base': can't resolve symbol [repeat 54 more times] perl: symbol 'PL_stack_sp': can't resolve symbol [repeat 29 more times] perl: symbol 'Perl_sv_2io': can't resolve symbol [repeat 10 more times] perl: symbol 'Perl_newSV': can't resolve symbol [repeat once] perl: symbol 'Perl_sv_2mortal': can't resolve symbol [repeat 3 more times] perl: symbol 'PerlIO_getpos': can't resolve symbol perl: symbol 'PL_sv_undef': can't resolve symbol [repeat 4 more times] perl: symbol 'PerlIO_setpos': can't resolve symbol perl: symbol 'Perl_sv_newmortal': can't resolve symbol [repeat 8 more times] perl: symbol 'Perl_sv_setpvn': can't resolve symbol [repeat 4 more times] perl: symbol 'Perl_sv_setiv': can't resolve symbol [repeat 10 more times] perl: symbol 'PerlIO_tmpfile': can't resolve symbol perl: symbol 'Perl_newGVgen': can't resolve symbol perl: symbol 'Perl_hv_delete': can't resolve symbol perl: symbol 'Perl_do_open': can't resolve symbol perl: symbol 'Perl_newRV': can't resolve symbol perl: symbol 'Perl_gv_stashpv': can't resolve symbol perl: symbol 'Perl_sv_bless': can't resolve symbol perl: symbol 'Perl_sv_free': can't resolve symbol [repeat once] perl: symbol 'Perl_sv_2pv_nolen': can't resolve symbol perl: symbol 'Perl_newSViv': can't resolve symbol [repeat 13 more times] perl: symbol 'Perl_sv_2iv': can't resolve symbol [repeat 4 more times] perl: symbol 'PL_op': can't resolve symbol [repeat 3 more times] perl: symbol 'PL_curpad': can't resolve symbol [repeat 3 more times] perl: symbol 'PerlIO_ungetc': can't resolve symbol [repeat 4 more times] perl: symbol 'Perl_PerlIO_error': can't resolve symbol perl: symbol 'Perl_PerlIO_clearerr': can't resolve symbol perl: symbol 'Perl_PerlIO_flush': can't resolve symbol perl: symbol 'Perl_newXS': can't resolve symbol [repeat 13 more times] perl: symbol 'Perl_sv_setpv': can't resolve symbol [repeat once] perl: symbol 'Perl_gv_stashpvn': can't resolve symbol [repeat once] perl: symbol 'Perl_newCONSTSUB': can't resolve symbol [repeat 11 more times] perl: symbol 'PL_sv_yes': can't resolve symbol perl: symbol 'Perl_sv_2pv_flags': can't resolve symbol [repeat once] perl: symbol 'Perl_form': can't resolve symbol [repeat once] perl: symbol 'Perl_get_sv': can't resolve symbol [repeat once] Can't load '/usr/lib/perl/5.8.0/i386-linux/auto/IO/IO.so' for module IO: Unable to resolve symbol at /usr/lib/perl/5.8.0/i386-linux/XSLoader.pm line 83. at /usr/lib/perl/5.8.0/i386-linux/IO.pm line 9 Compilation failed in require at /usr/lib/perl/5.8.0/i386-linux/IO/Handle.pm line 256. BEGIN failed--compilation aborted at /usr/lib/perl/5.8.0/i386-linux/IO/Handle.pm line 256. Compilation failed in require at /usr/lib/perl/5.8.0/i386-linux/IO/Socket.pm line 11. BEGIN failed--compilation aborted at /usr/lib/perl/5.8.0/i386-linux/IO/Socket.pm line 11. Compilation failed in require. BEGIN failed--compilation aborted. [root at moonbeam root]# ldd /usr/lib/perl/5.8.0/i386-linux/auto/IO/IO.so not a dynamic executable [root at moonbeam root] Any ideas would be greatly appreciated. Thanks. -- Michael Ryan Lacklustre Networking michael at lacklustre.net http://www.lacklustre.net/ -- Michael Ryan Lacklustre Networking michael at lacklustre.net http://www.lacklustre.net/ From Calilonhuang at bj.t2-design.com Wed Jul 2 00:40:51 2003 From: Calilonhuang at bj.t2-design.com (Calilonhuang) Date: Wed, 2 Jul 2003 08:40:51 +0800 Subject: [uClibc] Can ftpd tftpd openssh etc compiled through uclibc ? Message-ID: I want to build one of them under mips using uclibc. I find openssh is listed in working list. But I can't compile it successfully. From h_happy at 263.net Wed Jul 2 02:40:36 2003 From: h_happy at 263.net (Calilon) Date: Wed, 2 Jul 2003 10:40:36 +0800 Subject: [uClibc] Can ftpd tftpd openssh etc compiled through uclibc ? Message-ID: From andersen at codepoet.org Wed Jul 2 03:04:49 2003 From: andersen at codepoet.org (Erik Andersen) Date: Tue, 1 Jul 2003 21:04:49 -0600 Subject: [uClibc] Can ftpd tftpd openssh etc compiled through uclibc ? In-Reply-To: References: Message-ID: <20030702030449.GA4339@codepoet.org> On Wed Jul 02, 2003 at 10:40:36AM +0800, Calilon wrote: > _______________________________________________ > uClibc mailing list > uClibc at uclibc.org > http://uclibc.org/mailman/listinfo/uclibc Thanks for sharing, -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- From andersen at codepoet.org Wed Jul 2 03:21:36 2003 From: andersen at codepoet.org (Erik Andersen) Date: Tue, 1 Jul 2003 21:21:36 -0600 Subject: [uClibc] Can ftpd tftpd openssh etc compiled through uclibc ? In-Reply-To: References: Message-ID: <20030702032136.GB4339@codepoet.org> On Wed Jul 02, 2003 at 08:40:51AM +0800, Calilonhuang wrote: > I want to build one of them under mips using uclibc. > I find openssh is listed in working list. But I can't compile it successfully. It works. I have compiled openssh with uClibc on mips using uClibc 0.9.20. Therefore, since you did not provide a proper problem report, I have to assume you did something wrong. -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- From seh at zee2.com Wed Jul 2 14:50:41 2003 From: seh at zee2.com (Stuart Hughes) Date: Wed, 02 Jul 2003 15:50:41 +0100 Subject: [uClibc] installing more that one toolchain Message-ID: <3F02F141.95A071BE@zee2.com> Greetings, Not sure if I've goofed up here, but I'm trying to install 2 cross compilers (mipsel and powerpc) but I'm finding that the later install overwrites files from the earlier one. This seems to be because /-linux>/lib is a symlink to /lib in the toolchains I've built (from the script on uclibc.org). Is this a known limitation, or did I just mess up on my toolchain build ?? Regards, Stuart From dpforos at yahoo.com Wed Jul 2 14:56:15 2003 From: dpforos at yahoo.com (Daniel Pezoa) Date: Wed, 2 Jul 2003 07:56:15 -0700 (PDT) Subject: [uClibc] help in compile uclibc gtk Message-ID: <20030702145615.21121.qmail@web11202.mail.yahoo.com> Hello I see gtk in the list of what can be compiled with uclibc. But it require glib, pango, atk, pkgconfig, libiconv. And i can't compile libiconv-1.8 It send me that error: ../lib/.libs/libiconv.so: undefined reference to `_IO_getc' collect2: ld returned 1 exit status make[1]: *** [iconv_no_i18n] Error 1 make[1]: Leaving directory `/libiconv-1.8/src' make: *** [all] Error 2 [root at tvmovil libiconv-1.8]# Can you help me with it. I set my root-fs_i386 with this steps: bzip -d root-fs_i386.bz2 mkdir mnt mount -o loop root-fs_i386 mnt chroot mnt then i do ./configure make What is the way to compile gtk, please let me know the steps you use to make it compile, i need that library. Daniel Pezoa __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com From ps.m at gmx.net Wed Jul 2 15:10:08 2003 From: ps.m at gmx.net (Peter S. Mazinger) Date: Wed, 2 Jul 2003 17:10:08 +0200 (CEST) Subject: [uClibc] uClibc-0.9.20 and ldd coredump Message-ID: Hello! The changelog of 0.9.20 says, that the problem with ldd coredumping if ran against non-executables is solved. Attached are the outputs of strace ldd /lib/libc.so.0 (native environment) for: ulimit -c 0 (ldd.0) ulimit -c 128 (ldd.1) I have to mention that I am using a grsecurity enabled kernel (mainly the PaX options - http://pageexec.virtualave.net - are relevant for this case). Although I've got earlier the answer that PaX/grsecurity has problems with uClibc (true for uClibc < 0.9.18, reported by me), I am using grsecurity since uClibc-0.9.19 natively on x86 and there are no problems (only the ones present also on a glibc system ;-). Peter -- Peter S. Mazinger ID: 0xA5F059F2 NIC: IXUYHSKQLI Key fingerprint = 92A4 31E1 56BC 3D5A 2D08 BB6E C389 975E A5F0 59F2 -------------- next part -------------- execve("/usr/bin/ldd", ["ldd", "/lib/libc.so.0"], [/* 18 vars */]) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0) = 0x246ee000 readlink("/lib/ld-uClibc.so.0", "ld-uClibc-0.9.20.so", 1024) = 19 open("/lib/libc.so.0", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\240\345"..., 4096) = 4096 old_mmap(NULL, 278528, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x246ef000 old_mmap(0x246ef000, 256583, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x246ef000 old_mmap(0x2472e000, 7564, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x3e000) = 0x2472e000 old_mmap(0x24730000, 11692, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x24730000 close(3) = 0 ioctl(0, SNDCTL_TMR_TIMEBASE, {B38400 opost isig icanon echo ...}) = 0 ioctl(1, SNDCTL_TMR_TIMEBASE, {B38400 opost isig icanon echo ...}) = 0 brk(0x804d924) = 0x804d924 brk(0x804e000) = 0x804e000 brk(0x804f000) = 0x804f000 brk(0x8050000) = 0x8050000 open("/lib/libc.so.0", O_RDONLY) = 3 ioctl(3, SNDCTL_TMR_TIMEBASE, 0x58b4f878) = -1 ENOTTY (Inappropriate ioctl for device) fstat(3, {st_mode=S_IFREG|0755, st_size=263084, ...}) = 0 old_mmap(NULL, 263084, PROT_READ|PROT_WRITE, MAP_PRIVATE, 3, 0) = 0x24733000 brk(0x8051000) = 0x8051000 brk(0x8052000) = 0x8052000 stat("/lib/ld-uClibc.so.0", {st_mode=S_IFREG|0755, st_size=16068, ...}) = 0 fork() = 5188 --- SIGCHLD (Child exited) --- wait4(5188, [WIFSIGNALED(s) && WTERMSIG(s) == SIGSEGV && WCOREDUMP(s)], 0, NULL) = 5188 _exit(0) = ? -------------- next part -------------- execve("/usr/bin/ldd", ["ldd", "/lib/libc.so.0"], [/* 18 vars */]) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0) = 0x2a630000 readlink("/lib/ld-uClibc.so.0", "ld-uClibc-0.9.20.so", 1024) = 19 open("/lib/libc.so.0", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\240\345"..., 4096) = 4096 old_mmap(NULL, 278528, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2a631000 old_mmap(0x2a631000, 256583, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x2a631000 old_mmap(0x2a670000, 7564, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x3e000) = 0x2a670000 old_mmap(0x2a672000, 11692, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2a672000 close(3) = 0 ioctl(0, SNDCTL_TMR_TIMEBASE, {B38400 opost isig icanon echo ...}) = 0 ioctl(1, SNDCTL_TMR_TIMEBASE, {B38400 opost isig icanon echo ...}) = 0 brk(0x804d924) = 0x804d924 brk(0x804e000) = 0x804e000 brk(0x804f000) = 0x804f000 brk(0x8050000) = 0x8050000 open("/lib/libc.so.0", O_RDONLY) = 3 ioctl(3, SNDCTL_TMR_TIMEBASE, 0x5cdf11b8) = -1 ENOTTY (Inappropriate ioctl for device) fstat(3, {st_mode=S_IFREG|0755, st_size=263084, ...}) = 0 old_mmap(NULL, 263084, PROT_READ|PROT_WRITE, MAP_PRIVATE, 3, 0) = 0x2a675000 brk(0x8051000) = 0x8051000 brk(0x8052000) = 0x8052000 stat("/lib/ld-uClibc.so.0", {st_mode=S_IFREG|0755, st_size=16068, ...}) = 0 fork() = 5178 --- SIGCHLD (Child exited) --- wait4(5178, [WIFSIGNALED(s) && WTERMSIG(s) == SIGSEGV], 0, NULL) = 5178 _exit(0) = ? From mjn3 at codepoet.org Wed Jul 2 15:57:04 2003 From: mjn3 at codepoet.org (Manuel Novoa III) Date: Wed, 2 Jul 2003 09:57:04 -0600 Subject: [uClibc] uClibc Mozilla In-Reply-To: <20030701194254.5254.qmail@web11207.mail.yahoo.com> References: <20030701194254.5254.qmail@web11207.mail.yahoo.com> Message-ID: <20030702155704.GA10257@codepoet.org> On Tue, Jul 01, 2003 at 12:42:54PM -0700, Daniel Pezoa wrote: > I'am new to Uclibc. > > I want to compile mozilla for the use in a Freevix, > one small linux distribution booteable from network, > wich is compiled with uClibc. If you are new to uClibc, then you _might_ want to try something less ambitious than building mozilla and all the necessary dependencies. > i attempt to compile libiconv-1.8 > > ./configure // I think it run ok > make // It send one error > > The last lines of the output are: > > make[1]: Entering directory `/libiconv-1.8/src' > /bin/sh ../libtool --mode=link gcc iconv_no_i18n.o > ../lib/libiconv.la > -o iconv_no_i18n > gcc iconv_no_i18n.o -o .libs/iconv_no_i18n > ../lib/.libs/libiconv.so > -Wl,--rpath -Wl,/usr/local/lib > iconv_no_i18n.o: In function `main': > /libiconv-1.8/src/iconv.c:247: the 'setlocale' > function supports only > C|POSIX locales > ../lib/.libs/libiconv.so: undefined reference to > `_IO_getc' > collect2: ld returned 1 exit status > make[1]: *** [iconv_no_i18n] Error 1 > make[1]: Leaving directory `/libiconv-1.8/src' > make: *** [all] Error 2 > [root at tvmovil libiconv-1.8]# It looks like somehow you built libiconv using the glibc headers. The _IO_getc function is invoked by the getc macro in glibc, while uClibc has an entirely different stdio implementation. > I appreciate your comments, sugestion, please don't be > brief in your responses, i'am very new to that uClibc > world and need to understand it. Expect to spend a lot of time getting up to speed. Browse the mailing list archives at uclibc.org. Look at Erik's buildroot stuff (there's a link on the uclibc home page) for examples of how to build libraries and applications using uClibc. Manuel From seh at zee2.com Wed Jul 2 16:12:18 2003 From: seh at zee2.com (Stuart Hughes) Date: Wed, 02 Jul 2003 17:12:18 +0100 Subject: [uClibc] time.h Message-ID: <3F030462.279B120A@zee2.com> Greetings, I had a problem with struct tm in time.h when compiling with a c++ compiler (mipsel-uclibc-g++). If a declaration is: struct tm; (uninitialised) The compiler complains and fails: .cpp:line: structure `timeStruct' with uninitialized const members Looking at glibc they have a slight difference. I've attached a patch that changes the uclibc file to be like glibc, and this stops the error. Regards, Stuart -------------- next part -------------- --- time.h.orig Wed Jul 2 16:52:57 2003 +++ time.h Wed Jul 2 16:54:45 2003 @@ -130,10 +130,10 @@ #ifdef __UCLIBC_HAS_TM_EXTENSIONS__ # ifdef __USE_BSD long int tm_gmtoff; /* Seconds east of UTC. */ - __const char tm_zone[8]; /* Timezone abbreviation. */ + __const char *tm_zone; /* Timezone abbreviation. */ # else long int __tm_gmtoff; /* Seconds east of UTC. */ - __const char __tm_zone[8];/* Timezone abbreviation. */ + __const char *__tm_zone; /* Timezone abbreviation. */ # endif #endif /* __UCLIBC_HAS_TM_EXTENSIONS__ */ }; From mjn3 at codepoet.org Wed Jul 2 16:30:55 2003 From: mjn3 at codepoet.org (Manuel Novoa III) Date: Wed, 2 Jul 2003 10:30:55 -0600 Subject: [uClibc] time.h In-Reply-To: <3F030462.279B120A@zee2.com> References: <3F030462.279B120A@zee2.com> Message-ID: <20030702163055.GA10726@codepoet.org> On Wed, Jul 02, 2003 at 05:12:18PM +0100, Stuart Hughes wrote: > Greetings, > > I had a problem with struct tm in time.h when compiling with a c++ > compiler (mipsel-uclibc-g++). > If a declaration is: struct tm; (uninitialised) > > The compiler complains and fails: > > .cpp:line: structure > `timeStruct' with uninitialized const members > > Looking at glibc they have a slight difference. I've attached a patch > that changes the uclibc file to be like glibc, and this stops the error. > > Regards, Stuart > --- time.h.orig Wed Jul 2 16:52:57 2003 > +++ time.h Wed Jul 2 16:54:45 2003 > @@ -130,10 +130,10 @@ > #ifdef __UCLIBC_HAS_TM_EXTENSIONS__ > # ifdef __USE_BSD > long int tm_gmtoff; /* Seconds east of UTC. */ > - __const char tm_zone[8]; /* Timezone abbreviation. */ > + __const char *tm_zone; /* Timezone abbreviation. */ > # else > long int __tm_gmtoff; /* Seconds east of UTC. */ > - __const char __tm_zone[8];/* Timezone abbreviation. */ > + __const char *__tm_zone; /* Timezone abbreviation. */ > # endif > #endif /* __UCLIBC_HAS_TM_EXTENSIONS__ */ > }; Your patch isn't going work, since the uClibc time code expects to store the timezone in the struct itself. You'll wind up with overwrites and invalid memory accesses. I suppose to get around this I'll have to add a seperate data field and initialize a __const char *__tm_zone member to point to the internal data array. I was trying to avoid doing that, and wasn't counting on such nit-picky compilers. Oh well... For the time being, you could try removing the __const qualifier on the tm_zone[8] members. Manuel From geetham at india.hp.com Wed Jul 2 12:58:18 2003 From: geetham at india.hp.com (Geetha Manjunath) Date: Wed, 02 Jul 2003 18:28:18 +0530 Subject: [uClibc]python 2.2.2 Message-ID: <3F02D6EA.B04B3E89@india.hp.com> Hello Rob, I am trying to compile Python 2.1 with uclibc... facing linking problems.. I saw your posting on thsi subject. Can you kindly let me know the configure options you used for python and uclibs? I thought may be missing some features.. Or is it something to do with the Python version?? I would appreciate any help here. thanks and regards Geetha PS: These linking problems come in only when i execute python (dynamically linked). some of these are : _dl_nloaded, _dl_profile, __libc_stack_end and so on... From andersen at codepoet.org Wed Jul 2 16:34:12 2003 From: andersen at codepoet.org (Erik Andersen) Date: Wed, 2 Jul 2003 10:34:12 -0600 Subject: [uClibc] installing more that one toolchain In-Reply-To: <3F02F141.95A071BE@zee2.com> References: <3F02F141.95A071BE@zee2.com> Message-ID: <20030702163411.GA11041@codepoet.org> On Wed Jul 02, 2003 at 03:50:41PM +0100, Stuart Hughes wrote: > Greetings, > > Not sure if I've goofed up here, but I'm trying to install 2 cross > compilers (mipsel and powerpc) but I'm finding that the later install > overwrites files from the earlier one. This seems to be because > /-linux>/lib is a symlink to /lib in the > toolchains I've built (from the script on uclibc.org). > > Is this a known limitation, or did I just mess up on my toolchain build > ?? It is very possible I made a mistake. I do that on occasion despite popular opinion to the contrary... Patches to fix the problem are warmly welcome, -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- From andersen at codepoet.org Wed Jul 2 17:07:36 2003 From: andersen at codepoet.org (Erik Andersen) Date: Wed, 2 Jul 2003 11:07:36 -0600 Subject: [uClibc] uClibc-0.9.20 and ldd coredump In-Reply-To: References: Message-ID: <20030702170736.GB11041@codepoet.org> On Wed Jul 02, 2003 at 05:10:08PM +0200, Peter S. Mazinger wrote: > Hello! > > The changelog of 0.9.20 says, that the problem with ldd coredumping > if ran against non-executables is solved. > Attached are the outputs of strace ldd /lib/libc.so.0 (native environment) > for: > ulimit -c 0 (ldd.0) > ulimit -c 128 (ldd.1) > > I have to mention that I am using a grsecurity enabled kernel (mainly the > PaX options - http://pageexec.virtualave.net - are relevant for this > case). > Although I've got earlier the answer that PaX/grsecurity has problems with > uClibc (true for uClibc < 0.9.18, reported by me), I am using grsecurity > since uClibc-0.9.19 natively on x86 and there are no problems (only the > ones present also on a glibc system ;-). You have reported this several times now. Each time with straces of ldd doing its thing. And each time I have looked at the straces and I have not seen any evidence of coredumping or other problems.... Next time, pass the -f option to strace so we can also see what the child process is doing. And perhaps running ltrace (also with the -f option) may provide additional clues.... Anyway, I just took a close look and I think the problem is that I was trying to exec things like shared libraries and such. I just changed ldd to only exec elf type ET_EXEC files. Hopefully that should fix up the problem you are seeing. -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- From dpforos at yahoo.com Wed Jul 2 18:02:42 2003 From: dpforos at yahoo.com (Daniel Pezoa) Date: Wed, 2 Jul 2003 11:02:42 -0700 (PDT) Subject: [uClibc] uClibc Mozilla In-Reply-To: <20030702155704.GA10257@codepoet.org> Message-ID: <20030702180242.35523.qmail@web11203.mail.yahoo.com> Hello Manuel > Look at Erik's > buildroot > stuff (there's a link on the uclibc home page) for > examples of > how to build libraries and applications using > uClibc. Sorry for my bad search features, i can't find that link, i search in the Homepage and FAQ. And if i browse here: http://uclibc.org/cgi-bin/cvsweb/buildroot/ i don't know where to go for the samples, i search but i don't found the samples, if you can post the url of some sample. I will be very happy. I'am confused for the following info, i think the samples can help in solve my problems > It looks like somehow you built libiconv using the > glibc headers. > The _IO_getc function is invoked by the getc macro > in glibc, while > uClibc has an entirely different stdio > implementation. I should make something wrong in my settings causing the attempt of usage of the glibc, can you explain me how you set your root_fs-i386. I make the following. bzip2 -d root_fs-i386.bz2 mkdir mnt e2fsck -f root_fs-i386 // check filesystem resize2fs root_fs-i386 2500000 // resize filesystem mount -o loop root_fs-i386 mnt cp libiconv-1.8.tar.bz2 mnt chroot mnt tar -jxf libiconv-1.8.tar.bz2 cd libiconv-1.8 ./configure make Is that ok, or i need to do another step omitted. I see in some search in google some call ( sh --login ), i don't know if it or another step is required for this. If you find my steps correct please let me know it, otherwise you can rectify it. If i run it with ssh, or inside xwindow, it could affect my results. Thanks for share, your help is very usefull for me. Daniel Pezoa --- Manuel Novoa III wrote: > On Tue, Jul 01, 2003 at 12:42:54PM -0700, Daniel > Pezoa wrote: > > I'am new to Uclibc. > > > > I want to compile mozilla for the use in a > Freevix, > > one small linux distribution booteable from > network, > > wich is compiled with uClibc. > > If you are new to uClibc, then you _might_ want to > try something > less ambitious than building mozilla and all the > necessary > dependencies. > > > i attempt to compile libiconv-1.8 > > > > ./configure // I think it run ok > > make // It send one error > > > > The last lines of the output are: > > > > make[1]: Entering directory `/libiconv-1.8/src' > > /bin/sh ../libtool --mode=link gcc > iconv_no_i18n.o > > ../lib/libiconv.la > > -o iconv_no_i18n > > gcc iconv_no_i18n.o -o .libs/iconv_no_i18n > > ../lib/.libs/libiconv.so > > -Wl,--rpath -Wl,/usr/local/lib > > iconv_no_i18n.o: In function `main': > > /libiconv-1.8/src/iconv.c:247: the 'setlocale' > > function supports only > > C|POSIX locales > > ../lib/.libs/libiconv.so: undefined reference to > > `_IO_getc' > > collect2: ld returned 1 exit status > > make[1]: *** [iconv_no_i18n] Error 1 > > make[1]: Leaving directory `/libiconv-1.8/src' > > make: *** [all] Error 2 > > [root at tvmovil libiconv-1.8]# > > It looks like somehow you built libiconv using the > glibc headers. > The _IO_getc function is invoked by the getc macro > in glibc, while > uClibc has an entirely different stdio > implementation. > > > I appreciate your comments, sugestion, please > don't be > > brief in your responses, i'am very new to that > uClibc > > world and need to understand it. > > Expect to spend a lot of time getting up to speed. > Browse the > mailing list archives at uclibc.org. Look at Erik's > buildroot > stuff (there's a link on the uclibc home page) for > examples of > how to build libraries and applications using > uClibc. > > Manuel __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com From mjn3 at codepoet.org Wed Jul 2 18:16:04 2003 From: mjn3 at codepoet.org (Manuel Novoa III) Date: Wed, 2 Jul 2003 12:16:04 -0600 Subject: [uClibc] uClibc Mozilla In-Reply-To: <20030702180242.35523.qmail@web11203.mail.yahoo.com> References: <20030702155704.GA10257@codepoet.org> <20030702180242.35523.qmail@web11203.mail.yahoo.com> Message-ID: <20030702181604.GA12503@codepoet.org> On Wed, Jul 02, 2003 at 11:02:42AM -0700, Daniel Pezoa wrote: > Sorry for my bad search features, i can't find that > link, i search in the Homepage and FAQ. And if i > browse here: > > http://uclibc.org/cgi-bin/cvsweb/buildroot/ That's it. > i don't know where to go for the samples, i search but > i don't found the samples, if you can post the url of > some sample. I will be very happy. Look at the various make/*.mk files in buildroot. > I'am confused for the following info, i think the > samples can help in solve my problems > > > It looks like somehow you built libiconv using the > > glibc headers. > > The _IO_getc function is invoked by the getc macro > > in glibc, while > > uClibc has an entirely different stdio > > implementation. > > I should make something wrong in my settings causing > the attempt of usage of the glibc, can you explain me > how you set your root_fs-i386. I make the following. > > bzip2 -d root_fs-i386.bz2 > mkdir mnt > e2fsck -f root_fs-i386 // check filesystem > resize2fs root_fs-i386 2500000 // resize filesystem > mount -o loop root_fs-i386 mnt > cp libiconv-1.8.tar.bz2 mnt > chroot mnt > tar -jxf libiconv-1.8.tar.bz2 > cd libiconv-1.8 > ./configure > make That should work. If it doesn't, try looking at the preprocessor output (gcc -E) to see why _IO_getc is being referenced. Manuel From seh at zee2.com Wed Jul 2 18:22:38 2003 From: seh at zee2.com (Stuart Hughes) Date: Wed, 02 Jul 2003 19:22:38 +0100 Subject: [uClibc] time.h References: <3F030462.279B120A@zee2.com> <20030702163055.GA10726@codepoet.org> Message-ID: <3F0322EE.23A7F6D7@zee2.com> Manuel Novoa III wrote: > > On Wed, Jul 02, 2003 at 05:12:18PM +0100, Stuart Hughes wrote: > > Greetings, > > > > I had a problem with struct tm in time.h when compiling with a c++ > > compiler (mipsel-uclibc-g++). > > If a declaration is: struct tm; (uninitialised) > > [snip] > Your patch isn't going work, since the uClibc time code expects to > store the timezone in the struct itself. You'll wind up with > overwrites and invalid memory accesses. > Thought that may be the case. > I suppose to get around this I'll have to add a seperate data field > and initialize a __const char *__tm_zone member to point to the internal > data array. I was trying to avoid doing that, and wasn't counting on > such nit-picky compilers. Oh well... > > For the time being, you could try removing the __const qualifier on the > tm_zone[8] members. Yes, that fixes it too. Regards, Stuart From chris at txrx.org Wed Jul 2 19:14:51 2003 From: chris at txrx.org (Chris Brookes) Date: Wed, 02 Jul 2003 19:14:51 -0000 Subject: [uClibc] xfree86 4.3 tip and tvtime-0.9.8.5 problem Message-ID: <1057173261.582.53.camel@bit> Hi, I had a current CVS version of XFree86 4.3 compiled under the 0.9.19 development environment, with only minor changes to ceil and float errors, if I remember correctly. I might also have added -lcrypt to solve the dlopen linking problem. Anyway, just thought I'd mentioned that the same source tree failed to compile underthe new 0.9.20 image, stopping reporting undefined references to dlopen. The fix was to add -ldl as a link option... in my host.def I use a line like: #define DefaultGcc2i386Opt -O4 -fno-strength-reduce -march=i586 -mcpu=i586 -mmmx -lcrypt -ldl Don't know if that's the RIGHT way to do it, but I end up with a compiled and working X. :-) Anyway I'm trying to compile tvtime (http://tvtime.sf.net) .. apart from it's use of wordexp() which I get around by removing the function that uses it and just returning a normal value (that hack will work for now)... it then fails reporting several undefined refernces to rpl_malloc .. the code just has malloc() calls it in at the lines where the undefined references are. I looked through the archives and saw some mention of an rpl_malloc patch, and then an rpl workaround being removed... ?? Chris From wpl at cc4.ckitc.edu.tw Thu Jul 3 02:37:52 2003 From: wpl at cc4.ckitc.edu.tw (teacher &) Date: Thu, 3 Jul 2003 10:37:52 +0800 Subject: [uClibc] Can uClibc work with ipfwadm-2.3.0 ? Message-ID: <20030703023752.M58248@www.ckitc.edu.tw> Dear all, I am new to this discussion forum, but I have started using uClibc (0.9.5) for transplanting some applications from my x86 PC to a ARM7TDMI SBC running with uClinux 2.0.38. I am encoutering a problem with cross-compiling ipfwadm-2.3.0 with the uClibc mentioned above. In order to simplify the problem, the included header part of the code was kept intact, while the main functional part was replaced as follows: ======================================= #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include <---added according to the suggestion of www.xos.nl #include #include main() { exit(0); } ========================================= The purpose of doing this is simply to understand if the header files conflict with each other. As a result, it seems that doesn't like , e.g. will include which seems to conflict with . is not happy with either. So my questions are: 1. Is my understanding meaningful? 2. Can any version of uClibc work with ipfwadm-2.3.0 ? or 3. Can or work with ? 4. Has anyone ever cross-compiled ipfwadm-2.3.0 for uClinuc-based ARM7-TDMI? Thanks, Wen-Ping Lai Dept. of Management Information Systems TAIWAN wpl at mail.ckitc.edu.tw From andersen at codepoet.org Thu Jul 3 06:02:51 2003 From: andersen at codepoet.org (Erik Andersen) Date: Thu, 3 Jul 2003 00:02:51 -0600 Subject: [uClibc] Can ftpd tftpd openssh etc compiled through uclibc ? In-Reply-To: References: <20030702032136.GB4339@codepoet.org> Message-ID: <20030703060251.GA24158@codepoet.org> On Thu Jul 03, 2003 at 01:35:18PM +0800, Calilonhuang wrote: > I've using 0.9.19. gcc 3.2.3. > It told me it can't find some .h files. "It told me it can't find some .h files." is an absolutely worthless problem report. A useful report would actually include a cut and paste showing the gcc command and the actual error message. -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- From andersen at codepoet.org Thu Jul 3 06:08:34 2003 From: andersen at codepoet.org (Erik Andersen) Date: Thu, 3 Jul 2003 00:08:34 -0600 Subject: [uClibc] Can uClibc work with ipfwadm-2.3.0 ? In-Reply-To: <20030703023752.M58248@www.ckitc.edu.tw> References: <20030703023752.M58248@www.ckitc.edu.tw> Message-ID: <20030703060834.GB24158@codepoet.org> On Thu Jul 03, 2003 at 10:37:52AM +0800, teacher & wrote: > Dear all, > > I am new to this discussion forum, but I have started using > uClibc (0.9.5) for transplanting some applications from my x86 PC > to a ARM7TDMI SBC running with uClinux 2.0.38. > > I am encoutering a problem with cross-compiling ipfwadm-2.3.0 > with the uClibc mentioned above. In order to simplify the problem, > the included header part of the code was kept intact, while > the main functional part was replaced as follows: > > ======================================= > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include <---added according to the suggestion of Using linux kernel headers directly within a userspace application (i.e. #include ) is illegal. Therefore, ipfwadm-2.3.0 as shipped, is completely broken. Look at http://ftp.debian.org/debian/pool/main/i/ipfwadm/ipfwadm_2.3.0-4.diff.gz for an example showing how to fix ipfwadm-2.3.0 so it works with both glibc and uClibc. -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- From Calilonhuang at bj.t2-design.com Thu Jul 3 05:35:18 2003 From: Calilonhuang at bj.t2-design.com (Calilonhuang) Date: Thu, 3 Jul 2003 13:35:18 +0800 Subject: [uClibc] Can ftpd tftpd openssh etc compiled through uclibc ? In-Reply-To: <20030702032136.GB4339@codepoet.org> Message-ID: I've using 0.9.19. gcc 3.2.3. It told me it can't find some .h files. When I use uclibc compile dhcp & udhcp. It'll seach all .h in uclibc's include automaticly. I only change CC= $(MYPATH)\uclibc\bin\mipsel-uclibc-gcc That's all right. I needn't change CFLAG. Need I to make other changes to openssh's Makefile? Because these .h is in uclibc's include, xxx-uclibc-gcc can't find them. :( I don't think I need to add -I$(uclibcpath) -I$(uclibcpath) /bits -I$(uclibcpath) .......... to CFLAG Re: [uClibc] Can ftpd tftpd openssh etc compiled through uclibc ? On Wed Jul 02, 2003 at 08:40:51AM +0800, Calilonhuang wrote: > I want to build one of them under mips using uclibc. > I find openssh is listed in working list. But I can't compile it successfully. It works. I have compiled openssh with uClibc on mips using uClibc 0.9.20. Therefore, since you did not provide a proper problem report, I have to assume you did something wrong. -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- From andersen at codepoet.org Thu Jul 3 06:20:20 2003 From: andersen at codepoet.org (Erik Andersen) Date: Thu, 3 Jul 2003 00:20:20 -0600 Subject: [uClibc] xfree86 4.3 tip and tvtime-0.9.8.5 problem In-Reply-To: <1057173261.582.53.camel@bit> References: <1057173261.582.53.camel@bit> Message-ID: <20030703062020.GC24158@codepoet.org> On Wed Jul 02, 2003 at 02:14:22PM -0500, Chris Brookes wrote: > Hi, > > I had a current CVS version of XFree86 4.3 compiled under the 0.9.19 > development environment, with only minor changes to ceil and float > errors, if I remember correctly. I might also have added -lcrypt to > solve the dlopen linking problem. Anyway, just thought I'd mentioned > that the same source tree failed to compile underthe new 0.9.20 image, > stopping reporting undefined references to dlopen. The fix was to add > -ldl as a link option... in my host.def I use a line like: > > #define DefaultGcc2i386Opt -O4 -fno-strength-reduce -march=i586 > -mcpu=i586 -mmmx -lcrypt -ldl > > Don't know if that's the RIGHT way to do it, but I end up with a > compiled and working X. :-) You did just fine... :-) > Anyway I'm trying to compile tvtime (http://tvtime.sf.net) .. apart from > it's use of wordexp() which I get around by removing the function that > uses it and just returning a normal value (that hack will work for > now)... it then fails reporting several undefined refernces to > rpl_malloc .. the code just has malloc() calls it in at the lines where > the undefined references are. > > I looked through the archives and saw some mention of an rpl_malloc > patch, and then an rpl workaround being removed... ?? rpl_malloc is an abomination that was introduced by autoconf's broken AC_FUNC_MALLOC macro, which redefines malloc to rpl_malloc if it does not detect glibc's brain damaged return-a-valid-pointer-for-malloc(0) behavior, which we do not do because doing so is not required by the relevant standards and doing so is Incredibly Stupid(tm). Very very few applications actually rely on getting a usable pointer from a malloc(0) and most of those rely on this because they are buggy. Furthermore, many applications add the broken AC_FUNC_MALLOC macro to their configure.in, but fail to supply an implementation of rpl_malloc for when the test fails. Others do implement rpl_malloc (as the autoconf makers intended). So I had to remove my attempt at a workaround from uClibc... So, in short, your tvtime application is broken since it uses the AC_FUNC_MALLOC autoconf macro without supplying an implementation of rpl_malloc. Chances are about 99.999% that you should just remove the broken AC_FUNC_MALLOC macro from configure.in. But if they in fact depend on getting a usable pointer for malloc(0), then here is a trivial implementation: void *rpl_malloc (size_t __size) { if (__size == 0) { __size++; } return malloc(__size); } -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- From andrew.dennison at motec.com.au Thu Jul 3 07:52:05 2003 From: andrew.dennison at motec.com.au (Andrew Dennison) Date: Thu, 3 Jul 2003 17:52:05 +1000 Subject: [uClibc] idiot proofing development system images? In-Reply-To: <20030702155704.GA10257@codepoet.org> Message-ID: <003601c34137$ff0a2ed0$4000a8c0@ANDREWDT3> I just stupidly tried to experiment with the i386 development system images on a box with a 2.2 kernel. Unfortunately as the image is built with large file support this means that I had rather cryptic problems, and it took a while to work out what I had done wrong... May I suggest that there is a note on the web site to point out that a 2.4 kernel is required for the images to work? I built a buildroot image without large file support and I can chroot into that without any problems so I got there in the end... Andrew From andersen at codepoet.org Thu Jul 3 08:11:35 2003 From: andersen at codepoet.org (Erik Andersen) Date: Thu, 3 Jul 2003 02:11:35 -0600 Subject: [uClibc] idiot proofing development system images? In-Reply-To: <003601c34137$ff0a2ed0$4000a8c0@ANDREWDT3> References: <20030702155704.GA10257@codepoet.org> <003601c34137$ff0a2ed0$4000a8c0@ANDREWDT3> Message-ID: <20030703081134.GA25776@codepoet.org> On Thu Jul 03, 2003 at 05:52:05PM +1000, Andrew Dennison wrote: > I just stupidly tried to experiment with the i386 development system images > on a box with a 2.2 kernel. Unfortunately as the image is built with large > file support this means that I had rather cryptic problems, and it took a > while to work out what I had done wrong... > > May I suggest that there is a note on the web site to point out that a 2.4 > kernel is required for the images to work? > > I built a buildroot image without large file support and I can chroot into > that without any problems so I got there in the end... oops. ATTENTION ALL: the development system images are built with 2.4.x kernels and large file support enabled! -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- From tero at paravant.fi Thu Jul 3 11:23:33 2003 From: tero at paravant.fi (=?ISO-8859-15?Q?Tero_Lyytik=E4inen?=) Date: Thu, 3 Jul 2003 14:23:33 +0300 (EEST) Subject: [uClibc] Problems with IO.so in perl In-Reply-To: <20030701164037.6288dd26.uclibc@lacklustre.net> References: <20030701164037.6288dd26.uclibc@lacklustre.net> Message-ID: On Tue, 1 Jul 2003, Michael Ryan wrote: > I also tried to execute ldd on the shared object in question and it > seems to be compiled statically, while on my workstation [also Perl > 5.8.0], it is dynamically linked to glibc 2.3.1. My workstation is > running Debian Unstable, by the way. > I got a similar situation with perl and the problem was that the perl executable was statistically linked to libdl. (Actually it was statistically linked to everything but libc) So I just moved away the libdl.a file, recompiled perl and then ldd reported perl was dynamically linked to libdl! So I really don't know why this happens but my suggestion is to move all the relevant .a files temporarily away, recompile and then your perl and it's modules should be dynamically linked. I have previously encountered similar problems, like 'gcc -o test test.c' generating static executables. The location of the library files seems to cause this...? From andersen at codepoet.org Thu Jul 3 10:42:49 2003 From: andersen at codepoet.org (Erik Andersen) Date: Thu, 3 Jul 2003 04:42:49 -0600 Subject: [uClibc]Possible problem with soft-float on powerpc In-Reply-To: <3E7442B7.9070103@allot.com> References: <3E7442B7.9070103@allot.com> Message-ID: <20030703104249.GA5302@dillweed.codepoet.org> On Sun Mar 16, 2003 at 11:24:07AM +0200, Felix Radensky wrote: > Maybe the problem is in FP() macro definition in > libc/sysdeps/linux/powerpc/setjmp.S and > libc/sysdeps/linux/powerpc/__longjmp.S > > #ifdef __UCLIBC_HAS_FLOATS__ [-------snip--------] > which should be defined as > > if defined __UCLIBC_HAS_FLOATS__ && ! defined __UCLIBC_HAS_SOFT_FLOAT__ Thanks! You are absolutely correct! Sorry I didn't see this email before. I was just digging through my old mail and noticed this one... This problem is now (finally) fixed, -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- From andersen at codepoet.org Thu Jul 3 10:43:47 2003 From: andersen at codepoet.org (Erik Andersen) Date: Thu, 3 Jul 2003 04:43:47 -0600 Subject: [uClibc]PowerPC without FPU In-Reply-To: <1052113768.883.4.camel@kool> References: <1052113768.883.4.camel@kool> Message-ID: <20030703104347.GB5302@dillweed.codepoet.org> On Mon May 05, 2003 at 07:49:28AM +0200, Rasmus Rohde wrote: > It seems to me there is a small bug in the checking for FPU availability > in the PowerPC part of the code: > > In the dir uClibc/libc/sysdeps/linux we have the following checks on > arm: > > arm/__longjmp.S:#if defined __UCLIBC_HAS_FLOATS__ && ! defined > __UCLIBC_HAS_SOFT_FLOAT__ > arm/setjmp.S:#if defined __UCLIBC_HAS_FLOATS__ && ! defined > __UCLIBC_HAS_SOFT_FLOAT__ > > But on PowerPC there is no check for __UCLIBC_HAS_SOFT_FLOAT__: > > powerpc/__longjmp.S:#ifdef __UCLIBC_HAS_FLOATS__ > powerpc/setjmp.S:#ifdef __UCLIBC_HAS_FLOATS__ > > Shouldn't the PowerPC have the same check? Yup. Sorry I didn't see / respond to your email before... This problem is fixed now. -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- From os2doc at bellsouth.net Thu Jul 3 23:45:17 2003 From: os2doc at bellsouth.net (Michael Rowley) Date: Thu, 03 Jul 2003 23:45:17 -0000 Subject: [uClibc] 0.9.20 compile problem Message-ID: <1057275894.13673.2.camel@larafin.walker-rowley.net> Hello All, I am having a compile problem with 0.9.20, using redhat 9.0 as host, kernel 2.4.20, gcc 3.2.2. I get the following error when trying to compile. make[2]: Entering directory `/home/michael/lightweight Linux/uClibc/ldso/ldso' echo "const char *_dl_progname=\""ld-uClibc.so.0"\";" > ldso.h echo "#include \"i386/elfinterp.c\"" >> ldso.h gcc -Wall -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -mpreferred-stack-boundary=2 -falign-jumps=0 -falign-loops=0 -Os -march=i586 -fno-builtin -nostdinc -D_LIBC -I../../include -I. -I/usr/lib/gcc-lib/i386-redhat-linux/3.2.2/include -DNDEBUG -fPIC -I. -I./i386 -I../libdl -c i386/resolve.S -o i386/resolve.o strip -x -R .note -R .comment i386/resolve.o gcc -Wall -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -mpreferred-stack-boundary=2 -falign-jumps=0 -falign-loops=0 -Os -march=i586 -fno-builtin -nostdinc -D_LIBC -I../../include -I. -I/usr/lib/gcc-lib/i386-redhat-linux/3.2.2/include -DNDEBUG -fPIC -DUCLIBC_TARGET_PREFIX=\"/\" -DUCLIBC_DEVEL_PREFIX=\""/usr/i386-linux-uclibc"\" -DUCLIBC_BUILD_DIR=\"/home/michael/lightweight Linux/uClibc\" -I. -I./i386 -I../libdl -c ldso.c -o ldso.o gcc: cannot specify -o with -c or -S and multiple compilations make[2]: *** [ldso.o] Error 1 make[2]: Leaving directory `/home/michael/lightweight Linux/uClibc/ldso/ldso' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/michael/lightweight Linux/uClibc/ldso' make: *** [_dir_ldso] Error 2 [root at larafin uClibc]# I apologize, but I am fairly inexperienced with make, and usually can manage it. I am not sure how to fix this problem though. Any help? I checked the mail list archives, but found no reference to the problem. Michael. From dpforos at yahoo.com Fri Jul 4 00:03:14 2003 From: dpforos at yahoo.com (Daniel Pezoa) Date: Thu, 3 Jul 2003 17:03:14 -0700 (PDT) Subject: [uClibc] uclibc question :-) Message-ID: <20030704000314.71587.qmail@web11201.mail.yahoo.com> Hello :-) What is the function of linuxrc link to executable in the root_fs-i386, if i launch that link it start one session of logging, that i can easily solve with user root and without password. The steps for start using root_fs-i386 should be: mount -o loop root_fs-i386 mnt chroot mnt linuxrc And then i compile with uclibc, is that correct ? Or i need to set the path of uclibc ... , i'am confused with this, because when i try to compile libiconv-1.8 it print one referebce to glibc: undefined reference to '_IO_getc' What is the way to solve the problem when one program don't compile with uclibc, modify the Makefile?, modify the source code?, kill me :-) ? Good luck Daniel Pezoa __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com From tecneeq at gmx.net Fri Jul 4 01:05:29 2003 From: tecneeq at gmx.net (Karsten Kruse) Date: Fri, 4 Jul 2003 03:05:29 +0200 (CEST) Subject: [uClibc] uclibc question :-) In-Reply-To: <20030704000314.71587.qmail@web11201.mail.yahoo.com> References: <20030704000314.71587.qmail@web11201.mail.yahoo.com> Message-ID: On Thu, 3 Jul 2003, Daniel Pezoa wrote: > What is the function of linuxrc link to executable in > the root_fs-i386 Read this: http://lxr.linux.no/source/Documentation/initrd.txt > The steps for start using root_fs-i386 should be: > mount -o loop root_fs-i386 mnt > chroot mnt > linuxrc Not exactly: mkdir mnt mount -t ext2 -o loop root_fs-i386 mnt chroot mnt /bin/sh Thats all. But what i do is this: mkdir mnt mount -t ext2 -o loop root_fs-i386 mnt mount --bind /proc mnt/proc mount --bind /free/space mnt/mnt chroot mnt /bin/bash > And then i compile with uclibc, is that correct ? Yes. > Or i need to set the path of uclibc ... , i'am > confused with this, because when i try to compile > libiconv-1.8 it print one referebce to glibc: > undefined reference to '_IO_getc' > What is the way to solve the problem when one program > don't compile with uclibc, modify the Makefile?, > modify the source code?, kill me :-) ? I never saw that Problem, here are my steps: - Get and unpack libiconv-1.7.tar.gz - ./configure --prefix=/usr --disable-nls - make - make install or make DESTDIR=/somewhere install Karsten -- Homepage, Mac68k, A/UX-Links und Shorties: www.tecneeq.de () Linux/NetBSD-Anleitungen, Forum und Chat: www.newbie-net.de <\/> _/\_ When you are in it up to your ears, keep your mouth shut. From tecneeq at gmx.net Fri Jul 4 02:14:52 2003 From: tecneeq at gmx.net (Karsten Kruse) Date: Fri, 4 Jul 2003 04:14:52 +0200 (CEST) Subject: [uClibc] libdl-0.9.20.so not found Message-ID: Hi, i try to compile Openssh with the 0.9.20-dev-system. This was the plan (worked with the previous dev-system): - rm everything wich has todo with Openssl or Openssh - compile openssl-0.9.7b.tar.gz: CFLAGS="-DOPENSSL_NO_KRB5 -DOPENSSL_NO_IDEA \ -DOPENSSL_NO_MDC2 -DOPENSSL_NO_RC5" ./Configure linux-elf --prefix=/usr --openssldir=/usr/lib/ssl -ldl \ zlib-dynamic no-threads shared no-idea no-mdc2 no-rc5 make all build-shared make install make DESTDIR=target_dir install - compile openssh-3.6.1p2.tar.gz: ./configure --prefix=/usr --disable-lastlog --disable-utmp \ --disable-utmpx --disable-wtmp --disable-wtmpx \ --without-x --disable-nls make make DESTDIR=target_dir install With the new dev-system Openssh's configure stops: configure: error: *** Can't find recent OpenSSL libcrypto (see config.log for details) *** This is from config.log: configure:9483: gcc -o conftest -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I/usr/local/ssl/include -L/usr/local/ssl/lib conftest.c -lutil -lz -lcrypto >&5 /usr/lib/gcc-lib/i386-linux/3.3/../../../../i386-linux/bin/ld: warning: libdl.so.0, needed by /usr/lib/gcc-lib/i386-linux/3.3/../../../libcrypto.so, not found (try using -rpath or -rpath-link) /usr/lib/gcc-lib/i386-linux/3.3/../../../libcrypto.so: undefined reference to `dlerror' /usr/lib/gcc-lib/i386-linux/3.3/../../../libcrypto.so: undefined reference to `dlclose' /usr/lib/gcc-lib/i386-linux/3.3/../../../libcrypto.so: undefined reference to `dlopen' /usr/lib/gcc-lib/i386-linux/3.3/../../../libcrypto.so: undefined reference to `dlsym' collect2: ld returned 1 exit status ldd libcrypto.so.0.9.7 says: ldd /usr/lib/libcrypto.so.0.9.7 libdl.so.0 => /lib/libdl.so.0 (0x00000000) libc.so.0 => /lib/libc.so.0 (0x00000000) /lib/ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x00000000) Thanks for any help or hints :). Karsten -- Homepage, Mac68k, A/UX-Links und Shorties: www.tecneeq.de () Linux/NetBSD-Anleitungen, Forum und Chat: www.newbie-net.de <\/> _/\_ When you are in it up to your ears, keep your mouth shut. From tom at ceisystems.com Fri Jul 4 07:22:51 2003 From: tom at ceisystems.com (tom at ceisystems.com) Date: Fri, 4 Jul 2003 03:22:51 -0400 Subject: [uClibc] uclibc question :-) Message-ID: <6D31D5429FA6884CBE9ECAB6C9B5E6A907E08B@intel-srvr.patcameron.ne.mediaone.net> Hello all, You might also want to `mount --bind /dev mnt/dev`. This will help when you try to compile nice packages like Perl, etc. It also makes life much less confusing and obfuscated when you're flipping from chroot'ed environment to real system. :-P One thing you _should_ know, going into this, is that the buildroot system is targeted at developers and people that are comfortable with compiling sources, etc. This means that if you are not familiar with Makefiles, Configure scripts, compilers, linkers, cross-compilers, or any of the other terms that are frequently thrown around in development groups, you may want to consider doing some reading before attempting to dive right in. I would say, feel free to ask any (previously unanswered/unposted) question you like. Chances are, though, that most of the questions you will have while getting started may be found by using the Google search on the main uClibc page. That will prove to be an invaluable resource for you. Good luck, Thomas Cameron CEI Systems, Inc. -----Original Message----- From: Karsten Kruse [mailto:tecneeq at gmx.net] Sent: Thursday, July 03, 2003 9:05 PM To: Daniel Pezoa Cc: uclibc Subject: Re: [uClibc] uclibc question :-) On Thu, 3 Jul 2003, Daniel Pezoa wrote: > What is the function of linuxrc link to executable in > the root_fs-i386 Read this: http://lxr.linux.no/source/Documentation/initrd.txt > The steps for start using root_fs-i386 should be: > mount -o loop root_fs-i386 mnt > chroot mnt > linuxrc Not exactly: mkdir mnt mount -t ext2 -o loop root_fs-i386 mnt chroot mnt /bin/sh Thats all. But what i do is this: mkdir mnt mount -t ext2 -o loop root_fs-i386 mnt mount --bind /proc mnt/proc mount --bind /free/space mnt/mnt chroot mnt /bin/bash > And then i compile with uclibc, is that correct ? Yes. > Or i need to set the path of uclibc ... , i'am > confused with this, because when i try to compile libiconv-1.8 it > print one referebce to glibc: > undefined reference to '_IO_getc' > What is the way to solve the problem when one program > don't compile with uclibc, modify the Makefile?, > modify the source code?, kill me :-) ? I never saw that Problem, here are my steps: - Get and unpack libiconv-1.7.tar.gz - ./configure --prefix=/usr --disable-nls - make - make install or make DESTDIR=/somewhere install Karsten -- Homepage, Mac68k, A/UX-Links und Shorties: www.tecneeq.de () Linux/NetBSD-Anleitungen, Forum und Chat: www.newbie-net.de <\/> _/\_ When you are in it up to your ears, keep your mouth shut. _______________________________________________ uClibc mailing list uClibc at uclibc.org http://uclibc.org/mailman/listinfo/uclibc From seh at zee2.com Fri Jul 4 08:59:43 2003 From: seh at zee2.com (Stuart Hughes) Date: Fri, 04 Jul 2003 09:59:43 +0100 Subject: [uClibc] gcc-3.2 uclibc toolchain failure Message-ID: <3F0541FF.F53B8DCD@zee2.com> Greetings, I've been trying to build the latest cvs version of toolchain/gcc-3.2, but it fails on gcc-final. with many multiply defined symbols, the last is: libgcc/./_make_df.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:1342: first defined here libgcc/./dp-bit.o: In function `__truncdfsf2': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:1356: multiple definition of `__truncdfsf2' libgcc/./_df_to_sf.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:1356: first defined here collect2: ld returned 1 exit status make[3]: *** [libgcc_s.so] Error 1 make[3]: Leaving directory `/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/g I've attached the build full build messages. Anyone seen this before and know a fix ?? Regards, Stuart -------------- next part -------------- cat /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-3.2/gcc/libgcc-std.ver /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-3.2/gcc/config/libgcc-glibc.ver | sed -e "/^[ ]*#/d" -e 's/^%\(if\|else\|elif\|endif\|define\)/#\1/' \ | /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/xgcc -B/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/ -B/usr/local/uclibc/mipsel-linux/gcc-3.2/mipsel-linux/bin/ -B/usr/local/uclibc/mipsel-linux/gcc-3.2/mipsel-linux/lib/ -isystem /usr/local/uclibc/mipsel-linux/gcc-3.2/mipsel-linux/include -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-3.2/gcc -I/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-3.2/gcc/. -I/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-3.2/gcc/config -I/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-3.2/gcc/../include -E -xassembler-with-cpp -; \ } | gawk -f /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-3.2/gcc/mkmap-symver.awk > libgcc/./tmp-libgcc.map mv libgcc/./tmp-libgcc.map libgcc/./libgcc.map /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/xgcc -B/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/ -B/usr/local/uclibc/mipsel-linux/gcc-3.2/mipsel-linux/bin/ -B/usr/local/uclibc/mipsel-linux/gcc-3.2/mipsel-linux/lib/ -isystem /usr/local/uclibc/mipsel-linux/gcc-3.2/mipsel-linux/include -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -shared -nodefaultlibs -Wl,--soname=libgcc_s.so.0.9.9 -Wl,--version-script=libgcc/./libgcc.map -o libgcc_s.so.0.9.9 libgcc/./_muldi3.o libgcc/./_negdi2.o libgcc/./_lshrdi3.o libgcc/./_ashldi3.o libgcc/./_ashrdi3.o libgcc/./_ffsdi2.o libgcc/./_clz.o libgcc/./_cmpdi2.o libgcc/./_ucmpdi2.o libgcc/./_floatdidf.o libgcc/./_floatdisf.o libgcc/./_fixunsdfsi.o libgcc/./_fixunssfsi.o libgcc/./_fixunsdfdi.o libgcc/./_fixdfdi.o libgcc/./_fixunssfdi.o libgcc/./_fixsfdi.o libgcc/./_fixxfdi.o libgcc/./_fixunsxfdi.o libgcc/./_floatdixf.o libgcc/./_fixunsxfsi.o libgcc/./_fixtfdi.o libgcc/./_fixunstfdi.o libgcc/./_floatditf.o libgcc/./_clear_cache.o libgcc/./_trampoline.o libgcc/./__main.o libgcc/./_exit.o libgcc/./_absvsi2.o libgcc/./_absvdi2.o libgcc/./_addvsi3.o libgcc/./_addvdi3.o libgcc/./_subvsi3.o libgcc/./_subvdi3.o libgcc/./_mulvsi3.o libgcc/./_mulvdi3.o libgcc/./_negvsi2.o libgcc/./_negvdi2.o libgcc/./_ctors.o libgcc/./_divdi3.o libgcc/./_moddi3.o libgcc/./_udivdi3.o libgcc/./_umoddi3.o libgcc/./_udiv_w_sdiv.o libgcc/./_udivmoddi4.o libgcc/./_pack_sf.o libgcc/./_unpack_sf.o libgcc/./_addsub_sf.o libgcc/./_mul_sf.o libgcc/./_div_sf.o libgcc/./_fpcmp_parts_sf.o libgcc/./_compare_sf.o libgcc/./_eq_sf.o libgcc/./_ne_sf.o libgcc/./_gt_sf.o libgcc/./_ge_sf.o libgcc/./_lt_sf.o libgcc/./_le_sf.o libgcc/./_unord_sf.o libgcc/./_si_to_sf.o libgcc/./_sf_to_si.o libgcc/./_negate_sf.o libgcc/./_make_sf.o libgcc/./_sf_to_df.o libgcc/./_thenan_sf.o libgcc/./_sf_to_usi.o libgcc/./_usi_to_sf.o libgcc/./_pack_df.o libgcc/./_unpack_df.o libgcc/./_addsub_df.o libgcc/./_mul_df.o libgcc/./_div_df.o libgcc/./_fpcmp_parts_df.o libgcc/./_compare_df.o libgcc/./_eq_df.o libgcc/./_ne_df.o libgcc/./_gt_df.o libgcc/./_ge_df.o libgcc/./_lt_df.o libgcc/./_le_df.o libgcc/./_unord_df.o libgcc/./_si_to_df.o libgcc/./_df_to_si.o libgcc/./_negate_df.o libgcc/./_make_df.o libgcc/./_df_to_sf.o libgcc/./_thenan_df.o libgcc/./_df_to_usi.o libgcc/./_usi_to_df.o libgcc/./fp-bit.o libgcc/./dp-bit.o libgcc/./unwind-dw2.o libgcc/./unwind-dw2-fde-glibc.o libgcc/./unwind-sjlj.o -lc && rm -f libgcc_s.so && ln -s libgcc_s.so.0.9.9 libgcc_s.so libgcc/./fp-bit.o: In function `__pack_f': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:183: multiple definition of `__thenan_sf' libgcc/./_thenan_sf.o(.rodata+0x0): first defined here libgcc/./fp-bit.o: In function `__pack_f': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:183: multiple definition of `__pack_f' libgcc/./_pack_sf.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:183: first defined here libgcc/./fp-bit.o: In function `__unpack_f': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:309: multiple definition of `__unpack_f' libgcc/./_unpack_sf.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:309: first defined here libgcc/./fp-bit.o: In function `__addsf3': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:543: multiple definition of `__addsf3' libgcc/./_addsub_sf.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:543: first defined here libgcc/./fp-bit.o: In function `__subsf3': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:563: multiple definition of `__subsf3' libgcc/./_addsub_sf.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:563: first defined here libgcc/./fp-bit.o: In function `__mulsf3': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:757: multiple definition of `__mulsf3' libgcc/./_mul_sf.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:757: first defined here libgcc/./fp-bit.o: In function `__divsf3': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:868: multiple definition of `__divsf3' libgcc/./_div_sf.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:868: first defined here libgcc/./fp-bit.o: In function `__fpcmp_parts_f': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:895: multiple definition of `__fpcmp_parts_f' libgcc/./_fpcmp_parts_sf.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:895: first defined here libgcc/./fp-bit.o: In function `__cmpsf2': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:974: multiple definition of `__cmpsf2' libgcc/./_compare_sf.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:974: first defined here libgcc/./fp-bit.o: In function `__eqsf2': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:996: multiple definition of `__eqsf2' libgcc/./_eq_sf.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:996: first defined here libgcc/./fp-bit.o: In function `__nesf2': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:1017: multiple definition of `__nesf2' libgcc/./_ne_sf.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:1017: first defined here libgcc/./fp-bit.o: In function `__gtsf2': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:1038: multiple definition of `__gtsf2' libgcc/./_gt_sf.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:1038: first defined here libgcc/./fp-bit.o: In function `__gesf2': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:1059: multiple definition of `__gesf2' libgcc/./_ge_sf.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:1059: first defined here libgcc/./fp-bit.o: In function `__ltsf2': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:1079: multiple definition of `__ltsf2' libgcc/./_lt_sf.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:1079: first defined here libgcc/./fp-bit.o: In function `__lesf2': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:1100: multiple definition of `__lesf2' libgcc/./_le_sf.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:1100: first defined here libgcc/./fp-bit.o: In function `__unordsf2': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:1121: multiple definition of `__unordsf2' libgcc/./_unord_sf.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:1121: first defined here libgcc/./fp-bit.o: In function `__floatsisf': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:1141: multiple definition of `__floatsisf' libgcc/./_si_to_sf.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:1141: first defined here libgcc/./fp-bit.o: In function `__floatunsisf': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:1179: multiple definition of `__floatunsisf' libgcc/./_usi_to_sf.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:1179: first defined here libgcc/./fp-bit.o: In function `__fixsfsi': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:1211: multiple definition of `__fixsfsi' libgcc/./_sf_to_si.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:1211: first defined here libgcc/./fp-bit.o: In function `__negsf2': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:1279: multiple definition of `__negsf2' libgcc/./_negate_sf.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:1279: first defined here libgcc/./fp-bit.o: In function `__make_fp': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:1299: multiple definition of `__make_fp' libgcc/./_make_sf.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:1299: first defined here libgcc/./fp-bit.o: In function `__extendsfdf2': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:1320: multiple definition of `__extendsfdf2' libgcc/./_sf_to_df.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/fp-bit.c:1320: first defined here libgcc/./dp-bit.o: In function `__pack_d': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:183: multiple definition of `__thenan_df' libgcc/./_thenan_df.o(.rodata+0x0): first defined here libgcc/./dp-bit.o: In function `__pack_d': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:183: multiple definition of `__pack_d' libgcc/./_pack_df.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:183: first defined here libgcc/./dp-bit.o: In function `__unpack_d': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:309: multiple definition of `__unpack_d' libgcc/./_unpack_df.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:309: first defined here libgcc/./dp-bit.o: In function `__adddf3': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:543: multiple definition of `__adddf3' libgcc/./_addsub_df.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:543: first defined here libgcc/./dp-bit.o: In function `__subdf3': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:563: multiple definition of `__subdf3' libgcc/./_addsub_df.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:563: first defined here libgcc/./dp-bit.o: In function `__muldf3': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:757: multiple definition of `__muldf3' libgcc/./_mul_df.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:757: first defined here libgcc/./dp-bit.o: In function `__divdf3': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:868: multiple definition of `__divdf3' libgcc/./_div_df.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:868: first defined here libgcc/./dp-bit.o: In function `__fpcmp_parts_d': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:895: multiple definition of `__fpcmp_parts_d' libgcc/./_fpcmp_parts_df.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:895: first defined here libgcc/./dp-bit.o: In function `__cmpdf2': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:974: multiple definition of `__cmpdf2' libgcc/./_compare_df.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:974: first defined here libgcc/./dp-bit.o: In function `__eqdf2': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:996: multiple definition of `__eqdf2' libgcc/./_eq_df.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:996: first defined here libgcc/./dp-bit.o: In function `__nedf2': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:1017: multiple definition of `__nedf2' libgcc/./_ne_df.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:1017: first defined here libgcc/./dp-bit.o: In function `__gtdf2': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:1038: multiple definition of `__gtdf2' libgcc/./_gt_df.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:1038: first defined here libgcc/./dp-bit.o: In function `__gedf2': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:1059: multiple definition of `__gedf2' libgcc/./_ge_df.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:1059: first defined here libgcc/./dp-bit.o: In function `__ltdf2': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:1079: multiple definition of `__ltdf2' libgcc/./_lt_df.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:1079: first defined here libgcc/./dp-bit.o: In function `__ledf2': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:1100: multiple definition of `__ledf2' libgcc/./_le_df.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:1100: first defined here libgcc/./dp-bit.o: In function `__unorddf2': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:1121: multiple definition of `__unorddf2' libgcc/./_unord_df.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:1121: first defined here libgcc/./dp-bit.o: In function `__floatsidf': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:1141: multiple definition of `__floatsidf' libgcc/./_si_to_df.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:1141: first defined here libgcc/./dp-bit.o: In function `__floatunsidf': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:1179: multiple definition of `__floatunsidf' libgcc/./_usi_to_df.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:1179: first defined here libgcc/./dp-bit.o: In function `__fixdfsi': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:1211: multiple definition of `__fixdfsi' libgcc/./_df_to_si.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:1211: first defined here libgcc/./dp-bit.o: In function `__negdf2': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:1279: multiple definition of `__negdf2' libgcc/./_negate_df.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:1279: first defined here libgcc/./dp-bit.o: In function `__make_dp': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:1342: multiple definition of `__make_dp' libgcc/./_make_df.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:1342: first defined here libgcc/./dp-bit.o: In function `__truncdfsf2': /home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:1356: multiple definition of `__truncdfsf2' libgcc/./_df_to_sf.o:/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc/dp-bit.c:1356: first defined here collect2: ld returned 1 exit status make[3]: *** [libgcc_s.so] Error 1 make[3]: Leaving directory `/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc' make[2]: *** [stmp-multilib] Error 2 make[2]: Leaving directory `/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/gcc' make[1]: *** [all-gcc] Error 2 make[1]: Leaving directory `/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final' make: *** [/home/seh/toolchain/gcc-3.2/build_mipsel/gcc-final/.compiled] Error 2 From christian_michon at yahoo.fr Fri Jul 4 09:53:27 2003 From: christian_michon at yahoo.fr (=?iso-8859-1?q?Christian=20MICHON?=) Date: Fri, 4 Jul 2003 11:53:27 +0200 (CEST) Subject: [uClibc] help in compile uclibc gtk In-Reply-To: <20030702145615.21121.qmail@web11202.mail.yahoo.com> Message-ID: <20030704095327.79450.qmail@web11102.mail.yahoo.com> --- Daniel Pezoa a ?crit : > Hello > > I see gtk in the list of what can be compiled with > uclibc. > > But it require glib, pango, atk, pkgconfig, libiconv. > I think I reported gtk-1.2.10 (the old gnome toolkit). gtk-2.x.x is quite bloated compared to uclibc concept, no ? If your application can survive on the old toolkit, don't use version 2.x.x. Christian ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en fran?ais ! Yahoo! Mail : http://fr.mail.yahoo.com From cdweng at netrd.iii.org.tw Fri Jul 4 11:34:40 2003 From: cdweng at netrd.iii.org.tw (=?big5?B?r86n07lG?=) Date: Fri, 04 Jul 2003 19:34:40 +0800 Subject: [uClibc] Problem with pthread_create....!! Message-ID: <1d9b01c34220$41c545a0$e53d5c8c@iii.org.tw> hi,all: I got a problem when used pthread_create function call in my arm-uclinux kernel 2.0.38. The pthread_create had no return and all threads were freeze at the time. Could any body give me a hint for how to reslove this problem......? My uclibc is version 0.9.20. B.R. ==================================================== Chih-Da Weng Network Communication Laboratory, Institute for Information Industry. 5FL., 116, Sec. 2, Nan-King E. Rd., Taipei 104,Taiwan, R.O.C. TEL:886-2--2564-3588 ext. 220 FAX: 886-2-2564-3775 E-mail: cdweng at netrd.iii.org.tw -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.busybox.net/pipermail/uclibc/attachments/20030704/c43e5535/attachment-0001.htm From dpforos at yahoo.com Fri Jul 4 14:30:39 2003 From: dpforos at yahoo.com (Daniel Pezoa) Date: Fri, 4 Jul 2003 07:30:39 -0700 (PDT) Subject: [uClibc] uclibc question :-) In-Reply-To: Message-ID: <20030704143039.84628.qmail@web11207.mail.yahoo.com> Hello Karsten Kruse Thanks, your post help me a lot! I now have the libiconv-1.7 compiled ok My problem is because i use the 1.8 versi?n, but i really don't require 1.8, 1.7 is quite well. Good luck Daniel Pezoa --- Karsten Kruse wrote: > > On Thu, 3 Jul 2003, Daniel Pezoa wrote: > > > What is the function of linuxrc link to executable > in > > the root_fs-i386 > > Read this: > http://lxr.linux.no/source/Documentation/initrd.txt > > > The steps for start using root_fs-i386 should be: > > mount -o loop root_fs-i386 mnt > > chroot mnt > > linuxrc > > Not exactly: > mkdir mnt > mount -t ext2 -o loop root_fs-i386 mnt > chroot mnt /bin/sh > > Thats all. But what i do is this: > mkdir mnt > mount -t ext2 -o loop root_fs-i386 mnt > mount --bind /proc mnt/proc > mount --bind /free/space mnt/mnt > chroot mnt /bin/bash > > > And then i compile with uclibc, is that correct ? > > Yes. > > > Or i need to set the path of uclibc ... , i'am > > confused with this, because when i try to compile > > libiconv-1.8 it print one referebce to glibc: > > > undefined reference to '_IO_getc' > > > What is the way to solve the problem when one > program > > don't compile with uclibc, modify the Makefile?, > > modify the source code?, kill me :-) ? > > I never saw that Problem, here are my steps: > > - Get and unpack libiconv-1.7.tar.gz > - ./configure --prefix=/usr --disable-nls > - make > - make install or make DESTDIR=/somewhere install > > Karsten > > -- > Homepage, Mac68k, A/UX-Links und Shorties: > www.tecneeq.de > () Linux/NetBSD-Anleitungen, Forum und Chat: > www.newbie-net.de > <\/> > _/\_ When you are in it up to your ears, keep > your mouth shut. __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com From terjekv at math.uio.no Fri Jul 4 22:03:46 2003 From: terjekv at math.uio.no (Terje Kvernes) Date: Sat, 05 Jul 2003 00:03:46 +0200 Subject: [uClibc] pcmcia modules error. Message-ID: hm, is this a known issue when using the buildroot? mkdir -p /var/tmp/buildroot/build_i386/root/etc/default cp -f /var/tmp/buildroot/build_i386/pcmcia-cs-3.2.4/etc/pcmcia /var/tmp/buildroot/build_i386/root/etc/default/ cp -f /var/tmp/buildroot/build_i386/pcmcia-cs-3.2.4/etc/rc.pcmcia /var/tmp/buildroot/build_i386/root/etc/init.d/S30pcmcia rm -rf /var/tmp/buildroot/build_i386/root/etc/pcmcia/cis chmod a+x /var/tmp/buildroot/build_i386/root/etc/init.d/S30pcmcia chmod -R u+w /var/tmp/buildroot/build_i386/root/etc/pcmcia/* make: *** No rule to make target `/var/tmp/buildroot/build_i386/root/lib/modules', needed by `/var/tmp/buildroot/build_i386/pcmcia-cs-3.2.4/.modules.dep'. Stop. I have the following targets set: [x200 /var/tmp/buildroot] # grep ^TARGETS+ Makefile TARGETS+=uclibc_toolchain TARGETS+=system-linux TARGETS+=busybox tinylogin TARGETS+=zlib openssl openssh TARGETS+=coreutils findutils bash make diffutils patch sed TARGETS+=ed flex bison file gawk tar grep gcc_target TARGETS+=ncurses-headers zlib-headers openssl-headers TARGETS+=m4 autoconf automake libtool TARGETS+=perl TARGETS+=gdb strace TARGETS+=iptables hostap wtools dhcp_relay bridge TARGETS+=iproute2 netsnmp TARGETS+=ext2root since I have no big need for hostap, wtools, dhcp_relay, bridge and netsnmp I just removed them and the compile finished fine. -- Terje From dpforos at yahoo.com Fri Jul 4 22:44:39 2003 From: dpforos at yahoo.com (Daniel Pezoa) Date: Fri, 4 Jul 2003 15:44:39 -0700 (PDT) Subject: [uClibc] uclibc libIDL Message-ID: <20030704224439.94620.qmail@web11201.mail.yahoo.com> Hello I need help comipiling libIDL 0.6.8 at the end i have that output: /parser.y:2070: dereferencing pointer to incomplete type ./parser.y:2070: dereferencing pointer to incomplete type ./parser.y:2070: dereferencing pointer to incomplete type ./parser.y:2075: dereferencing pointer to incomplete type ./parser.y: In function `IDL_queue_new_ident_comment': ./parser.y:2091: warning: assignment makes pointer from integer without a cast make: *** [parser.lo] Error 1 [root at tvmovil libIDL-0.6.8]# If any have compiled it or another version, or have one idea about the problem, please give your help. Good luck. Daniel Pezoa __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com From os2doc at bellsouth.net Sat Jul 5 04:30:12 2003 From: os2doc at bellsouth.net (Michael Rowley) Date: Sat, 05 Jul 2003 04:30:12 -0000 Subject: [uClibc] compile perl-5.8.0 with uclibc Message-ID: <1057379400.20882.2.camel@larafin.walker-rowley.net> Hello! Problems compiling perl5.8.0. I am not using buildroot, just compiling with a modified path as per the uclibc install file, and it has worked well to now, but I can't get perl to compile. I applied the patch I found in the archives for perl, but it didn't help. I get the following error: cc -o miniperl \ miniperlmain.o opmini.o libperl.a libperl.a(pp.o)(.text+0x170a): In function `Perl_pp_pow': : undefined reference to `pow' libperl.a(pp.o)(.text+0x54d9): In function `Perl_pp_sin': : undefined reference to `sin' libperl.a(pp.o)(.text+0x55e5): In function `Perl_pp_cos': : undefined reference to `cos' libperl.a(pp.o)(.text+0x58c5): In function `Perl_pp_exp': : undefined reference to `exp' libperl.a(pp.o)(.text+0x5a07): In function `Perl_pp_log': : undefined reference to `log' collect2: ld returned 1 exit status make: *** [miniperl] Error 1 Any ideas/assistance? I need perl for my system to work... :( M. From andersen at codepoet.org Sat Jul 5 17:32:54 2003 From: andersen at codepoet.org (Erik Andersen) Date: Sat, 5 Jul 2003 11:32:54 -0600 Subject: [uClibc] compile perl-5.8.0 with uclibc In-Reply-To: <1057379400.20882.2.camel@larafin.walker-rowley.net> References: <1057379400.20882.2.camel@larafin.walker-rowley.net> Message-ID: <20030705173254.GA19604@codepoet.org> On Sat Jul 05, 2003 at 12:30:00AM -0400, Michael Rowley wrote: > Hello! > > Problems compiling perl5.8.0. I am not using buildroot, just compiling > with a modified path as per the uclibc install file, and it has worked > well to now, but I can't get perl to compile. I applied the patch I > found in the archives for perl, but it didn't help. I get the following > error: > > cc -o miniperl \ > miniperlmain.o opmini.o libperl.a > libperl.a(pp.o)(.text+0x170a): In function `Perl_pp_pow': > : undefined reference to `pow' > libperl.a(pp.o)(.text+0x54d9): In function `Perl_pp_sin': > : undefined reference to `sin' > libperl.a(pp.o)(.text+0x55e5): In function `Perl_pp_cos': > : undefined reference to `cos' > libperl.a(pp.o)(.text+0x58c5): In function `Perl_pp_exp': > : undefined reference to `exp' > libperl.a(pp.o)(.text+0x5a07): In function `Perl_pp_log': > : undefined reference to `log' > collect2: ld returned 1 exit status > make: *** [miniperl] Error 1 > > Any ideas/assistance? I need perl for my system to work... :( As a guess, it looks like you have failed to link with libm. Tried adding -lm? -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- From os2doc at bellsouth.net Mon Jul 7 01:37:28 2003 From: os2doc at bellsouth.net (Michael Rowley) Date: Mon, 07 Jul 2003 01:37:28 -0000 Subject: [uClibc] compile perl-5.8.0 with uclibc In-Reply-To: <20030705173254.GA19604@codepoet.org> References: <1057379400.20882.2.camel@larafin.walker-rowley.net> <20030705173254.GA19604@codepoet.org> Message-ID: <1057541812.26829.4.camel@larafin.walker-rowley.net> On Sat, 2003-07-05 at 13:32, Erik Andersen wrote: > On Sat Jul 05, 2003 at 12:30:00AM -0400, Michael Rowley wrote: > > Hello! > > > > Problems compiling perl5.8.0. I am not using buildroot, just compiling > > with a modified path as per the uclibc install file, and it has worked > > well to now, but I can't get perl to compile. I applied the patch I > > found in the archives for perl, but it didn't help. I get the following > > error: > > > > cc -o miniperl \ > > miniperlmain.o opmini.o libperl.a > > libperl.a(pp.o)(.text+0x170a): In function `Perl_pp_pow': > > : undefined reference to `pow' > > libperl.a(pp.o)(.text+0x54d9): In function `Perl_pp_sin': > > : undefined reference to `sin' > > libperl.a(pp.o)(.text+0x55e5): In function `Perl_pp_cos': > > : undefined reference to `cos' > > libperl.a(pp.o)(.text+0x58c5): In function `Perl_pp_exp': > > : undefined reference to `exp' > > libperl.a(pp.o)(.text+0x5a07): In function `Perl_pp_log': > > : undefined reference to `log' > > collect2: ld returned 1 exit status > > make: *** [miniperl] Error 1 > > > > Any ideas/assistance? I need perl for my system to work... :( > > As a guess, it looks like you have failed to link with libm. > Tried adding -lm? > > -Erik No, as stupid as this sounds, it was a problem with the path to where the code was.... I had a directory with a space, and the perl config script read it as 2 files... Changed the path, fixed the problem. One of those that makes you want to bang your head against the keyboard... :| Michael. From os2doc at bellsouth.net Mon Jul 7 01:46:49 2003 From: os2doc at bellsouth.net (Michael Rowley) Date: Mon, 07 Jul 2003 01:46:49 -0000 Subject: [uClibc] buildroot, and User Mode Linux Message-ID: <1057542378.26829.16.camel@larafin.walker-rowley.net> Hmm, For all the times I have been told to RTFM, now I wish I could. I am having some trouble with build root avaliable from the CSV site. There is a paucity of documentation. The readme seemed to imply that it would build UMlinux ( the final step in the instructions is to type ./UMlinux to check out the progress... ) Well, I couldn't find where UMlinux (or any other similar UML executable) was made during the compile, so I went to user-mode-linux.sourceforge.net and downloaded the RPM. It doesn't match my kernel (2.4.20-18.9, redhat 9.0), but got user_mode_linux-2.4.19.5um-0.i386.rpm and installed it, but now I am getting the following error when trying to load the root)fs made with buildroot Initializing RT netlink socket Kernel panic: outer trampoline didn't exit with SIGKILL Now, I am not sure if I have the right version, or the most recent, this one is dated Linux version 2.4.19-5um (jdike at uml.karaya.com) (gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-81)) #2 Mon Sep 16 15:41:15 EDT 2002 I hate being a pain, but any pointers to helpful information? I have done a google search for buildroot, and UML documentation, howto's and manual pages, but come up blank... With my luck this is another stupid mistake... Michael. From robm at flipturn.org Mon Jul 7 02:25:47 2003 From: robm at flipturn.org (Rob McMullen) Date: Sun, 06 Jul 2003 22:25:47 -0400 Subject: [uClibc] XEmacs success Message-ID: Finally got XEmacs working with uClibc and X11 under a uClibc-as-the-root-libc system: the trick is to use uClibc's malloc instead of configure's default that selects a malloc implementation included in XEmacs. Trigger this with the --with-system-malloc flag to configure. Also, due to the ld.so issues of shared libraries not able to load other shared libraries, I have to start XEmacs with: LD_PRELOAD=/usr/X11R6/lib/libXrender.so xemacs I leave out some bells and whistles here, but the configure command that I used should get you started: CC="gcc -Wl,-rpath-link=/usr/lib,-rpath-link=/lib" ./configure \ --with-widgets=athena --with-dialogs=athena --with-scrollbars=lucid \ --with-menubars=lucid --with-gif=yes --without-tiff --with-jpeg \ --without-xface --without-gpm --with-sound=native \ --with-database=gnudbm --with-system-malloc --prefix=/usr \ --with-ncurses --with-msw=no --mail-locking=flock \ --with-site-lisp=yes --with-site-modules=yes Rob From terjekv at math.uio.no Mon Jul 7 03:03:38 2003 From: terjekv at math.uio.no (Terje Kvernes) Date: Mon, 07 Jul 2003 05:03:38 +0200 Subject: [uClibc] XEmacs success In-Reply-To: (Rob McMullen's message of "Sun, 06 Jul 2003 22:25:47 -0400") References: Message-ID: Rob McMullen writes: > Finally got XEmacs working with uClibc and X11 under a > uClibc-as-the-root-libc system: the trick is to use uClibc's malloc > instead of configure's default that selects a malloc implementation > included in XEmacs. Trigger this with the --with-system-malloc flag > to configure. rather cute actually. :-) how large is the emacs binary and the full emacs tree? [ ... ] -- Terje From peter.kjellerstedt at axis.com Mon Jul 7 14:08:42 2003 From: peter.kjellerstedt at axis.com (Peter Kjellerstedt) Date: Mon, 7 Jul 2003 16:08:42 +0200 Subject: [uClibc] CRIS port Message-ID: > -----Original Message----- > From: Erik Andersen [mailto:andersen at codepoet.org] > Sent: 30 June 2003 19:35 > To: Simon Posnjak > Cc: uclibc at uclibc.org > Subject: Re: [uClibc] CRIS port > > On Mon Jun 30, 2003 at 05:59:36PM +0200, Simon Posnjak wrote: > > Hi all, > > > > Can somebody pleas tell me what is the status of CRIS port > > of uclibc. (Is it stable, is anybody working on it, anybody > > using it, etc). Thanks! > > It should be working. > > -Erik We have a number of updates for the CRIS architecture in our internal CVS that have not yet been applied to the official uClibc repository. They will be, eventually. As for working on it and using it: Yes, very much so. //Peter Kjellerstedt Axis Communications AB From kleine-budde at gmx.de Mon Jul 7 18:53:16 2003 From: kleine-budde at gmx.de (Marc Kleine-Budde) Date: Mon, 7 Jul 2003 20:53:16 +0200 Subject: [uClibc] CRIS port In-Reply-To: References: Message-ID: <20030707185316.GA11380@timberwolf.dyndns.org> Hello! On Mon, Jul 07, 2003 at 04:08:42PM +0200, Peter Kjellerstedt wrote: > > > Can somebody pleas tell me what is the status of CRIS port > > > of uclibc. (Is it stable, is anybody working on it, anybody > > > using it, etc). Thanks! > > It should be working. Hm - here uClibc-0.9.20 doesn't even compile out of the box. I'm using binutils 2.13.2.1, gcc 3.2.3 with the fixes and patches from buildroot. cris-uclibc-linux-gcc -Wall -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -Os -mlinux -fno-builtin -nostdinc -D_LIBC -I../../include -I. -I/home/frogger/ptxdist/xchain-cris/lib/gcc-lib/cris-uclibc-linux/3.2.3/include -DNDEBUG -fpic -mlinux -DUCLIBC_TARGET_PREFIX=\"/\" -DUCLIBC_DEVEL_PREFIX=\""/home/frogger/ptxdist/xchain-cris/cris-uclibc-linux"\" -DUCLIBC_BUILD_DIR=\"/home/frogger/projects/ptxdist/ptxdist-cris/build/uClibc-0.9.20\" -I. -I./cris -I../libdl -c ldso.c -o ldso.o In file included from ../../include/sys/syscall.h:23, from cris/ld_syscalls.h:7, from ld_syscall.h:6, from ldso.c:108: ../../include/bits/syscalls.h:9:26: bits/syscall.h: No such file or directory In file included from ldso.c:108: ld_syscall.h: In function `_dl_exit': ld_syscall.h:47: `__NR_exit' undeclared (first use in this function) ld_syscall.h:47: (Each undeclared identifier is reported only once ld_syscall.h:47: for each function it appears in.) ld_syscall.h: In function `_dl_close': [many missing __NR_s deleted] ld_syscall.h:155: `__NR_readlink' undeclared (first use in this function) In file included from linuxelf.h:6, from ldso.c:109: cris/ld_sysdep.h:55:35: warning: multi-line string literals are deprecated In file included from ldso.c:159: cris/boot1_arch.h:5:5: warning: multi-line string literals are deprecated after some random hacking and stumbling over another 'bug' [1] it compiles at least. I had no time to test it on the cris itself......See attached diff. Using buildroot, with the uClibc snapshot I get even more strage errors: /tmp/buildroot/build_cris/staging_dir/bin/cris-uclibc-gcc -Wall -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -Os -mlinux -fno-builtin -nostdinc -D_LIBC -I../../include -I. -I/tmp/buildroot/build_cris/staging_dir/lib/gcc-lib/cris-linux/3.3/include -DNDEBUG -fpic -mlinux -DUCLIBC_TARGET_PREFIX=\"/\" -DUCLIBC_DEVEL_PREFIX=\""/tmp/buildroot/build_cris/staging_dir"\" -DUCLIBC_BUILD_DIR=\"/tmp/buildroot/build_cris/uClibc\" -I. -I./cris -I../libdl -c ldso.c -o ldso.o In file included from ../../include/sys/syscall.h:23, from cris/ld_syscalls.h:7, from ld_syscall.h:6, from ldso.c:108: ../../include/bits/syscalls.h:9:26: bits/syscall.h: No such file or directory In file included from ldso.c:108: ld_syscall.h: In function `_dl_exit': ld_syscall.h:47: error: `__NR_exit' undeclared (first use in this function) ld_syscall.h:47: error: (Each undeclared identifier is reported only once ld_syscall.h:47: error: for each function it appears in.) ld_syscall.h: In function `_dl_close': ld_syscall.h:51: error: `__NR_close' undeclared (first use in this function) [many missing __NRs deleted] ld_syscall.h: In function `_dl_readlink': ld_syscall.h:155: error: `__NR_readlink' undeclared (first use in this function) In file included from linuxelf.h:6, from ldso.c:109: cris/ld_sysdep.h:55:35: missing terminating " character In file included from linuxelf.h:6, from ldso.c:109: cris/ld_sysdep.h: At top level: cris/ld_sysdep.h:56: error: parse error before "$r8" cris/ld_sysdep.h:56: warning: type defaults to `int' in declaration of `$r8' cris/ld_sysdep.h:56: error: stray '\' in program cris/ld_sysdep.h:56: warning: type defaults to `int' in declaration of `$srp' cris/ld_sysdep.h:56: error: parse error before "n" cris/ld_sysdep.h:56: error: stray '\' in program cris/ld_sysdep.h:57: error: stray '\' in program cris/ld_sysdep.h:57: error: stray '\' in program cris/ld_sysdep.h:58: error: stray '\' in program cris/ld_sysdep.h:58: error: stray '\' in program cris/ld_sysdep.h:58:107: missing terminating " character cris/ld_sysdep.h:66: warning: `struct elf_resolve' declared inside parameter list cris/ld_sysdep.h:66: warning: its scope is only this definition or declaration, which is probably not what you want In file included from ldso.c:159: cris/boot1_arch.h:5:5: missing terminating " character In file included from ldso.c:159: cris/boot1_arch.h:7: error: request for member `globl' in something not a structure or union cris/boot1_arch.h:7: error: parse error before "_dl_boot" cris/boot1_arch.h:8: error: syntax error at '@' token cris/boot1_arch.h:14:1: missing terminating " character In file included from ldso.h:2, from ldso.c:160: cris/elfinterp.c:102: error: conflicting types for `_dl_linux_resolver' cris/ld_sysdep.h:66: error: previous declaration of `_dl_linux_resolver' cris/elfinterp.c: In function `_dl_linux_resolver': cris/elfinterp.c:122: error: `_dl_progname' undeclared (first use in this function) In file included from ldso.h:2, from ldso.c:160: cris/elfinterp.c: In function `_dl_parse_lazy_relocation_information': cris/elfinterp.c:201: error: `_dl_progname' undeclared (first use in this function) In file included from ldso.h:2, from ldso.c:160: cris/elfinterp.c: In function `_dl_parse_relocation_information': cris/elfinterp.c:265: error: `_dl_progname' undeclared (first use in this function) In file included from ldso.h:2, from ldso.c:160: cris/elfinterp.c: In function `_dl_parse_copy_information': cris/elfinterp.c:378: error: `_dl_progname' undeclared (first use in this function) ldso.c: In function `_dl_boot2': ldso.c:598: error: `_dl_progname' undeclared (first use in this function) ldso.c:635: error: parse error before ';' token ldso.c:652: error: redeclaration of `goof' ldso.c:204: error: `goof' previously declared here ldso.c:723: error: `ppnt' undeclared (first use in this function) ldso.c:724: warning: value computed is not used ldso.c: In function `_dl_fixup': ldso.c:1322: error: `_dl_progname' undeclared (first use in this function) In file included from ldso.c:1399: readelflib1.c: In function `_dl_load_elf_shared_library': readelflib1.c:380: error: `_dl_progname' undeclared (first use in this function) In file included from ldso.c:1399: readelflib1.c: In function `_dl_malloc': readelflib1.c:776: error: `_dl_progname' undeclared (first use in this function) ld_string.h: At top level: ldso.c:158: warning: `_dl_get_ready_to_run' declared `static' but never defined regards - Marc [1] http://sources.redhat.com/ml/libc-alpha/2002-06/msg00006.html -- #!/bin/sh set - `type $0` 'tr "[a-zA-Z]" "[n-za-mN-ZA-M]"';while [ "$2" != "" ];do \ shift;done; echo 'frq -a -rc '`echo "$0"| $1 `'>$UBZR/.`rpub signature|'`\ echo $1|$1`'`;rpub "Jr ner fvtangher bs obet. Erfvfgnapr vf shgvyr!"'|$1|sh -------------- next part -------------- diff -ur uClibc-0.9.20.orig/include/features.h /home/frogger/ptxdist/ptxdist-cris/build/uClibc-0.9.20/include/features.h --- uClibc-0.9.20.orig/include/features.h Mon Feb 17 15:16:14 2003 +++ /home/frogger/ptxdist/ptxdist-cris/build/uClibc-0.9.20/include/features.h Mon Jul 7 20:08:14 2003 @@ -386,10 +386,15 @@ # define weak_const_function __attribute__ ((weak, __const__)) /* Tacking on "\n\t#" to the section name makes gcc put it's bogus * section attributes on what looks like a comment to the assembler. */ +# ifdef GNU_CRIS +# define __as_app_line "#APP\n" +# else +# define __as_app_line "" +# endif # define link_warning(symbol, msg) \ asm (".section " ".gnu.warning." #symbol "\n\t.previous"); \ static const char __evoke_link_warning_##symbol[] \ - __attribute__ ((unused, section (".gnu.warning." #symbol "\n\t#"))) = msg; + __attribute__ ((unused, section (".gnu.warning." #symbol "\n" __as_app_line "\t#"))) = msg; #else /* !defined __HAVE_ELF__ */ # define strong_alias(name, aliasname) _strong_alias (name, aliasname) # define weak_alias(name, aliasname) _strong_alias (name, aliasname) diff -ur uClibc-0.9.20.orig/ldso/ldso/cris/elfinterp.c /home/frogger/ptxdist/ptxdist-cris/build/uClibc-0.9.20/ldso/ldso/cris/elfinterp.c --- uClibc-0.9.20.orig/ldso/ldso/cris/elfinterp.c Tue Nov 5 19:21:00 2002 +++ /home/frogger/ptxdist/ptxdist-cris/build/uClibc-0.9.20/ldso/ldso/cris/elfinterp.c Mon Jul 7 20:08:14 2003 @@ -33,6 +33,10 @@ * SUCH DAMAGE. */ +#ifndef _dl_debug_file +#define _dl_debug_file 2 +#endif + /* Support for the LD_DEBUG variable. */ #if defined (__SUPPORT_LD_DEBUG__) static const char *_dl_reltypes_tab[] = { diff -ur uClibc-0.9.20.orig/ldso/ldso/ldso.c /home/frogger/ptxdist/ptxdist-cris/build/uClibc-0.9.20/ldso/ldso/ldso.c --- uClibc-0.9.20.orig/ldso/ldso/ldso.c Thu Jun 19 00:42:23 2003 +++ /home/frogger/ptxdist/ptxdist-cris/build/uClibc-0.9.20/ldso/ldso/ldso.c Mon Jul 7 20:08:14 2003 @@ -105,6 +105,7 @@ * application. */ +#include #include "ld_syscall.h" #include "linuxelf.h" #include "ld_hash.h" diff -ur uClibc-0.9.20.orig/ldso/libdl/dlib.c /home/frogger/ptxdist/ptxdist-cris/build/uClibc-0.9.20/ldso/libdl/dlib.c --- uClibc-0.9.20.orig/ldso/libdl/dlib.c Fri Jun 27 13:45:12 2003 +++ /home/frogger/ptxdist/ptxdist-cris/build/uClibc-0.9.20/ldso/libdl/dlib.c Mon Jul 7 20:08:14 2003 @@ -4,6 +4,7 @@ * Functions required for dlopen et. al. */ +#include #include #include #include "dlfcn.h" diff -ur uClibc-0.9.20.orig/libc/inet/socketcalls.c /home/frogger/ptxdist/ptxdist-cris/build/uClibc-0.9.20/libc/inet/socketcalls.c --- uClibc-0.9.20.orig/libc/inet/socketcalls.c Sun Jul 7 09:27:42 2002 +++ /home/frogger/ptxdist/ptxdist-cris/build/uClibc-0.9.20/libc/inet/socketcalls.c Mon Jul 7 20:08:14 2003 @@ -1,4 +1,5 @@ #define __FORCE_GLIBC +#include #include #include #include diff -ur uClibc-0.9.20.orig/libc/misc/sysvipc/msgq.c /home/frogger/ptxdist/ptxdist-cris/build/uClibc-0.9.20/libc/misc/sysvipc/msgq.c --- uClibc-0.9.20.orig/libc/misc/sysvipc/msgq.c Thu May 30 02:41:03 2002 +++ /home/frogger/ptxdist/ptxdist-cris/build/uClibc-0.9.20/libc/misc/sysvipc/msgq.c Mon Jul 7 20:08:14 2003 @@ -1,3 +1,4 @@ +#include #include #include #include "ipc.h" diff -ur uClibc-0.9.20.orig/libc/misc/sysvipc/sem.c /home/frogger/ptxdist/ptxdist-cris/build/uClibc-0.9.20/libc/misc/sysvipc/sem.c --- uClibc-0.9.20.orig/libc/misc/sysvipc/sem.c Sun Aug 25 02:08:23 2002 +++ /home/frogger/ptxdist/ptxdist-cris/build/uClibc-0.9.20/libc/misc/sysvipc/sem.c Mon Jul 7 20:08:14 2003 @@ -17,6 +17,7 @@ write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. */ +#include #include #include #include "ipc.h" diff -ur uClibc-0.9.20.orig/libc/misc/sysvipc/shm.c /home/frogger/ptxdist/ptxdist-cris/build/uClibc-0.9.20/libc/misc/sysvipc/shm.c --- uClibc-0.9.20.orig/libc/misc/sysvipc/shm.c Thu May 30 02:41:03 2002 +++ /home/frogger/ptxdist/ptxdist-cris/build/uClibc-0.9.20/libc/misc/sysvipc/shm.c Mon Jul 7 20:08:14 2003 @@ -17,6 +17,7 @@ write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. */ +#include #include #include #include diff -ur uClibc-0.9.20.orig/libc/sysdeps/linux/common/_exit.c /home/frogger/ptxdist/ptxdist-cris/build/uClibc-0.9.20/libc/sysdeps/linux/common/_exit.c --- uClibc-0.9.20.orig/libc/sysdeps/linux/common/_exit.c Mon Jul 22 19:11:58 2002 +++ /home/frogger/ptxdist/ptxdist-cris/build/uClibc-0.9.20/libc/sysdeps/linux/common/_exit.c Mon Jul 7 20:08:14 2003 @@ -21,6 +21,7 @@ */ #define _GNU_SOURCE +#include #include #include #include diff -ur uClibc-0.9.20.orig/libc/sysdeps/linux/common/create_module.c /home/frogger/ptxdist/ptxdist-cris/build/uClibc-0.9.20/libc/sysdeps/linux/common/create_module.c --- uClibc-0.9.20.orig/libc/sysdeps/linux/common/create_module.c Fri Nov 15 15:06:43 2002 +++ /home/frogger/ptxdist/ptxdist-cris/build/uClibc-0.9.20/libc/sysdeps/linux/common/create_module.c Mon Jul 7 20:08:14 2003 @@ -20,6 +20,7 @@ * Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ +#include #include #include #include diff -ur uClibc-0.9.20.orig/libc/sysdeps/linux/common/getdents.c /home/frogger/ptxdist/ptxdist-cris/build/uClibc-0.9.20/libc/sysdeps/linux/common/getdents.c --- uClibc-0.9.20.orig/libc/sysdeps/linux/common/getdents.c Mon Feb 10 22:15:20 2003 +++ /home/frogger/ptxdist/ptxdist-cris/build/uClibc-0.9.20/libc/sysdeps/linux/common/getdents.c Mon Jul 7 20:08:14 2003 @@ -16,6 +16,7 @@ Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. */ +#include #include #include #include diff -ur uClibc-0.9.20.orig/libc/sysdeps/linux/common/sync.c /home/frogger/ptxdist/ptxdist-cris/build/uClibc-0.9.20/libc/sysdeps/linux/common/sync.c --- uClibc-0.9.20.orig/libc/sysdeps/linux/common/sync.c Mon Jul 22 19:11:58 2002 +++ /home/frogger/ptxdist/ptxdist-cris/build/uClibc-0.9.20/libc/sysdeps/linux/common/sync.c Mon Jul 7 20:08:14 2003 @@ -21,6 +21,7 @@ */ #define _GNU_SOURCE +#include #include #include #include diff -ur uClibc-0.9.20.orig/libc/sysdeps/linux/common/syscalls.c /home/frogger/ptxdist/ptxdist-cris/build/uClibc-0.9.20/libc/sysdeps/linux/common/syscalls.c --- uClibc-0.9.20.orig/libc/sysdeps/linux/common/syscalls.c Fri Jun 27 09:36:43 2003 +++ /home/frogger/ptxdist/ptxdist-cris/build/uClibc-0.9.20/libc/sysdeps/linux/common/syscalls.c Mon Jul 7 20:08:14 2003 @@ -32,6 +32,7 @@ # undef __USE_FILE_OFFSET64 #endif +#include #include #include #include diff -ur uClibc-0.9.20.orig/libc/sysdeps/linux/cris/bits/syscalls.h /home/frogger/ptxdist/ptxdist-cris/build/uClibc-0.9.20/libc/sysdeps/linux/cris/bits/syscalls.h --- uClibc-0.9.20.orig/libc/sysdeps/linux/cris/bits/syscalls.h Fri Sep 20 17:17:16 2002 +++ /home/frogger/ptxdist/ptxdist-cris/build/uClibc-0.9.20/libc/sysdeps/linux/cris/bits/syscalls.h Mon Jul 7 20:23:14 2003 @@ -6,7 +6,7 @@ #endif /* Include the __NR_ definitions. */ -#include +/*#include */ #if 0 #ifndef __set_errno From simon at activetools.si Mon Jul 7 19:20:08 2003 From: simon at activetools.si (Simon Posnjak) Date: Mon, 07 Jul 2003 19:20:08 -0000 Subject: [uClibc] CRIS port In-Reply-To: <20030707185316.GA11380@timberwolf.dyndns.org> References: <20030707185316.GA11380@timberwolf.dyndns.org> Message-ID: <1057605543.5308.14.camel@klada.dyndns.org> Na 1057603996, 2003-07-07 ob 20:53, je Marc Kleine-Budde napisal(a): > I'm using binutils 2.13.2.1, gcc 3.2.3 with the fixes and patches from > buildroot. Is this tool chain stable? > cris-uclibc-linux-gcc -Wall -Wstrict-prototypes -Wno-trigraphs > -fno-strict-aliasing -Os -mlinux -fno-builtin -nostdinc -D_LIBC > -I../../include -I. > -I/home/frogger/ptxdist/xchain-cris/lib/gcc-lib/cris-uclibc-linux/3.2.3/include > -DNDEBUG -fpic -mlinux -DUCLIBC_TARGET_PREFIX=\"/\" > -DUCLIBC_DEVEL_PREFIX=\""/home/frogger/ptxdist/xchain-cris/cris-uclibc-linux"\" > -DUCLIBC_BUILD_DIR=\"/home/frogger/projects/ptxdist/ptxdist-cris/build/uClibc-0.9.20\" > -I. -I./cris -I../libdl -c ldso.c -o ldso.o > In file included from ../../include/sys/syscall.h:23, > from cris/ld_syscalls.h:7, > from ld_syscall.h:6, > from ldso.c:108: > ../../include/bits/syscalls.h:9:26: bits/syscall.h: No such file or > directory This will fix the error (found it going throu CVS logs): diff -uNr uClibc-0.9.20-orig/libc/sysdeps/linux/cris/bits/syscalls.h uClibc-0.9.20/libc/sysdeps/linux/cris/bits/syscalls.h --- uClibc-0.9.20-orig/libc/sysdeps/linux/cris/bits/syscalls.h 2002-09-20 17:17:16.000000000 +0200 +++ uClibc-0.9.20/libc/sysdeps/linux/cris/bits/syscalls.h 2003-07-04 11:46:06.000000000 +0200 @@ -6,7 +6,7 @@ #endif /* Include the __NR_ definitions. */ -#include +#include #if 0 #ifndef __set_errno > after some random hacking and stumbling over another 'bug' [1] it > compiles > at least. I had no time to test it on the cris itself......See attached > diff. I also found and fixed this little bug. And also a lot of missing #if defind in ldso/ldso/cris/elfinterp.c (debugging). Peter is there any chance that we could get your version of uClibc (or patches for mainstram) which works. (The one I hacked up seams to have some probles - after kernel boot system hangs - I'm just preparing to have a look whats going on) Regards Simon From kleine-budde at gmx.de Mon Jul 7 20:13:47 2003 From: kleine-budde at gmx.de (Marc Kleine-Budde) Date: Mon, 7 Jul 2003 22:13:47 +0200 Subject: [uClibc] CRIS port In-Reply-To: <1057605543.5308.14.camel@klada.dyndns.org> References: <20030707185316.GA11380@timberwolf.dyndns.org> <1057605543.5308.14.camel@klada.dyndns.org> Message-ID: <20030707201347.GA23298@timberwolf.dyndns.org> Hi On Mon, Jul 07, 2003 at 09:19:03PM +0200, Simon Posnjak wrote: > Na 1057603996, 2003-07-07 ob 20:53, je Marc Kleine-Budde napisal(a): > > I'm using binutils 2.13.2.1, gcc 3.2.3 with the fixes and patches from > > buildroot. > Is this tool chain stable? with this toolchain it's possible to compile glibc-2.2.5 (with some fixes). and we (a colleague actually) managed to get a glibc based system running....but we haven't tried the uClibc based jet.... > This will fix the error (found it going throu CVS logs): thanks regards - marc -- #!/bin/sh set - `type $0` 'tr "[a-zA-Z]" "[n-za-mN-ZA-M]"';while [ "$2" != "" ];do \ shift;done; echo 'frq -a -rc '`echo "$0"| $1 `'>$UBZR/.`rpub signature|'`\ echo $1|$1`'`;rpub "Jr ner fvtangher bs obet. Erfvfgnapr vf shgvyr!"'|$1|sh From simon at activetools.si Mon Jul 7 21:33:22 2003 From: simon at activetools.si (Simon Posnjak) Date: Mon, 07 Jul 2003 21:33:22 -0000 Subject: [uClibc] CRIS port In-Reply-To: <1057605543.5308.14.camel@klada.dyndns.org> References: <20030707185316.GA11380@timberwolf.dyndns.org> <1057605543.5308.14.camel@klada.dyndns.org> Message-ID: <1057613557.5308.31.camel@klada.dyndns.org> Na 1057605543, 2003-07-07 ob 21:19, je Simon Posnjak napisal(a): > Peter is there any chance that we could get your version of uClibc (or > patches for mainstram) which works. (The one I hacked up seams to have > some probles - after kernel boot system hangs - I'm just preparing to > have a look whats going on) Did some digging and discovered that dynamic linker dos not work at all. [First I compiled may distribution dynamical and nothing worked, then I complied init staticly and it worked (init that is, nothing else)]. ldd for dynamicaly linked init shows: [root at l15 tmp]# cris-uclibc-ldd init libc.so.0 => /work/buildroot/build/stage/lib/libc.so.0 (0x00000000) <---- /lib//ld-uClibc.so.0 => /lib//ld-uClibc.so.0 (0x00000000) [root at l15 tmp]# Is this correct (the first line)? If not any idea what is cosing it. init was compiled as(gcc_cris is a wrapper which is used by Axis to compile with uclibc): gcc_cris -mlinux -muclibc=/work/buildroot/build/stage/ -o init init.c and all so as: cris-uclibc-gcc -mlinux -isystem /usr/local/cris/lib/gcc-lib/cris/2.96/include -o init init.c THX, simon From vapier at gentoo.org Mon Jul 7 23:18:30 2003 From: vapier at gentoo.org (Mike Frysinger) Date: Mon, 7 Jul 2003 19:18:30 -0400 Subject: [uClibc] substr -g CFLAGS Message-ID: <200307071918.35489.vapier@gentoo.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 in some Makefiles you can find this code: SAFEFLAGS := $(subst -g,,$(CFLAGS)) which is all fine and dandy except for when CFLAGS contains a string that has '-g' in it ... specifically, i hit a case where gcc stores it's include files in /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/include/ ... when uclibc went to compile, gcc received '-I/usr/lib/gcc-lib/i686-pc-linuxnu/3.2.3/include' causing it to fail (because it couldnt locate stddef.h in this case). any thoughts on this ? one way of 'fixing' it would be to change the code to: SAFEFLAGS := $(subst -g ,, $(CFLAGS) ) notice the crazy usage of spaces ... ive attached an example Makefile to further illustrate my point ... - -mike -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iQIVAwUBPwn/y0FjO5/oN/WBAQKDpQ/+J+0V4+BUFrLKadlAJYJ39zpEQiT0kNQ4 TiIHbDojuiA/0p0tW4HHZIU3WcMCqU3DEHFEtJxcJGrGyGAjMv910ZiL1BgYqQC5 Vn2Yw86znf/GmpL0DNe67BBwqC6K1QyTr5S4sGFzlYNegxeLBbm4Kmd0NKZmBW7f dAszrZNmIBKcTjdhOraaTK/MhRiVokDO1iQAjywD7g7Nr29xEuaT7MfoDpgd6k8d peVoVr1kEkXdLE/3OjWjEMoymqg8J+KJZDBg1X8VCG3R0jYv3SltS05VQllxt6sB AjzrpkagOECg/7mdyscQ+ajGBbhRtofr4UpELNYXLm5QUN0dg0D4azilaBsbZ+Ck Fb3LKH+u28O9w1/CgEWkP7zV9+SscOGwl3t7QfZkHZtTKpDs/5KtJiUfzC7bFqAk RwUDTQDj7zT6pHVJDCXCZz3CFhvj68mKqfQnshJPqkX/gggi6eynrmpvN1PNDtBH TAgXXafkBS2UMERNjhVaZBAYNwp4L4H4glDfCLFow7/h0hVlznP10q5+ybak2y2+ yLj5GWezoPvXrHspLghyrz7TOFB8ivckiMhcnD1XtUYHLNI78le5e9gYq9W3zY1P u1LN0qOKJComXwzsHL0bwSTb/rKrnbIA1naMcbpLEyiO9QlErlRfhI7+NvMkNp4S NWUtdmmOCTg= =EYZd -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile Type: text/x-makefile Size: 425 bytes Desc: not available Url : http://lists.busybox.net/pipermail/uclibc/attachments/20030707/efb410be/attachment.bin From dpforos at yahoo.com Tue Jul 8 00:42:00 2003 From: dpforos at yahoo.com (Daniel Pezoa) Date: Mon, 7 Jul 2003 17:42:00 -0700 (PDT) Subject: [uClibc] Web Browser Uclibc Message-ID: <20030708004200.74996.qmail@web11201.mail.yahoo.com> Hello uClibc Community I want to have one graphical web browser uClibc compiled for my x86 box. If any have succesfully compiled any graphical web browser and can share the experience, i will be happy with it. Good luck! Daniel Pezoa __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com From uclibc at lacklustre.net Tue Jul 8 00:51:37 2003 From: uclibc at lacklustre.net (Michael Ryan) Date: Mon, 7 Jul 2003 17:51:37 -0700 Subject: [uClibc] Web Browser Uclibc In-Reply-To: <20030708004200.74996.qmail@web11201.mail.yahoo.com> References: <20030708004200.74996.qmail@web11201.mail.yahoo.com> Message-ID: <20030707175137.20f35ad9.uclibc@lacklustre.net> I haven't tried to compile it, but take a look at Dillo. It would probably work. http://www.dillo.org/ Best of luck. On Mon, 7 Jul 2003 17:42:00 -0700 (PDT) Daniel Pezoa wrote: > Hello uClibc Community > > I want to have one graphical web browser uClibc > compiled for my x86 box. If any have succesfully > compiled any graphical web browser and can share the > experience, i will be happy with it. > > Good luck! > > Daniel Pezoa > > > __________________________________ > Do you Yahoo!? > SBC Yahoo! DSL - Now only $29.95 per month! > http://sbc.yahoo.com > _______________________________________________ > uClibc mailing list > uClibc at uclibc.org > http://uclibc.org/mailman/listinfo/uclibc > -- Michael Ryan Lacklustre Networking michael at lacklustre.net http://www.lacklustre.net/ From alex at king.net.nz Tue Jul 8 01:05:51 2003 From: alex at king.net.nz (Alex King) Date: Tue, 8 Jul 2003 13:05:51 +1200 Subject: [uClibc] Web Browser Uclibc In-Reply-To: <20030708004200.74996.qmail@web11201.mail.yahoo.com> References: <20030708004200.74996.qmail@web11201.mail.yahoo.com> Message-ID: <20030708010550.GA12343@king.net.nz> I sucessfully compiled/run links which runs in a graphical mode directly on the linux framebuffer (http://atrey.karlin.mff.cuni.cz/~clock/twibright/links/) It doesn't display all images (GIFs I suspect). compiles to 2.7M, depends on png and jpeg libs which I compiled sucessfully also, and on gpm for mouse. On Mon, Jul 07, 2003 at 05:42:00PM -0700, Daniel Pezoa wrote: > Hello uClibc Community > > I want to have one graphical web browser uClibc > compiled for my x86 box. If any have succesfully > compiled any graphical web browser and can share the > experience, i will be happy with it. > > Good luck! > > Daniel Pezoa > > > __________________________________ > Do you Yahoo!? > SBC Yahoo! DSL - Now only $29.95 per month! > http://sbc.yahoo.com > _______________________________________________ > uClibc mailing list > uClibc at uclibc.org > http://uclibc.org/mailman/listinfo/uclibc From ibe at dcl.info.waseda.ac.jp Tue Jul 8 08:18:05 2003 From: ibe at dcl.info.waseda.ac.jp (ibe at dcl.info.waseda.ac.jp) Date: Tue, 8 Jul 2003 17:18:05 +0900 (JST) Subject: [uClibc]can't resolve symbol. Message-ID: <41672.202.232.97.131.1057652285.squirrel@mail2.dcl.info.waseda.ac.jp> Hi all, I am finally succesfully build uClibc with a powerpc gcc cross compiler. (I use 2.4.18 in Montavista linux PE3.0.) But I have some trouble when using some command like ls, mount or other. # ls ls: can't resolve symbol '__eqdf2' ls: can't resolve symbol '__floatsidf' ls: can't resolve symbol '__ltdf2' ls: can't resolve symbol '__adddf3' ls: can't resolve symbol '__fixdfsi' ls: can't resolve symbol '__negdf2' ls: can't resolve symbol '__divdf3' ls: can't resolve symbol '__muldf3' ls: can't resolve symbol '__truncdfsf2' ls: can't resolve symbol '__nedf2' ls: can't resolve symbol '__gedf2' ls: can't resolve symbol '__subdf3' bin dev proc usr boot etc linuxrc sbin # I think this problem is due to .config of uClibc. So, I try to enable libgcc option in "make menuconfig" of uClibc. General Library Settings ---> Add unresolved libgcc symbols to uClibc Y In this time, Although, my kernel stop after this message while booting. "Freeing unused kernel memory : 56k init" I found a hint in a log of make. ppc_8xx-ld -s -shared --warn-common --warn-once -z combreloc -soname=libc.so.0 -o libuClibc-0.9.19.so \ --whole-archive ./tmp/libgcc-need.a libc.a \ ..//libc/misc/internals/interp.o --no-whole-archive \ -init __uClibc_init /opt/hardhat/devkit/ppc/8xx/lib/gcc-lib/powerpc-hardhat-linux/3.2.1/libgcc.a and I tried to remove -s option and remake uClibc, then I make sure of symbol of libuClibc-0.9.19.so. $ nm libuClibc-0.9.19.so a part of result : 00000898 t __adddf3 00000af0 t __divdf3 00000d6c t __eqdf2 00000a40 t __fixdfsi 00001a08 t __floatsidf 00000f74 t __gedf2 00001050 t __ltdf2 00001114 t __muldf3 00001580 t __nedf2 0000160c t __negdf2 00000904 t __subdf3 000009cc t __truncdfsf2 All symbol type of libgcc is 't'(symbol is local). Although, my libgcc-need.a has a global symbol as below. $ nm libgcc-need.a _addsub_df.oS: 00000384 T __adddf3 ... Why does all symbol type of libgcc in libuClibc-0.9.19.so change into local? From slarty2 at ntlworld.com Tue Jul 8 09:11:29 2003 From: slarty2 at ntlworld.com (Mark Robson) Date: Tue, 8 Jul 2003 10:11:29 +0100 Subject: [uClibc] Web Browser Uclibc In-Reply-To: <20030708004200.74996.qmail@web11201.mail.yahoo.com> References: <20030708004200.74996.qmail@web11201.mail.yahoo.com> Message-ID: <20030708091130.RSCO4771.mta02-svc.ntlworld.com@there> > I want to have one graphical web browser uClibc > compiled for my x86 box. If any have succesfully > compiled any graphical web browser and can share the > experience, i will be happy with it. I also built the graphical console version of "links" using svgalib. The main problem is that the way it stores its fonts is hideously inefficient and hence I had to remove a lot of fonts to fit it on a floppy. It also needs libjpeg which I didn't quite have space for, but it works fine without it (just doesn't display jpegs) Mark From ibe at dcl.info.waseda.ac.jp Tue Jul 8 09:30:12 2003 From: ibe at dcl.info.waseda.ac.jp (ibe at dcl.info.waseda.ac.jp) Date: Tue, 8 Jul 2003 18:30:12 +0900 (JST) Subject: [uClibc]can't resolve symbol. In-Reply-To: <41672.202.232.97.131.1057652285.squirrel@mail2.dcl.info.waseda.ac.jp> References: <41672.202.232.97.131.1057652285.squirrel@mail2.dcl.info.waseda.ac.jp> Message-ID: <45070.202.232.97.131.1057656612.squirrel@mail2.dcl.info.waseda.ac.jp> Hi, By the way, what is .oS? Is it as same as .o? My libgcc.a has some .oS. $ nm libgcc.a _addsub_df.oS: 00000384 T __adddf3 U __pack_d 000003f0 T __subdf3 U __thenan_df U __unpack_d 00000004 t _fpadd_parts _ashldi3.oS: 00000000 T __ashldi3 _df_to_sf.oS: U __make_fp 00000000 T __truncdfsf2 U __unpack_d _df_to_si.oS: 00000000 T __fixdfsi U __lshrdi3 U __unpack_d _div_df.oS: 00000000 T __divdf3 U __pack_d U __thenan_df U __unpack_d 0000006c t _fpdiv_parts _eq_df.oS: 00000000 T __eqdf2 U __fpcmp_parts_d U __unpack_d _fpcmp_parts_df.oS: 00000000 T __fpcmp_parts_d _ge_df.oS: U __fpcmp_parts_d 00000000 T __gedf2 U __unpack_d _lshrdi3.oS: 00000000 T __lshrdi3 _lt_df.oS: U __fpcmp_parts_d 00000000 T __ltdf2 U __unpack_d _make_sf.oS: 00000000 T __make_fp U __pack_f _mul_df.oS: 00000000 T __muldf3 U __pack_d U __thenan_df U __unpack_d 00000070 t _fpmul_parts _ne_df.oS: U __fpcmp_parts_d 00000000 T __nedf2 U __unpack_d _negate_df.oS: 00000000 T __negdf2 U __pack_d U __unpack_d _pack_df.oS: U __ashldi3 U __lshrdi3 00000000 T __pack_d _pack_sf.oS: 00000000 T __pack_f _si_to_df.oS: 00000000 T __floatsidf U __pack_d _thenan_df.oS: 00000000 R __thenan_df _unpack_df.oS: 00000000 T __unpack_d I am Sorry to boring question. From ps.m at gmx.net Tue Jul 8 14:55:23 2003 From: ps.m at gmx.net (Peter S. Mazinger) Date: Tue, 8 Jul 2003 16:55:23 +0200 (CEST) Subject: [uClibc] ldd and cvs20030708 Message-ID: Hello! The change for ldd in cvs solves the ldd coredump ran against dynamic libraries, it returns "not a dynamic executable". glibc's ldd returns the dynamic loader /lib/ld-linux.so.2 I have checked strings libuClibc-0.9.20.so, the loader is there as /lib/ld-uClibc.so.0. Well, I do not know, which is the correct behaviour, so take it only as a status report. Thanks, Peter -- Peter S. Mazinger ID: 0xA5F059F2 NIC: IXUYHSKQLI Key fingerprint = 92A4 31E1 56BC 3D5A 2D08 BB6E C389 975E A5F0 59F2 From dpforos at yahoo.com Tue Jul 8 17:21:18 2003 From: dpforos at yahoo.com (Daniel Pezoa) Date: Tue, 8 Jul 2003 10:21:18 -0700 (PDT) Subject: [uClibc] Web Browser Uclibc In-Reply-To: <20030707175137.20f35ad9.uclibc@lacklustre.net> Message-ID: <20030708172118.13377.qmail@web11208.mail.yahoo.com> Thanks it compile! For the moment i need to make some corrections, because it attempt to create some .dillo directory in my read only ram filesystem. And next it abort the execution. Good luck! Daniel Pezoa --- Michael Ryan wrote: > I haven't tried to compile it, but take a look at > Dillo. It would probably work. http://www.dillo.org/ > > Best of luck. > > On Mon, 7 Jul 2003 17:42:00 -0700 (PDT) > Daniel Pezoa wrote: > > > Hello uClibc Community > > > > I want to have one graphical web browser uClibc > > compiled for my x86 box. If any have succesfully > > compiled any graphical web browser and can share > the > > experience, i will be happy with it. > > > > Good luck! > > > > Daniel Pezoa > > > > > > __________________________________ > > Do you Yahoo!? > > SBC Yahoo! DSL - Now only $29.95 per month! > > http://sbc.yahoo.com > > _______________________________________________ > > uClibc mailing list > > uClibc at uclibc.org > > http://uclibc.org/mailman/listinfo/uclibc > > > > > -- > Michael Ryan > Lacklustre Networking > > michael at lacklustre.net > http://www.lacklustre.net/ > _______________________________________________ > uClibc mailing list > uClibc at uclibc.org > http://uclibc.org/mailman/listinfo/uclibc __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com From mad at citynet.net.ar Tue Jul 8 20:02:33 2003 From: mad at citynet.net.ar (Mariano Drzazga) Date: Tue, 8 Jul 2003 17:02:33 -0300 Subject: [uClibc] upnp-igd compling against uclibc Message-ID: <003c01c3458b$ded09c50$0101a8c0@citynet2.com> Hi, I get the following error when I try to compile the upnpsdk-1.0.4 sources using uClibc. I'm using uClibc 0.9.20 (I chroot into the 150MB ext2 filesystem that I downloaded form www.uclibc.org Any suggestions would be appreciated. Thanks in advance Mariano Drzazga. make[2]: Entering directory `/home/upnpsdk-1.0.4/src/upnpdom' g++ -fpic -Wall -D_REENTRANT -O2 -DNO_DEBUG -DINCLUDE_CLIENT_APIS -DINCLUDE_DEVICE_APIS -c -I ../../inc/upnpdom -I ../inc domCif.cpp In file included from ../../inc/upnpdom/iostream.h:31, from domCif.cpp:40: ../../inc/upnpdom/backward_warning.h:32:2: warning: #warning This file includes at least one deprecated or antiquated header. Please consider using one of the 32 headers found in section 17.4.1.2 of the C++ standard. Examples include substituting the header for the header for C++ includes, or instead of the deprecated header . To disable this warning use -Wno-deprecated. In file included from domCif.cpp:40: ../../inc/upnpdom/iostream.h:32:20: iostream: No such file or directory In file included from domCif.cpp:40: ../../inc/upnpdom/iostream.h:34: error: `iostream' not declared ../../inc/upnpdom/iostream.h:35: error: `ostream' not declared ../../inc/upnpdom/iostream.h:36: error: `istream' not declared ../../inc/upnpdom/iostream.h:37: error: `ios' not declared ../../inc/upnpdom/iostream.h:38: error: `streambuf' not declared ../../inc/upnpdom/iostream.h:40: error: `cout' not declared From tom at ceisystems.com Tue Jul 8 20:45:16 2003 From: tom at ceisystems.com (tom at ceisystems.com) Date: Tue, 8 Jul 2003 16:45:16 -0400 Subject: [uClibc] upnp-igd compling against uclibc Message-ID: <6D31D5429FA6884CBE9ECAB6C9B5E6A907E08F@intel-srvr.patcameron.ne.mediaone.net> Mariano, I believe it has been posted here that streams are not supported under uClibc. I do not know if they are in the works for a later release, or if there is even a desire to get them to work. My suggestion would be to attempt to statically compile the uPNP libraries against the standard Glibc, and see where that gets you. Good luck, Thomas Cameron CEI Systems, Inc. -----Original Message----- From: Mariano Drzazga [mailto:mad at citynet.net.ar] Sent: Tuesday, July 08, 2003 4:03 PM To: uclibc at uclibc.org Subject: [uClibc] upnp-igd compling against uclibc Hi, I get the following error when I try to compile the upnpsdk-1.0.4 sources using uClibc. I'm using uClibc 0.9.20 (I chroot into the 150MB ext2 filesystem that I downloaded form www.uclibc.org Any suggestions would be appreciated. Thanks in advance Mariano Drzazga. make[2]: Entering directory `/home/upnpsdk-1.0.4/src/upnpdom' g++ -fpic -Wall -D_REENTRANT -O2 -DNO_DEBUG -DINCLUDE_CLIENT_APIS -DINCLUDE_DEVICE_APIS -c -I ../../inc/upnpdom -I ../inc domCif.cpp In file included from ../../inc/upnpdom/iostream.h:31, from domCif.cpp:40: ../../inc/upnpdom/backward_warning.h:32:2: warning: #warning This file includes at least one deprecated or antiquated header. Please consider using one of the 32 headers found in section 17.4.1.2 of the C++ standard. Examples include substituting the header for the header for C++ includes, or instead of the deprecated header . To disable this warning use -Wno-deprecated. In file included from domCif.cpp:40: ../../inc/upnpdom/iostream.h:32:20: iostream: No such file or directory In file included from domCif.cpp:40: ../../inc/upnpdom/iostream.h:34: error: `iostream' not declared ../../inc/upnpdom/iostream.h:35: error: `ostream' not declared ../../inc/upnpdom/iostream.h:36: error: `istream' not declared ../../inc/upnpdom/iostream.h:37: error: `ios' not declared ../../inc/upnpdom/iostream.h:38: error: `streambuf' not declared ../../inc/upnpdom/iostream.h:40: error: `cout' not declared _______________________________________________ uClibc mailing list uClibc at uclibc.org http://uclibc.org/mailman/listinfo/uclibc From mjn3 at codepoet.org Tue Jul 8 21:00:26 2003 From: mjn3 at codepoet.org (Manuel Novoa III) Date: Tue, 8 Jul 2003 15:00:26 -0600 Subject: [uClibc] upnp-igd compling against uclibc In-Reply-To: <6D31D5429FA6884CBE9ECAB6C9B5E6A907E08F@intel-srvr.patcameron.ne.mediaone.net> References: <6D31D5429FA6884CBE9ECAB6C9B5E6A907E08F@intel-srvr.patcameron.ne.mediaone.net> Message-ID: <20030708210026.GA23105@codepoet.org> Tom, On Tue, Jul 08, 2003 at 04:45:16PM -0400, tom at ceisystems.com wrote: > Mariano, > I believe it has been posted here that streams are not supported > under uClibc. I do not know if they are in the works for a later > release, or if there is even a desire to get them to work. My > suggestion would be to attempt to statically compile the uPNP libraries > against the standard Glibc, and see where that gets you. You're confusing the STREAMS functions prototyped in strotps.h with standard C++ streams. uClibc doesn't support stropts.h and the associated STREAMS functions. However, a uClibc version of libstd++ (say from buildroot) should support C++ streams. Manuel From f.callaghan at ieee.org Tue Jul 8 21:10:11 2003 From: f.callaghan at ieee.org (Frank R Callaghan) Date: Tue, 8 Jul 2003 17:10:11 -0400 Subject: [uClibc] system call segfault! Message-ID: <200307081710.11423.f.callaghan@ieee.org> Hi All I'm using uClibc.0.9.19, 2.4.19 + jffs2(from cvs) + busybox-0.60.5 + rtai I have been trying to track down a problem with my embedded prog segfaulting and found that with only system("ps -ax"); SegFaults ! (gdb) run Starting program: /myapp/test1 Running ps (no debugging symbols found)...(no debugging symbols found)... Program received signal SIGSEGV, Segmentation fault. 0x40013cd0 in _dl_envp () from /usr/i386-linux-uclibc/lib/libc.so.0 PID TTY Uid Size State Command 1 root 468 S init 2 root 0 S [keventd] 3 root 0 S [ksoftirqd_CPU0] 4 root 0 S [kswapd] 5 root 0 S [bdflush] 6 root 0 S [kupdated] 7 root 0 S [mtdblockd] 11 root 0 S [kjournald] 50 root 0 S [rpciod] 54 root 0 S [kjournald] 86 ttyS1 root 496 S -sh 161 ttyS1 root 3756 S gdb test1 162 ttyS1 root 348 T /myapp/test1 163 ttyS1 root 492 S sh -c ps -ax 164 ttyS1 root 460 R ps -ax (gdb) bt #0 0x40013cd0 in _dl_envp () from /usr/i386-linux-uclibc/lib/libc.so.0 #1 0x4003da79 in system () from /usr/i386-linux-uclibc/lib/libc.so.0 #2 0x0804844b in main () #3 0x40017624 in __uClibc_start_main () from /usr/i386-linux-uclibc/lib/libc.so.0 #4 0x08048424 in _start () (gdb) Any help greatly appreciated, TIA, Frank. From andersen at codepoet.org Tue Jul 8 21:32:19 2003 From: andersen at codepoet.org (Erik Andersen) Date: Tue, 8 Jul 2003 15:32:19 -0600 Subject: [uClibc]can't resolve symbol. In-Reply-To: <45070.202.232.97.131.1057656612.squirrel@mail2.dcl.info.waseda.ac.jp> References: <41672.202.232.97.131.1057652285.squirrel@mail2.dcl.info.waseda.ac.jp> <45070.202.232.97.131.1057656612.squirrel@mail2.dcl.info.waseda.ac.jp> Message-ID: <20030708213219.GA23791@codepoet.org> On Tue Jul 08, 2003 at 06:30:12PM +0900, ibe at dcl.info.waseda.ac.jp wrote: > Hi, > > By the way, what is .oS? > Is it as same as .o? > My libgcc.a has some .oS. ".oS" is the convention used by some GNU packages such as glibc for object files that were compiled as PIC code. -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- From ibe at dcl.info.waseda.ac.jp Tue Jul 8 22:49:27 2003 From: ibe at dcl.info.waseda.ac.jp (ibe at dcl.info.waseda.ac.jp) Date: Wed, 9 Jul 2003 07:49:27 +0900 (JST) Subject: [uClibc]can't resolve symbol. Message-ID: <1144.133.9.91.177.1057704567.squirrel@mail2.dcl.info.waseda.ac.jp> Thanks, Erik. > > Hi, > > > > By the way, what is .oS? > > Is it as same as .o? > > My libgcc.a has some .oS. > > ".oS" is the convention used by some GNU packages such as > glibc for object files that were compiled as PIC code. > > -Erik By the way, Do you know why my symbol of libgcc can not be linked successfully? Is it concerned with .oS object? When I link symbol of libgcc to libuClibc-0.9.19.so, some symbol change its type. For example, In a libgcc.a -> 00000384 T __adddf3 In a libuClibc-0.9.19.so -> 00000898 t __adddf3 So It cause this problem when I use ls or something, # ls ls: can't resolve symbol '__adddf3' Link script is below, ppc_8xx-ld -s -shared --warn-common --warn-once -z combreloc -soname=libc.so.0 -o libuClibc-0.9.19.so \ --whole-archive ./tmp/libgcc-need.a libc.a \ ..//libc/misc/internals/interp.o --no-whole-archive \ -init __uClibc_init /opt/hardhat/devkit/ppc/8xx/lib/gcc-lib/powerpc-hardhat-linux/3.2.1/ libgcc.a //////////////////////////////////////////////// WASEDA UNIVERSITY Department of Information and Computer Science Ubiquitous & Distributed computing Lab. Hiroaki Ibe E-mail:ibe at dcl.info.waseda.ac.jp /////////////////////////////////////////////// From tom at ceisystems.com Tue Jul 8 23:21:58 2003 From: tom at ceisystems.com (tom at ceisystems.com) Date: Tue, 8 Jul 2003 19:21:58 -0400 Subject: [uClibc] upnp-igd compling against uclibc Message-ID: <6D31D5429FA6884CBE9ECAB6C9B5E6A907E090@intel-srvr.patcameron.ne.mediaone.net> Whoops, you're right. My mistake. Perhaps _I_ should re-read the archives. -----Original Message----- From: Manuel Novoa III [mailto:mjn3 at codepoet.org] Sent: Tuesday, July 08, 2003 5:00 PM To: Thomas Cameron Cc: mad at citynet.net.ar; uclibc at uclibc.org Subject: Re: [uClibc] upnp-igd compling against uclibc Tom, On Tue, Jul 08, 2003 at 04:45:16PM -0400, tom at ceisystems.com wrote: > Mariano, > I believe it has been posted here that streams are not supported > under uClibc. I do not know if they are in the works for a later > release, or if there is even a desire to get them to work. My > suggestion would be to attempt to statically compile the uPNP > libraries against the standard Glibc, and see where that gets you. You're confusing the STREAMS functions prototyped in strotps.h with standard C++ streams. uClibc doesn't support stropts.h and the associated STREAMS functions. However, a uClibc version of libstd++ (say from buildroot) should support C++ streams. Manuel From seh at zee2.com Wed Jul 9 12:04:53 2003 From: seh at zee2.com (Stuart Hughes) Date: Wed, 09 Jul 2003 13:04:53 +0100 Subject: [uClibc]can't resolve symbol. References: <1144.133.9.91.177.1057704567.squirrel@mail2.dcl.info.waseda.ac.jp> Message-ID: <3F0C04E5.1FC4EF24@zee2.com> ibe at dcl.info.waseda.ac.jp wrote: > > Thanks, Erik. > > > > Hi, > > > > > > By the way, what is .oS? > > > Is it as same as .o? > > > My libgcc.a has some .oS. > > > > ".oS" is the convention used by some GNU packages such as > > glibc for object files that were compiled as PIC code. > > > > -Erik > > By the way, Do you know why my symbol of libgcc can not be linked > successfully? > Is it concerned with .oS object? > > When I link symbol of libgcc to libuClibc-0.9.19.so, > some symbol change its type. > For example, > > In a libgcc.a -> > 00000384 T __adddf3 > > In a libuClibc-0.9.19.so -> > 00000898 t __adddf3 > > So It cause this problem when I use ls or something, > > # ls > ls: can't resolve symbol '__adddf3' > > Link script is below, > > ppc_8xx-ld -s -shared --warn-common --warn-once -z combreloc > -soname=libc.so.0 -o libuClibc-0.9.19.so \ > --whole-archive ./tmp/libgcc-need.a libc.a \ > ..//libc/misc/internals/interp.o --no-whole-archive \ > -init __uClibc_init > /opt/hardhat/devkit/ppc/8xx/lib/gcc-lib/powerpc-hardhat-linux/3.2.1/ > libgcc.a > I see the same problem on powerpc 8xx too. The work-around was to set: # UCLIBC_HAS_FLOATS is not set in the uclibc configuration. This is not a proper solution though as I can't work out why/how when busybox links it resolves __adddf3 and friends, but on the target when it runs, these symbols get reported as unresolved. Note I had wondered whether the linker should be using the shared libgcc_s library, but looking at the specs file for gcc, the default is to use the static libgcc and libgcc_eh libraries. Regards, Stuart From joerg.rensing at siemens.com Tue Jul 8 10:11:32 2003 From: joerg.rensing at siemens.com (Rensing Joerg ICM Bocholt) Date: Tue, 8 Jul 2003 12:11:32 +0200 Subject: [uClibc]uclibc buildroot woes Message-ID: <07A65A7D0D6CD311B0F900A0C99AFFF50B4FD101@bchk006a.bch.siemens.de> I really don't know if I'm to late for this patch, but I added the following lines to gcc_target.mk and the build of binutils and gcc works fine. <> ...................................................... Mit freundlichem Gruss / kind regards Joerg Rensing Siemens AG > Information and Communication Products > Communication Devices ICM CP RD SD2 > Frankenstr. 2 (Geb?ude 2401/4te Etage) > 46395 Bocholt > Phone: +49-2871-91-3341 > Fax: +49-2871-91-63341 > Mail: Mailto:joerg.rensing at siemens.com > -------------- next part -------------- A non-text attachment was scrubbed... Name: gcc_target.mk.diff Type: application/octet-stream Size: 852 bytes Desc: not available Url : http://lists.busybox.net/pipermail/uclibc/attachments/20030708/c864d492/attachment.obj From thomas.betker at siemens.com Wed Jul 9 13:41:10 2003 From: thomas.betker at siemens.com (Betker Thomas ICM CP RD SD 1) Date: Wed, 9 Jul 2003 15:41:10 +0200 Subject: [uClibc] Problems with pthreads / MIPS Message-ID: Hi all: We are experiencing a lot of problems with pthreads on a MIPS/MMU platform. Most tests were originally done with uclibc-0.9.12 (as provided by a third party), but were rechecked with a current CVS snapshot. We are using a 2.4.17 Linux kernel here. A. pthread_create() hangs (sometimes, not always - say 50%), i.e., the call won't return. [This one was not rechecked with uclibc-0.9.20 yet.] B. exit() hangs (always), if you have created any threads. The process doesn't terminate, not even the thread that called exit(). C. sigwait() doesn't work at all. If there is no signal, the call returns anyway, indicating a signal 0 (which doesn't exist). If there is a signal, it may be lost (not seen by any thread, which happens most of the time), or it may be received by a thread not waiting for it. D. The 'kill ' command usually kills the thread with the given , but not the whole process; i.e., the other threads may live on. Does anybody else have the same problems, or is it just me? And more important, is there anything I could do about it? Any ideas? I tried to run my test programs on a i386 platform (kernel 2.4.19), and everything worked as it should. The only exception was D., which occurs on i386 as well, but it's rather A. to C. I am concerned about. Best regards, Thomas Betker From joel at wmi.com Wed Jul 9 17:32:57 2003 From: joel at wmi.com (Joel Coltoff) Date: Wed, 9 Jul 2003 13:32:57 -0400 (EDT) Subject: [uClibc] Question on floating point exceptions Message-ID: Hi, We are using uclibc-0.9.19 on a MIPS 32355. This is a fixed point processor so we end up using the Algorithmics Floating Emulator. I'm trying to catch (or detect) floating point exceptions. I have no problem generating them but my programs always exit. The first thing I noticed is that there is no fenv.h file in /usr include. The file .../bits/fenv.h is there but that is not the one you include. What do I need to do to either catch a SIGFPE or use functions like feclearexcept() and fetestexcept()? This may be obvious but these past few weeks I've needed lots of smacks in the head to see even the painfully obvious. Thanks. -- Joel Coltoff We don't see things as they are, we see them as we are. -- Anais Nin From f.callaghan at ieee.org Wed Jul 9 17:39:48 2003 From: f.callaghan at ieee.org (Frank R Callaghan) Date: Wed, 9 Jul 2003 13:39:48 -0400 Subject: [uClibc] system call segfault! In-Reply-To: <200307081710.11423.f.callaghan@ieee.org> References: <200307081710.11423.f.callaghan@ieee.org> Message-ID: <200307091339.48824.f.callaghan@ieee.org> Fixed, just downloaded 0.9.20 built, installed and the system() problem dissapeared ! Thanks Guys. On Tuesday 08 July 2003 05:10 pm, Frank R Callaghan wrote: > Hi All > > I'm using uClibc.0.9.19, 2.4.19 + jffs2(from cvs) + busybox-0.60.5 + rtai > > I have been trying to track down a problem with my embedded prog > segfaulting and found that with only system("ps -ax"); SegFaults ! > > (gdb) run > Starting program: /myapp/test1 > Running ps > (no debugging symbols found)...(no debugging symbols found)... > Program received signal SIGSEGV, Segmentation fault. > 0x40013cd0 in _dl_envp () from /usr/i386-linux-uclibc/lib/libc.so.0 > PID TTY Uid Size State Command > 1 root 468 S init > 2 root 0 S [keventd] > 3 root 0 S [ksoftirqd_CPU0] > 4 root 0 S [kswapd] > 5 root 0 S [bdflush] > 6 root 0 S [kupdated] > 7 root 0 S [mtdblockd] > 11 root 0 S [kjournald] > 50 root 0 S [rpciod] > 54 root 0 S [kjournald] > 86 ttyS1 root 496 S -sh > 161 ttyS1 root 3756 S gdb test1 > 162 ttyS1 root 348 T /myapp/test1 > 163 ttyS1 root 492 S sh -c ps -ax > 164 ttyS1 root 460 R ps -ax > (gdb) bt > #0 0x40013cd0 in _dl_envp () from /usr/i386-linux-uclibc/lib/libc.so.0 > #1 0x4003da79 in system () from /usr/i386-linux-uclibc/lib/libc.so.0 > #2 0x0804844b in main () > #3 0x40017624 in __uClibc_start_main () > from /usr/i386-linux-uclibc/lib/libc.so.0 > #4 0x08048424 in _start () > (gdb) > > Any help greatly appreciated, > > TIA, > Frank. > > > > > > > > > _______________________________________________ > uClibc mailing list > uClibc at uclibc.org > http://uclibc.org/mailman/listinfo/uclibc From tom at ceisystems.com Wed Jul 9 20:10:13 2003 From: tom at ceisystems.com (tom at ceisystems.com) Date: Wed, 9 Jul 2003 16:10:13 -0400 Subject: [uClibc]uclibc buildroot woes Message-ID: <6D31D5429FA6884CBE9ECAB6C9B5E6A9445D@intel-srvr.patcameron.ne.mediaone.net> Gute abend, I appologise for my German, I have not spoken it in many years. Anyway, I think the best solution to this problem would be to use a variable, much like we do for "--target", and "--host" variables. This would allow people using other arch.'s to build the utils without having to modify the .mk files. As an example, this patch would make it impossible to compile gcc_target on, say, an ARM system, or even a PPC. Perhaps, we should add a variable into the main Makefile that contains our current architecture, much like in the Linux kernel compilation. Just my .02DM, Thomas Cameron CEI Systems, Inc. -----Original Message----- From: Rensing Joerg ICM Bocholt [mailto:joerg.rensing at siemens.com] Sent: Tuesday, July 08, 2003 6:12 AM To: uclibc at uclibc.org Subject: [uClibc]uclibc buildroot woes I really don't know if I'm to late for this patch, but I added the following lines to gcc_target.mk and the build of binutils and gcc works fine. <> ...................................................... Mit freundlichem Gruss / kind regards Joerg Rensing Siemens AG > Information and Communication Products > Communication Devices ICM CP RD SD2 > Frankenstr. 2 (Geb?ude 2401/4te Etage) > 46395 Bocholt > Phone: +49-2871-91-3341 > Fax: +49-2871-91-63341 > Mail: Mailto:joerg.rensing at siemens.com > From mrakes at vivato.net Thu Jul 10 01:20:11 2003 From: mrakes at vivato.net (Mark Rakes) Date: Wed, 9 Jul 2003 18:20:11 -0700 Subject: [uClibc] buildroot + uClibc + xscale??? Message-ID: Greetings. I'm trying to build a buildroot-uClibc toolchain for an xscale platform. I know this came up at least once in the past (see http://www.uclibc.org/lists/uclibc/2003-June/008696.html), but with no resolution that I can discover. From top-of-CVS buildroot, change ARCH to arm, and with the uClibc.config below, I get the same results Patrick did: make -C ldso make[2]: Entering directory `/home/mrakes/cvs/buildroot/build_arm/uClibc/ldso' make -C ldso; make[3]: Entering directory `/home/mrakes/cvs/buildroot/build_arm/uClibc/ldso/ldso' echo "const char *_dl_progname=\""ld-uClibc.so.0"\";" > ldso.h echo "#include \"arm/elfinterp.c\"" >> ldso.h /home/mrakes/cvs/buildroot/build_arm/staging_dir/bin/arm-uclibc-gcc -Wall -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fstrict-aliasing -Os -march=xscale -fno-builtin -nostdinc -D_LIBC -I../../include -I. -I/home/mrakes/cvs/buildroot/build_arm/staging_dir/lib/gcc-lib/arm- linux/3.3/include -DNDEBUG -fPIC -I. -I./arm -I../libdl -c arm/resolve.S -o arm/resolve.o cc1: error: bad value (xscale) for -march= switch make[3]: *** [arm/resolve.o] Error 1 I know I get "farther" if I change the cpu line in the uclibc Makefile to "-mcpu=xscale -mtune=xscale", but that breaks later on with some "unsupported instruction" errors. has anyone got this to build this before? Any hints? Is it so obvious I can't see it? I've also included the gcc "dumpspecs" from the cross compiler in case that will help somebody diagnose as well... thanks, -mark rakes ======================================================================== === uClibc.config # # Automatically generated make config: don't edit # # # Target Architecture Features and Options # HAVE_ELF=y # ADD_LIBGCC_FUNCTIONS is not set # CONFIG_GENERIC_ARM is not set # CONFIG_ARM7TDMI is not set # CONFIG_STRONGARM is not set CONFIG_XSCALE=y UCLIBC_HAS_MMU=y UCLIBC_HAS_FLOATS=y HAS_FPU=y DO_C99_MATH=y WARNINGS="-Wall" KERNEL_SOURCE="/home/mrakes/cvs/buildroot/build_arm/linux" C_SYMBOL_PREFIX="" HAVE_DOT_CONFIG=y # # General Library Settings # DOPIC=y HAVE_SHARED=y BUILD_UCLIBC_LDSO=y LDSO_LDD_SUPPORT=y UCLIBC_CTOR_DTOR=y # UCLIBC_PROFILING is not set UCLIBC_HAS_THREADS=y PTHREADS_DEBUG_SUPPORT=y UCLIBC_HAS_LFS=y # MALLOC is not set MALLOC_930716=y UCLIBC_DYNAMIC_ATEXIT=y HAS_SHADOW=y UCLIBC_HAS_REGEX=y UNIX98PTY_ONLY=y ASSUME_DEVPTS=y # # Networking Support # # UCLIBC_HAS_IPV6 is not set UCLIBC_HAS_RPC=y # UCLIBC_HAS_FULL_RPC is not set # # String and Stdio Support # UCLIBC_HAS_WCHAR=y # UCLIBC_HAS_LOCALE is not set # USE_OLD_VFPRINTF is not set # # Library Installation Options # SHARED_LIB_LOADER_PATH="/lib" DEVEL_PREFIX="/home/mrakes/cvs/buildroot/build_arm/staging_dir" SYSTEM_DEVEL_PREFIX="/home/mrakes/cvs/buildroot/build_arm/staging_dir" DEVEL_TOOL_PREFIX="/home/mrakes/cvs/buildroot/build_arm/staging_dir/usr" # # uClibc hacking options # # DODEBUG is not set # DOASSERTS is not set # SUPPORT_LD_DEBUG is not set # SUPPORT_LD_DEBUG_EARLY is not set ======================================================================== ============== jethro/home/mrakes/cvs/buildroot> ./build_arm/staging_dir/bin/arm-uclibc-gcc -dumpspecs *asm: %{mbig-endian:-EB} %{mlittle-endian:-EL} %{mcpu=*:-mcpu=%*} %{march=*:-march=%*} %{mapcs-*:-mapcs-%*} %(subtarget_asm_float_spec) %{mthumb-interwork:-mthumb-interwork} %(subtarget_extra_asm_spec) *asm_debug: %{gstabs*:--gstabs}%{!gstabs*:%{g*:--gdwarf2}} *asm_final: *asm_options: %a %Y %{c:%W{o*}%{!o*:-o %w%b%O}}%{!c:-o %d%w%u%O} *invoke_as: %{!S:-o %{|!pipe:%g.s} | as %(asm_options) %{!pipe:%g.s} %A } *cpp: %(cpp_cpu_arch) %(subtarget_cpp_spec) %{mapcs-32:%{mapcs-26: %e-mapcs-26 and -mapcs-32 may not be used together}} %{msoft-float:%{mhard-float: %e-msoft-float and -mhard_float may not be used together}} %{mbig-endian:%{mlittle-endian: %e-mbig-endian and -mlittle-endian may not be used together}} *cpp_options: %(cpp_unique_options) %1 %{m*} %{std*} %{ansi} %{W*&pedantic*} %{w} %{f*} %{O*} %{undef} *cpp_debug_options: %{d*} *cpp_unique_options: %{C:%{!E:%eGNU C does not support -C without using -E}} %{CC:%{!E:%eGNU C does not support -CC without using -E}} %{!Q:-quiet} %{nostdinc*} %{C} %{CC} %{v} %{I*} %{P} %I %{MD:-MD %{!o:%b.d}%{o*:%.d%*}} %{MMD:-MMD %{!o:%b.d}%{o*:%.d%*}} %{M} %{MM} %{MF*} %{MG} %{MP} %{MQ*} %{MT*} %{!E:%{!M:%{!MM:%{MD|MMD:%{o*:-MQ %*}}}}} %{!no-gcc:-D__GNUC__=%v1 -D__GNUC_MINOR__=%v2 -D__GNUC_PATCHLEVEL__=%v3} %{!undef:%{!ansi:%{!std=*:%p}%{std=gnu*:%p}} %P} %{trigraphs} %{remap} %{g3:-dD} %{H} %C %{D*&U*&A*} %{i*} %Z %i %{E|M|MM:%W{o*}} *trad_capable_cpp: cc1 -E %{traditional|ftraditional|traditional-cpp:-traditional-cpp} *cc1: %{profile:-p} *cc1_options: %{pg:%{fomit-frame-pointer:%e-pg and -fomit-frame-pointer are incompatible}} %1 %{!Q:-quiet} -dumpbase %B %{d*} %{m*} %{a*} -auxbase%{c|S:%{o*:-strip %*}%{!o*: %b}}%{!c:%{!S: %b}} %{g*} %{O*} %{W*&pedantic*} %{w} %{std*} %{ansi} %{v:-version} %{pg:-p} %{p} %{f*} %{undef} %{Qn:-fno-ident} %{--help:--help} %{--target-help:--target-help} %{!fsyntax-only:%{S:%W{o*}%{!o*:-o %b.s}}} %{fsyntax-only:-o %j} %{-param*} *cc1plus: *link_gcc_c_sequence: %G %L %G *endfile: %{!shared:crtend.o%s} %{shared:crtendS.o%s} crtn.o%s *link: %{h*} %{version:-v} %{b} %{Wl,*:%*} %{static:-Bstatic} %{shared:-shared} %{symbolic:-Bsymbolic} %{rdynamic:-export-dynamic} %{!dynamic-linker: -dynamic-linker /lib/ld-uClibc.so.0} -X %{mbig-endian:-EB} -m armelf_linux -p *lib: %{pthread:-lpthread} %{shared:-lc} %{!shared:%{profile:-lc_p}%{!profile:-lc}} *libgcc: %{msoft-float:-lfloat} -lgcc *startfile: %{!shared: %{pg:gcrt1.o%s} %{!pg:%{p:gcrt1.o%s} %{!p:%{profile:gcrt1.o%s} %{!profile:crt1.o%s}}}} crti.o%s %{!shared:crtbegin.o%s} %{shared:crtbeginS.o%s} *switches_need_spaces: *predefines: *cross_compile: 1 *version: 3.3 *multilib: . ; *multilib_defaults: marm mlittle-endian mhard-float mapcs-32 mno-thumb-interwork *multilib_extra: *multilib_matches: *multilib_exclusions: *multilib_options: *linker: collect2 *link_libgcc: %D *md_exec_prefix: *md_startfile_prefix: *md_startfile_prefix_1: *startfile_prefix_spec: *cpp_cpu_arch: %{march=arm2:-D__ARM_ARCH_2__} %{march=arm250:-D__ARM_ARCH_2__} %{march=arm3:-D__ARM_ARCH_2__} %{march=arm6:-D__ARM_ARCH_3__} %{march=arm600:-D__ARM_ARCH_3__} %{march=arm610:-D__ARM_ARCH_3__} %{march=arm7:-D__ARM_ARCH_3__} %{march=arm700:-D__ARM_ARCH_3__} %{march=arm710:-D__ARM_ARCH_3__} %{march=arm720:-D__ARM_ARCH_3__} %{march=arm7100:-D__ARM_ARCH_3__} %{march=arm7500:-D__ARM_ARCH_3__} %{march=arm7500fe:-D__ARM_ARCH_3__} %{march=arm7m:-D__ARM_ARCH_3M__} %{march=arm7dm:-D__ARM_ARCH_3M__} %{march=arm7dmi:-D__ARM_ARCH_3M__} %{march=arm7tdmi:-D__ARM_ARCH_4T__} %{march=arm8:-D__ARM_ARCH_4__} %{march=arm810:-D__ARM_ARCH_4__} %{march=arm9:-D__ARM_ARCH_4T__} %{march=arm920:-D__ARM_ARCH_4__} %{march=arm920t:-D__ARM_ARCH_4T__} %{march=arm9tdmi:-D__ARM_ARCH_4T__} %{march=strongarm:-D__ARM_ARCH_4__} %{march=strongarm110:-D__ARM_ARCH_4__} %{march=strongarm1100:-D__ARM_ARCH_4__} %{march=xscale:-D__ARM_ARCH_5TE__} %{march=xscale:-D__XSCALE__} %{march=armv2:-D__ARM_ARCH_2__} %{march=armv2a:-D__ARM_ARCH_2__} %{march=armv3:-D__ARM_ARCH_3__} %{march=armv3m:-D__ARM_ARCH_3M__} %{march=armv4:-D__ARM_ARCH_4__} %{march=armv4t:-D__ARM_ARCH_4T__} %{march=armv5:-D__ARM_ARCH_5__} %{march=armv5t:-D__ARM_ARCH_5T__} %{march=armv5e:-D__ARM_ARCH_5E__} %{march=armv5te:-D__ARM_ARCH_5TE__} %{!march=*: %{mcpu=arm2:-D__ARM_ARCH_2__} %{mcpu=arm250:-D__ARM_ARCH_2__} %{mcpu=arm3:-D__ARM_ARCH_2__} %{mcpu=arm6:-D__ARM_ARCH_3__} %{mcpu=arm600:-D__ARM_ARCH_3__} %{mcpu=arm610:-D__ARM_ARCH_3__} %{mcpu=arm7:-D__ARM_ARCH_3__} %{mcpu=arm700:-D__ARM_ARCH_3__} %{mcpu=arm710:-D__ARM_ARCH_3__} %{mcpu=arm720:-D__ARM_ARCH_3__} %{mcpu=arm7100:-D__ARM_ARCH_3__} %{mcpu=arm7500:-D__ARM_ARCH_3__} %{mcpu=arm7500fe:-D__ARM_ARCH_3__} %{mcpu=arm7m:-D__ARM_ARCH_3M__} %{mcpu=arm7dm:-D__ARM_ARCH_3M__} %{mcpu=arm7dmi:-D__ARM_ARCH_3M__} %{mcpu=arm7tdmi:-D__ARM_ARCH_4T__} %{mcpu=arm8:-D__ARM_ARCH_4__} %{mcpu=arm810:-D__ARM_ARCH_4__} %{mcpu=arm9:-D__ARM_ARCH_4T__} %{mcpu=arm920:-D__ARM_ARCH_4__} %{mcpu=arm920t:-D__ARM_ARCH_4T__} %{mcpu=arm9tdmi:-D__ARM_ARCH_4T__} %{mcpu=strongarm:-D__ARM_ARCH_4__} %{mcpu=strongarm110:-D__ARM_ARCH_4__} %{mcpu=strongarm1100:-D__ARM_ARCH_4__} %{mcpu=xscale:-D__ARM_ARCH_5TE__} %{mcpu=xscale:-D__XSCALE__} %{!mcpu*:%(cpp_cpu_arch_default)}} *cpp_cpu_arch_default: -D__ARM_ARCH_4T__ *subtarget_cpp_spec: %{posix:-D_POSIX_SOURCE} %{fPIC:-D__PIC__ -D__pic__} %{fpic:-D__PIC__ -D__pic__} *subtarget_extra_asm_spec: *subtarget_asm_float_spec: %{mapcs-float:-mfloat} %{msoft-float:-mno-fpu} *link_command: %{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S: %(linker) %l %X %{o*} %{A} %{d} %{e*} %{m} %{N} %{n} %{r} %{s} %{t} %{u*} %{x} %{z} %{Z} %{!A:%{!nostdlib:%{!nostartfiles:%S}}} %{static:} %{L*} %(link_libgcc) %o %{!nostdlib:%{!nodefaultlibs:%(link_gcc_c_sequence)}} %{!A:%{!nostdlib:%{!nostartfiles:%E}}} %{T*} }}}}}} From robin.gilks at tait.co.nz Thu Jul 10 04:50:00 2003 From: robin.gilks at tait.co.nz (Robin Gilks) Date: Thu, 10 Jul 2003 16:50:00 +1200 Subject: [uClibc] Interesting buildroot problem Message-ID: <3F0CF078.7030702@tait.co.nz> Greetings An interesting problem has arisen with the building of a cross target gdb (i.e. hosted on i386 to debug a powerpc) in that whenever I try to make gdb with the -C switch to make, the readline library doesn't work. I get an executable that runs but doesn't accept user input!! Building gdb by hand and copying the libreadline.a file across and it links OK so its definitely within the readline sub-tree!! I've appended the make file gdbhost.mk that fails and also another makefile that creates a simple initrd root file system - a bit easier than cramfs etc when first starting out!! ========================= gdbhost.mk ====================== ############################################################# # # gdbhost - gdb running on the host but aimed at target!! # ############################################################# # Use other GDB values from gdb.mk GDBHOST_DIR:=$(TOOL_BUILD_DIR)/gdb-5.3 # make a new directory in our toolchain tree $(GDBHOST_DIR): mkdir -p $(GDBHOST_DIR) $(DL_DIR)/$(GDB_SOURCE): $(WGET) -P $(DL_DIR) $(GDB_SITE)/$(GDB_SOURCE) $(GDBHOST_DIR)/.unpacked: $(DL_DIR)/$(GDB_SOURCE) $(GDB_PATCH) gunzip -c $(DL_DIR)/$(GDB_SOURCE) | tar -C $(TOOL_BUILD_DIR) -xvf - cat $(GDB_PATCH) | patch -p1 -d $(GDBHOST_DIR) touch $(GDBHOST_DIR)/.unpacked $(GDBHOST_DIR)/.configured: $(GDBHOST_DIR)/.unpacked (cd $(GDBHOST_DIR); rm -rf config.cache; \ CC=$(HOSTCC) \ ./configure \ --target=$(GNU_TARGET_NAME) \ --host=$(GNU_HOST_NAME) \ --prefix=$(STAGING_DIR) \ --enable-readline \ ); touch $(GDBHOST_DIR)/.configured # note the hack with the cd to gdb directory due to a bug in readline Makefile $(GDBHOST_DIR)/gdb/gdb: $(GDBHOST_DIR)/.configured cd $(GDBHOST_DIR); $(MAKE) CC=$(HOSTCC) $(STAGING_DIR)/$(GNU_TARGET_NAME)/bin/gdb: $(GDBHOST_DIR)/gdb/gdb cd $(GDBHOST_DIR); $(MAKE) CC=$(HOSTCC) install rm -rf $(GDBHOST_DIR)/info $(GDBHOST_DIR)/man $(GDBHOST_DIR)/share/doc \ $(GDBHOST_DIR)/share/locale mkdir -p $(STAGING_DIR)/usr/bin; set -e; \ if [ -x $(STAGING_DIR)/bin/$(ARCH)-linux-gdb ] ; then \ (cd $(STAGING_DIR)/$(GNU_TARGET_NAME)/bin; \ ln -fs ../../bin/$(ARCH)-linux-gdb gdb; \ ); \ (cd $(STAGING_DIR)/usr/bin; \ ln -fs ../../bin/$(ARCH)-linux-gdb gdb; \ ); \ fi; \ gdbhost: $(STAGING_DIR)/$(GNU_TARGET_NAME)/bin/gdb gdbhost-clean: $(MAKE) -C $(GDBHOST_DIR) clean gdbhost-dirclean: rm -rf $(GDBHOST_DIR) ========================= gdbhost.mk ====================== ========================= initrd.mk ======================= ############################################################# # # make an initrd image - assumes all the tools are available # ############################################################# # this comes from the u-boot project!! MKIMAGE=/usr/local/bin/mkimage MNTPOINT:=$(STAGING_DIR)/mnt $(MNTPOINT): mkdir -p $(MNTPOINT) ############################################################# # # Build the ramfs root filesystem image # ############################################################# initrd.gz: $(TARGET_DIR) $(MNTPOINT) dd if=/dev/zero of=initrd bs=1024 count=2048 /sbin/mkfs.ext2 -F -m0 -b 1024 initrd sudo mount -o loop initrd $(MNTPOINT) echo cp -R $(TARGET_DIR)/root $(MNTPOINT) cp -R $(TARGET_DIR)/* $(MNTPOINT) sudo umount $(MNTPOINT) gzip -9 -c initrd > initrd.gz rm -f initrd initrd: initrd.u-boot initrd.gz $(MKIMAGE) -n 'Simple Ramdisk Image' \ -A ppc -O linux -T ramdisk -C gzip \ -d initrd.gz initrd.u-boot rm -f initrd.gz ========================= initrd.mk ======================= -- Robin Gilks Senior Design Engineer Phone: (+64)(3) 357 1569 Tait Electronics Fax : (+64)(3) 359 4632 PO Box 1645 Christchurch Email : robin.gilks at tait.co.nz New Zealand From uclibc at vanriel.xs4all.nl Thu Jul 10 07:09:58 2003 From: uclibc at vanriel.xs4all.nl (Henri van Riel) Date: Thu, 10 Jul 2003 09:09:58 +0200 Subject: [uClibc] What libraries are used for what symbols? Message-ID: <1932955840.20030710090958@vanriel.xs4all.nl> Hello, I'm compiling a package with uClibc. Compilation is successful except for the following warnings: pptpctrl.c: In function `pptp_handle_ctrl_connection': pptpctrl.c:258: warning: implicit declaration of function `time' ctrlpacket.c: In function `deal_start_ctrl_conn': ctrlpacket.c:371: warning: implicit declaration of function `bzero' inststr.c: In function `inststr': inststr.c:46: warning: implicit declaration of function `strlcpy' Then when I ldd the object I get the following output: # ldd pptpd libc.so.0 => /usr/i386-linux-uclibc/lib/libc.so.0 /usr/i386-linux-uclibc/lib/ld-uClibc.so.0 => /usr/i386-linux-uclibc/lib/ld-uClibc.so.0 How do I find out why it needs libc? What symbols cause this linkage against libc? I tried nm and readelf and strace and a few other tools but nothing tells me which symbol in in which library... Can anyone help? -- Best regards, Henri mailto:uclibc at vanriel.xs4all.nl From kleine-budde at gmx.de Thu Jul 10 08:34:40 2003 From: kleine-budde at gmx.de (Marc Kleine-Budde) Date: Thu, 10 Jul 2003 10:34:40 +0200 Subject: [uClibc] buildroot + uClibc + xscale??? In-Reply-To: References: Message-ID: <20030710083440.GA25283@timberwolf.dyndns.org> Hi! On Wed, Jul 09, 2003 at 06:20:11PM -0700, Mark Rakes wrote: > # CONFIG_GENERIC_ARM is not set > # CONFIG_ARM7TDMI is not set > # CONFIG_STRONGARM is not set > CONFIG_XSCALE=y According yo the gcc-3.3 manual [1], the valid -march= switches are: armv2, armv2a, armv3, armv3m, armv4, armv4t, armv5, armv5t, armv5te A quick workaround is to use GENERIC_ARM as target processor type. The generated code will run on a xscale... hope that helps - marc [1] http://gcc.gnu.org/onlinedocs/gcc-3.3/gcc/ARM-Options.html#ARM%20Options -- #!/bin/sh set - `type $0` 'tr "[a-zA-Z]" "[n-za-mN-ZA-M]"';while [ "$2" != "" ];do \ shift;done; echo 'frq -a -rc '`echo "$0"| $1 `'>$UBZR/.`rpub signature|'`\ echo $1|$1`'`;rpub "Jr ner fvtangher bs obet. Erfvfgnapr vf shgvyr!"'|$1|sh From Gusti at pallas.dk Thu Jul 10 09:52:05 2003 From: Gusti at pallas.dk (Agust Karlsson) Date: Thu, 10 Jul 2003 11:52:05 +0200 Subject: [uClibc] gcc 3.3 toolchain + templates Message-ID: Hi there. I have just installed the uClibc (0.9.20) toolchain with gcc-3.3 but have discovered a problem when compiling my old applications. When I compile with the "plain" gcc-3.3 compiler everything is OK, and it was OK before I upgraded (uClibc 0.9.12 on gcc-3.1). But when I use the toolchain I get an error (see below). I have checked that the include files in the toolchain are identical with the ones in the "plain" gcc. Hope that someone can guide my out of my misery. Gusti Here is the listing: g++ -c -Wall -I../lib -o ph.o ph.cpp In file included from /usr/local/uclibc-9.20/include/c++/vector:68, from ../lib/bookkeeper.h:22, from ../lib/dbmessage.h:10, from ../lib/tmmessage.h:12, from ph.h:28, from ph.cpp:14: /usr/local/uclibc-9.20/include/c++/bits/stl_alloc.h:382: error: parse error before `;' token /usr/local/uclibc-9.20/include/c++/bits/stl_alloc.h:452: error: syntax error before `<' token /usr/local/uclibc-9.20/include/c++/bits/stl_alloc.h:452: error: `__threads' was not declared in this scope /usr/local/uclibc-9.20/include/c++/bits/stl_alloc.h:452: error: `__inst' was not declared in this scope /usr/local/uclibc-9.20/include/c++/bits/stl_alloc.h:452: error: template argument 1 is invalid /usr/local/uclibc-9.20/include/c++/bits/stl_alloc.h:452: error: template argument 2 is invalid ph.cpp: In member function `void cPH::Go()': ph.cpp:72: warning: unused variable `termios ts' /usr/local/uclibc-9.20/include/c++/bits/stl_alloc.h: In static member function `static void* std::__default_alloc_template<__threads, __inst>::allocate(unsigned int) [with bool __threads = true, int __inst = 0] ': /usr/local/uclibc-9.20/include/c++/bits/stl_alloc.h:232: instantiated from `static _Tp* std::__simple_alloc<_Tp, _Alloc>::allocate(unsigned int) [with _Tp = Bookkeeper::Duty, _Alloc = std::__default_alloc_template]' /usr/local/uclibc-9.20/include/c++/bits/stl_vector.h:127: instantiated from `_Tp* std::_Vector_alloc_base<_Tp, _Allocator, true>::_M_allocate(unsigned int) [with _Tp = Bookkeeper::Duty, _Allocator = std::allocator]' /usr/local/uclibc-9.20/include/c++/bits/stl_vector.h:156: instantiated from `std::_Vector_base<_Tp, _Alloc>::_Vector_base(unsigned int, typename std::_Vector_alloc_base<_Tp, _Alloc, std::_Alloc_traits<_Tp, _Allocator>::_S_instanceless>::allocator_type&) [with _Tp = Bookkeeper::Duty, _Alloc = std::allocator]' /usr/local/uclibc-9.20/include/c++/bits/stl_vector.h:266: instantiated from `std::vector<_Tp, _Alloc>::vector(const std::vector<_Tp, _Alloc>&) [with _Tp = Bookkeeper::Duty, _Alloc = std::allocator]' ../lib/bookkeeper.h:524: instantiated from here /usr/local/uclibc-9.20/include/c++/bits/stl_alloc.h:397: error: `__atomic_add' undeclared (first use this function) /usr/local/uclibc-9.20/include/c++/bits/stl_alloc.h:397: error: (Each undeclared identifier is reported only once for each function it appears in.) make: *** [ph.o] Error 1 --------------------------- and the ouput from g++ -v Reading specs from /usr/local/uclibc-9.20/i386-linux/bin/../lib/gcc-lib/i386-linux/3.3/specs Configured with: /Elan/LogiTux/gcc-3.3/build_i386/gcc-3.3/configure --target=i386-linux --prefix=/usr/local/uclibc-9.20 --exec-prefix=/usr/local/uclibc-9.20 --bindir=/usr/local/uclibc-9.20/bin --sbindir=/usr/local/uclibc-9.20/sbin --sysconfdir=/usr/local/uclibc-9.20/etc --datadir=/usr/local/uclibc-9.20/share --localstatedir=/usr/local/uclibc-9.20/var --mandir=/usr/local/uclibc-9.20/man --infodir=/usr/local/uclibc-9.20/info --with-local-prefix=/usr/local/uclibc-9.20/usr/local --libdir=/usr/local/uclibc-9.20/lib --includedir=/usr/local/uclibc-9.20/include --with-gxx-include-dir=/usr/local/uclibc-9.20/include/c++ --oldincludedir=/usr/local/uclibc-9.20/include --enable-shared --enable-target-optspace --disable-nls --with-gnu-ld --disable-__cxa_atexit --enable-languages=c,c++ --program-prefix=i386-uclibc- Thread model: posix gcc version 3.3 -- Agust Karlsson mailto:gusti at pallas.dk Pallas Informatik A/S http://www.pallas.dk Aller?d Stationsvej 2D Tel.: +45 48 10 24 10 DK-3450 Aller?d Fax.: +45 48 10 24 01 From ibe at dcl.info.waseda.ac.jp Thu Jul 10 12:32:09 2003 From: ibe at dcl.info.waseda.ac.jp (ibe at dcl.info.waseda.ac.jp) Date: Thu, 10 Jul 2003 21:32:09 +0900 Subject: [uClibc]can't resolve symbol. In-Reply-To: <3F0C04E5.1FC4EF24@zee2.com> References: <3F0C04E5.1FC4EF24@zee2.com> Message-ID: Thanks, Stuart. > > I see the same problem on powerpc 8xx too. The work-around was to set: > > # UCLIBC_HAS_FLOATS is not set > > in the uclibc configuration. This is not a proper solution though as I > can't work out why/how when busybox links it resolves __adddf3 and > friends, but on the target when it runs, these symbols get reported as > unresolved. But I tried to do such approach, my linux stoped while booting. (after appearing init message. So it can't boot.) Busybox (or libc) use object of libgcc, so if I set # UCLIBC_HAS_FLOATS is not set I think it naturally can't run. Does your linux run properly? or Do you think I forget any important things? If you have other hint, please help me. I am Sorry to bother you. //////////////////////////////////////////////// WASEDA UNIVERSITY Department of Information and Computer Science Ubiquitous & Distributed computing Lab. Hiroaki Ibe E-mail:ibe at dcl.info.waseda.ac.jp ibe at fuji.waseda.jp /////////////////////////////////////////////// From seh at zee2.com Thu Jul 10 13:03:48 2003 From: seh at zee2.com (Stuart Hughes) Date: Thu, 10 Jul 2003 14:03:48 +0100 Subject: [uClibc]can't resolve symbol. References: <3F0C04E5.1FC4EF24@zee2.com> Message-ID: <3F0D6434.F7C96EEE@zee2.com> ibe at dcl.info.waseda.ac.jp wrote: > > Thanks, Stuart. > > > > > I see the same problem on powerpc 8xx too. The work-around was to > set: > > > > # UCLIBC_HAS_FLOATS is not set > > > > in the uclibc configuration. This is not a proper solution though as > I > > can't work out why/how when busybox links it resolves __adddf3 and > > friends, but on the target when it runs, these symbols get reported as > > unresolved. > > But I tried to do such approach, my linux stoped while booting. > (after appearing init message. So it can't boot.) > > Busybox (or libc) use object of libgcc, so if I set > > # UCLIBC_HAS_FLOATS is not set > > I think it naturally can't run. > > Does your linux run properly? > or > Do you think I forget any important things? > > If you have other hint, please help me. > > I am Sorry to bother you. Mine runs okay, but I did change the toolchain build to add --nfp to both binutils an a gcc (using EXTRA_CONFIG_OPTIONS from memory, not sure if that is the right name). Also the toolchain built the uclibc part with -msoft float. Not sure if this is relevant. The most significant other thing I noticed was that originally I was using busybox-0.60 and my system would hang on boot (after mounting the rootfs). Upgrading busybox to the latest version fixed this for me. Hope this helps, Regards, Stuart From seh at zee2.com Thu Jul 10 13:06:11 2003 From: seh at zee2.com (Stuart Hughes) Date: Thu, 10 Jul 2003 14:06:11 +0100 Subject: [uClibc] Problems with pthreads / MIPS References: Message-ID: <3F0D64C3.5115F970@zee2.com> Hi Thomas, I've see similar problems. I've been testing a c++ application with a large number of pthreads, this hangs during initialisation. I've not be able to debug it as I've not be able to build a gdb (host or target) that works correctly with pthreads. Regards, Stuart Betker Thomas ICM CP RD SD 1 wrote: > > Hi all: > > We are experiencing a lot of problems with pthreads on a MIPS/MMU platform. Most tests were originally done with uclibc-0.9.12 (as provided by a third party), but were rechecked with a current CVS snapshot. We are using a 2.4.17 Linux kernel here. > > A. pthread_create() hangs (sometimes, not always - say 50%), i.e., the call won't return. [This one was not rechecked with uclibc-0.9.20 yet.] > > B. exit() hangs (always), if you have created any threads. The process doesn't terminate, not even the thread that called exit(). > > C. sigwait() doesn't work at all. If there is no signal, the call returns anyway, indicating a signal 0 (which doesn't exist). If there is a signal, it may be lost (not seen by any thread, which happens most of the time), or it may be received by a thread not waiting for it. > > D. The 'kill ' command usually kills the thread with the given , but not the whole process; i.e., the other threads may live on. > > Does anybody else have the same problems, or is it just me? And more important, is there anything I could do about it? Any ideas? > > I tried to run my test programs on a i386 platform (kernel 2.4.19), and everything worked as it should. The only exception was D., which occurs on i386 as well, but it's rather A. to C. I am concerned about. > > Best regards, > Thomas Betker > _______________________________________________ > uClibc mailing list > uClibc at uclibc.org > http://uclibc.org/mailman/listinfo/uclibc From dave-gnus at bfnet.com Thu Jul 10 18:53:48 2003 From: dave-gnus at bfnet.com (David Wuertele) Date: Thu, 10 Jul 2003 11:53:48 -0700 Subject: [uClibc] gcc-target on mipsel, buildroot: "no include path in which to find limits.h" Message-ID: Arch: mipsel uclibc: 0.9.20 gcc: 3.2.3 buildroot: CVS snapshot on 12:08PDT, July 1, 2003 Buildroot doesn't succeed in building gcc-target because of the following error: make[2]: Entering directory `/home/dave/buildroot-200307011208/build_mipsel/gcc-target/gcc' (cd intl && make all) make[3]: Entering directory `/home/dave/buildroot-200307011208/build_mipsel/gcc-target/gcc/intl' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/home/dave/buildroot-200307011208/build_mipsel/gcc-target/gcc/intl' /home/dave/buildroot-200307011208/build_mipsel/staging_dir/bin/mipsel-uclibc-gcc -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -isystem ./include -I. -I. -I/home/dave/buildroot-200307011208/toolchain_build_mipsel/gcc-3.2.3/gcc -I/home/dave/buildroot-200307011208/toolchain_build_mipsel/gcc-3.2.3/gcc/. -I/home/dave/buildroot-200307011208/toolchain_build_mipsel/gcc-3.2.3/gcc/config -I/home/dave/buildroot-200307011208/toolchain_build_mipsel/gcc-3.2.3/gcc/../include -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions \ -c /home/dave/buildroot-200307011208/toolchain_build_mipsel/gcc-3.2.3/gcc/crtstuff.c -DCRT_BEGIN \ -o crtbegin.o In file included from include/limits.h:11, from /home/dave/buildroot-200307011208/toolchain_build_mipsel/gcc-3.2.3/gcc/tsystem.h:84, from /home/dave/buildroot-200307011208/toolchain_build_mipsel/gcc-3.2.3/gcc/crtstuff.c:62: /home/dave/buildroot-200307011208/build_mipsel/staging_dir/lib/gcc-lib/mipsel-linux/3.2.3/include/syslimits.h:7:25: no include path in which to find limits.h /home/dave/buildroot-200307011208/toolchain_build_mipsel/gcc-3.2.3/gcc/crtstuff.c:195: warning: `__EH_FRAME_BEGIN__' defined but not used make[2]: *** [crtbegin.o] Error 1 make[2]: Leaving directory `/home/dave/buildroot-200307011208/build_mipsel/gcc-target/gcc' make[1]: *** [all-gcc] Error 2 make[1]: Leaving directory `/home/dave/buildroot-200307011208/build_mipsel/gcc-target' make: *** [/home/dave/buildroot-200307011208/build_mipsel/gcc-target/.compiled] Error 2 Has anyone seen this before? I already STFW, and found some out of date references to similar errors. But they don't seem to apply to gcc-3.2.3. I didn't see any mention of it in the uclibc archives. Suggestions? Thanks, Dave From andersen at codepoet.org Thu Jul 10 20:44:35 2003 From: andersen at codepoet.org (Erik Andersen) Date: Thu, 10 Jul 2003 14:44:35 -0600 Subject: [uClibc] Problems with pthreads / MIPS In-Reply-To: <3F0D64C3.5115F970@zee2.com> References: <3F0D64C3.5115F970@zee2.com> Message-ID: <20030710204435.GA15291@codepoet.org> On Thu Jul 10, 2003 at 02:06:11PM +0100, Stuart Hughes wrote: > Hi Thomas, > > I've see similar problems. I've been testing a c++ application with a > large number of pthreads, this hangs during initialisation. I've not be > able to debug it as I've not be able to build a gdb (host or target) > that works correctly with pthreads. See uClibc/ldso/ldso/ldso.c around line 440, where it says: #warning "Debugging threads on mips won't work till someone fixes this..." At one point sjhill mentioned he would look into this, but until someone addresses that, debugging pthreads on mips won't work. I suspect that on mips, the step of scanning the PT_DYNAMIC dynamic linking information and assigning a struct r_debug when a DT_DEBUG dynamic entry is found, probably needs to occur right before we transfer control to the application. It doesn't work in the current location since, for mips, one needs to do all sorts of relocation processing first. As a quick try, you could try adding something like this right before we transfer control to the application. Does that help? #if defined(__mips__) { elf_phdr *ppnt; int i; ppnt = (elf_phdr *) auxvt[AT_PHDR].a_un.a_ptr; for (i = 0; i < auxvt[AT_PHNUM].a_un.a_val; i++, ppnt++) if (ppnt->p_type == PT_DYNAMIC) { dpnt = (Elf32_Dyn *) ppnt->p_vaddr; while (dpnt->d_tag) { if (dpnt->d_tag == DT_DEBUG) { dpnt->d_un.d_val = (unsigned long) debug_addr; } dpnt++; } } } #endif -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- From uc9394 at hotmail.com Fri Jul 11 10:35:40 2003 From: uc9394 at hotmail.com (Eric) Date: Fri, 11 Jul 2003 18:35:40 +0800 Subject: [uClibc] Which one to use Message-ID: I am now writing a bootloader on arm7tdmi. When I link the files, I got an undefined reference to '_bootstrap' at si.S. I have everything inside the same directory. I got 5 files. extern void main(void); void bootstrap(void) { typedef void(*ENTRY)(void); ENTRY entry_addr; entry_addr = &main; (*entry_addr)(); } ENTRY(main) SECTIONS { .reset : { si.o } .text : {*(.text)} .bss : {*(.bss)} .data : {*(.data)} } int main(int argc, char *argv[]) { unsigned int abc; abc=0; return(0); } .text .align .global _start _start: mov r0,#0xD3 msr cpsr, r0 b _bootstrap Did I make anything wrong? More, I have find two sets of toolchain. One is arm-elf-gcc and the other is arm-linux-gcc. Which one should I use when I want to compile a bootloader? Thanks, Eric From harilal at blueshift.com Sun Jul 13 10:36:08 2003 From: harilal at blueshift.com (Harilal S.B.) Date: Sun, 13 Jul 2003 16:06:08 +0530 Subject: [uClibc] error in installing uClibc Message-ID: <90B3181C75A07740BAF743AD0E84803C405D8A@exchange.chennai.blueshift.com> Hello, I am getting the error given below if try to call make path is correct . please help me out for solving this With Regards Harilal [root at rnd2 uClibc-0.9.18]# make rm -f include/asm; The path '/usr/src/linux/include/asm' doesn't exist. I bet you didn't set KERNEL_SOURCE, TARGET_ARCH or UCLIBC_HAS_MMU correctly when you configured uClibc. Please fix these settings. make: *** [headers] Error 1 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.busybox.net/pipermail/uclibc/attachments/20030713/15417d90/attachment-0001.htm From uclibc at lacklustre.net Sun Jul 13 17:05:03 2003 From: uclibc at lacklustre.net (Michael Ryan) Date: Sun, 13 Jul 2003 10:05:03 -0700 Subject: [uClibc] error in installing uClibc In-Reply-To: <90B3181C75A07740BAF743AD0E84803C405D8A@exchange.chennai.blueshift.com> References: <90B3181C75A07740BAF743AD0E84803C405D8A@exchange.chennai.blueshift.com> Message-ID: <20030713100503.6811dc91.uclibc@lacklustre.net> Edit the makefile to point to the path of your current kernel source. In my case, the makefile looked like this: KERNEL_SOURCE = /usr/src/linux-2.4.21 Then, you should be able to build. On Sun, 13 Jul 2003 16:06:08 +0530 "Harilal S.B." wrote: > > Hello, > > I am getting the error given below if try to call make > path is correct . please help me out for solving this > > With Regards > Harilal > > > [root at rnd2 uClibc-0.9.18]# make > rm -f include/asm; > > The path '/usr/src/linux/include/asm' doesn't exist. > I bet you didn't set KERNEL_SOURCE, TARGET_ARCH or UCLIBC_HAS_MMU > correctly when you configured uClibc. Please fix these settings. > > make: *** [headers] Error 1 > -- Michael Ryan Lacklustre Networking michael at lacklustre.net http://www.lacklustre.net/ From fredrik.johnsson at orestad-linux.net Mon Jul 14 20:38:03 2003 From: fredrik.johnsson at orestad-linux.net (Fredrik Johnsson) Date: Mon, 14 Jul 2003 22:38:03 +0200 Subject: [uClibc] TinyX with Xfree 4.3 Message-ID: <3F1314AB.5090502@orestad-linux.se> Hi! A while back some guys said they had tried Xfree86 4.3 without much success. Now i've been occupied with other things and haven't really followed the mailing list and can't seem to find any more info. Has the possibillity for compiling TinyX changed or is to keep on with Xfree86 4.2? / Fredrik Johnsson From christian_michon at yahoo.fr Tue Jul 15 08:42:29 2003 From: christian_michon at yahoo.fr (=?iso-8859-1?q?Christian=20MICHON?=) Date: Tue, 15 Jul 2003 10:42:29 +0200 (CEST) Subject: [uClibc] TinyX with Xfree 4.3 In-Reply-To: <3F1314AB.5090502@orestad-linux.se> Message-ID: <20030715084229.39662.qmail@web11104.mail.yahoo.com> --- Fredrik Johnsson a ?crit : > Hi! > > A while back some guys said they had tried Xfree86 4.3 without much success. I should count me as one of them... > > Now i've been occupied with other things and haven't really followed the > mailing list and can't seem to find any more info. Me too. Another son, now two months old ;) I hardly find time to fine tune my scripts recently. > > Has the possibillity for compiling TinyX changed or is to keep on with > Xfree86 4.2? Some people recently reported that LD_PRELOAD can be used to force the render library to be read properly by uclibc ld and get the bins to work, finally. I still need some time to confirm/infirm this and update scripts. I still owe Erik long overdue .mk for xfree. Soon to come... By the way, got broadband recently, and got hacked into through wuftpd. As it seems a pretty nasty buffer overflow, do we know yet if such exploits exist with uclibc/busybox ? Christian ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en fran?ais ! Yahoo! Mail : http://fr.mail.yahoo.com From bernie at develer.com Tue Jul 15 20:07:09 2003 From: bernie at develer.com (Bernardo Innocenti) Date: Tue, 15 Jul 2003 22:07:09 +0200 Subject: [uClibc] SPAM[RBL] Re: SPAM[RBL] Re: SPAM[RBL] sys_errlist In-Reply-To: <20030715184136.GA6184@codepoet.org> References: <200307152002.26358.bernie@develer.com> <20030715184136.GA6184@codepoet.org> Message-ID: <200307152207.09701.bernie@develer.com> On Tuesday 15 July 2003 20:41, Erik Andersen wrote: > Using sys_errlist[] requires that I actually populate the entire > array with strings. Once all apps stop using sys_errlist[] there > will be a number of additional options available for efficiently > handling the storage for the various error stings. > > Last time I checked, a whole bunch of apps in uClinx-dist were > still using the sys_errlist[] array... I would suggest taking an approach similar to glibc's handling of multithreaded errno. Something like this: #define sys_errlist (__get_sys_errlist()) const char * const * __get_sys_errlist(void) __THROW { static __sys_errlist; if (unlikely(__sys_errlist == NULL)) __sys_errlist = __load_sys_errlist(); return __sys_errlist; } void __load_sys_errlist(void) { FILE *f; int i; char buf[128]; if (!(__sys_errlist = calloc(sys_nerr, sizeof(char *)))) abort(); if ((f = fopen("/lib/libc_errors.txt", "r"))) for(i = 0; i < sys_nerr; ++i) if (fgets(f, buf, sizeof(buf))) __sys_errlist[i] = strdup(buf); } -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ Please don't send Word attachments - http://www.gnu.org/philosophy/no-word-attachments.html From mjn3 at codepoet.org Wed Jul 16 06:49:42 2003 From: mjn3 at codepoet.org (Manuel Novoa III) Date: Wed, 16 Jul 2003 00:49:42 -0600 Subject: [uClibc] SPAM[RBL] Re: SPAM[RBL] Re: SPAM[RBL] sys_errlist In-Reply-To: <200307152207.09701.bernie@develer.com> References: <200307152002.26358.bernie@develer.com> <20030715184136.GA6184@codepoet.org> <200307152207.09701.bernie@develer.com> Message-ID: <20030716064942.GA5817@codepoet.org> On Tue, Jul 15, 2003 at 10:07:09PM +0200, Bernardo Innocenti wrote: > On Tuesday 15 July 2003 20:41, Erik Andersen wrote: > > > Using sys_errlist[] requires that I actually populate the entire > > array with strings. Once all apps stop using sys_errlist[] there > > will be a number of additional options available for efficiently > > handling the storage for the various error stings. > > > > Last time I checked, a whole bunch of apps in uClinx-dist were > > still using the sys_errlist[] array... > > I would suggest taking an approach similar to glibc's handling > of multithreaded errno. Something like this: > > #define sys_errlist (__get_sys_errlist()) > > const char * const * __get_sys_errlist(void) __THROW > { > static __sys_errlist; > > if (unlikely(__sys_errlist == NULL)) > __sys_errlist = __load_sys_errlist(); > return __sys_errlist; > } > > void __load_sys_errlist(void) > { > FILE *f; > int i; > char buf[128]; > > if (!(__sys_errlist = calloc(sys_nerr, sizeof(char *)))) > abort(); > > if ((f = fopen("/lib/libc_errors.txt", "r"))) > for(i = 0; i < sys_nerr; ++i) > if (fgets(f, buf, sizeof(buf))) > __sys_errlist[i] = strdup(buf); > } I checked the archives for the previous messages in this thread and found that you referenced strerror.c, which I removed from uClibc over a year ago. It last appeared in version 0.9.12. If you're not interested in upgrading to the latest version, you should at least look at the diffs to see what bugs got fixed. Regarding your concerns about the size increase in staticly linked apps due to the system error messages, I'd be happy to add a an option to the current version of uClibc to force strerror (and strsignal for that matter) to omit the actual text messages. Of course, that won't help applications still using sys_errlist[]. But any application still using sys_errlist[] really needs to be updated. If you wanted to store the system error message text in a file and load it dynamically, all you would have to do is replace the function int _susv3_strerror_r(int errnum, char *strerrbuf, size_t buflen) in the current version of uClibc. Well... that _and_ get rid of all the outdated sys_errlist[] cruft in any relevant apps. Currently no uClibc routines use sys_errlist[]. About a year ago, I removed it completely and then reinstated it because of complaints that it was still used in some of the uClinux userland apps. So I put a link warning in place that it was deprecated (in SUSv2) and it would eventually be removed (as it has from SUSv3). In fact, I will probably make it a build-time config option in the next release. If you _still_ wanted to support sys_errlist[] with a scheme like you suggest above, you would need to do a bit more. A failure in opening or reading the file, or in memory allocation, would result in one or more of the table entries being NULL. Last time I looked, at least some of the uClinux userland apps using sys_errlist[] were not prepared for a NULL ptr corresponding to a valid errno. Manuel From bernie at develer.com Wed Jul 16 16:26:03 2003 From: bernie at develer.com (Bernardo Innocenti) Date: Wed, 16 Jul 2003 18:26:03 +0200 Subject: [uClibc] sys_errlist In-Reply-To: <20030716064942.GA5817@codepoet.org> References: <200307152002.26358.bernie@develer.com> <200307152207.09701.bernie@develer.com> <20030716064942.GA5817@codepoet.org> Message-ID: <200307161826.03809.bernie@develer.com> On Wednesday 16 July 2003 08:49, Manuel Novoa III wrote: > I checked the archives for the previous messages in this thread and > found that you referenced strerror.c, which I removed from uClibc > over a year ago. It last appeared in version 0.9.12. If you're not > interested in upgrading to the latest version, you should at least > look at the diffs to see what bugs got fixed. I'm using version 0.9.19 from the latest uClinux distribution. The problem is that for several months I did new imports into our CVS using a stupid way to do the merge: cvs checkout -jUCLINUX:yesterday -jUCLINUX uclinux instead of the correct way: cvs checkout -jUCLINUX_20030515 -jUCLINUX_20030525 uclinux As a result, I have a lot of files in my HEAD branch which should have been removed by the merge. Fixing this requires a long and tedious search all over the source tree so I've not bothered. > Regarding your concerns about the size increase in staticly linked apps > due to the system error messages, I'd be happy to add a an option to > the current version of uClibc to force strerror (and strsignal for > that matter) to omit the actual text messages. Of course, that won't > help applications still using sys_errlist[]. But any application still > using sys_errlist[] really needs to be updated. > > If you wanted to store the system error message text in a file and > load it dynamically, all you would have to do is replace the function > int _susv3_strerror_r(int errnum, char *strerrbuf, size_t buflen) > in the current version of uClibc. Well... that _and_ get rid of all > the outdated sys_errlist[] cruft in any relevant apps. So I'd better fix that instead. Does glibc provide sys_errlist[] to applications? Is it required by any relevant standard? The fact that there are no underscores in the name makes me think that it's not something internal. > Currently no uClibc routines use sys_errlist[]. About a year ago, > I removed it completely and then reinstated it because of complaints > that it was still used in some of the uClinux userland apps. So I put > a link warning in place that it was deprecated (in SUSv2) and it would > eventually be removed (as it has from SUSv3). In fact, I will probably > make it a build-time config option in the next release. Actually, the application where I've noticed this problem - telnetd - does not use sys_errlist[] at all, but all the messages get linked into the binary because of perror(). I'd like to drop this overhead. > If you _still_ wanted to support sys_errlist[] with a scheme like you > suggest above, you would need to do a bit more. A failure in opening > or reading the file, or in memory allocation, would result in one or > more of the table entries being NULL. Last time I looked, at least > some of the uClinux userland apps using sys_errlist[] were not prepared > for a NULL ptr corresponding to a valid errno. Hmmm... if they're just passing to uClinux version of printf(), they should be safe. Otherwise, we could always set all slots to point at an empty string instead of storing NULL into them. -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ Please don't send Word attachments - http://www.gnu.org/philosophy/no-word-attachments.html From mjn3 at codepoet.org Wed Jul 16 17:41:18 2003 From: mjn3 at codepoet.org (Manuel Novoa III) Date: Wed, 16 Jul 2003 11:41:18 -0600 Subject: [uClibc] sys_errlist In-Reply-To: <200307161826.03809.bernie@develer.com> References: <200307152002.26358.bernie@develer.com> <200307152207.09701.bernie@develer.com> <20030716064942.GA5817@codepoet.org> <200307161826.03809.bernie@develer.com> Message-ID: <20030716174118.GA13127@codepoet.org> On Wed, Jul 16, 2003 at 06:26:03PM +0200, Bernardo Innocenti wrote: > On Wednesday 16 July 2003 08:49, Manuel Novoa III wrote: > > If you wanted to store the system error message text in a file and > > load it dynamically, all you would have to do is replace the function > > int _susv3_strerror_r(int errnum, char *strerrbuf, size_t buflen) > > in the current version of uClibc. Well... that _and_ get rid of all > > the outdated sys_errlist[] cruft in any relevant apps. > > So I'd better fix that instead. Does glibc provide sys_errlist[] to > applications? Yes, but current versions issue the following link warning -- : `sys_errlist' is deprecated; use `strerror' or `strerror_r' instead > Is it required by any relevant standard? I thought it appeared as deprecated in SUSv2, but apparently not. I just searched and didn't find a reference. > The fact that > there are no underscores in the name makes me think that it's not > something internal. It still uses an internal version in its strerror_r implementation. > Actually, the application where I've noticed this problem - telnetd - > does not use sys_errlist[] at all, but all the messages get linked into > the binary because of perror(). I'd like to drop this overhead. Everything in uClibc goes through _susv3_strerror_r() now, except for the sys_errlist[] table. As I said, I'll add an option to omit the message text and simply print the errno. > > If you _still_ wanted to support sys_errlist[] with a scheme like you > > suggest above, you would need to do a bit more. A failure in opening > > or reading the file, or in memory allocation, would result in one or > > more of the table entries being NULL. Last time I looked, at least > > some of the uClinux userland apps using sys_errlist[] were not prepared > > for a NULL ptr corresponding to a valid errno. > > Hmmm... if they're just passing to uClinux version of printf(), > they should be safe. I don't recall the usage. > Otherwise, we could always set all slots to point > at an empty string instead of storing NULL into them. A couple of other issues... Some of the errnos for the same error are different on some archs. That is why the internal strerror stuff has to check an index table. So you'd either have to include an index table in the code and share a file with all supported archs, or you'd have to supply a seperate file for each supported arch. One other fun note is that mips has a max errno of 1133. What were they thinking? Also, since many applications that use sys_errlist[] are older, they often declare it themselves. If you were to define sys_errlist as a function returning a pointer to a dynamicly constructed table, you will likely still have to go in and patch a number of userland apps. Manuel From peter.kjellerstedt at axis.com Thu Jul 17 15:19:41 2003 From: peter.kjellerstedt at axis.com (Peter Kjellerstedt) Date: Thu, 17 Jul 2003 17:19:41 +0200 Subject: [uClibc] [PATCH] Uninitialized value used through vsscanf() Message-ID: The attached patch should solve a problem whereby vsscanf() (and thus sscanf()) failed to initialize bufread in the FILE struct that is passed to vfscanf() and which is then later used. The problem occurred if the end of the buffer being parsed has already been reached and a %s format specifier is found. Then it could parse past the end of the buffer, resulting in incorrect return values from vfscanf() and sometimes causing SIGSEGV. The test program below showed the problem. //Peter #include #include #include #define CRAP_SIZE 1 int main(void) { int a; #if 1 char *crap = malloc(CRAP_SIZE); #else char crap[CRAP_SIZE]; /* stack allocation may not trig bug */ #endif memset(crap, 'a', CRAP_SIZE); crap[CRAP_SIZE - 1] = '\0'; /* yields (should be 1): * 2 * ## * when bug triggered */ printf("%d\n", sscanf("1", "%d%s", &a, crap)); printf("crap = #%s#\n", crap); return EXIT_SUCCESS; } <> -------------- next part -------------- A non-text attachment was scrubbed... Name: scanf.patch Type: application/octet-stream Size: 646 bytes Desc: not available Url : http://lists.busybox.net/pipermail/uclibc/attachments/20030717/40d76130/attachment.obj From ibe at dcl.info.waseda.ac.jp Thu Jul 17 15:26:42 2003 From: ibe at dcl.info.waseda.ac.jp (ibe at dcl.info.waseda.ac.jp) Date: Fri, 18 Jul 2003 00:26:42 +0900 Subject: [uClibc]can't resolve symbol. In-Reply-To: <1144.133.9.91.177.1057704567.squirrel@mail2.dcl.info.waseda.ac.jp> References: <1144.133.9.91.177.1057704567.squirrel@mail2.dcl.info.waseda.ac.jp> Message-ID: Hi, all. > I have some trouble when using some command like > ls, mount or other > > # ls > ls: can't resolve symbol '__eqdf2' > ls: can't resolve symbol '__floatsidf' > ls: can't resolve symbol '__ltdf2' > ls: can't resolve symbol '__adddf3' > ls: can't resolve symbol '__fixdfsi' > ls: can't resolve symbol '__negdf2' > ls: can't resolve symbol '__divdf3' > ls: can't resolve symbol '__muldf3' > ls: can't resolve symbol '__truncdfsf2' > ls: can't resolve symbol '__nedf2' > ls: can't resolve symbol '__gedf2' > ls: can't resolve symbol '__subdf3' > bin dev proc usr > boot etc linuxrc sbin > # Finally, I found the solution this problem. In a Makefile, there is some script below, $(LD) $(LDFLAGS) $(VERSION_SCRIPT) -soname=$(SHARED_MAJORNAME) -o $(SHARED_FULLNAME) \ --whole-archive $(LIBGCC_NEED) $(LIBNAME) \ $(TOPDIR)/libc/misc/internals/interp.o --no-whole-archive \ -init __uClibc_init $(LIBGCC) They turn into below in my environment, > ppc_8xx-ld -s -shared --warn-common --warn-once -z combreloc > -soname=libc.so.0 -o libuClibc-0.9.19.so \ > --whole-archive ./tmp/libgcc-need.a libc.a \ > ..//libc/misc/internals/interp.o --no-whole-archive \ > -init __uClibc_init > /opt/hardhat/devkit/ppc/8xx/lib/gcc-lib/powerpc-hardhat-linux/3.2.1/ > libgcc.a Perhaps, there is s bug in the GCC linker that causes the libgcc library to be included twice if there is a -whole-archive -no-whole-archive sequence passed to the linker without any libraries specified in between. So My fix was to remove final $(LIBGCC). Although, I wouder why this script repeat to link some objects of libgcc again? And in the man of ld, --whole-archive For each archive mentioned on the command line after the --whole-archive option, include every object file in the archive in the link, rather than searching the archive for the required object files. This is normally used to turn an archive file into a shared library, forcing every object to be included in the resulting shared library. This option may be used more than once. If I don't use --whole-archive option, How does gcc know which object is required object files? //////////////////////////////////////////////// WASEDA UNIVERSITY Department of Information and Computer Science Ubiquitous & Distributed computing Lab. Hiroaki Ibe E-mail:ibe at dcl.info.waseda.ac.jp /////////////////////////////////////////////// From mjn3 at codepoet.org Thu Jul 17 16:12:15 2003 From: mjn3 at codepoet.org (Manuel Novoa III) Date: Thu, 17 Jul 2003 10:12:15 -0600 Subject: [uClibc] Re: [PATCH] Uninitialized value used through vsscanf() In-Reply-To: References: Message-ID: <20030717161215.GA24848@codepoet.org> On Thu, Jul 17, 2003 at 05:19:41PM +0200, Peter Kjellerstedt wrote: > The attached patch should solve a problem whereby vsscanf() > (and thus sscanf()) failed to initialize bufread in the > FILE struct that is passed to vfscanf() and which is then > later used. Thanks. Applied. You should know that there are several other bugs in the current vfscanf() implementation. I'm just about finished a new version which fixes the ones I've found, as well as adds optional positional arg support (required by SUSv3) as well as some other configurable features. It will be in the cvs before the end of July. Manuel From fredrik.johnsson at orestad-linux.se Thu Jul 17 14:58:21 2003 From: fredrik.johnsson at orestad-linux.se (Fredrik Johnsson) Date: Thu, 17 Jul 2003 16:58:21 +0200 Subject: [uClibc] TinyX with Xfree 4.3 In-Reply-To: <20030715084229.39662.qmail@web11104.mail.yahoo.com> References: <20030715084229.39662.qmail@web11104.mail.yahoo.com> Message-ID: <3F16B98D.6050709@orestad-linux.se> Christian MICHON wrote: >--- Fredrik Johnsson a ?crit : > > >>Hi! >> >>A while back some guys said they had tried Xfree86 4.3 without much success. >> >> > >I should count me as one of them... > > > >>Now i've been occupied with other things and haven't really followed the >>mailing list and can't seem to find any more info. >> >> > > > Hi all! I'm now getting around to actually compiling TinyX and matchbox. Since I only got on erespons eon the matter I'm assuming there is no working solution for Xfree86 4.3 nad will go along with 4.2. But I could try with complete 4.3 for uclibc is that possible) and then when I or someone else finds a solution use the tinyX >Me too. Another son, now two months old ;) >I hardly find time to fine tune my scripts recently. > > > >>Has the possibillity for compiling TinyX changed or is to keep on with >>Xfree86 4.2? >> >> > >Some people recently reported that LD_PRELOAD can be used to force the >render library to be read properly by uclibc ld and get the bins to work, >finally. I still need some time to confirm/infirm this and update >scripts. > >I still owe Erik long overdue .mk for xfree. Soon to come... > >By the way, got broadband recently, and got hacked into through wuftpd. >As it seems a pretty nasty buffer overflow, do we know yet if such >exploits exist with uclibc/busybox ? > >Christian > > >___________________________________________________________ >Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en fran?ais ! >Yahoo! Mail : http://fr.mail.yahoo.com >_______________________________________________ >uClibc mailing list >uClibc at uclibc.org >http://uclibc.org/mailman/listinfo/uclibc > > From jrigby at metrowerks.com Mon Jul 21 18:06:41 2003 From: jrigby at metrowerks.com (John Rigby) Date: Mon, 21 Jul 2003 12:06:41 -0600 Subject: [uClibc] uclibc on mmufull m68k Message-ID: <3F1C2BB1.3050907@metrowerks.com> Anyone running uClibc on mmufull m68k linux like old macs, NeXT and SUN 3 boxes? From andersen at codepoet.org Mon Jul 21 19:27:47 2003 From: andersen at codepoet.org (Erik Andersen) Date: Mon, 21 Jul 2003 13:27:47 -0600 Subject: [uClibc] uclibc on mmufull m68k In-Reply-To: <3F1C2BB1.3050907@metrowerks.com> References: <3F1C2BB1.3050907@metrowerks.com> Message-ID: <20030721192747.GB22605@codepoet.org> On Mon Jul 21, 2003 at 12:06:41PM -0600, John Rigby wrote: > Anyone running uClibc on mmufull m68k linux like old macs, NeXT and SUN > 3 boxes? Around a year or so ago I was briefly given access to an old mac and made uClibc compile and run at that time. But I suspect that work has not kept up with the latest and greatest, so there may be a bit or arch specific work still needed. -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- From robert.searle at tait.co.nz Tue Jul 22 00:33:41 2003 From: robert.searle at tait.co.nz (searler) Date: Tue, 22 Jul 2003 12:33:41 +1200 Subject: [uClibc] compile of buildroot fails for i386 default target Message-ID: <3F1C8665.4050208@tait.co.nz> I checked out buildroot according to the instructions and changed the uclibs from snapshot and tinylogin from snapshot defines to false. I typed make and eventually the make fails with the messages cc1: unrecognized option `-auxbase' cc1: output filename specified twice I tried this a few days ago and everything worked (used daily snapshots that time). I have tried make clean and reverting the Makefile to the check-out default but nothing fixes the problem now. Any ideas where my environment might be going astray? Mandrake 9.1 distribution gcc -v Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2.2/specs Configured with: ../configure --prefix=/usr --libdir=/usr/lib --with-slibdir=/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --enable-long-long --enable-__cxa_atexit --enable-languages=c,c++,ada,f77,objc,java --host=i586-mandrake-linux-gnu --with-system-zlib Thread model: posix gcc version 3.2.2 (Mandrake Linux 9.1 3.2.2-3mdk) make -v GNU Make 3.80 Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ls -l /usr/src/linux lrwxrwxrwx 1 root root 22 Jul 21 09:43 /usr/src/linux -> /usr/src/linux-2.4.21// -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: log.txt Url: http://lists.busybox.net/pipermail/uclibc/attachments/20030722/afea5b62/attachment.txt From werkt at csh.rit.edu Tue Jul 22 04:43:39 2003 From: werkt at csh.rit.edu (George Gensure) Date: Tue, 22 Jul 2003 00:43:39 -0400 Subject: [uClibc] libstdc++ Message-ID: <3F1CC0FB.4020302@csh.rit.edu> I've seen hints and snatches of recommendations for this, but can anyone tell me exactly the config options and sources needed to build libstdc++ under uclibc? I've had no success even getting libstdc++ to build within the gcc sources. Anyone have any suggestions? -George From rmcmullen at broadq.com Tue Jul 22 04:33:41 2003 From: rmcmullen at broadq.com (Rob McMullen) Date: Tue, 22 Jul 2003 00:33:41 -0400 Subject: [uClibc] TinyX with Xfree 4.3 In-Reply-To: <3F1314AB.5090502@orestad-linux.se> References: <3F1314AB.5090502@orestad-linux.se> Message-ID: With uClibc-0.9.20, I got XFree 4.3 working with no changes to its source code. I am using the ebuild scripts from a Gentoo install, so I can't help with .mk file, but... Here's my xc/config/cf/host.def if it helps. It assumes you have freetype and other stuff installed, so you'll have to do some commenting out of stuff... Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: host.def Type: application/octet-stream Size: 4915 bytes Desc: not available Url : http://lists.busybox.net/pipermail/uclibc/attachments/20030722/48a83067/attachment.obj -------------- next part -------------- At Mon, 14 Jul 2003 22:38:03 +0200, Fredrik Johnsson wrote: > > Hi! > > A while back some guys said they had tried Xfree86 4.3 without much success. > > Now i've been occupied with other things and haven't really followed the > mailing list and can't seem to find any more info. > > Has the possibillity for compiling TinyX changed or is to keep on with > Xfree86 4.2? > > > > / Fredrik Johnsson > > > _______________________________________________ > uClibc mailing list > uClibc at uclibc.org > http://uclibc.org/mailman/listinfo/uclibc > From andersen at codepoet.org Tue Jul 22 05:03:45 2003 From: andersen at codepoet.org (Erik Andersen) Date: Mon, 21 Jul 2003 23:03:45 -0600 Subject: [uClibc] libstdc++ In-Reply-To: <3F1CC0FB.4020302@csh.rit.edu> References: <3F1CC0FB.4020302@csh.rit.edu> Message-ID: <20030722050345.GA26526@codepoet.org> On Tue Jul 22, 2003 at 12:43:39AM -0400, George Gensure wrote: > I've seen hints and snatches of recommendations for this, but can anyone > tell me exactly the config options and sources needed to build libstdc++ > under uclibc? I've had no success even getting libstdc++ to build > within the gcc sources. Anyone have any suggestions? http://uclibc.org/cgi-bin/cvsweb/toolchain/ -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- From jsun at junsun.net Wed Jul 23 17:24:52 2003 From: jsun at junsun.net (Jun Sun) Date: Wed, 23 Jul 2003 10:24:52 -0700 Subject: [uClibc] size difference between uclibc and glibc Message-ID: <20030723172452.GB6588@gateway.junsun.net> Can someone give an idea on what size difference it gives if I switch to use uclibc instead of glibc? Also, probably a dumb question, the applications should have the same size no matter what C library you are using, correct? If the later is true, it seems if your system has more applications then one would have less movtivation to use uclibc. Size reduction seems to be the most bragging about point of uclibc. This questions probably should be on FAQ. :) Also, are there other benefits to switch to uclibc? Thanks in advance. Jun From andersen at codepoet.org Wed Jul 23 18:56:14 2003 From: andersen at codepoet.org (Erik Andersen) Date: Wed, 23 Jul 2003 12:56:14 -0600 Subject: [uClibc] size difference between uclibc and glibc In-Reply-To: <20030723172452.GB6588@gateway.junsun.net> References: <20030723172452.GB6588@gateway.junsun.net> Message-ID: <20030723185614.GA12226@codepoet.org> On Wed Jul 23, 2003 at 10:24:52AM -0700, Jun Sun wrote: > > Can someone give an idea on what size difference it gives if I > switch to use uclibc instead of glibc? Also, probably a dumb question, > the applications should have the same size no matter what C library > you are using, correct? There are a number of places where we do not inline functions, or where we use more compact preprocessor defines causing application programs to also be smaller and use less memory. > If the later is true, it seems if your system has more applications then one > would have less movtivation to use uclibc. > > Size reduction seems to be the most bragging about point of uclibc. > This questions probably should be on FAQ. :) Please feel free to provide any additions you think best.... http://uclibc.org/FAQ.html > Also, are there other benefits to switch to uclibc? yes -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- From jsun at junsun.net Wed Jul 23 21:39:03 2003 From: jsun at junsun.net (Jun Sun) Date: Wed, 23 Jul 2003 14:39:03 -0700 Subject: [uClibc] size difference between uclibc and glibc In-Reply-To: <20030723185614.GA12226@codepoet.org> References: <20030723172452.GB6588@gateway.junsun.net> <20030723185614.GA12226@codepoet.org> Message-ID: <20030723213903.GA7338@gateway.junsun.net> On Wed, Jul 23, 2003 at 12:56:14PM -0600, Erik Andersen wrote: > On Wed Jul 23, 2003 at 10:24:52AM -0700, Jun Sun wrote: > > > > Can someone give an idea on what size difference it gives if I > > switch to use uclibc instead of glibc? Also, probably a dumb question, > > the applications should have the same size no matter what C library > > you are using, correct? > > There are a number of places where we do not inline functions, > or where we use more compact preprocessor defines causing > application programs to also be smaller and use less memory. > Thanks. > > If the later is true, it seems if your system has more applications then one > > would have less movtivation to use uclibc. > > > > Size reduction seems to be the most bragging about point of uclibc. > > This questions probably should be on FAQ. :) > > Please feel free to provide any additions you think best.... > http://uclibc.org/FAQ.html > Will do after I get permissions from the people who sent me data. > > Also, are there other benefits to switch to uclibc? > > yes > Care to elaborate more? And yes, I looked at the FAQ and the answer is not there. :) Jun From deanm at earthlink.net Thu Jul 24 01:55:23 2003 From: deanm at earthlink.net (Dean Matsen) Date: Wed, 23 Jul 2003 18:55:23 -0700 Subject: [uClibc] Noted problem with vsnprintf() in 0.9.20 Message-ID: <3F1F3C8B.5090103@earthlink.net> Hope this is not a repeat posting, but I didn't see any search engine to search the archives... In version 0.9.20, I noticed that my telnetd (from netkit-telnet-0.17, using a recent buildroot) server was locking up. The problem, it turns out (I THINK), is that telnetd puts some non-printable characters in the format strings. This causes vsnprintf() to return -1, and ultimately causes telnetd to infinite loop (said loop is obviously intended to wait until the buffer is flushed, not until the vsnprintf call works...). For example, telnetd declares a format string like this: static unsigned char doopt[] = { IAC, DO, '%', 'c', 0 }; and then tries to do char c; vsnprintf ( buffer, maxsize, (char *)doopt, c ); (where IAC = 255 and DO = 253, the offending control characters) For now, I modified the code to use a "%c" and pass the control character as a parameter, ie: vsnprintf ( buffer, maxsize, "%c%c%c", IAC, DO, c ); (which makes more sense anyway, but hey, this is THE telnetd code, right? so who am I to propose that someone fix it?). Anyway, depending on the goals of uClibc, I recommend that vsnprintf NOT fail in this case, since it pertains to a very prominent daemon program! Regards, Dean From mjn3 at codepoet.org Thu Jul 24 03:02:28 2003 From: mjn3 at codepoet.org (Manuel Novoa III) Date: Wed, 23 Jul 2003 21:02:28 -0600 Subject: [uClibc] Noted problem with vsnprintf() in 0.9.20 In-Reply-To: <3F1F3C8B.5090103@earthlink.net> References: <3F1F3C8B.5090103@earthlink.net> Message-ID: <20030724030228.GA15191@codepoet.org> Hello, On Wed, Jul 23, 2003 at 06:55:23PM -0700, Dean Matsen wrote: > Hope this is not a repeat posting, but I didn't see > any search engine to search the archives... Coincidentally, I just posted something on this to the uClinux list. http://mailman.uclinux.org/pipermail/uclinux-dev/2003-July/019647.html > In version 0.9.20, I noticed that my telnetd (from > netkit-telnet-0.17, using a recent buildroot) server was > locking up. > > The problem, it turns out (I THINK), is that telnetd > puts some non-printable characters in the format strings. Yes. See below. > This causes vsnprintf() to return -1, and ultimately > causes telnetd to infinite loop (said loop is obviously > intended to wait until the buffer is flushed, not until > the vsnprintf call works...). Sigh.. No one ever checks return values on *printf()... > For example, telnetd declares a format string like this: > > static unsigned char doopt[] = { IAC, DO, '%', 'c', 0 }; > > and then tries to do > > char c; > > vsnprintf ( buffer, maxsize, (char *)doopt, c ); > > (where IAC = 255 and DO = 253, the offending control > characters) Regarding format strings for the *printf functions, ANSI/ISO C99 standard (and C89 too) states The format shall be a multibyte character sequence, beginning and ending in its initial shift state. This is also true of the format strings for the *scanf and strftime functions. The codeset for the C locale in uClibc is ASCII. Any char with a value outside the range of 0-0x7f is treated as an invalid multibyte sequence since there is no associated wchar_t mapping. This is actually less restrictive than it could be, as ASCII is a superset of the portable C codeset. > For now, I modified the code to use a "%c" and pass the > control character as a parameter, ie: > > vsnprintf ( buffer, maxsize, "%c%c%c", IAC, DO, c ); That's fine. According to the standard, %c and %s simply treat their data as bytes. Multibyte considerations don't come into play. Of course, using vsnprintf to assign 4 bytes in a buffer is pretty inefficient... > (which makes more sense anyway, but hey, this is THE > telnetd code, right? so who am I to propose that someone > fix it?). Why not? It is broken. The restrictions on format strings have been around since C89 at least. Even if uClibc can be configured to not check in the C locale, wouldn't you rather fix it in the app now than have the app mysteriously fail when run in some UTF-8 codeset locale for instance? > Anyway, depending on the goals of uClibc, I recommend > that vsnprintf NOT fail in this case, since it pertains > to a very prominent daemon program! As I mentioned in my post to the uClinux list, I will probably make checking the format string when in the C locale a uClibc configuration option, since there are so many broken programs out there. However, format strings have to be checked in locales using other codesets. So this is just postponing the inevitable fixing of the app itself. I do not intend my code in uClibc to be as 'tolerant' of standards violations as glibc is; at least not be default. Bad format strings are (potential) application _bugs_ and need to be found and fixed. The same could be said for allowing signed chars with negative values to be accepted by the ctype functions. glibc allows this to support 'old broken programs'. In the next uClibc release, such support will be configurable, since by allowing this you can never be sure if the value passed was supposed to be ((unsigned char)(-1)) or -1, which is EOF in most libc implementations. (And yes, I've even considered making the value of EOF configurable... just to see what breaks.) Manuel From deanm at earthlink.net Thu Jul 24 04:17:06 2003 From: deanm at earthlink.net (Dean Matsen) Date: Wed, 23 Jul 2003 21:17:06 -0700 Subject: [uClibc] Noted problem with vsnprintf() in 0.9.20 In-Reply-To: <20030724030228.GA15191@codepoet.org> References: <3F1F3C8B.5090103@earthlink.net> <20030724030228.GA15191@codepoet.org> Message-ID: <3F1F5DC2.1010703@earthlink.net> Manuel Novoa III wrote: >Hello, > >On Wed, Jul 23, 2003 at 06:55:23PM -0700, Dean Matsen wrote: > > >>Hope this is not a repeat posting, but I didn't see >>any search engine to search the archives... >> >> > >Coincidentally, I just posted something on this to the uClinux list. > >http://mailman.uclinux.org/pipermail/uclinux-dev/2003-July/019647.html > > I sent a message to webmaster @ codepoet.net to maybe add a search capability using htdig or something... >As I mentioned in my post to the uClinux list, I will probably make >checking the format string when in the C locale a uClibc configuration >option, since there are so many broken programs out there. However, >format strings have to be checked in locales using other codesets. >So this is just postponing the inevitable fixing of the app itself. > >I do not intend my code in uClibc to be as 'tolerant' of standards >violations as glibc is; at least not be default. Bad format strings >are (potential) application _bugs_ and need to be found and fixed. >The same could be said for allowing signed chars with negative values >to be accepted by the ctype functions. glibc allows this to support >'old broken programs'. In the next uClibc release, such support will >be configurable, since by allowing this you can never be sure if >the value passed was supposed to be ((unsigned char)(-1)) or -1, >which is EOF in most libc implementations. (And yes, I've even >considered making the value of EOF configurable... just to see what >breaks.) > >Manuel > > Ok, well the version of telnetd in question comes from the uClibc buildroot extracted a couple of days ago from the uclibc.org cvsweb server. Specificaly, I went to http://www.uclibc.org/cgi-bin/cvsweb/buildroot/ and then clicked on "download tarball". It seems like the buildroot available from the uclibc.org web server ought to be compatible with uclibc itself, right? I don't keep up on the minutia in the ANSI C standards, but I understand what you mean on the multibyte stuff... So I guess I agree that the telnetd should be changed, not vsnprintf(). I have enclosed a patch to make it easy for any interested source maintainers (I hope this list server allows that -- we'll find out). The patch is to be applied immediately following, and in the same manner as, the existing "netkittelnet.patch" file in buildroot/sources/ . Thanks Dean -------------- next part -------------- A non-text attachment was scrubbed... Name: dm-telnetd-vsnprintf.patch.gz Type: application/x-gzip Size: 548 bytes Desc: not available Url : http://lists.busybox.net/pipermail/uclibc/attachments/20030723/96af2e2d/attachment.bin From mjn3 at codepoet.org Thu Jul 24 04:23:20 2003 From: mjn3 at codepoet.org (Manuel Novoa III) Date: Wed, 23 Jul 2003 22:23:20 -0600 Subject: [uClibc] Noted problem with vsnprintf() in 0.9.20 In-Reply-To: <3F1F5DC2.1010703@earthlink.net> References: <3F1F3C8B.5090103@earthlink.net> <20030724030228.GA15191@codepoet.org> <3F1F5DC2.1010703@earthlink.net> Message-ID: <20030724042320.GA16171@codepoet.org> On Wed, Jul 23, 2003 at 09:17:06PM -0700, Dean Matsen wrote: > Ok, well the version of telnetd in question comes from the uClibc buildroot > extracted a couple of days ago from the uclibc.org cvsweb server. > Specificaly, > I went to http://www.uclibc.org/cgi-bin/cvsweb/buildroot/ and then clicked > on "download tarball". It seems like the buildroot available from the > uclibc.org web server ought to be compatible with uclibc itself, right? It probably was never caught before because I'm not currently checking the multibyte validity of the format strings unless uClibc is built with wide char support. Manuel From tom at ceisystems.com Thu Jul 24 05:22:19 2003 From: tom at ceisystems.com (tom at ceisystems.com) Date: Thu, 24 Jul 2003 01:22:19 -0400 Subject: [uClibc] Speed issues with Perl/Webmin? Message-ID: <6D31D5429FA6884CBE9ECAB6C9B5E6A907E0A2@intel-srvr.patcameron.ne.mediaone.net> Hello all, I have a half-way on-topic question for everyone. Well, a couple, really. First off, is anyone using Perl & webmin on a uClibc-based system? If so, what is the speed like? I'm seeing the miniserv.pl process taking up almost no CPU, 1.4% of memory, and some extremely slow speeds. I think it has something to do with the caching of images, etc. but I have no real idea. Anyway, when I run this in a chrooted environment on my dev. system, all is well. Well, as well as well could be. As soon as the packages are dropped onto my target machine (Via C3/533), it crawls. Should I be using Perl's malloc functions? What about the PerlIO features, will they gain me any benefits? My second question pertains more to the Perl side of things. What experiences have people had with stripping perl up? I have gone through files removing the the PerlDOC and comment garbage, but that obviously only slims things down so far. Has anyone else found places to cut corners to get the size to a more tollerable level? Thanks for you help, Thomas Cameron CEI Systems, Inc. From andersen at codepoet.org Thu Jul 24 05:52:07 2003 From: andersen at codepoet.org (Erik Andersen) Date: Wed, 23 Jul 2003 23:52:07 -0600 Subject: [uClibc] Noted problem with vsnprintf() in 0.9.20 In-Reply-To: <3F1F5DC2.1010703@earthlink.net> References: <3F1F3C8B.5090103@earthlink.net> <20030724030228.GA15191@codepoet.org> <3F1F5DC2.1010703@earthlink.net> Message-ID: <20030724055206.GA16646@codepoet.org> On Wed Jul 23, 2003 at 09:17:06PM -0700, Dean Matsen wrote: > I sent a message to webmaster @ codepoet.net to maybe add a search > capability > using htdig or something... webmaster at codepoet.org is me. And I find visiting google works rather nicely... :-) I've also added your telnet patch to buildroot. -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- From jsun at junsun.net Thu Jul 24 18:01:21 2003 From: jsun at junsun.net (Jun Sun) Date: Thu, 24 Jul 2003 11:01:21 -0700 Subject: [uClibc] size difference between uclibc and glibc In-Reply-To: <20030723185614.GA12226@codepoet.org> References: <20030723172452.GB6588@gateway.junsun.net> <20030723185614.GA12226@codepoet.org> Message-ID: <20030724180121.GA11952@gateway.junsun.net> On Wed, Jul 23, 2003 at 12:56:14PM -0600, Erik Andersen wrote: > On Wed Jul 23, 2003 at 10:24:52AM -0700, Jun Sun wrote: > > > > Can someone give an idea on what size difference it gives if I > > switch to use uclibc instead of glibc? Also, probably a dumb question, > > the applications should have the same size no matter what C library > > you are using, correct? > > There are a number of places where we do not inline functions, > or where we use more compact preprocessor defines causing > application programs to also be smaller and use less memory. > > > If the later is true, it seems if your system has more applications then one > > would have less movtivation to use uclibc. > > > > Size reduction seems to be the most bragging about point of uclibc. > > This questions probably should be on FAQ. :) > > Please feel free to provide any additions you think best.... > http://uclibc.org/FAQ.html > Here is one item I think should go to FAQ: Q: What is the size difference between uclibc and glibc? A: [Joseph Chiu]"My glibc shared libraries on MIPS total up to about 10.9 MB. (Add another 9 MB for locale support.) uClibc's shared libraries add up to a whopping 608 KB." Different CPU architectures should see different numbers. RISC CPUs should see numbers in about the same range while i386 might numbers a little over half of those. Jun From Amit.Lubovsky at infineon.com Fri Jul 25 00:09:27 2003 From: Amit.Lubovsky at infineon.com (Amit.Lubovsky at infineon.com) Date: Fri, 25 Jul 2003 02:09:27 +0200 Subject: [uClibc] zebra - uClinux Message-ID: Hi, I work with uClinux-dist-20030305 and uClibc-0.9.19 on a custom board with a mips5kc. I have compiled zebra succesfully but couldn't compile vtysh. I have seen that the port doesn't even include the Makefile for this utility. can anyone advise about that ?, Is the readline library working with uClibc ?, and how can you add it ? Thanks, Amit. From thomas.huld at jrc.it Fri Jul 25 07:19:54 2003 From: thomas.huld at jrc.it (Thomas Huld) Date: Fri, 25 Jul 2003 09:19:54 +0200 Subject: [uClibc] A simple uClibc-based system with an old linux kernel? Message-ID: <200307250919.54677.Thomas.Huld@jrc.it> Ciao Tutti, Is there any way of making the uClibc development system (compiled with buildroot) work to produce binaries that will work under an older linux kernel (2.0.3x)? I would like to run such a system on a modern linux machine (2.4.21), but using it to produce a small system with uClibc, busybox and tinylogin running under an old kernel (to save space). I've tried but I have run into problems. An out-of-the-box development system (the downloadable root_fs-i386) produces binaries that don't run at all under linux 2.0.34 (it complains about getcwd() not being implemented). I then tried to substitute all the linux includes in the /usr/include subdirectories with the include files from the 2.0.34 kernel. After a bit of tweaking I could get uClibc, busybox and tinylogin to compile. Then I can actually boot the old linux system and some things work. BUT: the system is somewhat rickety. For instance: when busybox is called with a not-implemented applet name it exits with the error message, but this causes the underlying (busybox) ash shell to crash as well! I've narrowed the problem down to a call to the builtin va_end. Does this mean that it is the compiler that produces code not compatible with linux-2.0.34? I