This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch] Adding fedfs to /etc/rpc


On 3/8/2012 7:01 AM, Joseph S. Myers wrote:
> On Thu, 8 Mar 2012, Ulrich Drepper wrote:
>
>> On Wed, Mar 7, 2012 at 07:42, Joseph S. Myers <joseph@codesourcery.com> wrote:
>>> I think making libtirpc a build dependency is bad - in general circular
>>> dependencies should be avoided where possible - as it makes bootstrapping
>>> unduly hard.
>> Some people goal to do everything themselves by bootstrapping an
>> entire system cannot possibly be allowed to have any influence on the
>> design.  All that counts is the flexibility and robustness of the
>> system.
> In my view, flexibility and robustness includes build system flexibility 
> and robustness for a wide range of uses to which people wish to put glibc.  
> And it improves flexibility and robustness to have clean interfaces with 
> good support for building pieces separately rather than having circular 
> dependencies.  That's not just about NSS modules and libtirpc; there are 
> several other ways in which I think it would be good to split up the 
> source tree and build.
>
> Given the disagreements, we should clearly seek a wider range of opinions 
> to get a rough community consensus on the way to handle this.

Speaking for the tile architecture (and in general, I suspect, for any
architecture where at least some initial cross-building for the
architecture makes sense), I heartily endorse Joseph's recent work at
starting to disentangle the glibc build from the build environment.  (See
the complicated and unaesthetic "gcc and glibc from scratch" section of
http://www.tilera.com/scm/source.html where we document how to build our
environment, for example.)

> You can have NSS modules that are maintained by the glibc developers, but
> in a separate repository and released at the same time in separate
> glibc-nss tarballs, built separately rather than as part of the glibc
> build. That way glibc developers can update them as desired for new
> interfaces, without having circular build dependencies. I think that
> would address both our concerns. 

This suggestion strikes me as eminently reasonable.  Presumably the basic
"file" and "dns" support would remain in glibc as a necessary part of
bootstrapping up to be able to build the other NSS modules.

-- 
Chris Metcalf, Tilera Corp.
http://www.tilera.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]