From rep.dot.nop at gmail.com Sun Jun 1 06:02:20 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Sun, 1 Jun 2008 15:02:20 +0200 Subject: [RFC] build system replacement In-Reply-To: <200805311757.38863.vda.linux@googlemail.com> References: <200805071729.28418.vda.linux@googlemail.com> <200805311158.12076.vda.linux@googlemail.com> <48413CB7.3080300@t-online.de> <200805311757.38863.vda.linux@googlemail.com> Message-ID: <20080601130219.GY27768@mx.loc> On Sat, May 31, 2008 at 05:57:38PM +0200, Denys Vlasenko wrote: >On Saturday 31 May 2008 13:55, Bernd Schmidt wrote: >> Denys Vlasenko wrote: >> > 2. The breakage is not as widespread as I thought - actually, >> > all .c files are properly tracked. Or almost all - >> > I did not check all possibilities, maybe there are a few more >> > obscure .config's with problems. >> > >> >> Adding header file dependencies would be a good thing. IMO, if it can >> >> be done within the existing framework, that's better than throwing >> >> everything out. >> > >> > Are you willing to look into it? >> >> I'm not really a make expert, and I didn't intend to become maintainer >> when I submitted a patch... > >Is there a maintainer of it? If not, is anyone willing to become one? No and i don't think such a thing is really needed. > >> The patch below copies over just enough parts of the glibc dependency >> system to make it work on simple cases in uClibc (tested by touching >> include/mntent.h and watching it rebuild only five files). It's >> probably uglier and less efficient than it needs to be; I doubt it >> tracks all object files, and it doesn't integrate with "make clean". > >"compile-mkdep-flags" variable is used exactly in one place. >It's not clear to the casual reader why you want it to be >a separate variable. CC from random vendor may barf on those -MXYZ It's more obvious to encapsulate it like we did in CFLAGS_gen.dep > >+depfiles := ... > >A variable with '+' in name? Well, yes, make allows even this, >but is there a reason for it? Reader gets confused again... > >> Finishing the job is left as an exercise for the reader :-) I hope i improved the situation a bit now (if you use r22158 and later). We honour both all our prerequisites (if your compiler groks what we mean to ask for in our gcc-ism) as well as the used CC and flags. I consider this fixed, issue closed, nothing to see here, please move on (or holler if i broke something) :) From bernds_cb1 at t-online.de Sun Jun 1 06:24:15 2008 From: bernds_cb1 at t-online.de (Bernd Schmidt) Date: Sun, 01 Jun 2008 15:24:15 +0200 Subject: [RFC] build system replacement In-Reply-To: <20080601130219.GY27768@mx.loc> References: <200805071729.28418.vda.linux@googlemail.com> <200805311158.12076.vda.linux@googlemail.com> <48413CB7.3080300@t-online.de> <200805311757.38863.vda.linux@googlemail.com> <20080601130219.GY27768@mx.loc> Message-ID: <4842A2FF.3060506@t-online.de> Bernhard Fischer wrote: > I hope i improved the situation a bit now (if you use r22158 and later). Yeah, good stuff. My little ploy seems to have worked :) Thanks. > We honour both all our prerequisites (if your compiler groks what we > mean to ask for in our gcc-ism) as well as the used CC and flags. > I consider this fixed, issue closed, nothing to see here, please move on > (or holler if i broke something) :) Well, I seem to have trouble with the flag-compare code. libdl.oS doesn't seem to build here (i386 default config), it doesn't get the -Ildso/ options passed. Before that ldso.oS and resolve.oS are rebuilt every time. Not sure if that's breakage local to my tree, but "svn diff" is clean and the tree is uptodate. I'm also not sure I understand how the flag-compare code works, or how it ensures things are rebuilt when the flags do match. Bernd -- This footer brought to you by insane German lawmakers. Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif From bernds_cb1 at t-online.de Sun Jun 1 08:50:41 2008 From: bernds_cb1 at t-online.de (Bernd Schmidt) Date: Sun, 01 Jun 2008 17:50:41 +0200 Subject: [RFC] build system replacement In-Reply-To: <20080601130219.GY27768@mx.loc> References: <200805071729.28418.vda.linux@googlemail.com> <200805311158.12076.vda.linux@googlemail.com> <48413CB7.3080300@t-online.de> <200805311757.38863.vda.linux@googlemail.com> <20080601130219.GY27768@mx.loc> Message-ID: <4842C551.8090605@t-online.de> Bernhard Fischer wrote: > I hope i improved the situation a bit now (if you use r22158 and later). > We honour both all our prerequisites (if your compiler groks what we > mean to ask for in our gcc-ism) as well as the used CC and flags. > I consider this fixed, issue closed, nothing to see here, please move on > (or holler if i broke something) :) I've done a bit of digging, and found the cause of two problems. 1. So far, only libc-so-y and libc-a-y are tracked. This needs to be extended to handle all the other libraries, including ld.so. 2. The CFLAGS passed to the compiler have changed in some cases. Previously, when compiling ldso/libdl/libdl.c, $^ used to be "ldso/libdl/libdl.c"; it is now "ldso/libdl/libdl.c FORCE", which means that $(CFLAGS-$(notdir $(^D)) no longer does the right thing: $(notdir $(^D)) is now "libdl .". There's also $(CFLAGS-$(notdir $<)) in the command line, which doesn't work for this case, since it expands to "ldso/libdl/"; note the prefix "ldso/" and the trailing slash. We could fix this by using $( References: <200805200018.58346.vda.linux@googlemail.com> <20080520071552.GA27753@mx.loc> <200805201759.45719.vda.linux@googlemail.com> Message-ID: <1212343356.10979.8.camel@isis> On Tue, 2008-05-20 at 17:59 +0200, Denys Vlasenko wrote: > On Tuesday 20 May 2008 09:15, Bernhard Fischer wrote: > > >Attached patch instroduces smallint type, and uses it > > >for flag variables. It results in size reduction > > >ont only for bss, but text too: > > > > > > text data bss dec hex filename > > >- 648 4 24 676 2a4 libc/misc/internals/__uClibc_main.o > > >+ 645 4 21 670 29e libc/misc/internals/__uClibc_main.o > > >- 129 0 4 133 85 libc/termios/tcgetsid.o > > >+ 126 0 1 127 7f libc/termios/tcgetsid.o > > > > > >because "flag_var = 1" is a smaller instruction now. > > >Size in smallint can be set per-architecture. > > > > > >I am a bit unsire I picked suitable include files to put > > >new definitions in. > > > > > >Can someone eyeball the patch? > > >-- > > >vda > > > > >diff -d -urpN uClibc.1/libc/termios/tcgetsid.c uClibc.2/libc/termios/tcgetsid.c > > >--- uClibc.1/libc/termios/tcgetsid.c 2008-05-19 16:23:16.000000000 +0200 > > >+++ uClibc.2/libc/termios/tcgetsid.c 2008-05-20 00:03:31.000000000 +0200 > > >@@ -34,7 +34,7 @@ tcgetsid (fd) > > > pid_t pgrp; > > > pid_t sid; > > > #ifdef TIOCGSID > > >- static int tiocgsid_does_not_work; > > >+ static smallint tiocgsid_does_not_work; > > > > For cases like this i prefer to just use a bool. > > Yeah, sounds logical. I'd do this too, but I don't have sufficient faith > in gcc not being stupid. In my opinion using bool is right thing to do and less error-prone on userside. At least compilers will do it consistent even if wrong. btw the you did not consider the architectures which do not define their own smallint in wordsize.h on such arches the definition will come from unistd.h. libc/misc/fnmatch.c change would require to include unistd.h so that it will also get definition for other arches. As far as I see only x86 defines smallint as of now. btw saving three bytes in size is fine. Did you also consider/measure the performance hit? Now a days accessing int is much faster and I would consider this a better trade-off than size. Thanks -Khem -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://busybox.net/lists/uclibc/attachments/20080601/d7da3078/attachment.pgp From vda.linux at googlemail.com Sun Jun 1 13:53:15 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sun, 1 Jun 2008 22:53:15 +0200 Subject: [PATCH] smallint In-Reply-To: <1212343356.10979.8.camel@isis> References: <200805200018.58346.vda.linux@googlemail.com> <200805201759.45719.vda.linux@googlemail.com> <1212343356.10979.8.camel@isis> Message-ID: <200806012253.15516.vda.linux@googlemail.com> On Sunday 01 June 2008 20:02, Khem Raj wrote: > > > >diff -d -urpN uClibc.1/libc/termios/tcgetsid.c uClibc.2/libc/termios/tcgetsid.c > > > >--- uClibc.1/libc/termios/tcgetsid.c 2008-05-19 16:23:16.000000000 +0200 > > > >+++ uClibc.2/libc/termios/tcgetsid.c 2008-05-20 00:03:31.000000000 +0200 > > > >@@ -34,7 +34,7 @@ tcgetsid (fd) > > > > pid_t pgrp; > > > > pid_t sid; > > > > #ifdef TIOCGSID > > > >- static int tiocgsid_does_not_work; > > > >+ static smallint tiocgsid_does_not_work; > > > > > > For cases like this i prefer to just use a bool. > > > > Yeah, sounds logical. I'd do this too, but I don't have sufficient faith > > in gcc not being stupid. > > In my opinion using bool is right thing to do and less error-prone on > userside. At least compilers will do it consistent even if wrong. > > btw the you did not consider the architectures which do not define their > own smallint in wordsize.h on such arches the definition will come from > unistd.h. Yes, it was intended. Do you want it to be changed so that compile fails if unistd.h is mistakennly not included? > libc/misc/fnmatch.c change would require to include unistd.h > so that it will also get definition for other arches. As far as I see > only x86 defines smallint as of now. Fixed now. > btw saving three bytes in size is fine. Did you also consider/measure > the performance hit? Now a days accessing int is much faster and I would > consider this a better trade-off than size. I thought that uclibc's goal was smaller code size. Anyway, with attached test program I am getting: # gcc -Os t.c # ./a.out char reads: 1469029 us int reads: 1441760 us It measures the time it takes to sum up bytes: addb buf+8, %al addb buf+12, %al addb buf+16, %al addb buf+20, %al addb buf+24, %al versus words: addl buf+8, %eax addl buf+12, %eax addl buf+16, %eax addl buf+20, %eax addl buf+24, %eax -- vda -------------- next part -------------- A non-text attachment was scrubbed... Name: t.c Type: text/x-csrc Size: 1531 bytes Desc: not available Url : http://busybox.net/lists/uclibc/attachments/20080601/37777e3c/attachment.c From vda.linux at googlemail.com Sun Jun 1 18:47:17 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Mon, 2 Jun 2008 03:47:17 +0200 Subject: cross-compile to blackfin fails Message-ID: <200806020347.17227.vda.linux@googlemail.com> Hi, I got around to building my blackfin toolchain. I have binutils and gcc built (bfin-linux-uclibc-XXX variety), now trying to build uclibc: ... CC libc/inet/rpc/rpc_thread.o CC libc/stdlib/atexit.o AS lib/crt1.o AS lib/crti.o AS lib/crtn.o CC lib/crtreloc.o libc/sysdeps/linux/bfin/crtreloc.c:91: warning: 'visibility' attribute ignored on non-class types STRIP -x -R .note -R .comment lib/libc.a bfin-linux-uclibc-strip: 'libc/sysdeps/linux/bfin/mmap.o': No such file AR cr lib/libc.a bfin-linux-uclibc-ar: libc/sysdeps/linux/bfin/mmap.o: No such file or directory make: *** [lib/libc.a] Error 1 What puzzles me is that libc/sysdeps/linux/bfin/Makefile.arch mentions mmap.c: CSRC := brk.c bsdsetjmp.c clone.c syscall.c mmap.c \ sram-alloc.c sram-free.c dma-memcpy.c but actual file doesn't exist in libc/sysdeps/linux/bfin, and make indeed does not build it: ... AR cr lib/librt.a CC libc/sysdeps/linux/bfin/brk.o CC libc/sysdeps/linux/bfin/bsdsetjmp.o CC libc/sysdeps/linux/bfin/clone.o CC libc/sysdeps/linux/bfin/syscall.o CC libc/sysdeps/linux/bfin/sram-alloc.o CC libc/sysdeps/linux/bfin/sram-free.o CC libc/sysdeps/linux/bfin/dma-memcpy.o AS libc/sysdeps/linux/bfin/__longjmp.o AS libc/sysdeps/linux/bfin/setjmp.o AS libc/sysdeps/linux/bfin/bsd-_setjmp.o AS libc/sysdeps/linux/bfin/vfork.o CC libc/sysdeps/linux/common/access.o CC libc/sysdeps/linux/common/acct.o ... What I'm doing wrong? -- vda -------------- next part -------------- # # Automatically generated make config: don't edit # Mon Jun 2 03:29:04 2008 # # TARGET_alpha is not set # TARGET_arm is not set # TARGET_avr32 is not set TARGET_bfin=y # TARGET_cris is not set # TARGET_e1 is not set # TARGET_frv is not set # TARGET_h8300 is not set # TARGET_hppa is not set # TARGET_i386 is not set # TARGET_i960 is not set # TARGET_ia64 is not set # TARGET_m68k is not set # TARGET_microblaze is not set # TARGET_mips is not set # TARGET_nios is not set # TARGET_nios2 is not set # TARGET_powerpc is not set # TARGET_sh is not set # TARGET_sh64 is not set # TARGET_sparc is not set # TARGET_v850 is not set # TARGET_vax is not set # TARGET_x86_64 is not set # TARGET_xtensa is not set # # Target Architecture Features and Options # TARGET_ARCH="bfin" FORCE_OPTIONS_FOR_ARCH=y TARGET_SUBARCH="" # UCLIBC_FORMAT_ELF is not set UCLIBC_FORMAT_FDPIC_ELF=y # UCLIBC_FORMAT_FLAT is not set # UCLIBC_FORMAT_FLAT_SEP_DATA is not set # UCLIBC_FORMAT_SHARED_FLAT is not set ARCH_LITTLE_ENDIAN=y # # Using Little Endian # ARCH_HAS_NO_MMU=y # # Target CPU lacks a memory management unit (MMU) # UCLIBC_HAS_FLOATS=y UCLIBC_HAS_FPU=y DO_C99_MATH=y UCLIBC_HAS_FENV=y KERNEL_HEADERS="/usr/srcdevel/uclibc/include_2.6.25.4_bfin/include" UCLIBC_UCLINUX_BROKEN_MUNMAP=y EXCLUDE_BRK=y HAVE_DOT_CONFIG=y # # General Library Settings # # HAVE_NO_PIC is not set # DOPIC is not set # HAVE_NO_SHARED is not set # ARCH_HAS_NO_LDSO is not set # HAVE_SHARED is not set UCLIBC_CTOR_DTOR=y # HAS_NO_THREADS is not set # UCLIBC_HAS_THREADS is not set UCLIBC_HAS_LFS=y MALLOC=y # MALLOC_SIMPLE is not set # MALLOC_STANDARD is not set # MALLOC_GLIBC_COMPAT is not set UCLIBC_DYNAMIC_ATEXIT=y # COMPAT_ATEXIT is not set # UCLIBC_SUSV3_LEGACY is not set # UCLIBC_SUSV3_LEGACY_MACROS is not set UCLIBC_HAS_SHADOW=y # UCLIBC_HAS_PROGRAM_INVOCATION_NAME is not set UNIX98PTY_ONLY=y ASSUME_DEVPTS=y UCLIBC_HAS_TM_EXTENSIONS=y UCLIBC_HAS_TZ_CACHING=y UCLIBC_HAS_TZ_FILE=y UCLIBC_HAS_TZ_FILE_READ_MANY=y UCLIBC_TZ_FILE_PATH="/etc/TZ" # # Advanced Library Settings # UCLIBC_PWD_BUFFER_SIZE=256 UCLIBC_GRP_BUFFER_SIZE=256 UCLIBC_LINUX_MODULE_24=y # # Networking Support # UCLIBC_HAS_IPV6=y UCLIBC_HAS_RPC=y UCLIBC_HAS_FULL_RPC=y UCLIBC_HAS_REENTRANT_RPC=y # UCLIBC_USE_NETLINK is not set # UCLIBC_HAS_BSD_RES_CLOSE is not set # # String and Stdio Support # UCLIBC_HAS_STRING_GENERIC_OPT=y UCLIBC_HAS_STRING_ARCH_OPT=y UCLIBC_HAS_CTYPE_TABLES=y UCLIBC_HAS_CTYPE_SIGNED=y UCLIBC_HAS_CTYPE_UNSAFE=y # UCLIBC_HAS_CTYPE_CHECKED is not set # UCLIBC_HAS_CTYPE_ENFORCED is not set # UCLIBC_HAS_WCHAR is not set # UCLIBC_HAS_LOCALE is not set # UCLIBC_HAS_HEXADECIMAL_FLOATS is not set # UCLIBC_HAS_GLIBC_CUSTOM_PRINTF is not set # USE_OLD_VFPRINTF is not set UCLIBC_PRINTF_SCANF_POSITIONAL_ARGS=9 # UCLIBC_HAS_SCANF_GLIBC_A_FLAG is not set # UCLIBC_HAS_STDIO_BUFSIZ_NONE is not set # UCLIBC_HAS_STDIO_BUFSIZ_256 is not set # UCLIBC_HAS_STDIO_BUFSIZ_512 is not set UCLIBC_HAS_STDIO_BUFSIZ_1024=y # UCLIBC_HAS_STDIO_BUFSIZ_2048 is not set # UCLIBC_HAS_STDIO_BUFSIZ_4096 is not set # UCLIBC_HAS_STDIO_BUFSIZ_8192 is not set UCLIBC_HAS_STDIO_BUILTIN_BUFFER_NONE=y # UCLIBC_HAS_STDIO_BUILTIN_BUFFER_4 is not set # UCLIBC_HAS_STDIO_BUILTIN_BUFFER_8 is not set # UCLIBC_HAS_STDIO_SHUTDOWN_ON_ABORT is not set UCLIBC_HAS_STDIO_GETC_MACRO=y UCLIBC_HAS_STDIO_PUTC_MACRO=y UCLIBC_HAS_STDIO_AUTO_RW_TRANSITION=y # UCLIBC_HAS_FOPEN_LARGEFILE_MODE is not set # UCLIBC_HAS_FOPEN_EXCLUSIVE_MODE is not set # UCLIBC_HAS_GLIBC_CUSTOM_STREAMS is not set UCLIBC_HAS_PRINTF_M_SPEC=y UCLIBC_HAS_ERRNO_MESSAGES=y # UCLIBC_HAS_SYS_ERRLIST is not set UCLIBC_HAS_SIGNUM_MESSAGES=y # UCLIBC_HAS_SYS_SIGLIST is not set UCLIBC_HAS_GNU_GETOPT=y UCLIBC_HAS_GNU_GETSUBOPT=y # # Big and Tall # UCLIBC_HAS_REGEX=y UCLIBC_HAS_REGEX_OLD=y UCLIBC_HAS_FNMATCH=y UCLIBC_HAS_FNMATCH_OLD=y # UCLIBC_HAS_WORDEXP is not set UCLIBC_HAS_FTW=y UCLIBC_HAS_GLOB=y # UCLIBC_HAS_GNU_GLOB is not set # # Library Installation Options # RUNTIME_PREFIX="/usr/app/uclibc-NEW/$(TARGET_ARCH)/" DEVEL_PREFIX="/usr/app/uclibc-NEW/$(TARGET_ARCH)/usr/" # # Security options # # UCLIBC_HAS_ARC4RANDOM is not set # HAVE_NO_SSP is not set # UCLIBC_HAS_SSP is not set UCLIBC_BUILD_NOEXECSTACK=y # # uClibc development/debugging options # CROSS_COMPILER_PREFIX="bfin-linux-uclibc-" UCLIBC_EXTRA_CFLAGS="" # DODEBUG is not set DOSTRIP=y # DOASSERTS is not set # UCLIBC_MALLOC_DEBUGGING is not set WARNINGS="-Wall" # EXTRA_WARNINGS is not set # DOMULTI is not set # UCLIBC_MJN3_ONLY is not set From vda.linux at googlemail.com Sun Jun 1 20:19:12 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Mon, 2 Jun 2008 05:19:12 +0200 Subject: blackfin toolchain build question Message-ID: <200806020519.12225.vda.linux@googlemail.com> Hi, I successfully built bfin-linux-uclibc toolchain (binutils+gcc) using binutils and gcc trees from svn://firewall-sources.blackfin.uclinux.org:80/svn/toolchain/trunk I already had quite a few toolchains on my machine and I have a preferred way to build one. Therefore I did not use canned scripts from svn but followed my own procedure, as a more familiar one for me. Basically, it involves building cross-compiled binutils, installing it, then building and installing gcc, then doing the same for libc. Trying to build gcc doesn't work, it needs usable $TARGET-ld. I observed the following peculiarity: binutils apparently tried to build newlib, and that requires $TARGET-cc! make[4]: Entering directory `/.1/usr/srcdevel/bfin/toolchain/binutils-2.17/.obj-bfin-linux-uclibc/bfin-linux-uclibc/newlib' if [ -z "" ]; then \ true; \ else \ rootpre=`${PWDCMD-pwd}`/; export rootpre; \ srcrootpre=`cd ../../../newlib; ${PWDCMD-pwd}`/; export srcrootpre; \ lib=`echo ${rootpre} | sed -e 's,^.*/\([^/][^/]*\)/$,\1,'`; \ compiler="bfin-linux-uclibc-cc -B/.1/usr/srcdevel/bfin/toolchain/binutils-2.17/.obj-bfin-linux-uclibc/bfin-linux-uclibc/newlib/ -isystem for i in `${compiler} --print-multi-lib 2>/dev/null`; do \ ... done; \ fi make[4]: Leaving directory `/.1/usr/srcdevel/bfin/toolchain/binutils-2.17/.obj-bfin-linux-uclibc/bfin-linux-uclibc/newlib' Making all in libc make[4]: Entering directory `/.1/usr/srcdevel/bfin/toolchain/binutils-2.17/.obj-bfin-linux-uclibc/bfin-linux-uclibc/newlib/libc' Making all in argz make[5]: Entering directory `/.1/usr/srcdevel/bfin/toolchain/binutils-2.17/.obj-bfin-linux-uclibc/bfin-linux-uclibc/newlib/libc/argz' bfin-linux-uclibc-cc -B/.1/usr/srcdevel/bfin/toolchain/binutils-2.17/.obj-bfin-linux-uclibc/bfin-linux-uclibc/newlib/ -isystem /.1/usr/src devel/bfin/toolchain/binutils-2.17/.obj-bfin-linux-uclibc/bfin-linux-uclibc/newlib/targ-include -isystem /.1/usr/srcdevel/bfin/toolchain/b inutils-2.17/newlib/libc/include -L/.1/usr/srcdevel/bfin/toolchain/binutils-2.17/.obj-bfin-linux-uclibc/./ld -DPACKAGE=\"newlib\" -DVERSIO N=\"1.14.0\" -I. -I../../../../../newlib/libc/argz -O2 -fno-builtin -O2 -g -O2 -c ../../../../../newlib/libc/argz/dummy.c make[5]: bfin-linux-uclibc-cc: Command not found make[5]: *** [dummy.o] Error 127 make[5]: Leaving directory `/.1/usr/srcdevel/bfin/toolchain/binutils-2.17/.obj-bfin-linux-uclibc/bfin-linux-uclibc/newlib/libc/argz' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/.1/usr/srcdevel/bfin/toolchain/binutils-2.17/.obj-bfin-linux-uclibc/bfin-linux-uclibc/newlib/libc' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/.1/usr/srcdevel/bfin/toolchain/binutils-2.17/.obj-bfin-linux-uclibc/bfin-linux-uclibc/newlib' make[2]: *** [all-recursive-am] Error 2 make[2]: Leaving directory `/.1/usr/srcdevel/bfin/toolchain/binutils-2.17/.obj-bfin-linux-uclibc/bfin-linux-uclibc/newlib' make[1]: *** [all-target-newlib] Error 2 make[1]: Leaving directory `/.1/usr/srcdevel/bfin/toolchain/binutils-2.17/.obj-bfin-linux-uclibc' make: *** [all] Error 2 This did not happen before to me. I'm puzzled. gcc wants $TARGET-ld but binutils wants $TARGET-gcc?! How they are supposed to be build with such circular dependency? Anyway. I ignored error, ran "make install" for binutils, then built and installed gcc, and then rebuilt (and reinstalled) binutils again. No error this time. But this didn't sound like correct solution at all. For comparison: x86_64-linux-uclibc binutils build ends like this, it doesn't try to build newlib: make[4]: Leaving directory `/.1/usr/srcdevel/uclibc/toolchain_x86_64-linux-uclibc/binutils-2.18/.obj/ld' make[3]: Leaving directory `/.1/usr/srcdevel/uclibc/toolchain_x86_64-linux-uclibc/binutils-2.18/.obj/ld' make[2]: Leaving directory `/.1/usr/srcdevel/uclibc/toolchain_x86_64-linux-uclibc/binutils-2.18/.obj/ld' make[1]: Nothing to be done for `all-target'. m68k-elf behaves similarly: make[4]: Leaving directory `/.1/usr/src/binutils-2.17/.obj-m68k-elf/ld' make[3]: Leaving directory `/.1/usr/src/binutils-2.17/.obj-m68k-elf/ld' make[2]: Leaving directory `/.1/usr/src/binutils-2.17/.obj-m68k-elf/ld' make[1]: Nothing to be done for `all-target'. make[1]: Leaving directory `/.1/usr/src/binutils-2.17/.obj-m68k-elf' Can somebody shed some light here? -- vda From bernds_cb1 at t-online.de Mon Jun 2 02:55:26 2008 From: bernds_cb1 at t-online.de (Bernd Schmidt) Date: Mon, 02 Jun 2008 11:55:26 +0200 Subject: svn commit: trunk/uClibc: include libc/inet libc/inet/rpc libc/mis etc... In-Reply-To: <200805311247.13242.vda.linux@googlemail.com> References: <20080519225736.CDEF63C682@busybox.net> <200805302255.03660.vda.linux@googlemail.com> <20080530215240.GB31894@mx.loc> <200805311247.13242.vda.linux@googlemail.com> Message-ID: <4843C38E.3070402@t-online.de> Denys Vlasenko wrote: > Thanks. The attached patch fixes it (I applied it to uclibc svn). These patches are not self-explanatory. Could you provide some information about the cause of the failures, and how your patches fix them? Bernd -- This footer brought to you by insane German lawmakers. Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif From bernds_cb1 at t-online.de Mon Jun 2 03:00:00 2008 From: bernds_cb1 at t-online.de (Bernd Schmidt) Date: Mon, 02 Jun 2008 12:00:00 +0200 Subject: cross-compile to blackfin fails In-Reply-To: <200806020347.17227.vda.linux@googlemail.com> References: <200806020347.17227.vda.linux@googlemail.com> Message-ID: <4843C4A0.8010102@t-online.de> Denys Vlasenko wrote: > I got around to building my blackfin toolchain. > I have binutils and gcc built (bfin-linux-uclibc-XXX variety), > now trying to build uclibc: The Blackfin isn't fully merged in uClibc. That should only affect ld.so and parts of the build system though, I thought the mmap thing was sorted. I'll look into it. Bernd -- This footer brought to you by insane German lawmakers. Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif From yoshfuji at linux-ipv6.org Mon Jun 2 03:17:25 2008 From: yoshfuji at linux-ipv6.org (YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=) Date: Mon, 02 Jun 2008 19:17:25 +0900 (JST) Subject: [UCLIBC BUG 1020]: IPv6 DNS Reverse lookup issue Message-ID: <20080602.191725.80845381.yoshfuji@linux-ipv6.org> Hello. Could you take a look at uClibc bug #1020, please? http://bugs.uclibc.org/view.php?id=1020 Due to the global transition of "reverse" DNS tree from ip6.int to ip6.arpa, uclibc cannot convert IPv6 address to name. If any concerns, please let me know. IMHO it is too trivial, and I cannot understand why this bug is alive for these two years. Thank you. -- YOSHIFUJI Hideaki @ USAGI Project GPG-FP : 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From vda.linux at googlemail.com Mon Jun 2 09:22:02 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Mon, 2 Jun 2008 18:22:02 +0200 Subject: svn commit: trunk/uClibc: include libc/inet =?iso-8859-1?q?libc/inet/rpc=09libc/mis?= etc... In-Reply-To: <4843C38E.3070402@t-online.de> References: <20080519225736.CDEF63C682@busybox.net> <200805311247.13242.vda.linux@googlemail.com> <4843C38E.3070402@t-online.de> Message-ID: <200806021822.02077.vda.linux@googlemail.com> On Monday 02 June 2008 11:55, Bernd Schmidt wrote: > Denys Vlasenko wrote: > > Thanks. The attached patch fixes it (I applied it to uclibc svn). > > These patches are not self-explanatory. Could you provide some > information about the cause of the failures, and how your patches fix them? The patch which caused this failure moved libc_hidden_proto(foo) declarations into string.h and strings.h for every function foo which is declared in these files. It is the second stage of a bigger plan to move ALL libc_hidden_proto's from .c files to .h files. It was done after first stage seemed to not cause any significant troubles. First stage was (1) addition of header sanitization step in "make install_headers" which ensured that headers can contain private uclibc parts which will be deleted at install time, and (2) just one libc_hidden_proto(time) was moved to corresponding .h file, and removed from all .c files. I picked string.h and strings.h for second stage of this change because it's one of the most used headers and if there are any problems with what I'm trying to do, I will likely see them. So, what happened in [wc]str[n]casecmp.c? Well, it was relying on the symmetry between strcasecmp and wcscasecmp and the like and played games trying to reduce the number of libc_hidden_proto's. This worked when both strcasecmp and wcscasecmp needed libc_hidden_proto(). But now after stage 2 strcasecmp does not need it anymore (it's from string.h), while wcscasecmp still needs it (it's in wchar.h). The fix is to stop playing tricks and use correct libc_hidden_proto's: #ifdef WANT_WIDE # define strcasecmp wcscasecmp # define strcasecmp_l wcscasecmp_l +libc_hidden_proto(wcscasecmp) +libc_hidden_proto(wcscasecmp_l) # ifdef __UCLIBC_DO_XLOCALE libc_hidden_proto(towlower_l) # define TOLOWER(C) towlower_l((C), locale_arg) @@ -21,6 +23,8 @@ libc_hidden_proto(towlower) # define TOLOWER(C) towlower((C)) # endif #else +/* Experimentally off - libc_hidden_proto(strcasecmp) */ +/* Experimentally off - libc_hidden_proto(strcasecmp_l) */ # ifdef __UCLIBC_DO_XLOCALE libc_hidden_proto(tolower_l) # define TOLOWER(C) tolower_l((C), locale_arg) @@ -35,9 +39,6 @@ libc_hidden_proto(tolower) #if defined(__UCLIBC_HAS_XLOCALE__) && !defined(__UCLIBC_DO_XLOCALE) -/* Experimentally off - libc_hidden_proto(strcasecmp_l) */ - -/* Experimentally off - libc_hidden_proto(strcasecmp) */ This fix is temporary - as soon as Carmelo announces that ntpl merge is complete, I will continue libc_hidden_proto removal from the rest of .c files, and this will remove libc_hidden_proto's shown above too. "/* Experimentally off - libc_hidden_proto(foo) */" lines will be removed too. For example, this will remove these repeated lines: #ifdef __UCLIBC_HAS_XLOCALE__ libc_hidden_proto(__ctype_b_loc) #elif defined __UCLIBC_HAS_CTYPE_TABLES__ libc_hidden_proto(__ctype_b) #endif from 22 .c files, and add them - just once - to ctype.h If you have more questions, please do not hesitate to ask. Thanks, -- vda From carmelo.amoroso at st.com Tue Jun 3 00:46:18 2008 From: carmelo.amoroso at st.com (Carmelo AMOROSO) Date: Tue, 03 Jun 2008 09:46:18 +0200 Subject: blackfin toolchain build question In-Reply-To: <200806020519.12225.vda.linux@googlemail.com> References: <200806020519.12225.vda.linux@googlemail.com> Message-ID: <4844F6CA.9010103@st.com> Denys Vlasenko wrote: > Hi, > > I successfully built bfin-linux-uclibc toolchain > (binutils+gcc) using binutils and gcc trees from > svn://firewall-sources.blackfin.uclinux.org:80/svn/toolchain/trunk > > I already had quite a few toolchains on my machine > and I have a preferred way to build one. > > Therefore I did not use canned scripts from svn > but followed my own procedure, as a more familiar one for me. > > Basically, it involves building cross-compiled binutils, > installing it, then building and installing gcc, > then doing the same for libc. > Trying to build gcc doesn't work, it needs usable $TARGET-ld. > > I observed the following peculiarity: binutils apparently > tried to build newlib, and that requires $TARGET-cc! > > > Hi Denys, cross-binutils can be built from scratch without requiring any TARGET-xxx tools, while cross-gcc needs proper cross-binutils. So probably you are misconfiguring bintuils... os something strange is happening. I never had problem with this, and I don't use buildroot. Cheers, Carmelo From rep.dot.nop at gmail.com Tue Jun 3 01:17:49 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Tue, 3 Jun 2008 10:17:49 +0200 Subject: svn commit: trunk/uClibc: extra/Configs include include/netinet i etc... In-Reply-To: <20080603081157.CCE1C3C659@busybox.net> References: <20080603081157.CCE1C3C659@busybox.net> Message-ID: <20080603081749.GA16015@mx.loc> On Tue, Jun 03, 2008 at 01:11:57AM -0700, aldot at uclibc.org wrote: >Author: aldot >Date: 2008-06-03 01:11:56 -0700 (Tue, 03 Jun 2008) >New Revision: 22198 I'm thinking about rewriting the resolver-code (leaving the current one as an .old alternative) because: 1) It's bloated. 2) It isn't designed to work for IPv6-only. Iff i find the time to tackle this then i expect a first draft to be thread-agnostic, of course. As to the rest below, please CC me if you experience unexpected problems. thanks, Bernhard >Log: >- adds several config-options to allow for turning off certain features > like > o UCLIBC_HAS_GNU_ERROR > o UCLIBC_HAS_BSD_ERR > o UCLIBC_HAS_PTY > o UCLIBC_HAS_GETPT (1) > o UCLIBC_SYSCALL_STUBS > o UCLIBC_SYSCALL_STUB_WARNING > o UCLIBC_LINUX_SPECIFIC (2) > o UCLIBC_BSD_SPECIFIC (3) > o UCLIBC_NTP_LEGACY (4) > o UCLIBC_SV4_DEPRECATED (5) > o UCLIBC_HAVE_REALTIME (6) > o UCLIBC_HAVE_ADVANCED_REALTIME (7) > o UCLIBC_HAVE_EPOLL (8) > o UCLIBC_HAVE_XATTR (9) > o UCLIBC_HAVE_PROFILING (10) > >(1) make non-standard getpt optional and implement standard posix_openpt >(2) fstatfs(), inotify_*(), ioperm(), iopl(), madvise(), modify_ldt(), > personality() > ppoll(), setresuid() >(3) mincore(), getdomainname(), setdomainname() >(4) ntp_adjtime(), ntp_gettime() aliases >(5) ustat() [use statfs(2) in your code instead] >(6) All marked as "(REALTIME)" in SUSv3 >(7) All marked as "(ADVANCED REALTIME)" in SUSv3 >(8) epoll_create(), epoll_ctl(), epoll_wait() >(9) all Extended Attributes >(10) helpers for gcc's -finstrument-functions > >- Fixes _dl_exit() >- Implements sleep(3) for !UCLIBC_HAVE_REALTIME >- Implements usleep(3) for !UCLIBC_HAVE_REALTIME >- adds #warning about incorrect posix_fadvise{,64}() >- removes unused and unwanted uselib() > >Net outcome is that an allnoconfig with HAVE_SHARED is now about 88k instead >of formerly 130k. > > >Modified: > trunk/uClibc/Makefile.in > trunk/uClibc/TODO > trunk/uClibc/extra/Configs/Config.in > trunk/uClibc/include/fcntl.h > trunk/uClibc/include/mqueue.h > trunk/uClibc/include/netinet/in.h > trunk/uClibc/include/signal.h > trunk/uClibc/include/stdlib.h > trunk/uClibc/include/sys/mman.h > trunk/uClibc/include/sys/poll.h > trunk/uClibc/include/sys/statfs.h > trunk/uClibc/include/sys/timex.h > trunk/uClibc/include/time.h > trunk/uClibc/include/unistd.h > trunk/uClibc/ldso/include/dl-syscall.h > trunk/uClibc/libc/inet/Makefile.in > trunk/uClibc/libc/inet/getaddrinfo.c > trunk/uClibc/libc/inet/hostid.c > trunk/uClibc/libc/inet/if_index.c > trunk/uClibc/libc/inet/resolv.c > trunk/uClibc/libc/inet/socketcalls.c > trunk/uClibc/libc/misc/dirent/Makefile.in > trunk/uClibc/libc/misc/error/Makefile.in > trunk/uClibc/libc/misc/error/err.c > trunk/uClibc/libc/misc/statfs/fstatvfs.c > trunk/uClibc/libc/misc/statfs/statvfs.c > trunk/uClibc/libc/misc/syslog/Makefile.in > trunk/uClibc/libc/misc/sysvipc/sem.c > trunk/uClibc/libc/misc/time/Makefile.in > trunk/uClibc/libc/signal/Makefile.in > trunk/uClibc/libc/signal/sigwait.c > trunk/uClibc/libc/stdlib/Makefile.in > trunk/uClibc/libc/stdlib/_atexit.c > trunk/uClibc/libc/stdlib/bsd_getpt.c > trunk/uClibc/libc/stdlib/getpt.c > trunk/uClibc/libc/sysdeps/linux/common/Makefile.in > trunk/uClibc/libc/sysdeps/linux/common/adjtimex.c > trunk/uClibc/libc/sysdeps/linux/common/fstatfs.c > trunk/uClibc/libc/sysdeps/linux/common/getdomainname.c > trunk/uClibc/libc/sysdeps/linux/common/getdtablesize.c > trunk/uClibc/libc/sysdeps/linux/common/getpgid.c > trunk/uClibc/libc/sysdeps/linux/common/getpgrp.c > trunk/uClibc/libc/sysdeps/linux/common/getrlimit.c > trunk/uClibc/libc/sysdeps/linux/common/mincore.c > trunk/uClibc/libc/sysdeps/linux/common/mprotect.c > trunk/uClibc/libc/sysdeps/linux/common/msync.c > trunk/uClibc/libc/sysdeps/linux/common/munlockall.c > trunk/uClibc/libc/sysdeps/linux/common/nanosleep.c > trunk/uClibc/libc/sysdeps/linux/common/poll.c > trunk/uClibc/libc/sysdeps/linux/common/posix_fadvise.c > trunk/uClibc/libc/sysdeps/linux/common/posix_fadvise64.c > trunk/uClibc/libc/sysdeps/linux/common/ppoll.c > trunk/uClibc/libc/sysdeps/linux/common/ptrace.c > trunk/uClibc/libc/sysdeps/linux/common/quotactl.c > trunk/uClibc/libc/sysdeps/linux/common/sbrk.c > trunk/uClibc/libc/sysdeps/linux/common/select.c > trunk/uClibc/libc/sysdeps/linux/common/seteuid.c > trunk/uClibc/libc/sysdeps/linux/common/setpgid.c > trunk/uClibc/libc/sysdeps/linux/common/setresuid.c > trunk/uClibc/libc/sysdeps/linux/common/sigaltstack.c > trunk/uClibc/libc/sysdeps/linux/common/sigpending.c > trunk/uClibc/libc/sysdeps/linux/common/sigprocmask.c > trunk/uClibc/libc/sysdeps/linux/common/sigqueue.c > trunk/uClibc/libc/sysdeps/linux/common/sigsuspend.c > trunk/uClibc/libc/sysdeps/linux/common/statfs.c > trunk/uClibc/libc/sysdeps/linux/common/symlink.c > trunk/uClibc/libc/sysdeps/linux/common/sync.c > trunk/uClibc/libc/sysdeps/linux/common/sysctl.c > trunk/uClibc/libc/sysdeps/linux/common/sysfs.c > trunk/uClibc/libc/sysdeps/linux/common/tee.c > trunk/uClibc/libc/sysdeps/linux/common/truncate64.c > trunk/uClibc/libc/sysdeps/linux/common/umount.c > trunk/uClibc/libc/sysdeps/linux/common/umount2.c > trunk/uClibc/libc/sysdeps/linux/common/uselib.c > trunk/uClibc/libc/sysdeps/linux/common/utimes.c > trunk/uClibc/libc/sysdeps/linux/common/wait3.c > trunk/uClibc/libc/sysdeps/linux/common/wait4.c > trunk/uClibc/libc/sysdeps/linux/common/waitid.c > trunk/uClibc/libc/sysdeps/linux/i386/sys/io.h > trunk/uClibc/libc/unistd/fpathconf.c > trunk/uClibc/libc/unistd/pathconf.c > trunk/uClibc/libc/unistd/sleep.c > trunk/uClibc/libc/unistd/usleep.c > trunk/uClibc/librt/Makefile.in > trunk/uClibc/librt/mq_receive.c > trunk/uClibc/librt/mq_send.c > trunk/uClibc/libutil/Makefile.in > trunk/uClibc/libutil/openpty.c > > >Changeset: > >Sorry, the patch is too large to include (2729 lines). >Please use ViewCVS to see it! > >http://uclibc.org/cgi-bin/viewcvs.cgi?view=rev&root=svn&rev=22198 From rep.dot.nop at gmail.com Tue Jun 3 01:29:15 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Tue, 3 Jun 2008 10:29:15 +0200 Subject: [RFC] build system replacement In-Reply-To: <4842C551.8090605@t-online.de> References: <200805071729.28418.vda.linux@googlemail.com> <200805311158.12076.vda.linux@googlemail.com> <48413CB7.3080300@t-online.de> <200805311757.38863.vda.linux@googlemail.com> <20080601130219.GY27768@mx.loc> <4842C551.8090605@t-online.de> Message-ID: <20080603082915.GB16015@mx.loc> On Sun, Jun 01, 2008 at 05:50:41PM +0200, Bernd Schmidt wrote: > Bernhard Fischer wrote: >> I hope i improved the situation a bit now (if you use r22158 and later). >> We honour both all our prerequisites (if your compiler groks what we >> mean to ask for in our gcc-ism) as well as the used CC and flags. >> I consider this fixed, issue closed, nothing to see here, please move on >> (or holler if i broke something) :) > > I've done a bit of digging, and found the cause of two problems. > > 1. So far, only libc-so-y and libc-a-y are tracked. > This needs to be extended to handle all the other libraries, including > ld.so. > > 2. The CFLAGS passed to the compiler have changed in some cases. > Previously, when compiling ldso/libdl/libdl.c, $^ used to be > "ldso/libdl/libdl.c"; it is now "ldso/libdl/libdl.c FORCE", which means > that $(CFLAGS-$(notdir $(^D)) no longer does the right thing: $(notdir > $(^D)) is now "libdl .". > > There's also $(CFLAGS-$(notdir $<)) in the command line, which doesn't > work for this case, since it expands to "ldso/libdl/"; note the prefix > "ldso/" and the trailing slash. > > We could fix this by using $( maybe it makes sense to clean up the CFLAGS to always mention the full > path without trailing slash. I see that you already took care of this, many thanks. We still have a problem, though. Consider HAVE_SHARED set (i.e. ldso is built) and also some thread variant selected. Build. Turn off thread-support. make clean && make; bummer. Suddently there is no rule to make include/bits/pthreadtypes.h (anymore). We recorded this header as a prereq in the first build, but of course turning off thread-support breaks this horribly. A make realclean obviously would bypass this, but either we need dummy-rules for conditional headers like this or do something else to drop those now unavailable prerequisites. I'll think about this some more, but perhaps somebody has an opinion or an idea.. :) From rep.dot.nop at gmail.com Tue Jun 3 01:53:06 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Tue, 3 Jun 2008 10:53:06 +0200 Subject: [RFC] build system replacement In-Reply-To: References: <20080603082915.GB16015@mx.loc> Message-ID: <20080603085306.GC16015@mx.loc> On Tue, Jun 03, 2008 at 10:39:15AM +0200, Peter Kjellerstedt wrote: >> We still have a problem, though. Consider HAVE_SHARED set >> (i.e. ldso is built) and also some thread variant selected. >> Build. Turn off thread-support. make clean && make; bummer. >> >> Suddently there is no rule to make include/bits/pthreadtypes.h >> (anymore). We recorded this header as a prereq in the first >> build, but of course turning off thread-support breaks this >> horribly. A make realclean obviously would bypass this, but >> either we need dummy-rules for conditional headers like this >> or do something else to drop those now unavailable prerequisites. > >Something along what gcc's -MP option does? Yes. I initially had -MP but dropped it for reasons i don't remember offhand.. So let's just go back to using -MP. Thanks! From peter.kjellerstedt at axis.com Tue Jun 3 01:39:15 2008 From: peter.kjellerstedt at axis.com (Peter Kjellerstedt) Date: Tue, 3 Jun 2008 10:39:15 +0200 Subject: [RFC] build system replacement In-Reply-To: <20080603082915.GB16015@mx.loc> Message-ID: > -----Original Message----- > From: uclibc-bounces at uclibc.org > [mailto:uclibc-bounces at uclibc.org] On Behalf Of Bernhard Fischer > Sent: den 3 juni 2008 10:29 > To: Bernd Schmidt > Cc: uClibc > Subject: Re: [RFC] build system replacement > > On Sun, Jun 01, 2008 at 05:50:41PM +0200, Bernd Schmidt wrote: > > Bernhard Fischer wrote: > >> I hope i improved the situation a bit now (if you use > >> r22158 and later). We honour both all our prerequisites > >> (if your compiler groks what we mean to ask for in our > >> gcc-ism) as well as the used CC and flags. I consider > >> this fixed, issue closed, nothing to see here, please move > >> on (or holler if i broke something) :) > > > > I've done a bit of digging, and found the cause of two > > problems. > > > > 1. So far, only libc-so-y and libc-a-y are tracked. > > This needs to be extended to handle all the other > > libraries, including ld.so. > > > > 2. The CFLAGS passed to the compiler have changed in some > > cases. Previously, when compiling ldso/libdl/libdl.c, $^ > > used to be "ldso/libdl/libdl.c"; it is now > > "ldso/libdl/libdl.c FORCE", which means that > > $(CFLAGS-$(notdir $(^D)) no longer does the right thing: > > $(notdir $(^D)) is now "libdl .". > > > > There's also $(CFLAGS-$(notdir $<)) in the command line, > > which doesn't work for this case, since it expands to > > "ldso/libdl/"; note the prefix "ldso/" and the trailing slash. > > > > We could fix this by using $( > above. Also, maybe it makes sense to clean up the CFLAGS to > > always mention the full path without trailing slash. > > I see that you already took care of this, many thanks. > > We still have a problem, though. Consider HAVE_SHARED set > (i.e. ldso is built) and also some thread variant selected. > Build. Turn off thread-support. make clean && make; bummer. > > Suddently there is no rule to make include/bits/pthreadtypes.h > (anymore). We recorded this header as a prereq in the first > build, but of course turning off thread-support breaks this > horribly. A make realclean obviously would bypass this, but > either we need dummy-rules for conditional headers like this > or do something else to drop those now unavailable prerequisites. Something along what gcc's -MP option does? > I'll think about this some more, but perhaps somebody has an > opinion or an idea.. :) //Peter From bernds_cb1 at t-online.de Tue Jun 3 02:25:42 2008 From: bernds_cb1 at t-online.de (Bernd Schmidt) Date: Tue, 03 Jun 2008 11:25:42 +0200 Subject: svn commit: trunk/uClibc: include libc/stdio In-Reply-To: <20080603035131.C72833C66F@busybox.net> References: <20080603035131.C72833C66F@busybox.net> Message-ID: <48450E16.8000605@t-online.de> vda at uclibc.org wrote: > -struct printf_info > -{ > - int prec; /* Precision. */ > - int width; /* Width. */ > +struct printf_info { > + int prec; /* Precision. */ > + int width; /* Width. */ Please stop mixing code changes with whitespace fixes in a single commit. If you must make whitespace changes (note that they are likely to break out-of-tree patches for very little gain), commit them separately so that functional changes are clearly visible when looking at a patch. Personally I'm not even sure that the way the brace moved in this patch is an improvement. Bernd -- This footer brought to you by insane German lawmakers. Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif From bernds_cb1 at t-online.de Tue Jun 3 02:36:21 2008 From: bernds_cb1 at t-online.de (Bernd Schmidt) Date: Tue, 03 Jun 2008 11:36:21 +0200 Subject: [RFC] build system replacement In-Reply-To: <20080603082915.GB16015@mx.loc> References: <200805071729.28418.vda.linux@googlemail.com> <200805311158.12076.vda.linux@googlemail.com> <48413CB7.3080300@t-online.de> <200805311757.38863.vda.linux@googlemail.com> <20080601130219.GY27768@mx.loc> <4842C551.8090605@t-online.de> <20080603082915.GB16015@mx.loc> Message-ID: <48451095.8030905@t-online.de> There appears to be one additional problem. Sometimes I get the following cycle: bernds at beaker /local/src/uclibc/bernds/uClibc $ make make[1]: `conf' is up to date. STRIP -X --strip-debug -R .note -R .comment lib/libpthread.a AR cr lib/libpthread.a bernds at beaker /local/src/uclibc/bernds/uClibc $ make make[1]: `conf' is up to date. STRIP -X --strip-debug -R .note -R .comment libpthread/linuxthreads.old/libpthread_so.a AR cr libpthread/linuxthreads.old/libpthread_so.a LD libpthread-0.9.29.so bernds at beaker /local/src/uclibc/bernds/uClibc $ make make[1]: `conf' is up to date. STRIP -X --strip-debug -R .note -R .comment lib/libpthread.a AR cr lib/libpthread.a The patch below fixes it. Again, it's probably crude, since I'm not that familiar with all of make's tricks. I noticed you added some rules for .u which contain a strip step in the toplevel Makerules, but I'm not sure how to use these. Comments? Bernd -- This footer brought to you by insane German lawmakers. Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif -------------- next part -------------- A non-text attachment was scrubbed... Name: pthread.diff Type: text/x-patch Size: 4191 bytes Desc: not available Url : http://busybox.net/lists/uclibc/attachments/20080603/29bfb0c9/attachment-0001.bin From carmelo.amoroso at st.com Tue Jun 3 04:49:53 2008 From: carmelo.amoroso at st.com (Carmelo AMOROSO) Date: Tue, 03 Jun 2008 13:49:53 +0200 Subject: [PATCH] doubt in _dl_exit In-Reply-To: <20080523222949.GR27768@mx.loc> References: <20080523222949.GR27768@mx.loc> Message-ID: <48452FE1.8080705@st.com> Bernhard Fischer wrote: > Could somebody who uses ldso please have a look if this breaks his > setup? > > $ size ldso/ldso/ldso.oS* > text data bss dec hex filename > 12424 12 72 12508 30dc ldso/ldso/ldso.oS.old > 12290 12 72 12374 3056 ldso/ldso/ldso.oS > > @@ -59,7 +59,11 @@ > dynamic linking at all, so we cannot return any error codes. > We just punt if there is an error. */ > #define __NR__dl_exit __NR_exit > -static __always_inline _syscall1(void, _dl_exit, int, status); > +static __always_inline attribute_noreturn void _dl_exit(int status) > +{ > + while (1) > + INLINE_SYSCALL(exit, 1, status); > +} > > Hi Bernd, I've just now the chance to update my repo and figured out that this brakes sh4 build. My you explain the rationale for this change ? Thanks, Carmelo > _______________________________________________ > uClibc mailing list > uClibc at uclibc.org > http://busybox.net/cgi-bin/mailman/listinfo/uclibc > > From rep.dot.nop at gmail.com Tue Jun 3 05:07:44 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Tue, 3 Jun 2008 14:07:44 +0200 Subject: [PATCH] doubt in _dl_exit In-Reply-To: <48452FE1.8080705@st.com> References: <20080523222949.GR27768@mx.loc> <48452FE1.8080705@st.com> Message-ID: <20080603120744.GA17981@mx.loc> On Tue, Jun 03, 2008 at 01:49:53PM +0200, Carmelo AMOROSO wrote: > Bernhard Fischer wrote: >> Could somebody who uses ldso please have a look if this breaks his >> setup? >> >> $ size ldso/ldso/ldso.oS* >> text data bss dec hex filename >> 12424 12 72 12508 30dc ldso/ldso/ldso.oS.old >> 12290 12 72 12374 3056 ldso/ldso/ldso.oS >> >> @@ -59,7 +59,11 @@ >> dynamic linking at all, so we cannot return any error codes. >> We just punt if there is an error. */ >> #define __NR__dl_exit __NR_exit >> -static __always_inline _syscall1(void, _dl_exit, int, status); >> +static __always_inline attribute_noreturn void _dl_exit(int status) >> +{ >> + while (1) >> + INLINE_SYSCALL(exit, 1, status); >> +} >> > Hi Bernd, > I've just now the chance to update my repo and figured out that this > brakes sh4 build. > My you explain the rationale for this change ? http://busybox.net/lists/uclibc/2008-May/019394.html I'm not opposed to reverting that hunk but that explicit variant was better, imho. From vda.linux at googlemail.com Tue Jun 3 05:29:31 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Tue, 3 Jun 2008 14:29:31 +0200 Subject: svn commit: trunk/uClibc: include libc/stdio In-Reply-To: <48450E16.8000605@t-online.de> References: <20080603035131.C72833C66F@busybox.net> <48450E16.8000605@t-online.de> Message-ID: <200806031429.31289.vda.linux@googlemail.com> On Tuesday 03 June 2008 11:25, Bernd Schmidt wrote: > vda at uclibc.org wrote: > > -struct printf_info > > -{ > > - int prec; /* Precision. */ > > - int width; /* Width. */ > > +struct printf_info { > > + int prec; /* Precision. */ > > + int width; /* Width. */ > > Please stop mixing code changes with whitespace fixes in a single > commit. If you must make whitespace changes (note that they are likely > to break out-of-tree patches for very little gain), commit them > separately so that functional changes are clearly visible when looking > at a patch. Sorry. Will do that in the future. -- vda From vda.linux at googlemail.com Tue Jun 3 05:31:42 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Tue, 3 Jun 2008 14:31:42 +0200 Subject: blackfin toolchain build question In-Reply-To: <4844F6CA.9010103@st.com> References: <200806020519.12225.vda.linux@googlemail.com> <4844F6CA.9010103@st.com> Message-ID: <200806031431.42430.vda.linux@googlemail.com> On Tuesday 03 June 2008 09:46, Carmelo AMOROSO wrote: > > I successfully built bfin-linux-uclibc toolchain > > (binutils+gcc) using binutils and gcc trees from > > svn://firewall-sources.blackfin.uclinux.org:80/svn/toolchain/trunk > > > > I already had quite a few toolchains on my machine > > and I have a preferred way to build one. > > > > Therefore I did not use canned scripts from svn > > but followed my own procedure, as a more familiar one for me. > > > > Basically, it involves building cross-compiled binutils, > > installing it, then building and installing gcc, > > then doing the same for libc. > > Trying to build gcc doesn't work, it needs usable $TARGET-ld. > > > > I observed the following peculiarity: binutils apparently > > tried to build newlib, and that requires $TARGET-cc! > > > > > > > Hi Denys, > cross-binutils can be built from scratch without requiring any > TARGET-xxx tools, > while cross-gcc needs proper cross-binutils. > So probably you are misconfiguring bintuils... os something strange is > happening. > I never had problem with this, and I don't use buildroot. Are you building blackfin toolchain(s) too? Can you let me know exact version of binutils you use, and also full configure command line which you use? Do you set some special CFLAGS etc? -- vda From carmelo.amoroso at st.com Tue Jun 3 05:27:08 2008 From: carmelo.amoroso at st.com (Carmelo AMOROSO) Date: Tue, 03 Jun 2008 14:27:08 +0200 Subject: [PATCH] doubt in _dl_exit In-Reply-To: <20080603120744.GA17981@mx.loc> References: <20080523222949.GR27768@mx.loc> <48452FE1.8080705@st.com> <20080603120744.GA17981@mx.loc> Message-ID: <4845389C.5040605@st.com> Bernhard Fischer wrote: > On Tue, Jun 03, 2008 at 01:49:53PM +0200, Carmelo AMOROSO wrote: > >> Bernhard Fischer wrote: >> >>> Could somebody who uses ldso please have a look if this breaks his >>> setup? >>> >>> $ size ldso/ldso/ldso.oS* >>> text data bss dec hex filename >>> 12424 12 72 12508 30dc ldso/ldso/ldso.oS.old >>> 12290 12 72 12374 3056 ldso/ldso/ldso.oS >>> >>> @@ -59,7 +59,11 @@ >>> dynamic linking at all, so we cannot return any error codes. >>> We just punt if there is an error. */ >>> #define __NR__dl_exit __NR_exit >>> -static __always_inline _syscall1(void, _dl_exit, int, status); >>> +static __always_inline attribute_noreturn void _dl_exit(int status) >>> +{ >>> + while (1) >>> + INLINE_SYSCALL(exit, 1, status); >>> +} >>> >>> >> Hi Bernd, >> I've just now the chance to update my repo and figured out that this >> brakes sh4 build. >> My you explain the rationale for this change ? >> > > http://busybox.net/lists/uclibc/2008-May/019394.html > > I'm not opposed to reverting that hunk but that explicit variant was > better, imho. > > Hi, the problem is that it needs to update sh4/bits/syscall.h because it doesn't define INLINE_SYSCALL macro. I'll see to update this... so let's keep this. At this point I support all other _syscall macro will be removed as well to use the explicit variant ? Carmelo From bernds_cb1 at t-online.de Tue Jun 3 06:00:58 2008 From: bernds_cb1 at t-online.de (Bernd Schmidt) Date: Tue, 03 Jun 2008 15:00:58 +0200 Subject: blackfin toolchain build question In-Reply-To: <200806031431.42430.vda.linux@googlemail.com> References: <200806020519.12225.vda.linux@googlemail.com> <4844F6CA.9010103@st.com> <200806031431.42430.vda.linux@googlemail.com> Message-ID: <4845408A.30005@t-online.de> Denys Vlasenko wrote: > Are you building blackfin toolchain(s) too? > > Can you let me know exact version of binutils you use, > and also full configure command line which you use? > Do you set some special CFLAGS etc? Just use the buildscript, please. That ensures you get the same toolchain that everyone else uses. Bernd -- This footer brought to you by insane German lawmakers. Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif From rep.dot.nop at gmail.com Tue Jun 3 06:18:32 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Tue, 3 Jun 2008 15:18:32 +0200 Subject: [RFC] build system replacement In-Reply-To: <48451095.8030905@t-online.de> References: <200805071729.28418.vda.linux@googlemail.com> <200805311158.12076.vda.linux@googlemail.com> <48413CB7.3080300@t-online.de> <200805311757.38863.vda.linux@googlemail.com> <20080601130219.GY27768@mx.loc> <4842C551.8090605@t-online.de> <20080603082915.GB16015@mx.loc> <48451095.8030905@t-online.de> Message-ID: <20080603131832.GB17981@mx.loc> On Tue, Jun 03, 2008 at 11:36:21AM +0200, Bernd Schmidt wrote: > There appears to be one additional problem. Sometimes I get the > following cycle: > > bernds at beaker /local/src/uclibc/bernds/uClibc $ make > make[1]: `conf' is up to date. > STRIP -X --strip-debug -R .note -R .comment lib/libpthread.a > AR cr lib/libpthread.a yea, that doesn't make sense to me. First create the archive, then strip it. > bernds at beaker /local/src/uclibc/bernds/uClibc $ make > make[1]: `conf' is up to date. > STRIP -X --strip-debug -R .note -R .comment > libpthread/linuxthreads.old/libpthread_so.a > AR cr libpthread/linuxthreads.old/libpthread_so.a > LD libpthread-0.9.29.so > bernds at beaker /local/src/uclibc/bernds/uClibc $ make > make[1]: `conf' is up to date. > STRIP -X --strip-debug -R .note -R .comment lib/libpthread.a > AR cr lib/libpthread.a > > The patch below fixes it. Again, it's probably crude, since I'm not > that familiar with all of make's tricks. I noticed you added some rules > for .u which contain a strip step in the toplevel Makerules, but I'm not > sure how to use these. > > Comments? I don't really like t_strip_d, let's honour STRIP_FLAGS-$@ instead. From rep.dot.nop at gmail.com Tue Jun 3 06:23:09 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Tue, 3 Jun 2008 15:23:09 +0200 Subject: [PATCH] doubt in _dl_exit In-Reply-To: <4845389C.5040605@st.com> References: <20080523222949.GR27768@mx.loc> <48452FE1.8080705@st.com> <20080603120744.GA17981@mx.loc> <4845389C.5040605@st.com> Message-ID: <20080603132309.GC17981@mx.loc> On Tue, Jun 03, 2008 at 02:27:08PM +0200, Carmelo AMOROSO wrote: > Bernhard Fischer wrote: >> On Tue, Jun 03, 2008 at 01:49:53PM +0200, Carmelo AMOROSO wrote: >> >>> Bernhard Fischer wrote: >>> >>>> Could somebody who uses ldso please have a look if this breaks his >>>> setup? >>>> >>>> $ size ldso/ldso/ldso.oS* >>>> text data bss dec hex filename >>>> 12424 12 72 12508 30dc ldso/ldso/ldso.oS.old >>>> 12290 12 72 12374 3056 ldso/ldso/ldso.oS >>>> >>>> @@ -59,7 +59,11 @@ >>>> dynamic linking at all, so we cannot return any error codes. >>>> We just punt if there is an error. */ >>>> #define __NR__dl_exit __NR_exit >>>> -static __always_inline _syscall1(void, _dl_exit, int, status); >>>> +static __always_inline attribute_noreturn void _dl_exit(int status) >>>> +{ >>>> + while (1) >>>> + INLINE_SYSCALL(exit, 1, status); >>>> +} >>>> >>> Hi Bernd, >>> I've just now the chance to update my repo and figured out that this >>> brakes sh4 build. >>> My you explain the rationale for this change ? >>> >> >> http://busybox.net/lists/uclibc/2008-May/019394.html >> >> I'm not opposed to reverting that hunk but that explicit variant was >> better, imho. >> >> > Hi, > the problem is that it needs to update sh4/bits/syscall.h because it > doesn't define INLINE_SYSCALL macro. > I'll see to update this... so let's keep this. ah, i should have looked if the other arches also do it by INLINE_SYSCALL and not assume they do. I don't want to touch the other arches right now, so i'll revert this hunk in the evening (in a couple of hours). > At this point I support all other _syscall macro will be removed as well > to use the explicit variant ? I didn't intend to look at ldso, no. A janitorial thing somebody could do is make sure all arches are synced so we can remove that errnoeous trailing ';' from _syscall[[:digit:]][[:space:]]*(.*) From rep.dot.nop at gmail.com Tue Jun 3 07:02:05 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Tue, 3 Jun 2008 16:02:05 +0200 Subject: [RFC] build system replacement In-Reply-To: <48451095.8030905@t-online.de> References: <200805071729.28418.vda.linux@googlemail.com> <200805311158.12076.vda.linux@googlemail.com> <48413CB7.3080300@t-online.de> <200805311757.38863.vda.linux@googlemail.com> <20080601130219.GY27768@mx.loc> <4842C551.8090605@t-online.de> <20080603082915.GB16015@mx.loc> <48451095.8030905@t-online.de> Message-ID: <20080603140205.GD17981@mx.loc> On Tue, Jun 03, 2008 at 11:36:21AM +0200, Bernd Schmidt wrote: > There appears to be one additional problem. Sometimes I get the > following cycle: > The patch below fixes it. Again, it's probably crude, since I'm not > that familiar with all of make's tricks. I noticed you added some rules > for .u which contain a strip step in the toplevel Makerules, but I'm not > sure how to use these. > > Comments? I would prefer the attached, completely untested hunks. Please apply if it works for you. PS: seen that odd glitch with new pthreads and pthread_atfork.oS already? I'll look at it later.. -------------- next part -------------- A non-text attachment was scrubbed... Name: stripstuff.patch Type: text/x-diff Size: 2854 bytes Desc: not available Url : http://busybox.net/lists/uclibc/attachments/20080603/cee8f472/attachment-0001.patch From carmelo.amoroso at st.com Tue Jun 3 06:14:06 2008 From: carmelo.amoroso at st.com (Carmelo AMOROSO) Date: Tue, 03 Jun 2008 15:14:06 +0200 Subject: blackfin toolchain build question In-Reply-To: <200806031431.42430.vda.linux@googlemail.com> References: <200806020519.12225.vda.linux@googlemail.com> <4844F6CA.9010103@st.com> <200806031431.42430.vda.linux@googlemail.com> Message-ID: <4845439E.2070307@st.com> Denys Vlasenko wrote: > On Tuesday 03 June 2008 09:46, Carmelo AMOROSO wrote: > >>> I successfully built bfin-linux-uclibc toolchain >>> (binutils+gcc) using binutils and gcc trees from >>> svn://firewall-sources.blackfin.uclinux.org:80/svn/toolchain/trunk >>> >>> I already had quite a few toolchains on my machine >>> and I have a preferred way to build one. >>> >>> Therefore I did not use canned scripts from svn >>> but followed my own procedure, as a more familiar one for me. >>> >>> Basically, it involves building cross-compiled binutils, >>> installing it, then building and installing gcc, >>> then doing the same for libc. >>> Trying to build gcc doesn't work, it needs usable $TARGET-ld. >>> >>> I observed the following peculiarity: binutils apparently >>> tried to build newlib, and that requires $TARGET-cc! >>> >>> >>> >>> >> Hi Denys, >> cross-binutils can be built from scratch without requiring any >> TARGET-xxx tools, >> while cross-gcc needs proper cross-binutils. >> So probably you are misconfiguring bintuils... os something strange is >> happening. >> I never had problem with this, and I don't use buildroot. >> > > Are you building blackfin toolchain(s) too? > Hi Denis, sorry for incomplete reply.. I use only sh4. > Can you let me know exact version of binutils you use, > Version:2.18.50.0.6 ../configure --target=sh4-linux-uclibc --prefix=/opt/STM/STLinux-2.3/devkit/sh4_uclibc --exec-prefix=/opt/STM/STLinux-2.3/devkit/sh4_uclibc --bindir=/opt/STM/STLinux-2.3/devkit/sh4_uclibc/bin --sbindir=/opt/STM/STLinux-2.3/devkit/sh4_uclibc/sbin --sysconfdir=/opt/STM/STLinux-2.3/devkit/sh4_uclibc/etc --datadir=/opt/STM/STLinux-2.3/devkit/sh4_uclibc/share --includedir= /opt/STM/STLinux-2.3/devkit/sh4_uclibc/include --libdir=/opt/STM/STLinux-2.3/devkit/sh4_uclibc/lib --libexecdir=/opt/STM/STL inux-2.3/devkit/sh4_uclibc/libexec --localstatedir=/opt/STM/STLinux-2.3/devkit/sh4_uclibc/var --sharedstatedir=/opt/STM/STLi nux-2.3/devkit/sh4_uclibc/share --mandir=/opt/STM/STLinux-2.3/devkit/sh4_uclibc/man --infodir=/opt/STM/STLinux-2.3/devkit/sh 4_uclibc/info --enable-nls --disable-multilib --program-prefix=sh4-linux-uclibc- --enable-install-libbfd --with-sysroot=/opt /STM/STLinux-2.3/devkit/sh4_uclibc/target nothing special Carmelo > and also full configure command line which you use? > Do you set some special CFLAGS etc? > -- > vda > > From rep.dot.nop at gmail.com Tue Jun 3 07:27:05 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Tue, 3 Jun 2008 16:27:05 +0200 Subject: [RFC] build system replacement In-Reply-To: <48451095.8030905@t-online.de> References: <200805071729.28418.vda.linux@googlemail.com> <200805311158.12076.vda.linux@googlemail.com> <48413CB7.3080300@t-online.de> <200805311757.38863.vda.linux@googlemail.com> <20080601130219.GY27768@mx.loc> <4842C551.8090605@t-online.de> <20080603082915.GB16015@mx.loc> <48451095.8030905@t-online.de> Message-ID: <20080603142705.GE17981@mx.loc> On Tue, Jun 03, 2008 at 11:36:21AM +0200, Bernd Schmidt wrote: Alright. The repeated superfluous rebuild of libpthread/linuxthreads/pthread_atfork.oS was due to a missing files.dep := $(libc-a-y) $(libc-so-y) $(libc-nonshared-y) $(libm-a-y) $(libm-so-y) -files.dep += $(libpthread-a-y) $(libpthread-so-y) $(libthread_db-a-y) $(libthread_db-so-y) +files.dep += $(libpthread-a-y) $(libpthread-so-y) $(libthread_db-a-y) $(libthread_db-so-y) $(libpthread-nonshared-y) files.dep += $(librt-a-y) $(librt-so-y) $(libresolv-a-y) $(libresolv-so-y) From vda.linux at googlemail.com Tue Jun 3 07:27:41 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Tue, 3 Jun 2008 16:27:41 +0200 Subject: [RFC] build system replacement In-Reply-To: <20080603131832.GB17981@mx.loc> References: <200805071729.28418.vda.linux@googlemail.com> <48451095.8030905@t-online.de> <20080603131832.GB17981@mx.loc> Message-ID: <200806031627.41277.vda.linux@googlemail.com> On Tuesday 03 June 2008 15:18, Bernhard Fischer wrote: > On Tue, Jun 03, 2008 at 11:36:21AM +0200, Bernd Schmidt wrote: > > There appears to be one additional problem. Sometimes I get the > > following cycle: > > > > bernds at beaker /local/src/uclibc/bernds/uClibc $ make > > make[1]: `conf' is up to date. > > STRIP -X --strip-debug -R .note -R .comment lib/libpthread.a > > AR cr lib/libpthread.a > > yea, that doesn't make sense to me. First create the archive, > then strip it. I don't think it will work. strip can't operate on .a files. The message is misleading - in reality here strip acts not on lib/libpthread.a but on .o files which will then go into lib/libpthread.a. Run make V=1 and it will be visible. -- vda From rep.dot.nop at gmail.com Tue Jun 3 07:33:55 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Tue, 3 Jun 2008 16:33:55 +0200 Subject: svn commit: trunk/uClibc/libc/misc/syslog In-Reply-To: <20080603142613.3D4193C6F0@busybox.net> References: <20080603142613.3D4193C6F0@busybox.net> Message-ID: <20080603143355.GF17981@mx.loc> On Tue, Jun 03, 2008 at 07:26:13AM -0700, vda at uclibc.org wrote: >Author: vda >Date: 2008-06-03 07:26:12 -0700 (Tue, 03 Jun 2008) >New Revision: 22201 >-static int LogFile = -1; /* fd for log */ >-static smalluint connected; /* have done connect */ >-static int LogStat = 0; /* status bits, set by openlog() */ >-static const char *LogTag = "syslog"; /* string to tag the entry with */ >-static int LogFacility = LOG_USER; /* default facility code */ >-static int LogMask = 0xff; /* mask of priorities to be logged */ >-static struct sockaddr SyslogAddr; /* AF_UNIX address of local logger */ >+static int LogFile = -1; /* fd for log */ >+static smalluint connected; /* have done connect */ >+/* all bits in option argument for openlog() fit in 8 bits */ >+static smalluint LogStat = 0; /* status bits, set by openlog() */ >+static const char *LogTag = "syslog"; /* string to tag the entry with */ >+/* this fits in 8 bits too (LOG_LOCAL7 = 23<<3 = 184), >+ * but NB: LOG_FACMASK is bigger (= 0x03f8 = 127<<3) for some strange reason. >+ * Oh well. */ >+static int LogFacility = LOG_USER;/* default facility code */ >+/* bits mask of priorities (eight prios - 8 bits is enough) */ >+static smalluint LogMask = 0xff; /* mask of priorities to be logged */ can't we just use different masks and just use one (let's say) static unsigned int _state; Even if this would not proove benefical in this very spot, there are quite some functions that can be shrinked by just masking several smaller state-vars (each only using a ver few bits) into one. Comments? From rep.dot.nop at gmail.com Tue Jun 3 07:45:45 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Tue, 3 Jun 2008 16:45:45 +0200 Subject: [RFC] build system replacement In-Reply-To: <200806031627.41277.vda.linux@googlemail.com> References: <200805071729.28418.vda.linux@googlemail.com> <48451095.8030905@t-online.de> <20080603131832.GB17981@mx.loc> <200806031627.41277.vda.linux@googlemail.com> Message-ID: <20080603144545.GA19467@mx.loc> On Tue, Jun 03, 2008 at 04:27:41PM +0200, Denys Vlasenko wrote: >On Tuesday 03 June 2008 15:18, Bernhard Fischer wrote: >> On Tue, Jun 03, 2008 at 11:36:21AM +0200, Bernd Schmidt wrote: >> > There appears to be one additional problem. Sometimes I get the >> > following cycle: >> > >> > bernds at beaker /local/src/uclibc/bernds/uClibc $ make >> > make[1]: `conf' is up to date. >> > STRIP -X --strip-debug -R .note -R .comment lib/libpthread.a >> > AR cr lib/libpthread.a >> >> yea, that doesn't make sense to me. First create the archive, >> then strip it. > >I don't think it will work. strip can't operate on .a files. really? $ for i in $(seq 1 3);do echo "int i$i=$i;" | gcc -g3 -xc -o foo$i.o -c -;done $ ar cr bar.a foo?.o $ ls -als bar.a 16 -rw-r--r-- 1 b b 12454 2008-06-03 16:43 bar.a $ strip -x bar.a ; echo $? 0 $ ls -als bar.a 4 -rw-r--r-- 1 b b 2230 2008-06-03 16:43 bar.a Sounds like a bit like it would work fine, no? From bernds_cb1 at t-online.de Tue Jun 3 07:54:20 2008 From: bernds_cb1 at t-online.de (Bernd Schmidt) Date: Tue, 03 Jun 2008 16:54:20 +0200 Subject: [RFC] build system replacement In-Reply-To: <20080603140205.GD17981@mx.loc> References: <200805071729.28418.vda.linux@googlemail.com> <200805311158.12076.vda.linux@googlemail.com> <48413CB7.3080300@t-online.de> <200805311757.38863.vda.linux@googlemail.com> <20080601130219.GY27768@mx.loc> <4842C551.8090605@t-online.de> <20080603082915.GB16015@mx.loc> <48451095.8030905@t-online.de> <20080603140205.GD17981@mx.loc> Message-ID: <48455B1C.10508@t-online.de> Bernhard Fischer wrote: > I would prefer the attached, completely untested hunks. > Please apply if it works for you. I'd drop the STRIP_FILES, as only STRIP_T_FILES really makes sense here. Also, I noticed that libpthread isn't the only place that does this, so we'll have to expand this a little :-/ Bernd -- This footer brought to you by insane German lawmakers. Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif From vda.linux at googlemail.com Tue Jun 3 08:54:50 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Tue, 3 Jun 2008 17:54:50 +0200 Subject: [RFC] build system replacement In-Reply-To: <20080603144545.GA19467@mx.loc> References: <200805071729.28418.vda.linux@googlemail.com> <200806031627.41277.vda.linux@googlemail.com> <20080603144545.GA19467@mx.loc> Message-ID: <200806031754.50183.vda.linux@googlemail.com> On Tuesday 03 June 2008 16:45, Bernhard Fischer wrote: > On Tue, Jun 03, 2008 at 04:27:41PM +0200, Denys Vlasenko wrote: > >On Tuesday 03 June 2008 15:18, Bernhard Fischer wrote: > >> On Tue, Jun 03, 2008 at 11:36:21AM +0200, Bernd Schmidt wrote: > >> > There appears to be one additional problem. Sometimes I get the > >> > following cycle: > >> > > >> > bernds at beaker /local/src/uclibc/bernds/uClibc $ make > >> > make[1]: `conf' is up to date. > >> > STRIP -X --strip-debug -R .note -R .comment lib/libpthread.a > >> > AR cr lib/libpthread.a > >> > >> yea, that doesn't make sense to me. First create the archive, > >> then strip it. > > > >I don't think it will work. strip can't operate on .a files. > > really? > $ for i in $(seq 1 3);do echo "int i$i=$i;" | gcc -g3 -xc -o foo$i.o -c -;done > $ ar cr bar.a foo?.o > $ ls -als bar.a > 16 -rw-r--r-- 1 b b 12454 2008-06-03 16:43 bar.a > $ strip -x bar.a ; echo $? > 0 > $ ls -als bar.a > 4 -rw-r--r-- 1 b b 2230 2008-06-03 16:43 bar.a > > Sounds like a bit like it would work fine, no? Wow :) I didn't expect it to work. :) But the rest of what I said I know for sure. Look: I touch libm/w_sqrt.c and run make: CC libm/w_sqrt.o STRIP -x -R .note -R .comment lib/libm.a AR cr lib/libm.a I touch libm/w_sqrt.c and run make V=1: gcc -c libm/w_sqrt.c -o libm/w_sqrt.o -include ./include/libc-symbols.h -Wall ... install -d lib/ rm -f lib/libm.a strip -x -R .note -R .comment libm/e_acos.o libm/e_acosh.o libm/e_asin.o ... libm/llrintf.o ar cr lib/libm.a libm/e_acos.o libm/e_acosh.o libm/e_asin.o ... libm/llrintf.o See? strip is run on .o files, not .a file. "STRIP -x -R .note -R .comment lib/libm.a" line is lying. -- vda > From rep.dot.nop at gmail.com Tue Jun 3 14:02:43 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Tue, 3 Jun 2008 23:02:43 +0200 Subject: [RFC] build system replacement In-Reply-To: <200806031754.50183.vda.linux@googlemail.com> References: <200805071729.28418.vda.linux@googlemail.com> <200806031627.41277.vda.linux@googlemail.com> <20080603144545.GA19467@mx.loc> <200806031754.50183.vda.linux@googlemail.com> Message-ID: <20080603210243.GB27768@mx.loc> On Tue, Jun 03, 2008 at 05:54:50PM +0200, Denys Vlasenko wrote: >On Tuesday 03 June 2008 16:45, Bernhard Fischer wrote: >> On Tue, Jun 03, 2008 at 04:27:41PM +0200, Denys Vlasenko wrote: >> >On Tuesday 03 June 2008 15:18, Bernhard Fischer wrote: >> >> On Tue, Jun 03, 2008 at 11:36:21AM +0200, Bernd Schmidt wrote: >> >> > There appears to be one additional problem. Sometimes I get the >> >> > following cycle: >> >> > >> >> > bernds at beaker /local/src/uclibc/bernds/uClibc $ make >> >> > make[1]: `conf' is up to date. >> >> > STRIP -X --strip-debug -R .note -R .comment lib/libpthread.a >> >> > AR cr lib/libpthread.a >> >> >> >> yea, that doesn't make sense to me. First create the archive, >> >> then strip it. >> > >> >I don't think it will work. strip can't operate on .a files. >> >> really? >> $ for i in $(seq 1 3);do echo "int i$i=$i;" | gcc -g3 -xc -o foo$i.o -c -;done >> $ ar cr bar.a foo?.o >> $ ls -als bar.a >> 16 -rw-r--r-- 1 b b 12454 2008-06-03 16:43 bar.a >> $ strip -x bar.a ; echo $? >> 0 >> $ ls -als bar.a >> 4 -rw-r--r-- 1 b b 2230 2008-06-03 16:43 bar.a >> >> Sounds like a bit like it would work fine, no? > >Wow :) I didn't expect it to work. :) > >But the rest of what I said I know for sure. Look: >I touch libm/w_sqrt.c and run make: > > CC libm/w_sqrt.o > STRIP -x -R .note -R .comment lib/libm.a > AR cr lib/libm.a > >I touch libm/w_sqrt.c and run make V=1: > >gcc -c libm/w_sqrt.c -o libm/w_sqrt.o -include ./include/libc-symbols.h -Wall ... >install -d lib/ >rm -f lib/libm.a >strip -x -R .note -R .comment libm/e_acos.o libm/e_acosh.o libm/e_asin.o ... libm/llrintf.o >ar cr lib/libm.a libm/e_acos.o libm/e_acosh.o libm/e_asin.o ... libm/llrintf.o > >See? strip is run on .o files, not .a file. I have a simpler fix pending than bernd's (and my follow-up) that i will test tomorrow evening (didn't have time this evening and should call it a day now, sorry). >"STRIP -x -R .note -R .comment lib/libm.a" line is lying. yea I know. We will trick this into just saying "STRIP" or (if anything else and if we just strip dbg-info "STRIP-dbg"). From bernds_cb1 at t-online.de Tue Jun 3 14:30:04 2008 From: bernds_cb1 at t-online.de (Bernd Schmidt) Date: Tue, 03 Jun 2008 23:30:04 +0200 Subject: svn commit: trunk/uClibc: extra/Configs include include/netinet i etc... In-Reply-To: <20080603081749.GA16015@mx.loc> References: <20080603081157.CCE1C3C659@busybox.net> <20080603081749.GA16015@mx.loc> Message-ID: <4845B7DC.1080300@t-online.de> Bernhard Fischer wrote: >> - adds several config-options to allow for turning off certain features This seems a good way to reduce size. One additional idea I had recently was to add a config option to turn off non-reentrant functions where a reentrant version exists (e.g. gethostbyname vs gethostbyname_r). That's because I still believe the uc_malloc trick comes at a reliability cost, so I'd rather revert that and provide a way for people to configure out the functions using static data. However, I don't know whether this is feasible, or if these functions are still very much in use. What do you guys think? Bernd -- This footer brought to you by insane German lawmakers. Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif From manuel at sisdetec.es Tue Jun 3 13:51:51 2008 From: manuel at sisdetec.es (Manuel Cano) Date: Tue, 03 Jun 2008 22:51:51 +0200 Subject: Compiling binutils 2.18. Message-ID: <1212526311.30766.15.camel@desarrollo.sisdetec.es> Hello. I've searched for this error but I haven't found an answer. When I compile binutils 2.18 I get an error from info (missing makeinfo) but I've compiled texinfo and installed in buildroot (a stock buildroot) and I have the same error. I run 'makeinfo' manually and it is there, but the binutils package tells me that it isn't there. I'm using http://www.uclibc.org/downloads/root_fs_i386.ext2.bz2 chroot'ed in an Ubuntu box (but Ubuntu shouldn't be a problem, isn't it?). I hope this is something known because I'm desperated now. I've tryied to compile a complete toolchain in several systems (Slackware, Arch, Ubuntu and others) to no avail, but once I've found uClibc and tested some software I absolutely want uClibc because all soft I've tryied runs much faster. The make output (from the warning): WARNING: `makeinfo' is missing on your system. You should only need it if you modified a `.texi' or `.texinfo' file, or any other file indirectly affecting the aspect of the manual. The spurious call might also be the consequence of using a buggy `make' (AIX, DU, IRIX). You might want to install the `Texinfo' package or the `GNU make' package. Grab either from any GNU archive site. make[3]: *** [bfd.info] Error 1 make[3]: Leaving directory `/usr/src/build-binutils/bfd/doc' Making info in po make[3]: Entering directory `/usr/src/build-binutils/bfd/po' ( if test 'x../../../binutils-2.18/bfd/po' != 'x.'; then \ posrcprefix='../../../binutils-2.18/bfd/'; \ else \ posrcprefix="../"; \ fi; \ rm -f SRC-POTFILES-t SRC-POTFILES \ && (sed -e '/^#/d' \ -e '/^[ ]*$/d' \ -e "s at .*@ $posrcprefix& \\\\@" < ../../../binutils-2.18/bfd/po/SRC-POTFILES.in \ | sed -e '$s/\\$//') > SRC-POTFILES-t \ && chmod a-w SRC-POTFILES-t \ && mv SRC-POTFILES-t SRC-POTFILES ) ( rm -f BLD-POTFILES-t BLD-POTFILES \ && (sed -e '/^#/d' \ -e '/^[ ]*$/d' \ -e "s at .*@ ../& \\\\@" < ../../../binutils-2.18/bfd/po/BLD-POTFILES.in \ | sed -e '$s/\\$//') > BLD-POTFILES-t \ && chmod a-w BLD-POTFILES-t \ && mv BLD-POTFILES-t BLD-POTFILES ) cd .. \ && CONFIG_FILES=po/Makefile.in:po/Make-in \ CONFIG_HEADERS= /bin/sh ./config.status config.status: creating po/Makefile.in config.status: executing depfiles commands config.status: executing libtool commands config.status: executing default-1 commands config.status: executing bfd_stdint.h commands config.status: executing default commands make[3]: Leaving directory `/usr/src/build-binutils/bfd/po' make[3]: Entering directory `/usr/src/build-binutils/bfd/po' make[3]: Nothing to be done for `info'. make[3]: Leaving directory `/usr/src/build-binutils/bfd/po' make[3]: Entering directory `/usr/src/build-binutils/bfd' make[3]: Nothing to be done for `info-am'. make[3]: Leaving directory `/usr/src/build-binutils/bfd' make[2]: *** [info-recursive] Error 1 make[2]: Leaving directory `/usr/src/build-binutils/bfd' make[1]: *** [all-bfd] Error 2 make[1]: Leaving directory `/usr/src/build-binutils' make: *** [all] Error 2 What I've typed: (root) /usr/src/build-binutils$ makeinfo makeinfo: missing file argument. Try `makeinfo --help' for more information. (root) /usr/src/build-binutils$ Thank you for your patience. Manuel. From rep.dot.nop at gmail.com Wed Jun 4 00:36:38 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Wed, 4 Jun 2008 09:36:38 +0200 Subject: [OT] Re: Compiling binutils 2.18. In-Reply-To: <1212526311.30766.15.camel@desarrollo.sisdetec.es> References: <1212526311.30766.15.camel@desarrollo.sisdetec.es> Message-ID: <20080604073637.GA20378@mx.loc> On Tue, Jun 03, 2008 at 10:51:51PM +0200, Manuel Cano wrote: >Hello. > >I've searched for this error but I haven't found an answer. This question is not really on topic here and this is an old issue that has been answered many, many times. http://repo.or.cz/w/buildroot.git?a=tree;f=toolchain/binutils/2.18;hb=HEAD From vda.linux at googlemail.com Wed Jun 4 08:40:09 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Wed, 4 Jun 2008 17:40:09 +0200 Subject: svn commit: trunk/uClibc/libc/sysdeps/linux/bfin In-Reply-To: <20080603232844.270D03C678@busybox.net> References: <20080603232844.270D03C678@busybox.net> Message-ID: <200806041740.10004.vda.linux@googlemail.com> On Wednesday 04 June 2008 01:28, bernds at uclibc.org wrote: > Author: bernds > Date: 2008-06-03 16:28:43 -0700 (Tue, 03 Jun 2008) > New Revision: 22207 > > Log: > Fix merge error: mmap.c no longer exists in bfin/. I confirm that this allowed me to build uclibc (and then busybox too). Thanks! Trying to run busybox on bfin board: BINFMT_FLAT: bad magic/rev (0x1010100, need 0x5) BINFMT_FLAT: bad magic/rev (0x1010100, need 0x5) I guess it means my kernel lacks fdpic support, it knows only flat format? Kernel's version: root:~> cat /proc/version Linux version 2.6.12.1-BFIN-2005R3 (root at sevens) (gcc version 3.4.4) #1 Fri Sep 30 10:59:31 CST 2005 -- vda From bernds_cb1 at t-online.de Wed Jun 4 08:55:02 2008 From: bernds_cb1 at t-online.de (Bernd Schmidt) Date: Wed, 04 Jun 2008 17:55:02 +0200 Subject: svn commit: trunk/uClibc/libc/sysdeps/linux/bfin In-Reply-To: <200806041740.10004.vda.linux@googlemail.com> References: <20080603232844.270D03C678@busybox.net> <200806041740.10004.vda.linux@googlemail.com> Message-ID: <4846BAD6.9070805@t-online.de> Denys Vlasenko wrote: > BINFMT_FLAT: bad magic/rev (0x1010100, need 0x5) > BINFMT_FLAT: bad magic/rev (0x1010100, need 0x5) > > I guess it means my kernel lacks fdpic support, it knows > only flat format? Either that or you didn't use -Wl,-elf2flt. Our version of the uClinux build system should get that right, but... Kernel's version: > > root:~> cat /proc/version > Linux version 2.6.12.1-BFIN-2005R3 (root at sevens) (gcc version 3.4.4) #1 Fri Sep 30 10:59:31 CST 2005 Those are really ancient versions. Bernd -- This footer brought to you by insane German lawmakers. Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif From rep.dot.nop at gmail.com Wed Jun 4 10:21:38 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Wed, 4 Jun 2008 19:21:38 +0200 Subject: cosmetic Makefile fix In-Reply-To: <200805310842.46012.vda.linux@googlemail.com> References: <200805310842.46012.vda.linux@googlemail.com> Message-ID: <20080604172138.GD30430@mx.loc> On Sat, May 31, 2008 at 08:42:45AM +0200, Denys Vlasenko wrote: >Hi Bernd, > >While testing build system with some scripts I was bitten >by the cosmetic problem that make is never silent. >Even if it doesn't build anything, it says >"make[1]: `conf' is up to date". My scripts were deciding >that if make says something, it means we see spurious >rebuilds happening. > >I added this TODO for now in top-level Makefile.in: > >extra/config/conf extra/config/mconf: include/bits ># TODO: this results in "make[1]: `conf' is up to date" printed ># on every rebuild, because extra/config/conf is already built ># on previous make run. Make it "test -x $@ || ..." (simple & a bit wrong) ># or "make -q -C extra/config $(notdir $@) || ..." (less readable)? > $(Q)$(MAKE) -C extra/config $(notdir $@) > >In your opinion, which option would be more appropriate here? I don't see why we need this dependency in the first place? Does anybody see why we shouldn't just remove it? With or without it, we miss one crucial dep anyway: $ make -j 128 [] ./extra/scripts/conf-header.sh .config > include/bits/uClibc_config.h CC ldso/ldso/ldso.oS AS ldso/ldso/i386/resolve.oS CC ldso/libdl/libdl.oS CC libc/sysdeps/linux/i386/brk.os In file included from ./ldso/ldso/i386/dl-syscalls.h:3, from ./ldso/include/dl-syscall.h:12, from ./ldso/include/ldso.h:36, from ldso/ldso/ldso.c:33: ./include/sys/syscall.h:32:25: error: bits/sysnum.h: No such file or directory I'm looking into this. -------------- next part -------------- A non-text attachment was scrubbed... Name: uClibc-0.9.29-no-odd-include_bits-dep.patch Type: text/x-diff Size: 2136 bytes Desc: not available Url : http://busybox.net/lists/uclibc/attachments/20080604/22205f69/attachment.patch From chtaylo3 at gmail.com Wed Jun 4 15:21:40 2008 From: chtaylo3 at gmail.com (Christopher Taylor) Date: Wed, 4 Jun 2008 18:21:40 -0400 Subject: double word ordering on little endian Message-ID: <2590773a0806041521v5e43f05ex559c558dcf891eaa@mail.gmail.com> For some reason when I examine the bytes of a double i'm getting the words swapped double = 2.048; on big endian: 4000 624d d2f1 a9fc what I'm getting on little endian: 4d62 0040 fca9 f1d2 what I'm expecting based on somone elses build (and my understanding of little vs big endian): fca9 f1d2 4d62 0040 Any guidance would be appreciated! -Chris From raj.khem at gmail.com Wed Jun 4 16:28:32 2008 From: raj.khem at gmail.com (Khem Raj) Date: Wed, 04 Jun 2008 16:28:32 -0700 Subject: double word ordering on little endian In-Reply-To: <2590773a0806041521v5e43f05ex559c558dcf891eaa@mail.gmail.com> References: <2590773a0806041521v5e43f05ex559c558dcf891eaa@mail.gmail.com> Message-ID: <48472520.7050100@gmail.com> Christopher Taylor wrote: > For some reason when I examine the bytes of a double i'm getting the > words swapped > > double = 2.048; > > on big endian: > 4000 624d d2f1 a9fc > > what I'm getting on little endian: > 4d62 0040 fca9 f1d2 > > what I'm expecting based on somone elses build (and my understanding > of little vs big endian): > fca9 f1d2 4d62 0040 > > > Any guidance would be appreciated! What architecture is it on. if ARM what float format are you using vfp or fpa > > -Chris > _______________________________________________ > uClibc mailing list > uClibc at uclibc.org > http://busybox.net/cgi-bin/mailman/listinfo/uclibc > From chtaylo3 at gmail.com Wed Jun 4 17:09:05 2008 From: chtaylo3 at gmail.com (Christopher Taylor) Date: Wed, 4 Jun 2008 20:09:05 -0400 Subject: double word ordering on little endian In-Reply-To: <48472520.7050100@gmail.com> References: <2590773a0806041521v5e43f05ex559c558dcf891eaa@mail.gmail.com> <48472520.7050100@gmail.com> Message-ID: <2590773a0806041709y17799ca8xbad8346c4b5d8df1@mail.gmail.com> arm5 (Atmel at91). As far as vfp vs fpa, I'm using the 'default' from buildroot with gcc 4.2.1. Not sure how this is set inside buildroot/uclibc. The previous developer on this task was using an older version of buildroot with gcc 3.4.6. Any thoughts? Thank you for your help! -Chris On Wed, Jun 4, 2008 at 7:28 PM, Khem Raj wrote: > Christopher Taylor wrote: >> For some reason when I examine the bytes of a double i'm getting the >> words swapped >> >> double = 2.048; >> >> on big endian: >> 4000 624d d2f1 a9fc >> >> what I'm getting on little endian: >> 4d62 0040 fca9 f1d2 >> >> what I'm expecting based on somone elses build (and my understanding >> of little vs big endian): >> fca9 f1d2 4d62 0040 >> >> >> Any guidance would be appreciated! > > What architecture is it on. if ARM what float format are you using vfp or fpa > >> >> -Chris >> _______________________________________________ >> uClibc mailing list >> uClibc at uclibc.org >> http://busybox.net/cgi-bin/mailman/listinfo/uclibc >> > > From vda.linux at googlemail.com Wed Jun 4 17:13:17 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Thu, 5 Jun 2008 02:13:17 +0200 Subject: elf2flt questions Message-ID: <200806050213.17578.vda.linux@googlemail.com> Hi Mike. A bit of a background of what I am doing here. I was given a blackfin board (BF537). I want to build and run busybox on it (for starters). I never built or ran blackfin binaries, and more broadly have no experience with flat binaries for any architecture. I want to do it in "Linux from scratch" style. This way, I will get better understanding of the way it is done, and possibly stumble upon rough edges in busybox, uclubc, etc. This will lead to "itch scratching" and bug fixing. I managed to build uclibc as a static lib and busybox as a static elf binary for bfin. Now I need to create a flat binary. For one, the kernel on this board seems to be unable to run elf binaries, it says "BINFMT_FLAT: bad magic/rev (0x1010100, need 0x5)". It means that I am venturing into unexplored (by me) territory of elf2flt. I took toolchain/trunk/elf2flt directory and built elf2flt: # ./elf2flt Usage: ./elf2flt [vrzd] [-p ] [-s stack-size] [-o ] -v : verbose operation -r : force load to RAM -k : enable kernel trace on load (for debug) -z : compress code/data/relocs -d : compress data/relocs -a : use existing symbol references instead of recalculating from relocation info -R reloc-file : read relocations from a separate file -p abs-pic-file : GOT/PIC processing with files -s stacksize : set application stack size -o output-file : output file name Compiled for bfin architecture To be honest, building it was somewhat contrived - I copied the directory into binutils' build dir and gave it all necessary configure parameters, and it still could not find e.g. elf/bfin.h - had to add some include paths by hand. (Do you want a more detailed report about this?) If I did it incorrectly - well, there are no build instructions apart from configure help. Looking into ld-elf2flt makes me doubtful - "LINKER="$0.real" # the original renamed-linker" - really? It will rename my linker and replace it by itself? This script looks rather contrived, will it really work correctly for all possible invocations of ld which don't even want to do any elf2flt-ification? This makes me reluctant to run "make install" blidly, I decided to ask you instead for some directions. In the order of importance: Can you write up a small explanation what elf2flt does, how to produce a flat executable with it? Let's say in my situation - I seem to have correctly built static elf bfin busybox, can I make a flat one out of it? What is this ld-elf2flt wrapper - what is it doing? How elf2flt is added into binutils? Again, my situation - I built bfin toolchain (binutils+gcc), it works, but it produces elf executables. (Actually, I have two toolchains - bfin-linux-uclibc and bfin-uclinux. Both produce elf executables). How to add elf2flt to the toolchain so that it can produce flat executables? After that, how to instruct ld to produce flat executable? Thanks. -- vda From vda.linux at googlemail.com Wed Jun 4 17:31:33 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Thu, 5 Jun 2008 02:31:33 +0200 Subject: cosmetic Makefile fix In-Reply-To: <20080604172138.GD30430@mx.loc> References: <200805310842.46012.vda.linux@googlemail.com> <20080604172138.GD30430@mx.loc> Message-ID: <200806050231.33740.vda.linux@googlemail.com> On Wednesday 04 June 2008 19:21, Bernhard Fischer wrote: > >I added this TODO for now in top-level Makefile.in: > > > >extra/config/conf extra/config/mconf: include/bits > ># TODO: this results in "make[1]: `conf' is up to date" printed > ># on every rebuild, because extra/config/conf is already built > ># on previous make run. Make it "test -x $@ || ..." (simple & a bit wrong) > ># or "make -q -C extra/config $(notdir $@) || ..." (less readable)? > > $(Q)$(MAKE) -C extra/config $(notdir $@) > > > >In your opinion, which option would be more appropriate here? > > I don't see why we need this dependency in the first place? > > Does anybody see why we shouldn't just remove it? Have no idea. Why? Because whoever added that dependency did not add a comment why it is needed. I am sure author was a much clever guy than me and it was obvious to him why it is needed. However, not everyone is a genius. Neither I nor you can see now why it is needed. Imagine how much more easier it could be if there was a comment like # Needed for "make; touch foo/bar; make" case Just a few comment lines can save hours of head scratching later. And yet, they are not there. I would like to ask you guys to add comments when you code up something non-obvious. Think about poor guy who will read it months/years later. It is not limited to makefiles - C files as well. I got this habit of forcing me to write down stuff after I had a recurring experience of coming back to *my own code* and not understanding what it is doing, or why it is coded in some specific way. Deciphering it again is a waste fo time and is error-prone. > I'm looking into this. -extra/config/conf extra/config/mconf: include/bits -# TODO: this results in "make[1]: `conf' is up to date" printed -# on every rebuild, because extra/config/conf is already built -# on previous make run. Make it "test -x $@ || ..." (simple & a bit wrong) -# or "make -q -C extra/config $(notdir $@) || ..." (less readable)? +extra/config/conf extra/config/mconf: $(Q)$(MAKE) -C extra/config $(notdir $@) In light of my previous passage... please, consider not removing comments... (Of course, not applicable to cases when comment is wrong, or is flatly obvious: "i++; /* increment index */" - well duh...) -- vda From bernds_cb1 at t-online.de Wed Jun 4 17:34:52 2008 From: bernds_cb1 at t-online.de (Bernd Schmidt) Date: Thu, 05 Jun 2008 02:34:52 +0200 Subject: elf2flt questions In-Reply-To: <200806050213.17578.vda.linux@googlemail.com> References: <200806050213.17578.vda.linux@googlemail.com> Message-ID: <484734AC.7050903@t-online.de> Denys Vlasenko wrote: > I want to do it in "Linux from scratch" style. This way, > I will get better understanding of the way it is done, > and possibly stumble upon rough edges in busybox, > uclubc, etc. This will lead to "itch scratching" > and bug fixing. It will also lead to unnecessary pain. > elf binaries, it says "BINFMT_FLAT: bad magic/rev (0x1010100, need 0x5)". One thing I just remembered is that we used to have non-standard flat files. Version 5 doesn't exist in any tools/kernels other than ancient Blackfin distributions. Our tools were fixed long ago to generate version 4 flat binaries. With a modern toolchain you can't actually produce binaries that will run on the 2005 kernel you're using (never mind that it's totally bug-infested anyway), so please upgrade that first. There's a u-boot installed on your board, surely? > To be honest, building it was somewhat contrived - I copied the directory > into binutils' build dir and gave it all necessary configure parameters, > and it still could not find e.g. elf/bfin.h - had to add some include paths > by hand. (Do you want a more detailed report about this?) No. Use the buildscript or look at how it does things. > Looking into ld-elf2flt makes me doubtful - > "LINKER="$0.real" # the original renamed-linker" - really? It will rename > my linker and replace it by itself? Yes. There'll be bfin-uclinux-ld and bfin-uclinux-ld.real, the former being the ld-elf2flt script which in turn calls the real ld and the elf2flt binary. > This script looks rather contrived, > will it really work correctly for all possible invocations of ld which > don't even want to do any elf2flt-ification? So far we've not had reports to the contrary. > Can you write up a small explanation what elf2flt does, how to produce > a flat executable with it? Let's say in my situation - I seem to have > correctly built static elf bfin busybox, can I make a flat one out of it? Nope. It's lacking the relocs. > What is this ld-elf2flt wrapper - what is it doing? Calling ld and elf2flt in a way to generate correct flat binaries. Bernd -- This footer brought to you by insane German lawmakers. Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif From vda.linux at googlemail.com Wed Jun 4 17:38:00 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Thu, 5 Jun 2008 02:38:00 +0200 Subject: elf2flt questions In-Reply-To: <200806050213.17578.vda.linux@googlemail.com> References: <200806050213.17578.vda.linux@googlemail.com> Message-ID: <200806050238.00646.vda.linux@googlemail.com> On Thursday 05 June 2008 02:13, Denys Vlasenko wrote: > Can you write up a small explanation what elf2flt does, how to produce > a flat executable with it? Let's say in my situation - I seem to have > correctly built static elf bfin busybox, can I make a flat one out of it? Straightforward approach suggested by "elf2flt --help" doesn't work: # ./elf2flt busybox_unstripped -a -o busybox_unstripped.flat busybox_unstripped: Input file contains no relocation info Obviously, input file should be something different than static elf binary... heeeeelp :) Sanity check: is it really an elf blackfin? Looks like it: # bfin-linux-uclibc-objdump -xrd busybox_unstripped busybox_unstripped: file format elf32-bfinfdpic busybox_unstripped architecture: bfin, flags 0x00000112: EXEC_P, HAS_SYMS, D_PAGED start address 0x000000b0 Program Header: LOAD off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**12 filesz 0x000bd4e4 memsz 0x000bd4e4 flags r-x LOAD off 0x000bd4e4 vaddr 0x000c14e4 paddr 0x000c14e4 align 2**12 filesz 0x0000879c memsz 0x00009f84 flags rw- STACK off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**3 filesz 0x00000000 memsz 0x00020000 flags rwx private flags = 2: -mfdpic Sections: Idx Name Size VMA LMA File off Algn 0 .init 0000001a 00000094 00000094 00000094 2**0 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .text 00094d40 000000b0 000000b0 000000b0 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE ... ... ... 00001cec g F .text 00000028 .hidden _xopen3 000855d0 g F .text 00000358 _strptime 000782f4 g F .text 000000ba _encrypt Disassembly of section .init: 00000094 <__init>: 94: 4b 01 [--SP] = P3; 96: 00 e8 03 00 LINK 0xc; /* (12) */ 9a: 73 ad P3 = [SP + 0x14]; 9c: 00 e3 dc 00 CALL 0x254 <_frame_dummy>; a0: 73 ad P3 = [SP + 0x14]; a2: 04 e3 95 a6 CALL 0x94dcc <___do_global_ctors_aux>; a6: 01 e8 00 00 UNLINK; aa: 73 90 P3 = [SP++]; ac: 10 00 RTS; Disassembly of section .text: 000000b0 <__start>: b0: 00 e3 02 00 CALL 0xb4 <__start+0x4>; b4: 27 31 R4 = RETS; b6: a6 6f SP += -0xc; /* (-12) */ ... -- vda From vda.linux at googlemail.com Wed Jun 4 20:43:06 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Thu, 5 Jun 2008 05:43:06 +0200 Subject: elf2flt questions In-Reply-To: <484734AC.7050903@t-online.de> References: <200806050213.17578.vda.linux@googlemail.com> <484734AC.7050903@t-online.de> Message-ID: <200806050543.06306.vda.linux@googlemail.com> On Thursday 05 June 2008 02:34, Bernd Schmidt wrote: > > elf binaries, it says "BINFMT_FLAT: bad magic/rev (0x1010100, need 0x5)". > > One thing I just remembered is that we used to have non-standard flat > files. Version 5 doesn't exist in any tools/kernels other than ancient > Blackfin distributions. Our tools were fixed long ago to generate > version 4 flat binaries. With a modern toolchain you can't actually > produce binaries that will run on the 2005 kernel you're using (never > mind that it's totally bug-infested anyway), so please upgrade that > first. There's a u-boot installed on your board, surely? Yes. U-Boot 1.1.6-svn1226 (ADI-2008R2-pre) (May 29 2008 - 15:54:06) CPU: ADSP bf537-0.2 (Detected Rev: 0.2) Board: ADI BF537 stamp board Support: http://blackfin.uclinux.org/ Clock: VCO: 500 MHz, Core: 500 MHz, System: 100 MHz RAM: 64 MB Flash: 4 MB In: serial Out: serial Err: serial Net: Blackfin EMAC MAC: 00:E0:22:FE:47:CC Hit any key to stop autoboot: 0 The board has one image: bfin> imls Image at 20100000: Image Name: uClinux Kernel Image Created: 2005-09-30 3:03:16 UTC Image Type: Blackfin Linux Kernel Image (gzip compressed) Data Size: 1429678 Bytes = 1.4 MB Load Address: 00001000 Entry Point: 00001000 Verifying Checksum ... OK From vda.linux at googlemail.com Wed Jun 4 21:18:24 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Thu, 5 Jun 2008 06:18:24 +0200 Subject: "building toolchain" wiki In-Reply-To: <200806050545.02758.vda.linux@googlemail.com> References: <200806050213.17578.vda.linux@googlemail.com> <484734AC.7050903@t-online.de> <200806050545.02758.vda.linux@googlemail.com> Message-ID: <200806050618.24553.vda.linux@googlemail.com> On Thursday 05 June 2008 05:45, Denys Vlasenko wrote: > Let's try building toolchain from blackfin.uclinux.org. > > I got svn://firewall-sources.blackfin.uclinux.org:80/svn/toolchain/trunk. > > I made a copy of checked-out tree. > > I run BuildToolChain: > > # buildscript/BuildToolChain 2>&1 | tee err > Checking for development packages (skip checks with the -D option) > BusyBox v1.10.0 (2008-03-22 15:35:10 CET) multi-call binary > > Usage: mktemp [-dt] [-p DIR] TEMPLATE > > Create a temporary file with its name based on TEMPLATE. > TEMPLATE is any name with six 'Xs' (i.e., /tmp/temp.XXXXXX). > > Options: > -d Make a directory instead of a file > -t Generate a path rooted in temporary directory > -p DIR Use DIR as a temporary directory (implies -t) > > For -t or -p, directory is chosen as follows: > $TMPDIR if set, else -p DIR, else /tmp I went to this page: http://docs.blackfin.uclinux.org/doku.php?id=toolchain:buildscript It says the following. My comments are with ===>, they mark the questions I've got while reading the page which I had no answers for. Can it be updated? (I tried editing it, it seems to be locked for editing). There is a build script for the toolchain that builds and installs the toolchain from source.... To build from source, you need the source of the kernel and toolchain. The kernel source is required because we need the userspace kernel headers... If you need to build a svn toolchain, it is recommended to use a svn kernel source. Although, at first glance, it seems like the toolchain, bootloader, libraries, and kernel should be separate - that is not true... Because of these, and other issues, building a svn toolchain, and using a non-svn kernel uClibc is not supported/tested/validated. ===> Great, I want to download source of toolchain and kernel. ===> Where I can do it? URLs? Building takes awhile as it will be compiling binutils/gcc/uClibc multiple times over (once per target). For example to run the script a command similar to this must be issued: ./BuildToolChain -s /home/user/checkouts/gcc/ \ -k /home/user/checkouts/kernel/uClinux-dist/linux-2.6.x \ -u /home/user/checkouts/uboot/u-boot_1.1.3 \ -b /home/user/gcc-build/ -o /home/user/cvsoutput ===> I went to http://blackfin.uclinux.org/gf/project/toolchain/frs/ ===> and downloaded blackfin-toolchain-08r1-8.src.tar.gz ===> It has no ./BuildToolChain, only buildscript.tar.bz2 (among others) ===> with blackfin-toolchain-08r1/* (including BuildToolChain script) inside. ===> Should I unpack buildscript.tar.bz2? Or should I unpack all *.tar.bz2? ===> Should I copy BuildToolChain to the top directory ===> (as implied by ./BuildToolChain above) or I can run it ===> inside blackfin-toolchain-08r1 dir? -- vda From raj.khem at gmail.com Wed Jun 4 22:12:40 2008 From: raj.khem at gmail.com (Khem Raj) Date: Wed, 04 Jun 2008 22:12:40 -0700 Subject: double word ordering on little endian In-Reply-To: <2590773a0806041709y17799ca8xbad8346c4b5d8df1@mail.gmail.com> References: <2590773a0806041521v5e43f05ex559c558dcf891eaa@mail.gmail.com> <48472520.7050100@gmail.com> <2590773a0806041709y17799ca8xbad8346c4b5d8df1@mail.gmail.com> Message-ID: <484775C8.1050604@gmail.com> Christopher Taylor wrote: > arm5 (Atmel at91). As far as vfp vs fpa, I'm using the 'default' from > buildroot with gcc 4.2.1. Not sure how this is set inside > buildroot/uclibc. Well if you can use -v option to gcc when you compile your testcase you should be able to see what fpu settings are used. How the gcc is configures and what commandline options are passed will help us to help you further. -Khem From vapier at gentoo.org Thu Jun 5 02:10:13 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Thu, 5 Jun 2008 05:10:13 -0400 Subject: elf2flt questions In-Reply-To: <200806050543.06306.vda.linux@googlemail.com> References: <200806050213.17578.vda.linux@googlemail.com> <484734AC.7050903@t-online.de> <200806050543.06306.vda.linux@googlemail.com> Message-ID: <200806050510.14665.vapier@gentoo.org> On Wednesday 04 June 2008, Denys Vlasenko wrote: > On Thursday 05 June 2008 02:34, Bernd Schmidt wrote: > > > elf binaries, it says "BINFMT_FLAT: bad magic/rev (0x1010100, need > > > 0x5)". > > > > One thing I just remembered is that we used to have non-standard flat > > files. Version 5 doesn't exist in any tools/kernels other than ancient > > Blackfin distributions. Our tools were fixed long ago to generate > > version 4 flat binaries. With a modern toolchain you can't actually > > produce binaries that will run on the 2005 kernel you're using (never > > mind that it's totally bug-infested anyway), so please upgrade that > > first. There's a u-boot installed on your board, surely? > > U-Boot 1.1.6-svn1226 (ADI-2008R2-pre) (May 29 2008 - 15:54:06) livin on the edge :) > bfin> imls > Image at 20100000: > Image Name: uClinux Kernel Image > Created: 2005-09-30 3:03:16 UTC yeah that's old. you can grab newer uImage's from the blackfin.uclinux.org website. those of course are just the default builds. -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20080605/94b9d386/attachment.pgp From vapier at gentoo.org Thu Jun 5 02:11:51 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Thu, 5 Jun 2008 05:11:51 -0400 Subject: elf2flt questions In-Reply-To: <200806050238.00646.vda.linux@googlemail.com> References: <200806050213.17578.vda.linux@googlemail.com> <200806050238.00646.vda.linux@googlemail.com> Message-ID: <200806050511.52232.vapier@gentoo.org> On Wednesday 04 June 2008, Denys Vlasenko wrote: > On Thursday 05 June 2008 02:13, Denys Vlasenko wrote: > > Can you write up a small explanation what elf2flt does, how to produce > > a flat executable with it? Let's say in my situation - I seem to have > > correctly built static elf bfin busybox, can I make a flat one out of it? > > Straightforward approach suggested by "elf2flt --help" doesn't work: well you really arent supposed to invoke elf2flt directly. just run your toolchain like normal but specify "-elf2flt" when doing the linking step. the wrapper script will take care of the rest. it really isnt worth knowing how to invoke elf2flt directly. honestly, such knowledge is completely useless. -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20080605/866f7fbb/attachment.pgp From vapier at gentoo.org Thu Jun 5 02:17:54 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Thu, 5 Jun 2008 05:17:54 -0400 Subject: "building toolchain" wiki In-Reply-To: <200806050618.24553.vda.linux@googlemail.com> References: <200806050213.17578.vda.linux@googlemail.com> <200806050545.02758.vda.linux@googlemail.com> <200806050618.24553.vda.linux@googlemail.com> Message-ID: <200806050517.55924.vapier@gentoo.org> On Thursday 05 June 2008, Denys Vlasenko wrote: > http://docs.blackfin.uclinux.org/doku.php?id=toolchain:buildscript > > It says the following. My comments are with ===>, they mark > the questions I've got while reading the page which I had no answers for. > Can it be updated? (I tried editing it, it seems to be locked for editing). the wiki at docs.b.u.o only allows writing to people who ask and are granted permission. that keeps the spammers at bay, keeps the less knowledgeable from entering incorrect info, and allows us to make sure copyright/licensing is in our domain. > ===> Great, I want to download source of toolchain and kernel. > ===> Where I can do it? URLs? the wiki operates with the implicit knowledge that all of the source code lives on blackfin.u.o. when you visit that site, the frontpage has links to all the places. but i'll toss in links at the top. > ===> I went to http://blackfin.uclinux.org/gf/project/toolchain/frs/ > ===> and downloaded blackfin-toolchain-08r1-8.src.tar.gz > ===> It has no ./BuildToolChain, only buildscript.tar.bz2 (among others) > ===> with blackfin-toolchain-08r1/* (including BuildToolChain script) > inside. ===> Should I unpack buildscript.tar.bz2? Or should I unpack all > *.tar.bz2? ===> Should I copy BuildToolChain to the top directory > ===> (as implied by ./BuildToolChain above) or I can run it > ===> inside blackfin-toolchain-08r1 dir? the src tarball is a little out of tune with how things are organized in svn. i blame bernd ;). you'll probably have to unpack all the archives and take it from there. generally people dont actually build the src tarball from a release because the binaries already exist. they do however frequently build from svn ... -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20080605/e4be8406/attachment.pgp From vda.linux at googlemail.com Thu Jun 5 04:00:39 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Thu, 5 Jun 2008 13:00:39 +0200 Subject: elf2flt questions In-Reply-To: <200806050449.53105.vapier@gentoo.org> References: <200806050213.17578.vda.linux@googlemail.com> <200806050835.06850.vda.linux@googlemail.com> <200806050449.53105.vapier@gentoo.org> Message-ID: <200806051300.39055.vda.linux@googlemail.com> On Thursday 05 June 2008 10:49, Mike Frysinger wrote: > > > i know at least 4 implementations out there that are > > > completely different. the only thing ive found in common is that simply > > > doing `mktemp` results in a filename. > > > > Well, that's the problem I want to solve: busybox's one does not do it > > (yet). Help he here - does bare "mktemp" just emit a new /tmp/SOMETHING > > filename or does it also create this file (with zero size I suppose)? Also, > > is mktemp on your machine from your distro? If yes, which distro/version is > > it? (I will document it in bbox source) > > if you consider the Linux case, the three versions that have existed all have > this behavior. > old: mktemp in debianutils > not-so-old: mktemp in the mktemp package > everyone-should-be-using-today: mktemp from coreutils None of the following: coreutils-5.2.1 coreutils-6.3 coreutils-6.8 coreutils-6.9 has mktemp applet, er, program. Can you interrogate yours where the hell it come from? mktemp --help, mktemp --version, strings /usr/bin/mktemp? -- vda From strange at nsk.no-ip.org Thu Jun 5 04:13:26 2008 From: strange at nsk.no-ip.org (Luciano Rocha) Date: Thu, 5 Jun 2008 12:13:26 +0100 Subject: elf2flt questions In-Reply-To: <200806051300.39055.vda.linux@googlemail.com> References: <200806050213.17578.vda.linux@googlemail.com> <200806050835.06850.vda.linux@googlemail.com> <200806050449.53105.vapier@gentoo.org> <200806051300.39055.vda.linux@googlemail.com> Message-ID: <20080605111325.GA4238@bit.office.eurotux.com> On Thu, Jun 05, 2008 at 01:00:39PM +0200, Denys Vlasenko wrote: > On Thursday 05 June 2008 10:49, Mike Frysinger wrote: > > > > i know at least 4 implementations out there that are > > > > completely different. the only thing ive found in common is that simply > > > > doing `mktemp` results in a filename. > > > > > > Well, that's the problem I want to solve: busybox's one does not do it > > > (yet). Help he here - does bare "mktemp" just emit a new /tmp/SOMETHING > > > filename or does it also create this file (with zero size I suppose)? Also, > > > is mktemp on your machine from your distro? If yes, which distro/version is > > > it? (I will document it in bbox source) > > > > if you consider the Linux case, the three versions that have existed all have > > this behavior. > > old: mktemp in debianutils > > not-so-old: mktemp in the mktemp package > > everyone-should-be-using-today: mktemp from coreutils > > None of the following: > > coreutils-5.2.1 > coreutils-6.3 > coreutils-6.8 > coreutils-6.9 > > has mktemp applet, er, program. Mine do, in /bin/mktemp. coreutils-6.10-23.fc9.i386. Coreutils includes src/mktemp.c since Jun 2007. -- lfr 0/0 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available Url : http://busybox.net/lists/uclibc/attachments/20080605/f37f1063/attachment.pgp From rep.dot.nop at gmail.com Thu Jun 5 04:52:45 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Thu, 5 Jun 2008 13:52:45 +0200 Subject: elf2flt questions In-Reply-To: <200806051300.39055.vda.linux@googlemail.com> References: <200806050213.17578.vda.linux@googlemail.com> <200806050835.06850.vda.linux@googlemail.com> <200806050449.53105.vapier@gentoo.org> <200806051300.39055.vda.linux@googlemail.com> Message-ID: <20080605115245.GA5252@mx.loc> On Thu, Jun 05, 2008 at 01:00:39PM +0200, Denys Vlasenko wrote: >On Thursday 05 June 2008 10:49, Mike Frysinger wrote: >> everyone-should-be-using-today: mktemp from coreutils great. They switched to git and didn't turn off CVS, and i bet CVS is not updated anymore since at least 20071210. From vda.linux at googlemail.com Thu Jun 5 05:04:22 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Thu, 5 Jun 2008 14:04:22 +0200 Subject: elf2flt questions In-Reply-To: <20080605111325.GA4238@bit.office.eurotux.com> References: <200806050213.17578.vda.linux@googlemail.com> <200806051300.39055.vda.linux@googlemail.com> <20080605111325.GA4238@bit.office.eurotux.com> Message-ID: <200806051404.22038.vda.linux@googlemail.com> On Thursday 05 June 2008 13:13, Luciano Rocha wrote: > > None of the following: > > > > coreutils-5.2.1 > > coreutils-6.3 > > coreutils-6.8 > > coreutils-6.9 > > > > has mktemp applet, er, program. > > Mine do, in /bin/mktemp. coreutils-6.10-23.fc9.i386. > > Coreutils includes src/mktemp.c since Jun 2007. Thanks. Fixed in busybox svn to match that one. -- vda From bernds_cb1 at t-online.de Thu Jun 5 05:17:44 2008 From: bernds_cb1 at t-online.de (Bernd Schmidt) Date: Thu, 05 Jun 2008 14:17:44 +0200 Subject: elf2flt questions In-Reply-To: <200806050238.00646.vda.linux@googlemail.com> References: <200806050213.17578.vda.linux@googlemail.com> <200806050238.00646.vda.linux@googlemail.com> Message-ID: <4847D968.5070108@t-online.de> Denys Vlasenko wrote: > busybox_unstripped: file format elf32-bfinfdpic Noticed this... Trying to use an FDPIC toolchain with elf2flt will produce interesting results. Bernd -- This footer brought to you by insane German lawmakers. Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif From bernds_cb1 at t-online.de Thu Jun 5 05:37:13 2008 From: bernds_cb1 at t-online.de (Bernd Schmidt) Date: Thu, 05 Jun 2008 14:37:13 +0200 Subject: svn commit: trunk/uClibc In-Reply-To: <20080605122936.8CFF13C6EF@busybox.net> References: <20080605122936.8CFF13C6EF@busybox.net> Message-ID: <4847DDF9.40804@t-online.de> aldot at uclibc.org wrote: > + libpthread/*/*.$(ext) libpthread/*/*/*.$(ext) \ > + libpthread/*/*/*/*.$(ext) libpthread/*/*/*/*/*.$(ext) \ > + libpthread/*/*/*/*/*/*.$(ext) libpthread/*/*/*/*/*/*/*.$(ext) \ > + libpthread/*/*/*/*/*/*/*/*.$(ext)) Uh... is there another way of doing this? Also, this really is supposed to be done by the make objclean-y step just below. Bernd -- This footer brought to you by insane German lawmakers. Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif From rep.dot.nop at gmail.com Thu Jun 5 06:33:25 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Thu, 5 Jun 2008 15:33:25 +0200 Subject: svn commit: trunk/uClibc In-Reply-To: <4847DDF9.40804@t-online.de> References: <20080605122936.8CFF13C6EF@busybox.net> <4847DDF9.40804@t-online.de> Message-ID: <20080605133325.GA8075@mx.loc> On Thu, Jun 05, 2008 at 02:37:13PM +0200, Bernd Schmidt wrote: >aldot at uclibc.org wrote: >> + libpthread/*/*.$(ext) libpthread/*/*/*.$(ext) \ >> + libpthread/*/*/*/*.$(ext) libpthread/*/*/*/*/*.$(ext) \ >> + libpthread/*/*/*/*/*/*.$(ext) libpthread/*/*/*/*/*/*/*.$(ext) \ >> + libpthread/*/*/*/*/*/*/*/*.$(ext)) > >Uh... is there another way of doing this? ok, that was a bit gross. > >Also, this really is supposed to be done by the make objclean-y step >just below. we can unconditionally add all 4 variants as objclean-y in libpthread/Makefile.in From vda.linux at googlemail.com Thu Jun 5 07:30:45 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Thu, 5 Jun 2008 16:30:45 +0200 Subject: elf2flt questions In-Reply-To: <4847D968.5070108@t-online.de> References: <200806050213.17578.vda.linux@googlemail.com> <200806050238.00646.vda.linux@googlemail.com> <4847D968.5070108@t-online.de> Message-ID: <200806051630.45413.vda.linux@googlemail.com> On Thursday 05 June 2008 14:17, Bernd Schmidt wrote: > Denys Vlasenko wrote: > > > busybox_unstripped: file format elf32-bfinfdpic > > Noticed this... Trying to use an FDPIC toolchain with elf2flt will > produce interesting results. Will this fare better? bfin-uclinux-objdump -xdr busybox_unstripped busybox_unstripped: file format elf32-bfin busybox_unstripped architecture: bfin, flags 0x00000112: EXEC_P, HAS_SYMS, D_PAGED start address 0x00000014 Program Header: LOAD off 0x00001000 vaddr 0x00000000 paddr 0x00000000 align 2**12 filesz 0x000b2634 memsz 0x000b2634 flags r-x LOAD off 0x000b3634 vaddr 0x000b3634 paddr 0x000b3634 align 2**12 filesz 0x000003c0 memsz 0x00001bac flags rw- STACK off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**2 filesz 0x00000000 memsz 0x00000000 flags rwx private flags = 0: ... Now I'll look into how to make bbox use correct options to ld in order to produce flat binary... -- vda From vapier at gentoo.org Thu Jun 5 07:39:16 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Thu, 5 Jun 2008 10:39:16 -0400 Subject: elf2flt questions In-Reply-To: <200806051630.45413.vda.linux@googlemail.com> References: <200806050213.17578.vda.linux@googlemail.com> <4847D968.5070108@t-online.de> <200806051630.45413.vda.linux@googlemail.com> Message-ID: <200806051039.17743.vapier@gentoo.org> On Thursday 05 June 2008, Denys Vlasenko wrote: > On Thursday 05 June 2008 14:17, Bernd Schmidt wrote: > > Denys Vlasenko wrote: > > > busybox_unstripped: file format elf32-bfinfdpic > > > > Noticed this... Trying to use an FDPIC toolchain with elf2flt will > > produce interesting results. > > Will this fare better? > > bfin-uclinux-objdump -xdr busybox_unstripped > > busybox_unstripped: file format elf32-bfin yes. bfin-uclinux is for FLAT, not any other toolchain. > Now I'll look into how to make bbox use correct options to ld in order > to produce flat binary... it already works today. just put -elf2flt into LDFLAGS. -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20080605/584a5618/attachment.pgp From bernds_cb1 at t-online.de Thu Jun 5 10:40:44 2008 From: bernds_cb1 at t-online.de (Bernd Schmidt) Date: Thu, 05 Jun 2008 19:40:44 +0200 Subject: svn commit: trunk/uClibc/libc/unistd In-Reply-To: <20080520203227.F0A503C814@busybox.net> References: <20080520203227.F0A503C814@busybox.net> Message-ID: <4848251C.1060902@t-online.de> vda at uclibc.org wrote: > Author: vda > Date: 2008-05-20 13:32:27 -0700 (Tue, 20 May 2008) > New Revision: 22027 > > Log: > getopt: do not needlessly use static structure. > Reorder structure members and change some of them into smallints > to reduce bss and text: > text data bss dec hex filename > - 2403 12 40 2455 997 libc/unistd/getopt.o > + 2252 12 0 2264 8d8 libc/unistd/getopt.o > > > > Modified: > trunk/uClibc/libc/unistd/getopt.c > trunk/uClibc/libc/unistd/getopt_int.h So, after about a day of bisecting and rebuilding stuff I've found that this is the patch that stops my Blackfin board from booting normally when using an updated version of uClibc. This patch shows a complete lack of understanding of the getopt interface (note: getopt is called several times in a row, so we can't clear the internal data on each call). Reading the code at the start of _getopt_internal_r should have made that plain. The patch also can't possibly have been tested. I'm reverting it. Bernd -- This footer brought to you by insane German lawmakers. Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif From chtaylo3 at gmail.com Thu Jun 5 14:06:57 2008 From: chtaylo3 at gmail.com (Christopher Taylor) Date: Thu, 5 Jun 2008 17:06:57 -0400 Subject: double word ordering on little endian In-Reply-To: <484775C8.1050604@gmail.com> References: <2590773a0806041521v5e43f05ex559c558dcf891eaa@mail.gmail.com> <48472520.7050100@gmail.com> <2590773a0806041709y17799ca8xbad8346c4b5d8df1@mail.gmail.com> <484775C8.1050604@gmail.com> Message-ID: <2590773a0806051406n71efc4bbid441a50332f6ab1c@mail.gmail.com> ok here's a test program: #include #include void printBytes( unsigned char* ptr1, uint8_t bytes){ int i=0; unsigned char* ptr = ptr1; for(i=0; i< bytes; i++){ printf(" %x ", *ptr); ptr++; } } int main(){ double myDouble = 2.048; int k=0; printf(" myDouble: %f myDouble: %llx myDouble:",myDouble,myDouble); printBytes((unsigned char*)&myDouble, sizeof(double)); printf("\n"); return(0); } I buit this against a known VFP, a known FPA and the old toolchain(which I don't know what it is). I built both dynamically and statically. I then ran it against the new kernel which was FPA and against the old kernel. I got incorrect answers for printf %f when I ran VFP dynamically linked code on the new FPA kernel I ran FPA dynamically linked code on the old unknown kernel I ran unknown (from the old tool chain) dynamically linked code on the new kernel all other printf's were as expected for their respective FPA/VFP settings. This leads me to conclude that the old toolchain was VFP. The question I have for everyone listening is .... any suggestion on which way to go? VFP/FPA? Thank you so much for the help Khem! -Chris From vda.linux at googlemail.com Thu Jun 5 18:09:53 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Fri, 6 Jun 2008 03:09:53 +0200 Subject: svn commit: trunk/uClibc/libc/unistd In-Reply-To: <4848251C.1060902@t-online.de> References: <20080520203227.F0A503C814@busybox.net> <4848251C.1060902@t-online.de> Message-ID: <200806060309.53595.vda.linux@googlemail.com> Hi Bernd On Thursday 05 June 2008 19:40, Bernd Schmidt wrote: > > Log: > > getopt: do not needlessly use static structure. > > Reorder structure members and change some of them into smallints > > to reduce bss and text: > > text data bss dec hex filename > > - 2403 12 40 2455 997 libc/unistd/getopt.o > > + 2252 12 0 2264 8d8 libc/unistd/getopt.o > > > > Modified: > > trunk/uClibc/libc/unistd/getopt.c > > trunk/uClibc/libc/unistd/getopt_int.h > > So, after about a day of bisecting and rebuilding stuff I've found that > this is the patch that stops my Blackfin board from booting normally > when using an updated version of uClibc. > > This patch shows a complete lack of understanding of the getopt > interface (note: getopt is called several times in a row, so we can't > clear the internal data on each call). Reading the code at the start of > _getopt_internal_r should have made that plain. The patch also can't > possibly have been tested. I'm reverting it. I feel ashamed. I caused far too much breakage in recent time than I did good things. Have to do much better than that. Sorry. :( -- vda From vda.linux at googlemail.com Thu Jun 5 20:19:05 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Fri, 6 Jun 2008 05:19:05 +0200 Subject: svn commit: trunk/uClibc/libc/unistd In-Reply-To: <200806060309.53595.vda.linux@googlemail.com> References: <20080520203227.F0A503C814@busybox.net> <4848251C.1060902@t-online.de> <200806060309.53595.vda.linux@googlemail.com> Message-ID: <200806060519.05933.vda.linux@googlemail.com> On Friday 06 June 2008 03:09, Denys Vlasenko wrote: > Hi Bernd > > On Thursday 05 June 2008 19:40, Bernd Schmidt wrote: > > > Log: > > > getopt: do not needlessly use static structure. > > > Reorder structure members and change some of them into smallints > > > to reduce bss and text: > > > text data bss dec hex filename > > > - 2403 12 40 2455 997 libc/unistd/getopt.o > > > + 2252 12 0 2264 8d8 libc/unistd/getopt.o > > > > > > Modified: > > > trunk/uClibc/libc/unistd/getopt.c > > > trunk/uClibc/libc/unistd/getopt_int.h > > > > So, after about a day of bisecting and rebuilding stuff I've found that > > this is the patch that stops my Blackfin board from booting normally > > when using an updated version of uClibc. > > > > This patch shows a complete lack of understanding of the getopt > > interface (note: getopt is called several times in a row, so we can't > > clear the internal data on each call). Reading the code at the start of > > _getopt_internal_r should have made that plain. The patch also can't > > possibly have been tested. I'm reverting it. > > I feel ashamed. I caused far too much breakage in recent time > than I did good things. Have to do much better than that. > > Sorry. :( I added some machinery to my uclibc build system so that I can run both uclibc testsuite and also a busybox testsuite against freshly built uclibc. I checked that it would have caught my blunder in getopt, had I created the system earlier. Found and fixed one false positive in uclibc testsuite. I see some other problems there, will take a look a bit later. I returned to getopt and did some shrinking, and tested it this time by running busybox testsuite (which uses tons of getopt calls). Will commit it in a fw minutes. Sorry again for my sloppy work earlier. -- vda From bernds_cb1 at t-online.de Fri Jun 6 03:41:57 2008 From: bernds_cb1 at t-online.de (Bernd Schmidt) Date: Fri, 06 Jun 2008 12:41:57 +0200 Subject: svn commit: trunk/uClibc/libc/inet In-Reply-To: <20080606072514.80DAE3C3EA@busybox.net> References: <20080606072514.80DAE3C3EA@busybox.net> Message-ID: <48491475.1060901@t-online.de> vda at uclibc.org wrote: > Author: vda > Date: 2008-06-06 00:25:12 -0700 (Fri, 06 Jun 2008) > New Revision: 22244 > > Log: > Use more natural way to return a value in __read_etc_hosts_r: > - if (buflen < sizeof(char *)*(ALIAS_DIM)) > + if (buflen < sizeof(char *)*ALIAS_DIM) > return ERANGE; Again mixing code style and functional changes. Bernd -- This footer brought to you by insane German lawmakers. Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif From carmelo.amoroso at st.com Fri Jun 6 03:49:33 2008 From: carmelo.amoroso at st.com (Carmelo AMOROSO) Date: Fri, 06 Jun 2008 12:49:33 +0200 Subject: svn commit: trunk/uClibc/libc/inet In-Reply-To: <48491475.1060901@t-online.de> References: <20080606072514.80DAE3C3EA@busybox.net> <48491475.1060901@t-online.de> Message-ID: <4849163D.7010904@st.com> Bernd Schmidt wrote: > vda at uclibc.org wrote: > >> Author: vda >> Date: 2008-06-06 00:25:12 -0700 (Fri, 06 Jun 2008) >> New Revision: 22244 >> >> Log: >> Use more natural way to return a value in __read_etc_hosts_r: >> > > >> - if (buflen < sizeof(char *)*(ALIAS_DIM)) >> + if (buflen < sizeof(char *)*ALIAS_DIM) >> return ERANGE; >> > > Again mixing code style and functional changes. > > > Bernd > I strongly agree with the point of Bernd.... avoid pointless change just for cometic, please. Cheers, Carmelo From vda.linux at googlemail.com Fri Jun 6 04:35:39 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Fri, 6 Jun 2008 13:35:39 +0200 Subject: svn commit: trunk/uClibc/libc/inet In-Reply-To: <4849163D.7010904@st.com> References: <20080606072514.80DAE3C3EA@busybox.net> <48491475.1060901@t-online.de> <4849163D.7010904@st.com> Message-ID: <200806061335.39749.vda.linux@googlemail.com> On Friday 06 June 2008 12:49, Carmelo AMOROSO wrote: > Bernd Schmidt wrote: > >> Author: vda > >> Date: 2008-06-06 00:25:12 -0700 (Fri, 06 Jun 2008) > >> New Revision: 22244 > >> > >> Log: > >> Use more natural way to return a value in __read_etc_hosts_r: > > > >> - if (buflen < sizeof(char *)*(ALIAS_DIM)) > >> + if (buflen < sizeof(char *)*ALIAS_DIM) > >> return ERANGE; > > > > Again mixing code style and functional changes. > > > > Bernd > > I strongly agree with the point of Bern