Future branch status

Bernhard Reutner-Fischer rep.dot.nop at gmail.com
Tue Apr 24 14:57:14 UTC 2012


Peter,

On 24 April 2012 16:14, Bernhard Reutner-Fischer <rep.dot.nop at gmail.com> wrote:
> Peter,
>
> On 23 April 2012 19:49, Carmelo AMOROSO <carmelo.amoroso at st.com> wrote:
>> On 23/04/2012 18.12, Bernhard Reutner-Fischer wrote:
>>> On 21 April 2012 19:36, Khem Raj <raj.khem at gmail.com> wrote:
>>>> On Sat, Apr 21, 2012 at 1:37 AM, Bernhard Reutner-Fischer
>>>> <rep.dot.nop at gmail.com> wrote:
>>>>>
>>>>> Let's leave this out for the merge and look at it after the merge
>>>>> (unless you can fix it for the failing arches), ok?
>>>>>
>>>>> I'm going through the other commits during the weekend (I have a few
>>>>> remarks).
>>>>>
>>>>
>>>> Yes thats a good plan I think. However there are some cleanup fixes that
>>>> are sort of obvious and some bug fixes that we can safely take after testing
>>>
>>> My notes so far:
>>>
>>> include/sched.h: remove __clone{,2}
>>> libc/misc/internals/__uClibc_main.c: vis of __uclibc_progname? Why not hidden?
>>>                                    : _dl_skip_args only for SH ?!
>>
>> It depends on how the asm SH startup code handle __dl_skip_args, that it
>> is not aligned with other archs, when running in standalone-mode-
>>
>> Something we should look at, indeed. I'll discuss with my colleague.
>>
>>> libc/misc/internals/tempname.h: __gen_tempname duplicated in nptl.. vis public?
>>> libc/sysdeps/linux/arm/posix_fadvise.c: __NR___syscall_arm_fadvise64_64 ?
>>> "[PATCH 382/408] linuxthreads: use __UCLIBC_HAS_TLS__ consistently" impossible
>>>       impossible combo for __resp
>>> syslog.c: disable locking in setlogmask (why?)
>>> pread_write.c: endianess broken? if so use __LONG_LONG_PAIR() !
>
> I get alot of errors when compiling for x86_64 (i.e. 64bit), e.g.:
>
> libc/misc/dirent/versionsort.c:16:1: warning: return type defaults to
> 'int' [enabled by default]
> libc/misc/dirent/versionsort.c:16:1: warning: function declaration
> isn't a prototype [-Wstrict-prototypes]
> libc/misc/dirent/versionsort.c: In function 'strongs_alias_untyped':
> libc/misc/dirent/versionsort.c:16:1: warning: type of 'versionsort'
> defaults to 'int' [enabled by default]
> libc/misc/dirent/versionsort.c:16:1: warning: type of 'versionsort64'
> defaults to 'int' [enabled by default]
> libc/misc/dirent/versionsort.c:16:1: error: expected '{' at end of input
> libc/misc/dirent/versionsort.c:16:1: warning: control reaches end of
> non-void function [-Wreturn-type]
>
> In the respective commit, you write:
>
> versionsort*.c, alphasort*.c: do not need *64 compiled for __WORDSIZE = 64
>
> but for this to really happen one would, i think, have to say:
> diff --git a/libc/misc/dirent/versionsort.c b/libc/misc/dirent/versionsort.c
> index e298728..6269862 100644
> --- a/libc/misc/dirent/versionsort.c
> +++ b/libc/misc/dirent/versionsort.c
> @@ -12,6 +12,6 @@ int versionsort(const struct dirent **a, const
> struct dirent **b)
>  {
>        return strverscmp((*a)->d_name, (*b)->d_name);
>  }
> -#if defined __UCLIBC_HAS_LFS__ && __WORDSIZE == 64
> +#if defined __UCLIBC_HAS_LFS__ && __WORDSIZE != 64
>  strongs_alias_untyped(versionsort,versionsort64)
--------------^ ah, notice the surplus 's'
>  #endif
Still, the guard should check for "== 32", no?

>
> Since this also happens in other such places like below, i must be
> doing something wrong?
> Please elaborate how you meant the hunks above and below to work.
>
> fcntl{64,}.c: fix x86_64 && LFS duly:
> -#if defined __UCLIBC_HAS_LFS__ && (__WORDSIZE == 64 || !defined __NR_fcntl64)
> +#if defined __UCLIBC_HAS_LFS__ && (__WORDSIZE != 64 && defined __NR_fcntl64)

We should cleanup the wordsize checks to unify them so that the
correct thing is done
automatically if theoretical X128 functions would be added. Thoughts?
>
> thanks,


More information about the uClibc mailing list