[linux-lvm] [lvm-devel] MUSL fun

[Zdenek Kabelac]

Dne 13.2.2016 v 20:22 Brendan Heading napsal(a):
> Bernd,
>
> [cc buildroot]
>
> Like you I'd been investigating this issue from the buildroot end.
> Since October I've had no spare time to look at buildroot fixes.
>
> I was hoping for an explanation about why LVM implemented the above
> behaviour, but I never got one, and I didn't fancy working on a patch
> that would never get accepted when other projects were more open ..
>
> I think the best approach is probably just to add the freopen() patch
> as Romain suggested and keep the patch available in buildroot in the
> hope that we can build support for LVM to accept it.
>
> Brendan
>
>
> On 13 February 2016 at 18:48, Bernd Kuhls <bernd.kuhls-zqRNUXuvxA0b1SvskN2V4Q at public.gmane.org> wrote:
>> Am Tue, 15 Sep 2015 17:43:58 +0100 schrieb Brendan Heading:
>>
>>> In theory a straightforward fix would be to do something like:
>>>
>>> if (!freopen(NULL, "r", stdin))
>>>       goto out;
>>>
>>> .. but I suspect there is a good reason why this isn't done. Can anyone
>>> shed any light on this ? If not I will submit a patch.
>>
>> Hi Brendan,
>>
>> the buildroot project also supports musl, the build of lvm2 fails due to
>> the problem you described. Did you find a working solution for the
>> problem? A patch I submitted to the buildroot project, based on patches I
>> found at the Alpinelinux project, raised some questions I am unable to
>> answer: http://patchwork.ozlabs.org/patch/573519/
>>
>> Regards, Bernd


Let's start from the beginning -

-- 
commands/toolcontext.c: In function 'create_toolcontext':
commands/toolcontext.c:1796:10: error: assignment of read-only variable 'stdin'
     stdin = new_stream;
-- 

So now - from where comes the idea  of  'stdin' being read-only variable ?
Looking at some POSIX spec e.g.:
http://pubs.opengroup.org/onlinepubs/009695399/functions/stdin.html

there is no sign of having this read-only var.

So what kind of OS this actually is ?


There is a reason from lvm2 implementation here - freopen() is not giving 
application full control over internal buffer allocation and we need to be 
sure we lock-in memory for critical section - and some glibc versions are 
allocating buffers here via 'mmap' call.

That said - there could be accepted a patch checking in configure  for
'read-only' stdin  - and using then #ifdef compilation that would
replace use of  internal lvm2 reopen code with libc function.

But the currently posted patch may possibly cause some other regressions.

Regards

Zdenek