Static build errors with pthread

2015-10-07 Thread James B 
Commit 2156e228537065f04e5f862e186421df0db36612 (Makefile.flags: survive a 
build system which has no pthread) doesn't fully fix the problem introduced 
bb2fd67d0bfe16441d4b1d2e6ece83b04955b379 (unconditional inclusion of pthread).

The test included in that commit only tests for dynamic linking of pthread; and 
if it works, pthread is added to LDLIBS. 

Unfortunately, there are (buggy) toolchains where dynamic linking of pthread 
library works fine but static linking fails; e.g. 
http://lists.uclibc.org/pipermail/uclibc-cvs/2015-May/031562.html. In this 
case, because the test succeeds, the build will continue until the final 
linking stage where it bombs out with duplicate symbols for setresgid and 
setresuid.

I don't know how prevalent these toolchains are; I use the one from Aboriginal 
Linux and I am able to reproduce the error from the latest release (Sep 2015) 
back to releases from two years ago. Yet I've been able to build busybox with 
these toolchains until very recently.

My own fix includes commenting out that entire block of #ifdefs because I don't 
need to use pthread (apparently only PAM code requires that); but the better 
fix would be to make the test follows the configuration - if static build is 
specified then test static pthread linking; if shared build is specified then 
test for dynamic linking.

cheers!

-- 
James B 
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] fix hush umask command

2015-10-07 Thread Denys Vlasenko 
On Wed, Oct 7, 2015 at 6:44 AM, Rich Felker  wrote:
> On Wed, Oct 07, 2015 at 12:31:15AM -0400, Rich Felker wrote:
>> The hush umask command is backwards; umask 022 sets the umask to 0755.
>> Attached patch should fix it.
>>
>> Rich
>
>> diff --git a/shell/hush.c b/shell/hush.c
>> index 96c739f..58c8dab 100644
>> --- a/shell/hush.c
>> +++ b/shell/hush.c
>> @@ -8956,9 +8956,7 @@ static int FAST_FUNC builtin_umask(char **argv)
>>   if (argv[0]) {
>>   mode_t old_mask = mask;
>>
>> - mask ^= 0777;
>>   rc = bb_parse_mode(argv[0], );
>> - mask ^= 0777;
>>   if (rc == 0) {
>>   mask = old_mask;
>>   /* bash messages:
>
> Hmm, this may break symbolic umask specs, a feature I've never seen
> used and wasn't aware even existed. I might look into it more later
> but it would be great if someone who already knows this stuff could
> figure it out and work out a correct patch.

Fixed in git, thanks!
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: find . -delete gives an error message for the . directory entry

2015-10-07 Thread Denys Vlasenko 
On Fri, Sep 25, 2015 at 5:01 PM, Ari Sundholm  wrote:
> Hello!
>
> Busybox (git HEAD) seems to give an error when doing a "find . -delete"
> within a directory:
>
> -->8-
> ~/busybox/foobarbaz$ ls
> ~/busybox/foobarbaz$ find
> .
> ~/busybox/foobarbaz$ find . -delete
> ~/busybox/foobarbaz$ echo $?
> 0
> ~/busybox/foobarbaz$ ../busybox find . -delete
> find: .: Invalid argument
> ~/busybox/foobarbaz$ echo $?
> 0
> -->8-
>
> This error is not given by the findutils version, as shown above.
> Strangely enough, the error is not reflected in the return value. This
> happens also when the directory is non-empty.

Fixed in git - now rmdir(".") will be silently skipped.
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox