<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>Hello Peter, <br>my concern is that if the file libc-symbols.h is patched like this:<br><br>#if defined(__OPTION_EGLIBC_LOCALE_CODE) && __OPTION_EGLIBC_LOCALE_CODE<br># define HAVE_MBSTATE_T 1<br># define HAVE_MBSRTOWCS 1<br>#endif<br><br>then it will be ALWAYS evaluated as: <br><br>#if 0<br># define HAVE_MBSTATE_T 1<br># define HAVE_MBSRTOWCS 1<br>#endif<br><br>because<br><br>#if defined __OPTION_EGLIBC_LOCALE_CODE<br><br>will always evaluate as 0.<br><br>To test this hypothesis, I actually build core-image-minimal with<br>an explicit #error:<br><br>#if defined(__OPTION_EGLIBC_LOCALE_CODE) && __OPTION_EGLIBC_LOCALE_CODE<br># error "I was wrong in my assumptions!!!"<br># define HAVE_MBSTATE_T 1<br># define HAVE_MBSRTOWCS 1<br>#endif<br><br>The image built fine, (Though I did not build/ran the glibc testsuite yet, nor did I try <br>to build tiny-poky). <br><br>I believe the purpose of this patching is simply to unconditionally prevent <br>suppport for mutibyte character handling if __OPTION_EGLIBC_LOCALE_CODE=0 <br>If this is indeed the case, then the files posix/fnmatch.c and (possibly posix/fnmatch_loop.c<br>may need revised patching. ).<br><br>Juro<br><br><br><div>> Date: Wed, 19 Nov 2014 14:09:33 -0600<br>> From: peter.seebach@windriver.com<br>> To: jurobystricky@hotmail.com<br>> CC: openembedded-core@lists.openembedded.org<br>> Subject: Re: [OE-core] [PATCH 1/1] eglibc-use-option-groups.patch: Several fixups<br>> <br>> On Wed, 19 Nov 2014 17:59:49 +0000<br>> Juro Bystricky <jurobystricky@hotmail.com> wrote:<br>> <br>> > I am not sure why the HAVE_MBSTATE_T needs to be conditioned at all, my<br>> > understanding is<br>> > it is defined if the file <wchar.h> contains type definition "mbstate_t".<br>> > This typedef either exists or not and saying it not exists when in fact <br>> > it does might be confusing (as it already is for me) and I don't see any <br>> > relation with __OPTION_EGLIBC_LOCALE_CODE.<br>> <br>> If it's not conditional, the build fails when the feature's not included,<br>> because one of the test programs attempts to use it. It may be that something<br>> else ought to be conditional to make that work. So it might be that your<br>> suggested change to fnmatch would fix poky-tiny as well.<br>> <br>> And you're right about the .out.<br>> <br>> -s<br>> -- <br>> Listen, get this. Nobody with a good compiler needs to be justified.<br></div> </div></body>
</html>