Re: [ANNOUNCE] 0.9.32-rc3 released
Have we fixed the bugs planned for 0.9.32 release? When do we plan to release 0.9.32, its been 2 months since rc3. Regards, Nitin ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [ANNOUNCE] 0.9.32-rc3 released
Hello All! On Tuesday 10 May 2011 18:38:32 Bernhard Reutner-Fischer wrote: We are shaking out some bugs still, but it will be released RSN (TM). Good! Once the release is out, I'll rebase and resubmit my ARM sub-arch selection removal. And then go on to other archs one by one. Probably MIPS firts, then i?86 and x86_64 as they are what I know a bit about. Then other archs as I understand what's going on. Regards, Yann E. MORIN. PS. Bernhard, sorry for the dup, sent to the list from an address I was not subscribed to. YEM. -- .-..--.. | Yann E. MORIN | Real-Time Embedded | /\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `.---: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL| v conspiracy. | '--^---^--^' ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [ANNOUNCE] 0.9.32-rc3 released
-Khem On May 12, 2011, at 10:36 AM, Yann E. MORIN yann.morin.1...@anciens.enib.fr wrote: Hello All! On Tuesday 10 May 2011 18:38:32 Bernhard Reutner-Fischer wrote: We are shaking out some bugs still, but it will be released RSN (TM). Good! Once the release is out, I'll rebase and resubmit my ARM sub-arch I have them already queued up here no need to rebase them selection removal. And then go on to other archs one by one. Probably MIPS firts, then i?86 and x86_64 as they are what I know a bit about. Then other archs as I understand what's going on. Regards, Yann E. MORIN. PS. Bernhard, sorry for the dup, sent to the list from an address I was not subscribed to. YEM. -- .-..--.. | Yann E. MORIN | Real-Time Embedded | /\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `.---: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL| v conspiracy. | '--^---^--^' ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [ANNOUNCE] 0.9.32-rc3 released
Khem, All, On Thursday 12 May 2011 23:19:05 Khem Raj wrote: On May 12, 2011, at 10:36 AM, Yann E. MORIN yann.morin.1...@anciens.enib.fr wrote: On Tuesday 10 May 2011 18:38:32 Bernhard Reutner-Fischer wrote: We are shaking out some bugs still, but it will be released RSN (TM). Good! Once the release is out, I'll rebase and resubmit my ARM sub-arch I have them already queued up here no need to rebase them Oh, Good! Thanks! :-) Regards, Yann E. MORIN. -- .-..--.. | Yann E. MORIN | Real-Time Embedded | /\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `.---: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL| v conspiracy. | '--^---^--^' ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [ANNOUNCE] 0.9.32-rc3 released
On Wed, May 11, 2011 at 12:23 AM, Rich Felker dal...@aerifal.cx wrote: On Tue, May 10, 2011 at 07:57:12PM +0100, Will Newton wrote: https://bugs.uclibc.org/2089 This is supposed to work just fine with NPTL. So is support for linuxthreads dropped with this release? It seems a shame when people are willing to support it. I hope so. Aside from pthread, is there any libc feature where an old, broken-by-design version is intentionally kept around and supported? Do we need an alternate stdio implementation where data in the buffers sometimes gets written or read twice under certain conditions? Do we need an alternate regex implementation that mixes up \(\) and ()? Do we need an alternate malloc that sometimes reserves too little memory and gives you heap corruption? LinuxThreads is *that* *broken*. Sure you could write a program using malloc that works around fatal bugs in malloc or a program using stdio that works around fatal bugs in stdio, but would you really want to put that out in a production environment? Why the same logic doesn't apply to threads is beyond me Well no, it isn't that broken. It was the default threading implementation on Linux for many years and has shipped in millions of devices that continue to work to this day, so from a POSIX lawyers point of view it may be broken but from a practical point of view it's a useful feature. Not all embedded architectures have full support for NPTL/TLS yet. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [ANNOUNCE] 0.9.32-rc3 released
Hi, We are shaking out some bugs still, but it will be released RSN (TM). On May 10, 2011 7:23 AM, Nitin Garg nitingar...@gmail.com wrote: ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [ANNOUNCE] 0.9.32-rc3 released
On Tue, May 10, 2011 at 5:38 PM, Bernhard Reutner-Fischer rep.dot@gmail.com wrote: Hi, We are shaking out some bugs still, but it will be released RSN (TM). Are there any plans to fix this bug? https://bugs.uclibc.org/2089 ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [ANNOUNCE] 0.9.32-rc3 released
On Tue, May 10, 2011 at 7:44 PM, Bernhard Reutner-Fischer rep.dot@gmail.com wrote: On Tue, May 10, 2011 at 05:49:02PM +0100, Will Newton wrote: On Tue, May 10, 2011 at 5:38 PM, Bernhard Reutner-Fischer rep.dot@gmail.com wrote: Hi, We are shaking out some bugs still, but it will be released RSN (TM). Are there any plans to fix this bug? https://bugs.uclibc.org/2089 This is supposed to work just fine with NPTL. So is support for linuxthreads dropped with this release? It seems a shame when people are willing to support it. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [ANNOUNCE] 0.9.32-rc3 released
On Tue, May 10, 2011 at 07:57:12PM +0100, Will Newton wrote: On Tue, May 10, 2011 at 7:44 PM, Bernhard Reutner-Fischer rep.dot@gmail.com wrote: On Tue, May 10, 2011 at 05:49:02PM +0100, Will Newton wrote: On Tue, May 10, 2011 at 5:38 PM, Bernhard Reutner-Fischer rep.dot@gmail.com wrote: Hi, We are shaking out some bugs still, but it will be released RSN (TM). Are there any plans to fix this bug? https://bugs.uclibc.org/2089 This is supposed to work just fine with NPTL. So is support for linuxthreads dropped with this release? It seems a shame when people are willing to support it. Thing is that you can only workaround it unless you have TLS. For arches that already have NPTL i suggest you use it. If folks find it clearer we can reflect that recommendation in the configury. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [ANNOUNCE] 0.9.32-rc3 released
On Tue, May 10, 2011 at 8:21 PM, Bernhard Reutner-Fischer rep.dot@gmail.com wrote: On Tue, May 10, 2011 at 07:57:12PM +0100, Will Newton wrote: On Tue, May 10, 2011 at 7:44 PM, Bernhard Reutner-Fischer rep.dot@gmail.com wrote: On Tue, May 10, 2011 at 05:49:02PM +0100, Will Newton wrote: On Tue, May 10, 2011 at 5:38 PM, Bernhard Reutner-Fischer rep.dot@gmail.com wrote: Hi, We are shaking out some bugs still, but it will be released RSN (TM). Are there any plans to fix this bug? https://bugs.uclibc.org/2089 This is supposed to work just fine with NPTL. So is support for linuxthreads dropped with this release? It seems a shame when people are willing to support it. Thing is that you can only workaround it unless you have TLS. For arches that already have NPTL i suggest you use it. If folks find it clearer we can reflect that recommendation in the configury. The patch in the bug from Peter works and I have yet to see a clear statement of what is wrong with it. Without the patch linuxthreads is pretty much unusable. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [ANNOUNCE] 0.9.32-rc3 released
Original-Nachricht Datum: Tue, 10 May 2011 21:21:13 +0200 Von: Bernhard Reutner-Fischer rep.dot@gmail.com An: Will Newton will.new...@gmail.com CC: uclibc@uclibc.org Betreff: Re: [ANNOUNCE] 0.9.32-rc3 released On Tue, May 10, 2011 at 07:57:12PM +0100, Will Newton wrote: On Tue, May 10, 2011 at 7:44 PM, Bernhard Reutner-Fischer rep.dot@gmail.com wrote: On Tue, May 10, 2011 at 05:49:02PM +0100, Will Newton wrote: On Tue, May 10, 2011 at 5:38 PM, Bernhard Reutner-Fischer rep.dot@gmail.com wrote: Hi, We are shaking out some bugs still, but it will be released RSN (TM). Are there any plans to fix this bug? https://bugs.uclibc.org/2089 This is supposed to work just fine with NPTL. So is support for linuxthreads dropped with this release? It seems a shame when people are willing to support it. Thing is that you can only workaround it unless you have TLS. For arches that already have NPTL i suggest you use it. If folks find it clearer we can reflect that recommendation in the configury. for the record, I will add TLS support in future branch (or master after release) for new linuxthreads (old LT won't be supported, since the changes are massive and I don't want to support this sort of compatibility). I consider new LT a config option, that was seldomly used, so it can be overworked to be more modern. Peter ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [ANNOUNCE] 0.9.32-rc3 released
Original-Nachricht Datum: Tue, 10 May 2011 20:31:12 +0100 Von: Will Newton will.new...@gmail.com An: Bernhard Reutner-Fischer rep.dot@gmail.com CC: uclibc@uclibc.org Betreff: Re: [ANNOUNCE] 0.9.32-rc3 released On Tue, May 10, 2011 at 8:21 PM, Bernhard Reutner-Fischer rep.dot@gmail.com wrote: On Tue, May 10, 2011 at 07:57:12PM +0100, Will Newton wrote: On Tue, May 10, 2011 at 7:44 PM, Bernhard Reutner-Fischer rep.dot@gmail.com wrote: On Tue, May 10, 2011 at 05:49:02PM +0100, Will Newton wrote: On Tue, May 10, 2011 at 5:38 PM, Bernhard Reutner-Fischer rep.dot@gmail.com wrote: Hi, We are shaking out some bugs still, but it will be released RSN (TM). Are there any plans to fix this bug? https://bugs.uclibc.org/2089 This is supposed to work just fine with NPTL. So is support for linuxthreads dropped with this release? It seems a shame when people are willing to support it. Thing is that you can only workaround it unless you have TLS. For arches that already have NPTL i suggest you use it. If folks find it clearer we can reflect that recommendation in the configury. The patch in the bug from Peter works and I have yet to see a clear statement of what is wrong with it. Without the patch linuxthreads is pretty much unusable. generally speaking of this sort of failures: - it would be better, if we would disable *hidden_proto/def/attribute_hidden for static builds (but that would mean double time for the build) Peter ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
RE: [ANNOUNCE] 0.9.32-rc3 released
This is obviously a safe option to fix this sort of static linking issues, and build time should never be a big issue. Can we go for it and merge into 0.9.32 release using this approach? And leave other more elegant solution in the future branch. It is better to have a solution, even if it is tentative, than leave it broken for 0.9.32 release, right? -Original Message- From: uclibc-boun...@uclibc.org [mailto:uclibc-boun...@uclibc.org] On Behalf Of Peter Mazinger Sent: Tuesday, May 10, 2011 2:35 PM To: uclibc@uclibc.org Subject: Re: [ANNOUNCE] 0.9.32-rc3 released Original-Nachricht Datum: Tue, 10 May 2011 20:31:12 +0100 Von: Will Newton will.new...@gmail.com An: Bernhard Reutner-Fischer rep.dot@gmail.com CC: uclibc@uclibc.org Betreff: Re: [ANNOUNCE] 0.9.32-rc3 released On Tue, May 10, 2011 at 8:21 PM, Bernhard Reutner-Fischer rep.dot@gmail.com wrote: On Tue, May 10, 2011 at 07:57:12PM +0100, Will Newton wrote: On Tue, May 10, 2011 at 7:44 PM, Bernhard Reutner-Fischer rep.dot@gmail.com wrote: On Tue, May 10, 2011 at 05:49:02PM +0100, Will Newton wrote: On Tue, May 10, 2011 at 5:38 PM, Bernhard Reutner-Fischer rep.dot@gmail.com wrote: Hi, We are shaking out some bugs still, but it will be released RSN (TM). Are there any plans to fix this bug? https://bugs.uclibc.org/2089 This is supposed to work just fine with NPTL. So is support for linuxthreads dropped with this release? It seems a shame when people are willing to support it. Thing is that you can only workaround it unless you have TLS. For arches that already have NPTL i suggest you use it. If folks find it clearer we can reflect that recommendation in the configury. The patch in the bug from Peter works and I have yet to see a clear statement of what is wrong with it. Without the patch linuxthreads is pretty much unusable. generally speaking of this sort of failures: - it would be better, if we would disable *hidden_proto/def/attribute_hidden for static builds (but that would mean double time for the build) Peter ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [ANNOUNCE] 0.9.32-rc3 released
Original-Nachricht Datum: Tue, 10 May 2011 23:35:29 +0200 Von: Peter Mazinger p...@gmx.net An: uclibc@uclibc.org Betreff: Re: [ANNOUNCE] 0.9.32-rc3 released Original-Nachricht Datum: Tue, 10 May 2011 20:31:12 +0100 Von: Will Newton will.new...@gmail.com An: Bernhard Reutner-Fischer rep.dot@gmail.com CC: uclibc@uclibc.org Betreff: Re: [ANNOUNCE] 0.9.32-rc3 released On Tue, May 10, 2011 at 8:21 PM, Bernhard Reutner-Fischer rep.dot@gmail.com wrote: On Tue, May 10, 2011 at 07:57:12PM +0100, Will Newton wrote: On Tue, May 10, 2011 at 7:44 PM, Bernhard Reutner-Fischer rep.dot@gmail.com wrote: On Tue, May 10, 2011 at 05:49:02PM +0100, Will Newton wrote: On Tue, May 10, 2011 at 5:38 PM, Bernhard Reutner-Fischer rep.dot@gmail.com wrote: Hi, We are shaking out some bugs still, but it will be released RSN (TM). Are there any plans to fix this bug? https://bugs.uclibc.org/2089 This is supposed to work just fine with NPTL. So is support for linuxthreads dropped with this release? It seems a shame when people are willing to support it. Thing is that you can only workaround it unless you have TLS. For arches that already have NPTL i suggest you use it. If folks find it clearer we can reflect that recommendation in the configury. The patch in the bug from Peter works and I have yet to see a clear statement of what is wrong with it. Without the patch linuxthreads is pretty much unusable. generally speaking of this sort of failures: - it would be better, if we would disable *hidden_proto/def/attribute_hidden for static builds (but that would mean double time for the build) another issue related to this (from __uClibc_main.c): /* Note: It is possible that any initialization done above could * have resulted in errno being set nonzero, so set it to 0 before * we call main. */ if (likely(not_null_ptr(__errno_location))) *(__errno_location()) = 0; /* Set h_errno to 0 as well */ if (likely(not_null_ptr(__h_errno_location))) *(__h_errno_location()) = 0; This code is IMHO wrong in __uClibc_main.c, it should not directly address __*errno_location, it should only use errno/h_errno, since these have different meanings depending on config options Peter ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [ANNOUNCE] 0.9.32-rc3 released
On Tue, May 10, 2011 at 07:57:12PM +0100, Will Newton wrote: https://bugs.uclibc.org/2089 This is supposed to work just fine with NPTL. So is support for linuxthreads dropped with this release? It seems a shame when people are willing to support it. I hope so. Aside from pthread, is there any libc feature where an old, broken-by-design version is intentionally kept around and supported? Do we need an alternate stdio implementation where data in the buffers sometimes gets written or read twice under certain conditions? Do we need an alternate regex implementation that mixes up \(\) and ()? Do we need an alternate malloc that sometimes reserves too little memory and gives you heap corruption? LinuxThreads is *that* *broken*. Sure you could write a program using malloc that works around fatal bugs in malloc or a program using stdio that works around fatal bugs in stdio, but would you really want to put that out in a production environment? Why the same logic doesn't apply to threads is beyond me Just my 2ยข... Rich ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [ANNOUNCE] 0.9.32-rc3 released
Hi All, When are we planning to release 0.9.32? What are we waiting on? Regards, Nitin On Wed, Mar 16, 2011 at 2:44 PM, Bernhard Reutner-Fischer rep.dot@gmail.com wrote: Hi, I'm happy to announce that we now have a 0.9.32-rc3. This is planned to be the last RC before the release which we aim at doing in 2 weeks, i.e end of March. Please test this release candidate and report back. Thanks alot to everybody who contributed and of course to those who reported bugs! Have fun, Bernhard PS: The changelog can be obtained by cloning our git repository $ git clone git://git.busybox.net/uClibc $ cd uClibc and running: $ git log v0.9.32-rc2..v0.9.32-rc3 ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [ANNOUNCE] 0.9.32-rc3 released
Rob Landley rland...@parallels.com wrote: On 03/16/2011 02:44 PM, Bernhard Reutner-Fischer wrote: Hi, I'm happy to announce that we now have a 0.9.32-rc3. This is planned to be the last RC before the release which we aim at doing in 2 weeks, i.e end of March. Please test this release candidate and report back. So in the Linux kernel, make V=1 gives you the actual command lines that make is calling. That's also how it works in uClibc 0.9.31. But now, make V=1 does... nothing that I can see. Instead to get the actual kernel command lines you have to say V=2. But if you feed V=2 to the kernel build, you get pages and pages of _why_ it's rebuilding each thing it's building, a flood of dependency information which makes the output pretty much unreadable. So uClibc used ot work like the kernel does, and no it no longer does, for no readily apparent reason. This broke my build scripts, or at least the ability to easily figure out why arm eabi and i686 are including libgcc_eh.a in their build but mips and arm-o abi aren't... Rob Hi Rob, V=1 is quiet plus defines. V=2 are verbatim commands. I don't know (nor care) what the kernel does for V=2 but if you want make to spit out dependency decisions then just run make -d -p or something. Note that we do _not_ use kbuild in uClibc, so please don't expect kbuild behaviour... ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [ANNOUNCE] 0.9.32-rc3 released
On 03/18/2011 09:25 AM, Bernhard Reutner-Fischer wrote: Rob Landley rland...@parallels.com wrote: On 03/16/2011 02:44 PM, Bernhard Reutner-Fischer wrote: Hi, I'm happy to announce that we now have a 0.9.32-rc3. This is planned to be the last RC before the release which we aim at doing in 2 weeks, i.e end of March. Please test this release candidate and report back. So in the Linux kernel, make V=1 gives you the actual command lines that make is calling. That's also how it works in uClibc 0.9.31. But now, make V=1 does... nothing that I can see. Instead to get the actual kernel command lines you have to say V=2. But if you feed V=2 to the kernel build, you get pages and pages of _why_ it's rebuilding each thing it's building, a flood of dependency information which makes the output pretty much unreadable. So uClibc used ot work like the kernel does, and no it no longer does, for no readily apparent reason. This broke my build scripts, or at least the ability to easily figure out why arm eabi and i686 are including libgcc_eh.a in their build but mips and arm-oabi aren't... Rob Hi Rob, V=1 is quiet plus defines. V=2 are verbatim commands. I don't know (nor care) what the kernel does So your build infrastructure (including make menuconfig and V=1) was copied from the Linux kernel, the previous release had a meaning that was compatible with the Linux kernel, and you decided to gratuitously change it because you don't care. for V=2 but if you want make to spit out dependency decisions then just run make -d -p or something. I don't want dependency decisions. I want V=1 to give me verbatim commands the ay it did in 0.9.31. You broke compatability with your _previous_release_. Note that we do _not_ use kbuild in uClibc, so please don't expect kbuild behaviour... I expected 0.9.31 behavior. Rob ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [ANNOUNCE] 0.9.32-rc3 released
On Fri, Mar 18, 2011 at 09:29:53AM -0500, Rob Landley wrote: On 03/18/2011 09:25 AM, Bernhard Reutner-Fischer wrote: Rob Landley rland...@parallels.com wrote: On 03/16/2011 02:44 PM, Bernhard Reutner-Fischer wrote: Hi, I'm happy to announce that we now have a 0.9.32-rc3. This is planned to be the last RC before the release which we aim at doing in 2 weeks, i.e end of March. Please test this release candidate and report back. So in the Linux kernel, make V=1 gives you the actual command lines that make is calling. That's also how it works in uClibc 0.9.31. But now, make V=1 does... nothing that I can see. Instead to get the actual kernel command lines you have to say V=2. But if you feed V=2 to the kernel build, you get pages and pages of _why_ it's rebuilding each thing it's building, a flood of dependency information which makes the output pretty much unreadable. So uClibc used ot work like the kernel does, and no it no longer does, for no readily apparent reason. This broke my build scripts, or at least the ability to easily figure out why arm eabi and i686 are including libgcc_eh.a in their build but mips and arm-oabi aren't... Rob Hi Rob, V=1 is quiet plus defines. V=2 are verbatim commands. I don't know (nor care) what the kernel does So your build infrastructure (including make menuconfig and V=1) was copied from the Linux kernel, the previous release had a meaning that was compatible with the Linux kernel, and you decided to gratuitously change it because you don't care. for V=2 but if you want make to spit out dependency decisions then just run make -d -p or something. I don't want dependency decisions. I want V=1 to give me verbatim commands the ay it did in 0.9.31. You broke compatability with your _previous_release_. Note that we do _not_ use kbuild in uClibc, so please don't expect kbuild behaviour... I expected 0.9.31 behavior. Perhaps V=0 could show quiet + defines, V=1 could show commands. That would give the new feature and be backwards compatible. Certainly completely changing an existing behaviour doesn't seem very nice. -- Len Sorensen ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [ANNOUNCE] 0.9.32-rc3 released
On Fri, Mar 18, 2011 at 10:57:36AM -0400, Lennart Sorensen wrote: Perhaps V=0 could show quiet + defines, V=1 could show commands. That would give the new feature and be backwards compatible. Certainly completely changing an existing behaviour doesn't seem very nice. So for example: diff --git a/Makefile.help b/Makefile.help index 1c2c96e..eef8937 100644 --- a/Makefile.help +++ b/Makefile.help @@ -46,7 +46,8 @@ help: @echo 'Environment variables:' @echo ' O=abspath- Use abspath as object directory' @echo ' V= - Quiet build (default)' - @echo ' V=1- Brief build (show defines, ld flags)' + @echo ' V=0- Brief build (show defines, ld flags)' + @echo ' V=1- Verbose build' @echo ' V=2- Very verbose build' @echo ' CROSS= - Override CROSS_COMPILER_PREFIX from .config' @echo ' ARCH= - Use given arch for config targets' diff --git a/Makerules b/Makerules index f045e52..e77e5a6 100644 --- a/Makerules +++ b/Makerules @@ -67,7 +67,7 @@ else export MAKE_IS_SILENT := n SECHO := @echo ifneq ($(V)$(VERBOSE),) -ifeq ($(V),1) +ifeq ($(V),0) DISP := bri# brief, like pur but with defines Q := @ else Not that I can see how V=1 and V=2 were different before. -- Len Sorensen ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [ANNOUNCE] 0.9.32-rc3 released
lsore...@csclub.uwaterloo.ca wrote: On Fri, Mar 18, 2011 at 09:29:53AM -0500, Rob Landley wrote: On 03/18/2011 09:25 AM, Bernhard Reutner-Fischer wrote: Rob Landley rland...@parallels.com wrote: On 03/16/2011 02:44 PM, Bernhard Reutner-Fischer wrote: Hi, I'm happy to announce that we now have a 0.9.32-rc3. This is planned to be the last RC before the release which we aim at doing in 2 weeks, i.e end of March. Please test this release candidate and report back. So in the Linux kernel, make V=1 gives you the actual command lines that make is calling. That's also how it works in uClibc 0.9.31. But now, make V=1 does... nothing that I can see. Instead to get the actual kernel command lines you have to say V=2. But if you feed V=2 to the kernel build, you get pages and pages of _why_ it's rebuilding each thing it's building, a flood of dependency information which makes the output pretty much unreadable. So uClibc used ot work like the kernel does, and no it no longer does, for no readily apparent reason. This broke my build scripts, or at least the ability to easily figure out why arm eabi and i686 are including libgcc_eh.a in their build but mips and arm-oabi aren't... Rob Hi Rob, V=1 is quiet plus defines. V=2 are verbatim commands. I don't know (nor care) what the kernel does So your build infrastructure (including make menuconfig and V=1) was copied from the Linux kernel, the previous release had a meaning that was compatible with the Linux kernel, and you decided to gratuitously change it because you don't care.for V=2 but if you want make to spit out dependency decisions then just run make -d -p or something. I don't want dependency decisions. I want V=1 to give me verbatim commands the ay it did in 0.9.31. You broke compatability with your _previous_release_.Note that we do _not_ use kbuild in uClibc, so please don't expect kbuild behaviour... I expected 0.9.31 behavior. Perhaps V=0 could show quiet + defines, V=1 could show commands. That would give the new feature and be backwards compatible. Certainly completely changing an existing behaviour doesn't seem very nice. -- Len Sorensen Hi, Sounds acceptable, I will change it accordingly. Thanks, ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [ANNOUNCE] 0.9.32-rc3 released
On Wed, Mar 16, 2011 at 8:44 PM, Bernhard Reutner-Fischer rep.dot@gmail.com 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
