Re: glob() appears to fails if errno is not already zero
>>>>> "Mark" == Mark Jackson <[EMAIL PROTECTED]> writes: Hi, >> I'll add the GNU_GLOB option and retry. Mark> Aha ... that's fixed it !! Mark> Excellent ... thanks for the pointer. Ahh. The default buildroot uclibc config has that set as well. I've enabled it in the target/device specific ones as well now. -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Reduce size of snapshots and fix path
>>>>> "Joachim" == Joachim Nilsson <[EMAIL PROTECTED]> writes: Joachim> Hi! Joachim> I noticed that the daily snapshot archives have the .svn Joachim> directories included. Another minor annoyance was that the Joachim> snaphot date was not included in the containing directory. Yes, I've noticed as well. Joachim> Do what you want with it, the license is the same as OpenBSD Joachim> recommends these days. Please use it for buildroot as well if it gets installed. -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [ANNOUNCE] uClibc-0.9.30-rc2 released
>>>>> "Rob" == Rob Landley <[EMAIL PROTECTED]> writes: Rob> C) Buildroot doesn't have releases. I'd be happy to try to Rob> debug a _specific_ release of buildroot, but they've Rob> categorically refused to ever do this. (I've argued about it Rob> before.) No promises, but I'm still trying to get a buildroot release out by the end of the year. -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Install problem (Cross compile AVR32)
>>>>> "Jeremy" == Jeremy Bowen <[EMAIL PROTECTED]> writes: Hi, Jeremy> On Wednesday 22 October 2008 12:52:07 pm John Voltz wrote: >> I would recommend you save yourself the pain, and just use buildroot. Jeremy> Jeremy> Argh! Why is the world full of lemmings. "buildroot" is not Jeremy> the magical answer to life the universe and everything. When Jeremy> something goes wrong with buildroot it is virtually Jeremy> impossible to determine WTF it is doing. Ofcause it isn't, but it shows a working setup. I definately don't find buildroot hard to comprehend, it's just a few makefiles afterall, but I might be less than objective. Jeremy> Everytime I see anyone post a problem with their toolchain, Jeremy> someone ALWAYS says; "Just use buildroot". It's a Jeremy> non-answer. It's like saying "You don't have to think. Trust Jeremy> us. We know what is best for you." Pertty soon we're all Jeremy> using "Visual Basic .NET" and having a lobotomy. hold it, noone forces anything on you or requires that you treat buildroot as a black box - But just like using a Linux distribution instead of rolling your own from scratch can save you a bunch of time, so can buildroot. Jeremy> It never encourages anyone to sort out an issue for Jeremy> themselves and eventually everyone gets spoon-fed all their Jeremy> answers and becomes an unquestioning sheep. Huh? We get plenty of patches on the buildroot list. Jeremy> Additional information. Jeremy> == Jeremy> A colleague and I are trying to sort out our build Jeremy> environments. He's using buildroot and it results in a broken Jeremy> (non-booting) linux kernel. I'm NOT using buildroot and my Jeremy> kernel is fine but I can't compile applications. Jeremy> $deity only knows what part of the buildroot chain is broken Jeremy> here so I'm trying to independently resolve the toolchain Jeremy> issue and hopefully identify exactly which component is Jeremy> broken. Patches are welcome - [EMAIL PROTECTED] >> This will have mixed results and will get _beyond_ tedious when you start >> discovering dependencies. Jeremy> Yes, because this the WRONG way to solve the problem. >> Save your time and use buildroot. Spend your >> spare time enjoying a beer or something more enjoyable... ;) You will also >> inevitably encounter a package with broken configure (or none at all) in >> which case you better break out a can of patience, because you'll need it! Jeremy> If I get my toochain fixed and working correctly I can Jeremy> confidently say I will NEVER have a problem with broken Jeremy> packages or configure scripts. This is entirely independent Jeremy> of whether I use buildroot or not. So by not using buildroot all dependency issues and problems with not-cross-compilation-capable packages just magically disappear? -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Segfault in re_string_reconstruct()
>>>>> "Hans-Christian" == Hans-Christian Egtvedt <[EMAIL PROTECTED]> writes: Hi, Hans-Christian> The AVR32 fork() of Buildroot should generate a Hans-Christian> proper GCC, if it does not then I am interested in Hans-Christian> fixing it. And the "normal" uclibc.org one not? What are all those avr32 patches for then? -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Segfault in re_string_reconstruct()
>>>>> "Hans-Christian" == Hans-Christian Egtvedt <[EMAIL PROTECTED]> writes: Hi, Hans-Christian> I do not use the external toolchain stuff, hence I do Hans-Christian> not subject it to testing. Ok. Does it work with the internal toolchain? I don't have access to any avr32 hw, so I never tried it. -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Segfault in re_string_reconstruct()
>>>>> "Arnar" == Arnar Mar Sigurðsson <[EMAIL PROTECTED]> writes: Hi, Hans-Christian> It works with the toolchain built by the AVR32 fork() Hans-Christian> of Buildroot. My preferred way is to get the Hans-Christian> toolchain upstream and have a minimal/none small Hans-Christian> patches in Buildroot. >> Great, that's also by far my preferred solution. >> So this probably means that we should mark avr32 as broken in the >> uclibc.org buildroot for now? Arnar> avr32 is working fine in the latest buildroot. I'm running the Arnar> v100sc2_defconfg target on a ngw100 board and everything is Arnar> working. Ok, good to hear. Is that with an internal toolchain or using the external stuff? -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Segfault in re_string_reconstruct()
>>>>> "Hans-Christian" == Hans-Christian Egtvedt <[EMAIL PROTECTED]> writes: Hans-Christian> It works with the toolchain built by the AVR32 fork() Hans-Christian> of Buildroot. My preferred way is to get the Hans-Christian> toolchain upstream and have a minimal/none small Hans-Christian> patches in Buildroot. Great, that's also by far my preferred solution. So this probably means that we should mark avr32 as broken in the uclibc.org buildroot for now? Hans-Christian> But as most people have noticed, this takes a whole Hans-Christian> lot of time, sadly :( Yeah :/ -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: make clean doesn't work with dash
>>>>> "Rob" == Rob Landley <[EMAIL PROTECTED]> writes: Hi, Rob> Nothing works properly with the Defective Annoying Shell. Ubuntu broke Rob> the /bin/sh link and nobody should use it anymore. Rob> Set the make environment variable "MAKE=/bin/bash". I guess you mean SHELL=/bin/bash instead. -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: n32 ABI problem when building a mipsel n32 cross compile uclibc toolchain
>>>>> "Bernhard" == Bernhard Reutner-Fischer writes: Hi, Bernhard> And second, AFAIK the buildroot from svn aparently only Bernhard> works for some i386 and a few arm variants. My tree Bernhard> (http://repo.or.cz/w/buildroot.git) was tested to compile Bernhard> fine on a wider set of arches, fwiw. Not true. I'm using it regularly for ppc and have used it for mips as well (~6months ago). Bernhard> So, as said, please direct your buildroot questions to the buildroot list. Exactly. -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: n32 ABI problem when building a mipsel n32 cross compile uclibc toolchain
>>>>> "Bernhard" == Bernhard Reutner-Fischer writes: >> Not true. I'm using it regularly for ppc and have used it for mips as >> well (~6months ago). Bernhard> That's interresting since you would have tripped issues Bernhard> with building kernel modules on pcc then and i do not see Bernhard> any patches in svn that fix this issue. Sorry, I don't use the kernel support in buildroot (I have my own kernel tree with hardware specific patches). Bernhard> As for mips (and arm, bfin, cris, ppc, sh, xtensa), where Bernhard> are the patches to make sure that one is able to install Bernhard> kernel headers under all circumstances? Where is proper Bernhard> mips abi propagation down to e.g. uClibc, to name just one Bernhard> mips related thing that i remember offhand? Bernhard> Been there, done that, so i don't really buy your "Not true." ;) Well, I can only repeat what I said before - I use buildroot for ppc daily, and have used it on a mips platform (lafonera) something like 6 months ago. Not to say there couldn't be bugs hiding somewhere, but it works for me (tm). -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: n32 ABI problem when building a mipsel n32 cross compile uclibc toolchain
>>>>> "Rob" == Rob Landley writes: >> Not true. I'm using it regularly for ppc and have used it for mips as >> well (~6months ago). Rob> Buildroot doesn't have releases, so a random svn snapshot you Rob> grab may be broken on any arbitrary architecture, or all of 'em. Rob> Wait 24 hours and do an "svn update" and you should have a fresh Rob> shiny set of _new_ random bugs to play with. I'm a buildroot developer, so I know - Chances are that those new bugs are mine ;) I'm working on getting a release out. -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: No existing uClibc release can build with 0.9.28 kernel headers.
>>>>> "Rob" == Rob Landley writes: Rob> So christmas day linus released 0.9.28, and I just tried building uClibc Rob> against it, and this is what I get building for i686: I guess you are talking about 2.6.28? It seems to build fine here with 0.9.30 (armv4l, buildroot) - Busybox 0.13.1 fails with the following error though: CC networking/libiproute/iptunnel.o In file included from /home/peko/tmp/br/build_arm/staging_dir/usr/include/linux/if_tunnel.h:5, from networking/libiproute/iptunnel.c:24: /home/peko/tmp/br/build_arm/staging_dir/usr/include/linux/ip.h:85: error: redefinition of ‘struct iphdr’ -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [Buildroot] PATCH: linuxthreads and arm compile fix
>>>>> "H" == H Heinold writes: H> Hi, H> thanks four your effort, but this already know and will be checked in H> after the nptl-merge. While compiling perl with linuxthreads on arm H> I found another issue and put the patch into the new bugtracker H> https://bugs.uclibc.org/show_bug.cgi?id=45 But otherwise no disagreement about the patch? I'll stick it in buildroot then to fix the build issue. -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: add __adjtimex to get ntpd to work properly
>>>>> "David" == David Mosberger-Tang writes: Hi, David> The patch seems reasonable enough. Could it be checked into David> buildroot so others don't have to discover this issue again? Sure, when we know about it ;) I'll add it. -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: error building uclibc 0.9.30 with kernel 2.6.28.1
>>>>> "Rob" == Rob Landley writes: Hi, >> To save you (and anyone else) some grief - those kernel headers >> needs to be "sanitized" kernel headers for your target kernel >> version. That is - they have certain symbols stripped >> out. Building uClibc with standard kernel headers is not supported >> (and I have never got that to work either). If you are building >> with Buildroot, it can fetch sanitized headers for you >> automatically (snapshot after Jan 19. is updated with 2.6.28). Rob> Or you could just grab any Linux kernel tarball for the past ~3 Rob> years and go "make headers_install ARCH=sh4 Rob> INSTALL_HDR_PATH=/blah/blah/blah" Which is what BR does. -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: cannot build: conflicting types for '__kernel_dev_t'
>>>>> "S0L0" == S0L0 writes: S0L0> Hello, S0L0> i just wanted to try again getting buildroot to wrk, but I seem S0L0> to have one more porblem: Please post buildroot questions to the buildroot list - buildr...@uclibc.org. Thanks. -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [ANNOUNCE] uClibc-0.9.30.1 released
>>>>> "Rob" == Rob Landley writes: >> uClibc-0.9.30.1 has been released. Rob> Builds fine here on arm x86, m688k, mips, ppc, sh4, sparc, and Rob> x86_64. I'll boot test it (just to be sure) later. But breaks with C99 math, atleast on ppc. Bernhard is looking into it. -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
strtouq on 64bit
Hi, The bsd extension strtouq (which maps to strtoull() on 32bit and strtoul on 64bit) is currently only available on 32bit: i586-linux-nm -D ./libuClibc-0.9.30.so|grep strtou 00046525 T strtoul 00046769 T strtoul_l 000466ec T strtoull 000468e5 T strtoull_l 000466ec T strtoumax 000466ec T strtouq vs: x86_64-linux-nm -D libuClibc-0.9.30.so|grep strtou 0004850c T strtoul 000486b4 T strtoul_l 0004850c T strtoull 000486b4 T strtoull_l 0004850c T strtoumax The following patch fixes it: - [PATCH]: Add strtouq alias (to strtoul) for 64bit The strtouq alias was only available on 32bit, breaking compilation of stuff using strtouq on 64bit machines. At the same time use the correct return type (u_quad_t). Signed-of-by: Peter Korsgaard --- include/stdlib.h |4 +++- libc/stdlib/stdlib.c |1 + 2 files changed, 4 insertions(+), 1 deletion(-) Index: uClibc-0.9.30.1/libc/stdlib/stdlib.c === --- uClibc-0.9.30.1.orig/libc/stdlib/stdlib.c +++ uClibc-0.9.30.1/libc/stdlib/stdlib.c @@ -401,6 +401,7 @@ libc_hidden_proto(__XL_NPP(strtoull)) strong_alias(__XL_NPP(strtoul),__XL_NPP(strtoull)) libc_hidden_def(__XL_NPP(strtoull)) +strong_alias(strtoul,strtouq) #endif Index: uClibc-0.9.30.1/include/stdlib.h === --- uClibc-0.9.30.1.orig/include/stdlib.h +++ uClibc-0.9.30.1/include/stdlib.h @@ -203,6 +203,8 @@ __END_NAMESPACE_STD #ifdef __USE_BSD +#include /* for u_quad_t */ + /* Convert a string to a quadword integer. */ __extension__ extern long long int strtoq (__const char *__restrict __nptr, @@ -210,7 +212,7 @@ __THROW __nonnull ((1)) __wur; /* Convert a string to an unsigned quadword integer. */ __extension__ -extern unsigned long long int strtouq (__const char *__restrict __nptr, +extern u_quad_t strtouq (__const char *__restrict __nptr, char **__restrict __endptr, int __base) __THROW __nonnull ((1)) __wur; #endif /* GCC and use BSD. */ -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: strtouq on 64bit
>>>>> "Khem" == Khem Raj writes: >> #endif /* GCC and use BSD. */ Khem> looks ok. Thanks, but it fails with locale support. This should be better: [PATCH]: Add strtouq alias (to strtoul) for 64bit The strtouq alias was only available on 32bit, breaking compilation of stuff using strtouq on 64bit machines. At the same time use the correct return type (u_quad_t). Signed-of-by: Peter Korsgaard --- include/stdlib.h |4 +++- libc/stdlib/stdlib.c |1 + 2 files changed, 4 insertions(+), 1 deletion(-) Index: uClibc-0.9.30.1/libc/stdlib/stdlib.c === --- uClibc-0.9.30.1.orig/libc/stdlib/stdlib.c +++ uClibc-0.9.30.1/libc/stdlib/stdlib.c @@ -401,6 +401,9 @@ libc_hidden_proto(__XL_NPP(strtoull)) strong_alias(__XL_NPP(strtoul),__XL_NPP(strtoull)) libc_hidden_def(__XL_NPP(strtoull)) +#if !defined(L_strtoul_l) +strong_alias(strtoul,strtouq) +#endif #endif Index: uClibc-0.9.30.1/include/stdlib.h === --- uClibc-0.9.30.1.orig/include/stdlib.h +++ uClibc-0.9.30.1/include/stdlib.h @@ -203,6 +203,8 @@ __END_NAMESPACE_STD #ifdef __USE_BSD +#include /* for u_quad_t */ + /* Convert a string to a quadword integer. */ __extension__ extern long long int strtoq (__const char *__restrict __nptr, @@ -210,7 +212,7 @@ __THROW __nonnull ((1)) __wur; /* Convert a string to an unsigned quadword integer. */ __extension__ -extern unsigned long long int strtouq (__const char *__restrict __nptr, +extern u_quad_t strtouq (__const char *__restrict __nptr, char **__restrict __endptr, int __base) __THROW __nonnull ((1)) __wur; #endif /* GCC and use BSD. */ -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: svn commit: [25823] trunk/uClibc: include libc/stdlib
>>>>> "Peter" == Peter Kjellerstedt writes: Hi, Peter> If you now changed strtouq() to return u_quad_t, shouldn't you Peter> also change strtoq() to return a quad_t? Yes, the same 64bit fix should probably we done for strtoq. -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: compiling older gcc and uclibc with new buildroot.
>>>>> "abhishek" == abhishek desai writes: abhishek> Hi, FYI: Buildroot questions belongs on the buildroot list (buildr...@uclibc.org) abhishek> I am trying to compile uclibc and gcc toolchains using abhishek> buildroot for mipsel architecture abhishek> using buildroot-2009.02-rc1. I want to use older versions abhishek> for kernel-headers, gcc and uclibc kernel headers - abhishek> 2.6.12, uclibc - 0.9.28 gcc - 3.4.6 I would strongly suggest you use something more modern, but the old versions are still available in the 2009.02 release - Just enable B2_DEPRECATED (Build options->Show packages that are deprecated). And also consider using the final 2009.02 release instead of -rc1. -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: no mail after git-push ?
>>>>> "Mike" == Mike Frysinger writes: Hi, >> For short diffs (<10kB by default) it includes the diff in the >> mail, and for longer diffs it includes a link instead Mike> we didnt have that before and no one complained that i know of, Mike> and mailman itself has a limit (40kB) which i dont believe has Mike> been hit before ... -mike We didn't? The commit-email.pl script did a check if the diff was longer than 1000 lines and sent a link to viewvc instead otherwise. We had that a few times in BR. -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: no mail after git-push ?
>>>>> "Mike" == Mike Frysinger writes: Hi, >> We didn't? The commit-email.pl script did a check if the diff was >> longer than 1000 lines and sent a link to viewvc instead otherwise. We >> had that a few times in BR. Mike> yeah, you're right. i see that in the svn script. do people Mike> desire this behavior ? i dont mind it personally. I would like it. Does your script call git-format-patch with rename/copy detection? Otherwise the diff when we add E.G. a new gcc version in BR could very well get bigger than 40k. -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: uclibc MIPS NPTL
>>>>> "Dan" == Dan E writes: Hi, >> I'm trying to run a recent D-Bus daemon. It works fine under >> 0.9.29 with threads completely disabled. Using the NPTL branch, >> however, the dbus daemon fails to read() from a Unix domain socket >> with errno = E2BIG. I have a few more tests to run before I can >> be sure what the real problem is. It may be with dbus itself. It >> has pthread calls in it but no makefile links using -lpthread, and >> 'ldd dbus-daemon' doesn't show a dependency on libpthread.so. >> Strangeness. Dan> Just a quick update to say further testing was not possible. I Dan> wanted to see what would happen using the NPTL branch of uClibc Dan> with NPTL itself disabled. Apparently the NPTL branch cannot be Dan> built at all unless NPTL is enabled. Multiple compiler errors Dan> occur because header files, like tls.h and sysdep-cancel.h, Dan> cannot be found. FYI, dbus works here on ppc with 0.9.30.1. -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [Buildroot] dead link report.
>>>>> "W" == W P writes: Hi, It would be good to get the buildroot references in http://uclibc.org/toolchains.html updated. The ancient 0.9.27 release is moved to /downloads/old/buildroot-0.9.27.tar.bz2, and the source mirror is at /downloads/sources/ (but I've purged that dir some months ago, so the ancient versions needed by 0.9.27 probably aren't there any more. Alternatively, you could drop the 0.9.27 link and just ask people to use the latest stable release. W> Hi (again), W> those 2 links (at least) seems to be dead and need correction: W> (On main page: http://www.uclibc.org/toolchains.html). W> http://buildroot.uclibc.org/downloads/buildroot-0.9.27.tar.bz2 W> http://buildroot.uclibc.org/downloads/buildroot-sources W> (I found that target simply moved). Thanks. -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [Buildroot] dead link report.
>>>>> "Mike" == Mike Frysinger writes: Mike> On Tuesday 13 October 2009 03:28:13 Peter Korsgaard wrote: >> It would be good to get the buildroot references in >> http://uclibc.org/toolchains.html updated. Mike> the uClibc website is in a normal git repo for people to push to And you don't mind me messing with it? Ok, then. -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [Buildroot] dead link report.
>>>>> "Mike" == Mike Frysinger writes: Mike> the uClibc website is in a normal git repo for people to push to .. except that I'm not in the uclibc group so I cannot. -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
[PATCH] toolchains.html: fix links to ancient buildroot release
Signed-off-by: Peter Korsgaard --- toolchains.html |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/toolchains.html b/toolchains.html index 8e4b78f..784d48b 100644 --- a/toolchains.html +++ b/toolchains.html @@ -66,8 +66,8 @@ strace, busybox, GNU coreutils, GNU tar, GNU grep, etc. Each of these uClibc development systems was created using http://buildroot.uclibc.org/";>buildroot, specifically, -http://buildroot.uclibc.org/downloads/buildroot-0.9.27.tar.bz2";>buildroot-0.9.27.tar.bz2 -along with http://buildroot.uclibc.org/downloads/buildroot-sources";>these sources. +http://buildroot.uclibc.org/downloads/old/buildroot-0.9.27.tar.bz2";>buildroot-0.9.27.tar.bz2 +along with http://buildroot.uclibc.org/downloads/sources";>these sources. -- 1.6.3.3 ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] toolchains.html: fix links to ancient buildroot release
>>>>> "Bernhard" == Bernhard Reutner-Fischer writes: Bernhard> On Tue, Oct 13, 2009 at 12:24:46PM +0200, Peter Korsgaard wrote: >> Signed-off-by: Peter Korsgaard Bernhard> Perhaps you could poke the buildroot maintainer to rebuild these Bernhard> periodically with the current stable series of BR, uClibc, busybox, Bernhard> toolchain? ;) What configurations and what packages? I guess it wouldn't be a big deal to rebuild those things (and it would be a nice verification step before release). -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: nptl branch going away, use nptl_merge
>>>>> "Carmelo" == Carmelo AMOROSO writes: Carmelo> If you are going to use buildroot, there is a problem during Carmelo> the configuration of the final gcc that will prevent to use Carmelo> the proper unwinding. Carmelo> I did a fixed times ago on an very old buildroot version, Carmelo> unfortunately never pushed out. Please send what you have + description of what the problem is exactly, and I'll integrate it in BR. -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: uclibc/buildroot build error
>>>>> "joyful" == joyful writes:
joyful> I don't think I did anything special, merely did make menuconfig and
joyful> selected some items on the menu, I got this error during make:
joyful> *** Unpacking kernel source
joyful> bzcat /tmp/buildroot/dl/linux-2.6.29.2.tar.bz2 | tar -C
joyful> /tmp/buildroot/project_build_i686/uclibc -xf -
joyful> touch /tmp/buildroot/project_build_i686/uclibc/linux-2.6.29.2/.unpacked
joyful> toolchain/patch-kernel.sh
joyful> /tmp/buildroot/project_build_i686/uclibc/linux-2.6.29.2
joyful> toolchain/kernel-headers \
joyful>linux-2.6.29.2-\*.patch{,.gz,.bz2}
joyful> touch /tmp/buildroot/project_build_i686/uclibc/linux-2.6.29.2/.patched
joyful> cp -dpf
/tmp/buildroot/project_build_i686/uclibc/linux-2.6.29.2/.config
joyful> cp: missing destination file operand after
joyful> `/tmp/buildroot/project_build_i686/uclibc/linux-2.6.29.2/.config'
joyful> Try `cp --help' for more information.
joyful> make: ***
joyful> [/tmp/buildroot/project_build_i686/uclibc/linux-2.6.29.2/.configured]
joyful> Error 1
Buildroot questions belongs on the buildroot list, this doesn't have
anything to do with uclibc.
What it says above is that the kernel compilation fails because you
don't have a kernel configuration (a .config).
I see that you are not using the latest stable release. Please give
buildroot-2009.11 a try.
--
Bye, Peter Korsgaard
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: uClibc-0.9.30.3-rc1
>>>>> "Javier" == Javier Viguera writes: Javier> Bernhard Reutner-Fischer wrote: >> Hi all, >> >> I'd like to do a maintenance 0.9.30.3 release soon (in a week or so). >> >> If you have patches/fixes that should be backported from master then >> please say so now (or push non-controversial fixes right to the branch). Javier> Hi Bernhard, Javier> It would be great if the "realpath-SUSv4-compliant" commit in master Javier> could be added also to 0_9_30 branch for upcoming 0.9.30.3 release. Yes, I recently ran into that issue as well. Javier> Please consider applying it for next 0.9.30.3. +1 -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: uClibc-0.9.30.3-rc1
>>>>> "Lennart" == Lennart Sorensen writes: Hi, Lennart> Sounds good to me. Certainly as far as coldfire is concerned, Lennart> the master works fine, while the 0.9.30 branch is broken. The Lennart> signal cleanup in master also seems useful to newer versions Lennart> of busybox. I get the impression that busybox 0.16.0 can't Lennart> compile against 0.9.30.x at all right now, although I haven't Lennart> tried on other architectures. It builds OK here on ARM and PPC. -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: copysignl.c
>>>>> "Nuno" == Nuno Pereira writes: Hi, Nuno> This fix allows to compile BR with software floating point support Nuno> with shared libgcc. Nuno> If you keep software floating point support enabled and disable shared Nuno> libgcc, it compiles ok but when you enable shared libgcc, compilation Nuno> blows due to an invalid reference to copysignl.c. Thanks for the description. uClibc people, is this a known issue? >> Nuno> Hi, >> Nuno> In the latest release of Buildroot, I think that fix should be >> included: >> >> Nuno> >> http://lists.busybox.net/pipermail/buildroot/2010-February/031987.html >> >> What exactly does this fix? I'm using BR on ppc daily, and never seen >> this problem. -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: powerpc NPTL port
>>>>> "Khem" == Khem Raj writes: Khem> Hi Khem> Based on the powerpc patch that Bernhard had, I have refreshed it with Khem> current master Khem> I am able to build a uclibc with nptl for powerpc but I have no Khem> hardware to test it on Khem> If someone with ppc hardware could try this out would be a great help Khem> The patch is Khem> http://uclibc.org/~kraj/0001-powerpc-Add-TLS-and-NPTL-support.patch I'll hopefully get some time to test it next week. -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: Bug in 0.9.31 with __errno_location in linuxthreads.old
On Tue, May 11, 2010 at 5:19 PM, Jean-Denis Boyer
wrote:
>
> Here is a fix that I suggest for 0.9.31.
I ran into this issue as well, while porting some multithreaded sw to
uclibc. The patch here improves stuff, but it doesn't fix the issue :/
The problem is that access to errno doesn't seem to be thread safe.
It's easy to verify using a small test program:
#include
#include
#include
#include
#include
#include
#define READERS 100
#define WRITERS 100
static void *read_test(void *data)
{
char buf[100];
int fd, good = 0, bad = 0;
fd = open("/dev/null", O_WRONLY);
while (1) {
if ((read(fd, buf, sizeof(buf)) != -1) || (errno != EBADF)) {
int err = errno;
fprintf(stderr, "%d: (%d/%d) got %d instead of %d\n",
pthread_self(), bad, bad+good, err, EBADF);
bad++;
} else {
good++;
}
}
return 0;
}
static void *write_test(void *data)
{
char buf[100];
int fd, good = 0, bad = 0;
fd = open("/dev/full", O_WRONLY);
while (1) {
if ((write(fd, buf, sizeof(buf)) != -1) || (errno != ENOSPC)) {
int err = errno;
fprintf(stderr, "%d: (%d/%d) got %d instead of %d\n",
pthread_self(), bad, bad+good, err, ENOSPC);
bad++;
} else {
good++;
}
}
return 0;
}
int main(void)
{
pthread_t id;
int i;
for (i=0; ihttp://git.buildroot.net/buildroot/tree/toolchain/uClibc/uClibc-0.9.31.config).
This is with Linuxthreads.old, but a quick check with Linuxthreads
shows the same behavior.
Any ideas?
> It is in folder linuxthreads.old, but I don't know if it also applies to the
> "new" version.
>
> --- a/libpthread/linuxthreads.old/errno.c 2010-04-02 11:34:27.0
> -0400
> +++ b/libpthread/linuxthreads.old/errno.c 2010-05-11 09:44:16.589502638
> -0400
> @@ -22,6 +22,7 @@
> #include "internals.h"
> #include
>
> +libpthread_hidden_proto(__errno_location)
> int *
> __errno_location (void)
> {
> @@ -29,6 +30,7 @@
> return THREAD_GETMEM (self, p_errnop);
> }
>
> +libpthread_hidden_proto(__h_errno_location)
> int *
> __h_errno_location (void)
> {
>
> The problem is shown when running the program in attachment.
> A thread cannot read the right value of errno, but the main can.
> The output of the program is:
>
> thread: Failed to connect (-1 errno=0): Operation now in progress
> main: Failed to connect (-1 errno=115): Operation now in progress
>
> Regards,
>
> Jean-Denis Boyer, Eng.
> Media5 Corporation - Mediatrix, M5T, Media5Boss
> 4229 Garlock Street, Sherbrooke (Québec), J1L 2C8, CANADA
>
> ___
> uClibc mailing list
> uClibc@uclibc.org
> http://lists.busybox.net/mailman/listinfo/uclibc
>
--
Bye, Peter Korsgaard
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: boost thread & get_nproc
>>>>> "Gerhard" == Lipp, Gerhard writes: Hi, Gerhard> i am trying to get the boost.thread 1.43 lib running, using buildroot Gerhard> with uclibc 0.9.31 configured. Gerhard> when building bjam from within buildroot env, the compiler complains Gerhard> about an undeclared get_nprocs function, which is ifdefed by _GNU_SOURCE Gerhard> (file: boost/libs/thread/src/pthread/thread.cpp, method Gerhard> boost::thread::hardware_concurrency). Gerhard> afaik, get_nprocs is not part of the libc standard and thus not Gerhard> implemented in uclibc up to now. apparently one could implement Gerhard> boost::thread::hardware_concurrency with means of sysinfo, but it seems Gerhard> this isnt implemented either. Yes, get_nprocs() is a GNU extension. You can use sysinfo(_SC_PROCESSORS_CONF); instead like I did for squashfs last week: http://git.buildroot.net/buildroot/tree/package/squashfs/squashfs-4.0-mksquashfs-get_nprocs.patch Don't forget to send the boost support to the BR list once you get it working. -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: boost thread & get_nproc
>>>>> "Bernhard" == Bernhard Reutner-Fischer writes: Hi, >> Yes, get_nprocs() is a GNU extension. You can use >> sysinfo(_SC_PROCESSORS_CONF); instead like I did for squashfs last week: Bernhard> http://www.mail-archive.com/uclibc@uclibc.org/msg05262.html Bernhard> As said, feedback on the locking in a threaded environment is welcome Bernhard> (ideally with testcases that we can put into the testsuite). Ok, also see https://bugs.uclibc.org/2089 for other threading issues (including a test case). -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
[PATCH] don't make __errno_location / __h_errno_location hidden
Closes #2089 (https://bugs.busybox.net/show_bug.cgi?id=2089)
__errno_location / __h_errno_location access has to go through the PLT
like malloc/free, so the linuxthread variants gets used instead when
compiling with -pthread.
Based on
http://github.com/mat-c/uClibc/commit/328d392c54aa5dc2b8e7f398a419087de497de2b
Signed-off-by: Peter Korsgaard
---
include/netdb.h |1 -
libc/misc/internals/__errno_location.c|3 ---
libc/misc/internals/__h_errno_location.c |1 -
libc/sysdeps/linux/common/bits/errno.h|1 -
libc/sysdeps/linux/common/bits/uClibc_errno.h |3 ---
5 files changed, 0 insertions(+), 9 deletions(-)
diff --git a/include/netdb.h b/include/netdb.h
index 9d3807d..ac411ab 100644
--- a/include/netdb.h
+++ b/include/netdb.h
@@ -59,7 +59,6 @@ __BEGIN_DECLS
/* Function to get address of global `h_errno' variable. */
extern int *__h_errno_location (void) __THROW __attribute__ ((__const__));
-libc_hidden_proto(__h_errno_location)
/* Macros for accessing h_errno from inside libc. */
#ifdef _LIBC
diff --git a/libc/misc/internals/__errno_location.c
b/libc/misc/internals/__errno_location.c
index aec7641..71c5461 100644
--- a/libc/misc/internals/__errno_location.c
+++ b/libc/misc/internals/__errno_location.c
@@ -15,6 +15,3 @@ __errno_location (void)
{
return &errno;
}
-#ifdef IS_IN_libc /* not really need, only to keep in sync w/
libc_hidden_proto */
-libc_hidden_weak(__errno_location)
-#endif
diff --git a/libc/misc/internals/__h_errno_location.c
b/libc/misc/internals/__h_errno_location.c
index 213d398..235df4e 100644
--- a/libc/misc/internals/__h_errno_location.c
+++ b/libc/misc/internals/__h_errno_location.c
@@ -10,4 +10,3 @@ int * weak_const_function __h_errno_location (void)
{
return &h_errno;
}
-libc_hidden_weak(__h_errno_location)
diff --git a/libc/sysdeps/linux/common/bits/errno.h
b/libc/sysdeps/linux/common/bits/errno.h
index 0bf6354..de9688a 100644
--- a/libc/sysdeps/linux/common/bits/errno.h
+++ b/libc/sysdeps/linux/common/bits/errno.h
@@ -43,7 +43,6 @@
# ifndef __ASSEMBLER__
/* Function to get address of global `errno' variable. */
extern int *__errno_location (void) __THROW __attribute__ ((__const__));
-libc_hidden_proto(__errno_location)
# ifdef __UCLIBC_HAS_THREADS__
/* When using threads, errno is a per-thread value. */
diff --git a/libc/sysdeps/linux/common/bits/uClibc_errno.h
b/libc/sysdeps/linux/common/bits/uClibc_errno.h
index 9c15618..79eb7e6 100644
--- a/libc/sysdeps/linux/common/bits/uClibc_errno.h
+++ b/libc/sysdeps/linux/common/bits/uClibc_errno.h
@@ -33,9 +33,6 @@ extern int *__errno_location (void) __THROW __attribute__
((__const__))
;
# if defined __UCLIBC_HAS_THREADS__
# include
-# if defined USE___THREAD && USE___THREAD
-libc_hidden_proto(__errno_location)
-# endif
# endif
#endif /* !__ASSEMBLER__ */
--
1.7.1
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: errno is not thread-safe in uClibc-0.9.30?
>>>>> "Pan" == Pan ruochen writes: Pan> Hi All, Pan> I am developing with uClibc-0.9.30. I came accoss very strange problems Pan> relating to `errno'. That's a known issue in both 0.9.30 and 0.9.31 - I've opened a bugzilla issue for it: https://bugs.uclibc.org/2089 I've posted a fix which fixed the problem for me, but the devs didn't like it: http://lists.uclibc.org/pipermail/uclibc/2010-July/044176.html But maybe you can use it until a proper fix is made. -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: Delay in dropbear login since 0.9.31
>>>>> "Will" == Will Moore writes: Will> Since buildroot 2010.05 (uclibc 0.9.31) targeting i486 and Will> building dropbear (0.52) I have found a several second delay Will> (perhaps as much as 10 seconds) in the ssh and scp login process. Will> I found that if I revert to uclibc 0.9.30.3 then this login delay Will> disappears. I am happy to look further into this to assist in Will> finding the problem but am unsure where to start. Some pointers Will> would be much appreciated. It sounds like a DNS issue. How is you DNS configuration? (/etc/resolv.conf) -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: Delay in dropbear login since 0.9.31
>>>>> "Will" == Will Moore writes: Hi, >> It sounds like a DNS issue. How is you DNS configuration? >> (/etc/resolv.conf) Will> I have not added anything to /etc/resolv.conf so it is an empty Will> (0 byte) file. This is true of systems with uclibc 0.9.30.x Will> without the delay and of systems with uclibc 0.9.31 with the Will> delay. Ok, I've also seen 0.9.31 doing a DNS request to 0.0.0.0 and waiting for timeout with empty/non-existing /etc/resolv.conf. uClibc people? -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: getservent, getservbyname and getservbyport and config parser
>>>>> "Natanael" == Natanael Copa writes: Hi, Natanael> Unless someone have some really strong arguments to keep the Natanael> 80 char bufsize, I'll just set static line bufsize to 256 Natanael> chars and then just let the config parser only ready the 256 Natanael> first chars on each line and ignore the rest. Agreed - Lets keep it simple. -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: Wrong DST flag
>>>>> "Viktar" == Viktar Palstsiuk writes: Viktar> Hello, Viktar> I've noticed that my target based on buildroot shows incorrect time. Viktar> The issue is caused by wrong DST flag. The `date +%Z` still shows that Viktar> it is summer time now but time supposed to be switched to standard Viktar> time on October 31 at 3 a.m. (according to Russian rules) Viktar> # cat /etc/TZ Viktar> MSK-3MSD Viktar> # date +%z Viktar> +0400 Viktar> # date +%Z Viktar> MSD Viktar> # date Viktar> Mon Nov 1 13:55:09 MSD 2010 Viktar> I'm using uClibc-0.9.31, busybox-1.17.0, buildroot-20100715. We don't do anything special about timezone in buildroot, so forwarding to the uclibc list. -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: Should BusyBox and uClibc also make a "flag version" like Embedded Linux?
>>>>> "Will" == Will Newton writes: Hi, Will> I'm not sure that there's quite the same need for flag versions. Will> Upgrading a kernel can cause lots of subtle changes in how the Will> system behaves and incur a lot of effort in updating out of tree Will> drivers, whereas swapping a new BusyBox in has been very painless Will> in our experience. I don't recall whether we have ever had any Will> issue other than perhaps having to update the config file we use. Indeed. HW specific stuff like the kernel and bootloader can be painful, but higher level stuff usually aren't. Will> To be honest I've experienced much larger problems with toolchain and Will> build system upgrades rather than uClibc and BusyBox version bumps. Which makes sense as you then normally upgrade the version of several packages at once, so the amount of potential problems get multiplied. -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [ANNOUNCE] 0.9.32-rc1 released
>>>>> "Bernhard" == Bernhard Reutner-Fischer writes: Hi, Bernhard> I'm happy to announce that we now have a 0.9.32-rc1. Bernhard> Please test this release candidate and report back. Bernhard> We aim to do the final release end of january to give people Bernhard> enough time to check the release candidate. After the 0.9.32 Bernhard> release we will merge the prelink branch into master. Bernhard> Thanks alot to everybody who contributed so far and to those Bernhard> who reported bugs. Let's make this release i success! Great, thanks. There unfortunately seems to be an issue on ppc with NPTL and UCLIBC_USE_NETLINK=y CC libc/inet/herror.os CC libc/inet/if_index.os In file included from libc/inet/if_index.c:37: libc/inet/netlinkaccess.h:29: error: redefinition of typedef '__u8' /home/peko/source/buildroot/output/toolchain/linux/include/asm-generic/int-ll64.h:20: note: previous declaration of '__u8' was here stdio.h seems to eventually include asm/types.h, which then conflicts with the local typedefs in netlinkaccess.h. The same config works on ARM. Why are we adding those local typedefs in the first place? They were added back in 2006 by Mike, but the commit message doesn't really explain why: commit 80908df22df6d73847801a48f26380f996cf10c4 Author: Mike Frysinger Date: Sat Jan 14 00:16:18 2006 + make sure linux/types.h doesnt screw us up -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [ANNOUNCE] 0.9.32-rc1 released
>>>>> "Khem" == Khem Raj writes: >> commit 80908df22df6d73847801a48f26380f996cf10c4 >> Author: Mike Frysinger >> Date: Sat Jan 14 00:16:18 2006 + >> >> make sure linux/types.h doesnt screw us up >> Khem> Can you try the attached patch ? Yes, then it works - Thanks. -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: uClibc Thread Safety
>>>>> "Chris" == Chris Loopenberg writes: Chris> Dear All! Chris> Is the 'errno' thread-safety related bug fixed in 0.9.32 RC1? Are you referring to https://bugs.busybox.net/show_bug.cgi?id=2089 ? No, that's afaik still not fixed. -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [git tag v0.9.32-rc2 1/1] release 0.9.32-rc2
>>>>> "Carmelo" == Carmelo AMOROSO writes: Hi, Carmelo> Folks, Carmelo> I've pushed the protected symbols stuff plus some few fixes from Will. Carmelo> Release bumped to 0.9.32-rc2 and git tagged as well. Nice - Don't forget to upload a tarball and update website. -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: pthread_create fails on a device with 16MB RAM
>>>>> "Carmelo" == Carmelo AMOROSO writes: Hi, Carmelo> --- a/libpthread/nptl/init.c Carmelo> +++ b/libpthread/nptl/init.c Carmelo> @@ -401,6 +401,10 @@ __pthread_initialize_minimal_internal (v Carmelo> Use the minimal size acceptable. */ Carmelo> limit.rlim_cur = PTHREAD_STACK_MIN; Carmelo> + /* Do not exceed architecture specific default */ Carmelo> + if (limit.rlim_cur > ARCH_STACK_DEFAULT_SIZE) Carmelo> +limit.rlim_cur = ARCH_STACK_DEFAULT_SIZE; Carmelo> + Carmelo>/* Make sure it meets the minimum size that allocate_stack Carmelo> (allocatestack.c) will demand, which depends on the page size. */ Carmelo>const uintptr_t pagesz = sysconf (_SC_PAGESIZE); Carmelo> At least the check should be guarded by #ifdef ARCH_STACK_DEFAULT_SIZE. It's already used in the same file without a guard. Carmelo> Anyway, where are you thinking to define this one ? Seems like most archs sets it to 2MB: git grep ARCH_STACK_DEFAULT_SIZE libpthread/nptl/init.c:limit.rlim_cur = ARCH_STACK_DEFAULT_SIZE; libpthread/nptl/sysdeps/alpha/pthreaddef.h:#define ARCH_STACK_DEFAULT_SIZE (4 * 1024 * 1024) libpthread/nptl/sysdeps/arm/pthreaddef.h:#define ARCH_STACK_DEFAULT_SIZE (2 * 1024 * 1024) libpthread/nptl/sysdeps/i386/pthreaddef.h:#define ARCH_STACK_DEFAULT_SIZE (2 * 1024 * 1024) libpthread/nptl/sysdeps/mips/pthreaddef.h:#define ARCH_STACK_DEFAULT_SIZE (2 * 1024 * 1024) libpthread/nptl/sysdeps/powerpc/pthreaddef.h:#define ARCH_STACK_DEFAULT_SIZE (4 * 1024 * 1024) libpthread/nptl/sysdeps/sh/pthreaddef.h:#define ARCH_STACK_DEFAULT_SIZE (2 * 1024 * 1024) libpthread/nptl/sysdeps/sparc/sparc32/pthreaddef.h:#define ARCH_STACK_DEFAULT_SIZE (2 * 1024 * 1024) libpthread/nptl/sysdeps/sparc/sparc64/pthreaddef.h:#define ARCH_STACK_DEFAULT_SIZE (4 * 1024 * 1024) libpthread/nptl/sysdeps/x86_64/pthreaddef.h:#define ARCH_STACK_DEFAULT_SIZE (2 * 1024 * 1024) -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
[PATCH] sync bits/socket.h PF_* / AF_* values with 2.6.38-rc3
A number of new address / protocol families have been added over the years, so sync with Linux 2.6.38-rc3, adding CAN, ISDN, Phonet, Zigbee, .. which are starting to be used by applications. Signed-off-by: Peter Korsgaard --- libc/sysdeps/linux/common/bits/socket.h | 22 +- libc/sysdeps/linux/mips/bits/socket.h | 22 +- libc/sysdeps/linux/sparc/bits/socket.h | 22 +- 3 files changed, 63 insertions(+), 3 deletions(-) diff --git a/libc/sysdeps/linux/common/bits/socket.h b/libc/sysdeps/linux/common/bits/socket.h index 11f6e97..7e12733 100644 --- a/libc/sysdeps/linux/common/bits/socket.h +++ b/libc/sysdeps/linux/common/bits/socket.h @@ -98,8 +98,18 @@ enum __socket_type #definePF_IRDA 23 /* IRDA sockets. */ #definePF_PPPOX24 /* PPPoX sockets. */ #definePF_WANPIPE 25 /* Wanpipe API sockets. */ +#definePF_LLC 26 /* Linux LLC. */ +#definePF_CAN 29 /* Controller Area Network. */ +#definePF_TIPC 30 /* TIPC sockets. */ #definePF_BLUETOOTH31 /* Bluetooth sockets. */ -#definePF_MAX 32 /* For now.. */ +#definePF_IUCV 32 /* IUCV sockets. */ +#definePF_RXRPC33 /* RxRPC sockets. */ +#definePF_ISDN 34 /* mISDN sockets. */ +#definePF_PHONET 35 /* Phonet sockets. */ +#definePF_IEEE802154 36 /* IEEE 802.15.4 sockets. */ +#definePF_CAIF 37 /* CAIF sockets. */ +#definePF_ALG 38 /* Algorithm sockets. */ +#definePF_MAX 39 /* For now.. */ /* Address families. */ #defineAF_UNSPEC PF_UNSPEC @@ -130,7 +140,17 @@ enum __socket_type #defineAF_IRDA PF_IRDA #defineAF_PPPOXPF_PPPOX #defineAF_WANPIPE PF_WANPIPE +#defineAF_LLC PF_LLC +#defineAF_CAN PF_CAN +#defineAF_TIPC PF_TIPC #defineAF_BLUETOOTHPF_BLUETOOTH +#defineAF_IUCV PF_IUCV +#defineAF_RXRPCPF_RXRPC +#defineAF_ISDN PF_ISDN +#defineAF_PHONET PF_PHONET +#defineAF_IEEE802154 PF_IEEE802154 +#defineAF_CAIF PF_CAIF +#defineAF_ALG PF_ALG #defineAF_MAX PF_MAX /* Socket level values. Others are defined in the appropriate headers. diff --git a/libc/sysdeps/linux/mips/bits/socket.h b/libc/sysdeps/linux/mips/bits/socket.h index b46e7be..27ceafa 100644 --- a/libc/sysdeps/linux/mips/bits/socket.h +++ b/libc/sysdeps/linux/mips/bits/socket.h @@ -100,8 +100,18 @@ enum __socket_type #definePF_IRDA 23 /* IRDA sockets. */ #definePF_PPPOX24 /* PPPoX sockets. */ #definePF_WANPIPE 25 /* Wanpipe API sockets. */ +#definePF_LLC 26 /* Linux LLC. */ +#definePF_CAN 29 /* Controller Area Network. */ +#definePF_TIPC 30 /* TIPC sockets. */ #definePF_BLUETOOTH31 /* Bluetooth sockets. */ -#definePF_MAX 32 /* For now.. */ +#definePF_IUCV 32 /* IUCV sockets. */ +#definePF_RXRPC33 /* RxRPC sockets. */ +#definePF_ISDN 34 /* mISDN sockets. */ +#definePF_PHONET 35 /* Phonet sockets. */ +#definePF_IEEE802154 36 /* IEEE 802.15.4 sockets. */ +#definePF_CAIF 37 /* CAIF sockets. */ +#definePF_ALG 38 /* Algorithm sockets. */ +#definePF_MAX 39 /* For now.. */ /* Address families. */ #defineAF_UNSPEC PF_UNSPEC @@ -132,7 +142,17 @@ enum __socket_type #defineAF_IRDA PF_IRDA #defineAF_PPPOXPF_PPPOX #defineAF_WANPIPE PF_WANPIPE +#defineAF_LLC PF_LLC +#defineAF_CAN PF_CAN +#defineAF_TIPC PF_TIPC #defineAF_BLUETOOTHPF_BLUETOOTH +#defineAF_IUCV PF_IUCV +#defineAF_RXRPCPF_RXRPC +#defineAF_ISDN PF_ISDN +#defineAF_PHONET PF_PHONET +#defineAF_IEEE802154 PF_IEEE802154 +#defineAF_CAIF PF_CAIF +#defineAF_ALG PF_ALG #defineAF_MAX PF_MAX /* Socket level values. Others are defined in the appropriate headers. diff --git a/libc/sysdeps/linux/sparc/bits/socket.h b/libc/sysdeps/linux/sparc/bits/socket.h index e41527f..64973e2 100644 --- a/libc/sysdeps/linux/sparc/bits/socket.h +++ b/libc/sysdeps/linux/sparc/bits/socket.h @@ -88,8 +88,18 @@ enum __socket_type #definePF_IRDA 23 /* IRDA sockets. */ #definePF_PPPOX24 /* PPPoX sockets. */ #define
Re: [ANNOUNCE] 0.9.32-rc3 released
On Wed, Mar 16, 2011 at 8:44 PM, Bernhard Reutner-Fischer wrote: > Hi, > > I'm happy to announce that we now have a 0.9.32-rc3. Great - Notice that there's a typo on the website snippet - It still links to -rc2. -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: buildroot system requirements - no documentation or guidelines
>>>>>writes: Hi, > In my limited experience, buildroot seems to be -highly- sensitive to > the environment of the host: I have had success with only one > buildroot release (an old one) on only one host configuration (also > an old one) - and this release will not build a C++ compiler. The > documentation contains information on packages required, but not on > version numbers, especially for critical elements such as Linux > kernel, gcc/g++, etc. Please direct buildroot questions to the buildroot ML - buildr...@busybox.net -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] fix errno location for non-TLS case
>>>>> "Andrew" == Andrew Rybchenko writes: Hi, Andrew> linuxthreads.old implementation just wraps libc socket calls like Andrew> recv() which set errno. Andrew> Since errno is set from libc call and libc_hidden_proto() is used for Andrew> __errno_location(), Andrew> libc version of the function is called and provides pointer to global Andrew> errno variable (not Andrew> thread-specific location). Andrew> Also it is important here that linuxthreads.old does not use Andrew> TLS. That's why I use Andrew> __UCLIBC_HAS_TLS__ conditional. Andrew> There is no such bug in 0.9.30.x. Sounds related to: https://bugs.busybox.net/show_bug.cgi?id=2089 -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] fix errno location for non-TLS case
>>>>> "Andrew" == Andrew Rybchenko writes: Hi, >> Sounds related to: >> >> https://bugs.busybox.net/show_bug.cgi?id=2089 Andrew> Yes, it is definitely related. I don't understand why the bug Andrew> is RESOLVED as WONTFIX. Of course it is nice that it is not an Andrew> issue with NPTL, but as far as I can see in Config.in NPTL is Andrew> still considered unstable/immature. Andrew> IMHO, suggested patch is short, fix exactly what was broken, does Andrew> not touch code for NPTL (TLS) case. Andrew> The bug makes uClibc 0.9.32 as well as 0.9.31 unusable with Andrew> linuxthreads.old. I've not checked linuxthreads. IMHO, it would be Andrew> really nice if it is finally fixed in upcoming releases. Agreed. We're been carrying the original patch in buildroot for a while now: http://git.buildroot.net/buildroot/commit/?id=06c1d1001e -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: Kernel panic!
>>>>> "Mahanteshwari" == Mahanteshwari Hiremath >>>>> writes: Mahanteshwari> Hi, Mahanteshwari> I am trying use buildroot built root file system for Mahanteshwari> my embedded target board. I am able to boot my system Mahanteshwari> partially, it stops at some point saying /sbin/init: Mahanteshwari> cannot load libc.so.0, kernel panic-not Mahanteshwari> syncing:Attempted to kill init Buildroot related questions should go to the buildroot list (addressed in this mail). Please reply (only to the buildroot list) with more details about your system, E.G. your hw platform and your buildroot version and configuration (run make savedefconfig and send the defconfig file). Thanks. -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] sys/queue.h: update to eglibc version
>>>>> "Natanael" == Natanael Copa writes:
Natanael> Forgot signed-off. sorry.
Natanael> Will resend.
Natanael> (Is there some way to add always-signed-off to .git/config?)
I believe you can add something like this to your ~/.gitconfig
[format]
signoff = true
--
Bye, Peter Korsgaard
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: [ERRATUM][PATCH] Fix _dl_ldsopath when no slash in INTERP path
>>>>> "Ignacy" == Ignacy Gawedzki writes: Ignacy> On Mon, Jan 02, 2012 at 03:03:56AM -0500, thus spake Mike Frysinger: >> your proposed fix was more complicated than necessary. i've checked in >> some >> simpler code. please test and verify (but it seems to work for me). Ignacy> Thanks. I couldn't test the code in uClibc HEAD, because that wouldn't Ignacy> compile in buildroot. No? Also not with buildroot head? It did last time I tried (a few weeks ago). -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
[PATCH] powerpc: use common ptrace.h
The ppc version has never been updated, is a subset of the common one
and E.G. ltrace needs the missing definitions.
Signed-off-by: Peter Korsgaard
---
libc/sysdeps/linux/powerpc/sys/ptrace.h | 99 ---
1 file changed, 99 deletions(-)
delete mode 100644 libc/sysdeps/linux/powerpc/sys/ptrace.h
diff --git a/libc/sysdeps/linux/powerpc/sys/ptrace.h
b/libc/sysdeps/linux/powerpc/sys/ptrace.h
deleted file mode 100644
index 91a8730..000
--- a/libc/sysdeps/linux/powerpc/sys/ptrace.h
+++ /dev/null
@@ -1,99 +0,0 @@
-/* `ptrace' debugger support interface. Linux version.
- Copyright (C) 2001 Free Software Foundation, Inc.
- This file is part of the GNU C Library.
-
- The GNU C Library is free software; you can redistribute it and/or
- modify it under the terms of the GNU Lesser General Public
- License as published by the Free Software Foundation; either
- version 2.1 of the License, or (at your option) any later version.
-
- The GNU C Library is distributed in the hope that it will be useful,
- but WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- Lesser General Public License for more details.
-
- You should have received a copy of the GNU Lesser General Public
- License along with the GNU C Library; if not, write to the Free
- Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
- 02111-1307 USA. */
-
-#ifndef _SYS_PTRACE_H
-#define _SYS_PTRACE_H 1
-
-#include
-
-__BEGIN_DECLS
-
-/* Type of the REQUEST argument to `ptrace.' */
-enum __ptrace_request
-{
- /* Indicate that the process making this request should be traced.
- All signals received by this process can be intercepted by its
- parent, and its parent can use the other `ptrace' requests. */
- PTRACE_TRACEME = 0,
-#define PT_TRACE_ME PTRACE_TRACEME
-
- /* Return the word in the process's text space at address ADDR. */
- PTRACE_PEEKTEXT = 1,
-#define PT_READ_I PTRACE_PEEKTEXT
-
- /* Return the word in the process's data space at address ADDR. */
- PTRACE_PEEKDATA = 2,
-#define PT_READ_D PTRACE_PEEKDATA
-
- /* Return the word in the process's user area at offset ADDR. */
- PTRACE_PEEKUSER = 3,
-#define PT_READ_U PTRACE_PEEKUSER
-
- /* Write the word DATA into the process's text space at address ADDR. */
- PTRACE_POKETEXT = 4,
-#define PT_WRITE_I PTRACE_POKETEXT
-
- /* Write the word DATA into the process's data space at address ADDR. */
- PTRACE_POKEDATA = 5,
-#define PT_WRITE_D PTRACE_POKEDATA
-
- /* Write the word DATA into the process's user area at offset ADDR. */
- PTRACE_POKEUSER = 6,
-#define PT_WRITE_U PTRACE_POKEUSER
-
- /* Continue the process. */
- PTRACE_CONT = 7,
-#define PT_CONTINUE PTRACE_CONT
-
- /* Kill the process. */
- PTRACE_KILL = 8,
-#define PT_KILL PTRACE_KILL
-
- /* Single step the process.
- This is not supported on all machines. */
- PTRACE_SINGLESTEP = 9,
-#define PT_STEP PTRACE_SINGLESTEP
-
- /* Attach to a process that is already running. */
- PTRACE_ATTACH = 16,
-#define PT_ATTACH PTRACE_ATTACH
-
- /* Detach from a process attached to with PTRACE_ATTACH. */
- PTRACE_DETACH = 17,
-#define PT_DETACH PTRACE_DETACH
-
- /* Continue and stop at the next (return from) syscall. */
- PTRACE_SYSCALL = 24
-#define PT_SYSCALL PTRACE_SYSCALL
-};
-
-/* Perform process tracing functions. REQUEST is one of the values
- above, and determines the action to be taken.
- For all requests except PTRACE_TRACEME, PID specifies the process to be
- traced.
-
- PID and the other arguments described above for the various requests should
- appear (those that are used for the particular request) as:
- pid_t PID, void *ADDR, int DATA, void *ADDR2
- after REQUEST. */
-extern long int ptrace (enum __ptrace_request __request, ...) __THROW;
-
-__END_DECLS
-
-#endif /* _SYS_PTRACE_H */
--
1.7.9.5
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] powerpc: use common ptrace.h
>>>>> "Peter" == Peter Korsgaard writes: Peter> The ppc version has never been updated, is a subset of the Peter> common one and E.G. ltrace needs the missing definitions. Ehh, forget about this patch. Seems I got my build dirs mixed up. This causes problems as asm/ptrace.h (which gets included from several places) #define's PTRACE_GETREGS, screwing up the enum in common/ptrace.h -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: gentoo once again
>>>>> "Mike" == Mike Frysinger writes: Hi, >> > is there still any problem with udev? >> >> try it out and let us know ;) Mike> i just emerged it on my system and rebooted and it came back, so Mike> sounds good enough for me ;) We also have udev 182 in Buildroot, and that afaik works ok without any patches (I don't use it myself though). -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: restoring spec docs
>>>>> "Mike" == Mike Frysinger writes:
Mike> after moving from svn to git, the docs/ subdir of trunk/ wasn't
Mike> migrated anywhere. any suggestions on where to restore these ?
Mike> i'm not sure we can exclude subdirs when using `git archive`, so
Mike> we can't add them to the main repo.
From a quick look at the git archive man page it seems you can actually:
ATTRIBUTES
export-ignore
Files and directories with the attribute export-ignore won’t be
added to archive files. See gitattributes(5) for details.
export-subst
If the attribute export-subst is set for a file then git will
expand several placeholders when adding this file to an archive.
See gitattributes(5) for details.
--
Bye, Peter Korsgaard
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: Unable to build x86_64 on x86_64
>>>>> "Piotr" == Piotr Karbowski writes: Hi, Buildroot questions belong on the buildroot list, rather than the uclibc one. Piotr> /usr/bin/gcc -c -I. -W -Wall -Wstrict-prototypes Piotr> -Wmissing-prototypes -Wshadow -O2 Piotr> -I/home/piotr/src/buildroot-2012.02/output/host/include Piotr> -I/home/piotr/src/buildroot-2012.02/output/host/usr/include sysinfo.c Piotr> /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/../../../../x86_64-pc-linux-gnu/bin/as: Piotr> error while loading shared libraries: libc.so.0: cannot open shared Piotr> object file: No such file or directory Piotr> make[3]: *** [sysinfo.o] Error 1 Your host assembler apparently has a problem finding libc. Strangely enough it wants libc.so.0 which is a soname used by uClibc and not glibc. Do you have LD_LIBRARY_PATH set in your environment? x86-64 to x86-64 works fine here with buildroot git. -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
[PATCH] bits/time.h: sync with glibc 2.16
CLOCK_MONOTONIC_RAW is available since 2.6.28 (2d42244ae71d: clocksource: introduce CLOCK_MONOTONIC_RAW), and CLOCK_*_COARSE since 2.6.32 (da15cfdae033: time: Introduce CLOCK_REALTIME_COARSE). Signed-off-by: Peter Korsgaard --- libc/sysdeps/linux/common/bits/time.h |6 ++ 1 file changed, 6 insertions(+) diff --git a/libc/sysdeps/linux/common/bits/time.h b/libc/sysdeps/linux/common/bits/time.h index 7ed54bf..c871223 100644 --- a/libc/sysdeps/linux/common/bits/time.h +++ b/libc/sysdeps/linux/common/bits/time.h @@ -54,6 +54,12 @@ # define CLOCK_PROCESS_CPUTIME_ID2 /* Thread-specific CPU-time clock. */ # define CLOCK_THREAD_CPUTIME_ID 3 +/* Monotonic system-wide clock, not adjusted for frequency scaling. */ +# define CLOCK_MONOTONIC_RAW 4 +/* Identifier for system-wide realtime clock, updated only on ticks. */ +# define CLOCK_REALTIME_COARSE 5 +/* Monotonic system-wide clock, updated only on ticks. */ +# define CLOCK_MONOTONIC_COARSE 6 /* Flag to indicate time is absolute. */ # define TIMER_ABSTIME 1 -- 1.7.10 ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] bits/time.h: sync with glibc 2.16
>>>>> "Peter" == Peter Korsgaard writes: Peter> CLOCK_MONOTONIC_RAW is available since 2.6.28 Peter> (2d42244ae71d: clocksource: introduce CLOCK_MONOTONIC_RAW), and Peter> CLOCK_*_COARSE since 2.6.32 (da15cfdae033: time: Introduce Peter> CLOCK_REALTIME_COARSE). Peter> Signed-off-by: Peter Korsgaard Ping? Peter> --- Peter> libc/sysdeps/linux/common/bits/time.h |6 ++ Peter> 1 file changed, 6 insertions(+) Peter> diff --git a/libc/sysdeps/linux/common/bits/time.h b/libc/sysdeps/linux/common/bits/time.h Peter> index 7ed54bf..c871223 100644 Peter> --- a/libc/sysdeps/linux/common/bits/time.h Peter> +++ b/libc/sysdeps/linux/common/bits/time.h Peter> @@ -54,6 +54,12 @@ Peter> # define CLOCK_PROCESS_CPUTIME_ID2 Peter> /* Thread-specific CPU-time clock. */ Peter> # define CLOCK_THREAD_CPUTIME_ID 3 Peter> +/* Monotonic system-wide clock, not adjusted for frequency scaling. */ Peter> +# define CLOCK_MONOTONIC_RAW 4 Peter> +/* Identifier for system-wide realtime clock, updated only on ticks. */ Peter> +# define CLOCK_REALTIME_COARSE 5 Peter> +/* Monotonic system-wide clock, updated only on ticks. */ Peter> +# define CLOCK_MONOTONIC_COARSE 6 Peter> /* Flag to indicate time is absolute. */ Peter> # define TIMER_ABSTIME 1 Peter> -- Peter> 1.7.10 -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: Fwd: [PATCH] Fix missing semicolon
>>>>> "Manuel" == Manuel Rüger writes: Manuel> Btw. it looks like http://git.uclibc.org/uClibc/ doesn't get Manuel> updated anymore? There's a caching issue that I reported a while ago. Compare the output of: http://git.uclibc.org/uClibc and http://git.uclibc.org/uClibc/ -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: Xtensa updates
>>>>> "Chris" == Chris Zankel writes: Chris> Hi, Chris> So, I pushed my changes upstream, but got the following warnings/errors. Chris> Was there something wrong on my side? Chris> Thanks, Chris> -Chris Chris> remote: XML-RPC Error: : Chris> remote: not well-formed (invalid token) at line 1, column 5, byte 5: Chris> remote: cache/COMMIT1351972790.xml Chris> remote: ^ Chris> remote: at /usr/lib/perl5/vendor_perl/5.12.2/RPC/XML/Client.pm line 394 No, I get that as well. I believe it is related to the recently dead cia.vc stuff. It looks to be harmless though. -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: Build breakage with thumb2
>>>>> "Will" == Will Newton writes:
Will> Hi all,
Will> It looks like the below patch breaks the build when the compiler
Will> defines __thumb2__. I don't see how this patch was intended to work -
Will> arm_asm.h does not define __USE_BX__ and it does not seem suitable to
Will> include in C files. I would suggest the patch is reverted.
It's probably a good idea to CC Yann on this..
Will> commit 3862c65a05983b2b18cb7884a124a905828f7a18
Will> Author: Yann E. MORIN
Will> Date: Sun Jan 9 01:45:08 2011 +0100
Will> ARM: #include where __USE_BX__ is used
Will> The check for __USE_BX__ will be available in bits/arm_asm.h,
Will> so the latter must be included wherever the former is used.
Will> Signed-off-by: "Yann E. MORIN"
Will> Cc: Khem Raj
Will> Cc: Bernhard Reutner-Fischer
Will> Cc: Carmelo AMOROSO
Will> Signed-off-by: Khem Raj
Will> Build log:
Will> CC ldso/ldso/ldso.oS
Will> In file included from ./ldso/include/dl-defs.h:77:0,
Will> from ./ldso/include/dl-string.h:16,
Will> from ./ldso/include/ldso.h:48,
Will> from ldso/ldso/ldso.c:33:
Will> ./ldso/ldso/arm/dl-sysdep.h: In function 'elf_machine_load_address':
Will> ./ldso/ldso/arm/dl-sysdep.h:119:37: warning: taking address of
Will> expression of type 'void' [enabled by default]
Will> In file included from ldso/ldso/ldso.c:46:0:
Will> ldso/ldso/arm/elfinterp.c: In function '_dl_linux_resolver':
Will> ldso/ldso/arm/elfinterp.c:72:11: warning: assignment makes integer
Will> from pointer without a cast [enabled by default]
Will> ldso/ldso/arm/elfinterp.c: In function '_dl_do_reloc':
Will> ldso/ldso/arm/elfinterp.c:206:15: warning: assignment makes integer
Will> from pointer without a cast [enabled by default]
Will> ldso/ldso/arm/elfinterp.c:193:22: warning: variable 'def_mod' set but
Will> not used [-Wunused-but-set-variable]
Will> In file included from ./ldso/ldso/arm/dl-startup.h:10:0,
Will> from ldso/ldso/dl-startup.c:95,
Will> from ldso/ldso/ldso.c:87:
Will> ./include/bits/arm_asm.h: At top level:
Will> ./include/bits/arm_asm.h:6:1: error: expected identifier or '(' before
'.' token
Will> make: *** [ldso/ldso/ldso.oS] Error 1
Will> ___
Will> uClibc mailing list
Will> uClibc@uclibc.org
Will> http://lists.busybox.net/mailman/listinfo/uclibc
--
Bye, Peter Korsgaard
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
[PATCH-0.9.33] common/pread_write.c: unbreak on archs without __NR_pread64
Some archs (avr32 in particular) still doesn't define __NR_pread64, so we should fall back to __NR_pread if it isn't available. The code nicely checks for it, but then ends up hard coding the syscall to use __NR_pread64 afterwards, rendering the check useless. Fix it by using the result of the test instead. Signed-off-by: Peter Korsgaard --- Noticed when adding the pending patches for 0.9.33.3 to Buildroot: http://jenkins.free-electrons.com/job/buildroot/config=atstk100x_defconfig/116/console libc/sysdeps/linux/common/pread_write.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libc/sysdeps/linux/common/pread_write.c b/libc/sysdeps/linux/common/pread_write.c index b13de66..8562ab4 100644 --- a/libc/sysdeps/linux/common/pread_write.c +++ b/libc/sysdeps/linux/common/pread_write.c @@ -42,7 +42,7 @@ extern __typeof(pwrite64) __libc_pwrite64; #include -# define __NR___syscall_pread __NR_pread64 +# define __NR___syscall_pread __NR_pread static __inline__ _syscall5(ssize_t, __syscall_pread, int, fd, void *, buf, size_t, count, off_t, offset_hi, off_t, offset_lo) -- 1.7.10.4 ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH-0.9.33] common/pread_write.c: unbreak on archs without __NR_pread64
>>>>> "Peter" == Peter Korsgaard writes: Hi, Peter> Some archs (avr32 in particular) still doesn't define __NR_pread64, so Peter> we should fall back to __NR_pread if it isn't available. Peter> The code nicely checks for it, but then ends up hard coding the syscall Peter> to use __NR_pread64 afterwards, rendering the check useless. Fix it by Peter> using the result of the test instead. I noticed another critical issue on ARM EABI. The use of __LONG_LONG_PAIR for the offset doesn't take alignment requirement of 64bit parameters on EABI into consideration, so the offset is off by one register :/ https://lkml.org/lkml/2006/1/12/175 How should that be handled? -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH-0.9.33] common/pread_write.c: unbreak on archs without __NR_pread64
>>>>> "Peter" == Peter Korsgaard writes: Peter> Some archs (avr32 in particular) still doesn't define __NR_pread64, so Peter> we should fall back to __NR_pread if it isn't available. Peter> The code nicely checks for it, but then ends up hard coding the syscall Peter> to use __NR_pread64 afterwards, rendering the check useless. Fix it by Peter> using the result of the test instead. Peter> Signed-off-by: Peter Korsgaard Peter> --- Peter> Noticed when adding the pending patches for 0.9.33.3 to Buildroot: Peter> http://jenkins.free-electrons.com/job/buildroot/config=atstk100x_defconfig/116/console Ping? Peter> libc/sysdeps/linux/common/pread_write.c |2 +- Peter> 1 file changed, 1 insertion(+), 1 deletion(-) Peter> diff --git a/libc/sysdeps/linux/common/pread_write.c b/libc/sysdeps/linux/common/pread_write.c Peter> index b13de66..8562ab4 100644 Peter> --- a/libc/sysdeps/linux/common/pread_write.c Peter> +++ b/libc/sysdeps/linux/common/pread_write.c Peter> @@ -42,7 +42,7 @@ extern __typeof(pwrite64) __libc_pwrite64; Peter> #include Peter> -# define __NR___syscall_pread __NR_pread64 Peter> +# define __NR___syscall_pread __NR_pread Peter> static __inline__ _syscall5(ssize_t, __syscall_pread, int, fd, void *, buf, Peter> size_t, count, off_t, offset_hi, off_t, offset_lo) Peter> -- Peter> 1.7.10.4 -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH-0.9.33] common/pread_write.c: unbreak on archs without __NR_pread64
>>>>> "Peter" == Peter Korsgaard writes: Hi, Peter> Some archs (avr32 in particular) still doesn't define __NR_pread64, so Peter> we should fall back to __NR_pread if it isn't available. Peter> The code nicely checks for it, but then ends up hard coding the syscall Peter> to use __NR_pread64 afterwards, rendering the check useless. Fix it by Peter> using the result of the test instead. Peter> I noticed another critical issue on ARM EABI. The use of Peter> __LONG_LONG_PAIR for the offset doesn't take alignment requirement of Peter> 64bit parameters on EABI into consideration, so the offset is off by one Peter> register :/ Peter> https://lkml.org/lkml/2006/1/12/175 Peter> How should that be handled? Anybody? -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH-0.9.33] common/pread_write.c: unbreak on archs without __NR_pread64
>>>>> "Mike" == Mike Frysinger writes: Hi, >> I noticed another critical issue on ARM EABI. The use of >> __LONG_LONG_PAIR for the offset doesn't take alignment requirement of >> 64bit parameters on EABI into consideration, so the offset is off by one >> register :/ >> >> https://lkml.org/lkml/2006/1/12/175 >> >> How should that be handled? Mike> i introduced __UCLIBC_SYSCALL_ALIGN_64BIT__ to handle this case. Mike> and the pread/pwrite logic takes that into account. do you have Mike> information to indicate it isn't working ? Well, as the subject indicates this is for the 0.9.33 branch, where there isn't any ALIGN_64BIT. I haven't tried master yet (will do now), but it looks like this should get backported before 0.9.33.3. Mike> your e-mail client still sucks btw Sorry, in what way? -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH-0.9.33] common/pread_write.c: unbreak on archs without __NR_pread64
>>>>> "Mike" == Mike Frysinger writes: Hi, >> The code nicely checks for it, but then ends up hard coding the syscall >> to use __NR_pread64 afterwards, rendering the check useless. Fix it by >> using the result of the test instead. Mike> i think you should look at all the pread/pwrite changes in Mike> master. afaik, all issues are addressed there. Yes, possible. I'm trying to test the 0.9.33 branch to hopefully speed up the 0.9.33.3 release as there's quite some fixes pending, but it looks like some more stuff should get backported. Anybody else testing the branch? -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH-0.9.33] common/pread_write.c: unbreak on archs without __NR_pread64
>>>>> "Mike" == Mike Frysinger writes: Hi, > On Tuesday 15 October 2013 16:37:32 Peter Korsgaard wrote: Mike> your e-mail client still sucks btw >> >> Sorry, in what way? > the quoting style unreasonably mangles things The supercite 'name>' thing? I kind of like it, but I've turned it off for @uclibc.org. -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH-0.9.33] common/pread_write.c: unbreak on archs without __NR_pread64
>>>>> "Khem" == Khem Raj writes: Hi, >>>> The code nicely checks for it, but then ends up hard coding the >>>> syscall to use __NR_pread64 afterwards, rendering the check >>>> useless. Fix it by using the result of the test instead. >> Mike> i think you should look at all the pread/pwrite changes in Mike> master. afaik, all issues are addressed there. >> >> Yes, possible. I'm trying to test the 0.9.33 branch to hopefully speed >> up the 0.9.33.3 release as there's quite some fixes pending, but it >> looks like some more stuff should get backported. >> >> Anybody else testing the branch? > I would be interested if you try out latest master. Sorry for the slow response - I only now found time to do so. I'm happy to say that the pread issue ISN'T present on todays snapshot of master. So these pread/pwrite changes imho should get backported to to the 0.9.33 branch if we ever plan on doing a bugfix release from it. -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: Doing a release?
>>>>> "Bernhard" == Bernhard Reutner-Fischer writes: Hi, > So, consider current master tip -rc point buildroot to use > http://git.uclibc.org/uClibc/snapshot/uClibc-0e03ac5a6c4265fb4ddcdcbf5fdc9f20bcbef203.tar.bz2 > and verify if that works for the arches buildroot supports. I did a quick test build with todays snapshot on ARM and noticed that the posix_fadvise stuff doesn't build on !LFS: libc/sysdeps/linux/common/posix_fadvise.c:19:29: error: unknown type name 'off64_t' libc/sysdeps/linux/common/posix_fadvise.c:19:45: error: unknown type name 'off64_t' I'm not quite sure how to fix this. We can certainly s/off64_t/__off64_t/, but then we end up with linker errors: libc/libc_so.a(posix_fadvise.os): In function `posix_fadvise': posix_fadvise.c:(.text+0x1c): undefined reference to `posix_fadvise64' collect2: error: ld returned 1 exit status As posix_fadvise64.c never gets built because of: libc/sysdeps/linux/common/Makefile.in: CSRC_LFS := $(notdir $(wildcard $(COMMON_DIR)/*64.c)) So how to fix? Just rename posix_fadvise64.c? ;) -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] LT.old: Make errno_location thread safe
>>>>> "Vineet" == Vineet Gupta writes:
> [summary: Get rid of libc alias __GI___errno_location]
> It seems with Linuxthreads.old (yet to confirm NPTL) errno is not thread
> safe.
> A simple pthread linked test program (at the bottom) which makes a
> failing syscall e.g. open("/not-exist") fails to observe the right errno
> in the thread (main is OK)
> Conceptually uClibc defines weak __errno_location() while libpthread
> defines astrong variant. This arrangement shd work when using -pthread
> links. The spoil sport is __GI___errno_location, intended to bypass PLT
> for intra-libc callers. It gets called even in case of LT.old links
> given the syscall wrappers in libpthread (LT.old). e.g.
> open [ in libpthread ]
> pthreadsetcanceltype()
>__libc_open()
> __GI__open()
>...
> - __GI___errno_location[ existing ]
> + __errno_location [ intended ]
>
> pthreadsetcanceltype()
> So the solution is to get rid of GI alias for errno_location
> altogether.
That sounds pretty much like:
http://lists.uclibc.org/pipermail/uclibc/2010-July/044176.html
Which afaik never got committed.
--
Bye, Peter Korsgaard
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
