This is the mail archive of the
mailing list for the glibc project.
Re: Support installing headers for bootstrapping libgcc
> * Put ldconfig (and sln, if kept at all) in a separate package -
> maintained by glibc maintainers, released at the same time, but with its
> own source tree, not part of the libc source tree, and configured and
> built with an installed compiler and glibc.
I'm not at all comfortable with doing that for something so closely tied
to libc-internal data formats. Let's see if we can solve the practical
problems without going that route. We can always reconsider later.
> Splitting out miscellaneous installed executables like that can be seen as
> part of disentangling and simplifying builds; if something doesn't have a
> clear need to be built at the same time as libc, building with a complete
> installed compiler and libc is certainly simpler than building against an
> uninstalled libc, and if something can be a "normal" application rather
> than being "special" as part of glibc, I'd rather it was a normal
I totally buy this for e.g. zic and memusagestat. I see the point for
localedef and locale, though that is a harder sell because of the close
integration with a file format not specified anywhere outside of libc.
ldconfig is such a crucial special case that I don't think it makes
nearly as much sense.
> I'll look further into stubbing these things out for ldconfig and sln.
Thanks very much! I still think we should be going toward dropping sln.
There's just nothing about it that couldn't be adequately handled with a
statically-linked program in some other package like coreutils or
util-linux or whatever. And, it probably goes without saying, but none
of this seems like a priority for 2.16 (though it may well be simple
enough that there's no special reason to wait if you have the cycles to