Re: gnulib cross-compiling issue with musl

[Rich Felker <dalias@aerifal.cx>]

On Tue, Jun 18, 2013 at 11:32:50AM -0700, Paul Eggert wrote:
> On 06/18/13 11:07, Rich Felker wrote:
> 
> > Of my two
> > proposed fixes, the first would fix the issue on any future system
> > that's not broken (not just existing ones), but would obviously not
> > support future broken systems.
> 
> But we're not talking about "future" systems here; we're merely talking
> about unported-to systems, not all of which are future systems.
> 
> Nor are we talking about "broken" systems; we're merely talking about
> systems that do not conform to POSIX -- they may conform to C11, say,
> without conforming to POSIX.
> 
> So this first fix sounds problematic.

I think the advent of new implementations that don't aim for at least
a reasonable level of POSIX compatibility is fairly unlikely. But if
you think it matters, you could add #elif defined _POSIX_VERSION
containing the if(0), and leave #else at the end with #error. This
should be entirely safe.

> > The second proposed fix should support
> > any future system, but would be a bit more costly, assuming it's even
> > possible.
> 
> That would be better, yes.  But it'd be more work to implement than
> method (3) would be.

I agree that it would be more work, but if you really don't accept
solution #1, I'd be happy to work with the gnulib team on figuring out
what solution #2 would entail, whether it's possible, and implementing
it.

> > To revisit why I don't like your proposed fix, for every bug we could
> > get fixed by making an easy way for applications to test "is this
> > musl?", we would have something like 10 new bugs created by people
> > doing that. This is not just speculation; it's based on questions we
> > get on the list and on IRC. Your idea of using such a test in the form
> > of "if (is_musl) assume_non_broken();" is the first proposed use of
> > this form I've seen. Every other request for an easy "if (is_musl)"
> > test have been from people who wanted to do something that would cause
> > bad breakage with future versions of musl.
> 
> I'm afraid I don't follow this reasoning.  Are you saying that,
> method (3) is OK here but its use here might encourage people
> to use it in other places where it's not OK?  If so, let's add
> a comment warning people to use method (3) carefully.

I'm saying that musl intentionally does not provide any macros to
identify itself. Changing this to help gnulib do one correct thing
would not be worth dealing with all the incorrect usages it would lead
to. And I'm confident that presence of such a macro would lead to lots
of bugs in lots of applications, and to people blaming us for changing
things when such incorrect applications break, on the basis of all the
requests we have received from users for a __MUSL__ macro. In every
case, we have been able to recommend clean portable solutions that did
not involve hard-coding assumptions about musl.

The same issue was discussed in the thread on musl and gnulib
compatibility last year, and we reached mutually acceptable
conclusions: instead of adding __MUSL__ and documenting ways for
gnulib to poke at stdio internals (which are documented by musl as
being subject to change between versions and not acceptable for
applications to poke at), we added functions like __freadahead etc.
and gnulib is simply probing for their existence.

Rich