Re: stdioext on musl

[Rich Felker]

On Sun, Jun 17, 2012 at 03:44:16PM -0700, Paul Eggert wrote:
> > will configure even find them?
> 
> Yes, it can be made to find them, as part of gnulib.

I mean will it find them without needing a special macro like
__MUSL__?

> This is a pragmatic approach that works well in practice.  Bruno has
> ported it to musl too, which is a good thing.  It would be nicer if
> the port used "approved" musl interfaces, but if musl can't or won't

I already said, if gnulib can find and use these interfaces by testing
that they exist and work, rather than by asking "is this musl?", I'm
(reluctantly) willing to add them. Mainly because I'd like to be done
with the "fighting with gnulib" issue that's made trouble for me and
my userbase from day one...

> do that we'll just have to continue to poke under musl's covers to get
> the behavior that we want, just like we do with many other libraries.
> If these libraries change in the future, gnulib will too.  But it would

Please don't do this. I'd rather just keep private interfaces private
by having civil discussions with developers who try to use them and
finding a mutually agreeable alternative, but if software starts
seriously trying to use musl internals, I'm going to update the build
process to make them all hidden and then a new solution will be
required anyway. This isn't for the sake of fighting; it's because I
don't want users' systems to break when they upgrade libc and suddenly
a lot of software aborts with dynamic linking errors because it was
using a private symbol that was exposed for a long time then later
changed or removed...

> be better if musl provided better interfaces for this useful functionality;
> as that would make gnulib-based applications more likely to port to
> future musl implementations without hassle.

Can you explain what you mean? By "better interfaces" do you mean the
4 already-mentioned stdio extension functions, or something else?

Rich