bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 00/11] Android compatibility


From: Kevin Cernekee
Subject: Re: [PATCH 00/11] Android compatibility
Date: Wed, 11 Feb 2015 16:22:59 -0800

On Wed, Feb 11, 2015 at 4:12 PM, Paul Eggert <address@hidden> wrote:
> Thanks for doing all that work!  I pushed the first 10 patches and have
> a couple of comments.  I'll send a separate email about the 11th patch.
>
> Kevin Cernekee wrote:
>
>> FAIL: test-verify.sh
>> ====================
>>
>> compiler didn't detect verification failure 1
>> ...
>> test-verify is trying to perform compile-time checks.  Since I didn't
>> rebuild NDK to run natively on the ARM target, this failure is expected.
>
>
> I'm still puzzled by this failure.  If there's no native compiler, then when
> test-verify.sh calls 'make', 'make' should try to compile and this
> compilation should fail, so test-verify.sh should think that the compiler
> correctly failed (presumably after reporting the verification failure).  Why
> didn't that happen for you?

Probably because I told it to use /bin/true for the compiler ;-)

    make check CC=true am__mv=true

For whatever reason (timestamp confusion?), "make check" wanted to
recompile all of the tests after I transferred the directory to the
target over NFS.  This was the easiest way to avoid fighting with it.

>> test-localename is calling strdup() on a NULL pointer returned by
>> gl_locale_name_thread(), and crashing.  From reading
>> gl_locale_name_thread() it seems like NULL is a valid result.  Maybe we
>> need to change the test case to "return 77" on systems that are unaware
>> of locales?
>
>
> Yes, that sounds right.  Can you propose a patch along those lines?

OK.  Should I just check for NULL, or is there a better test that
would indicate that the locale support is completely absent?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]