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
