On Friday 05 June 2009 07:36:48 Jeff Layton wrote: > Doing this now would add wider testing exposure for these codepaths and > help flush out bugs in TIRPC+IPV4 codepaths. OTOH, it means adding a > new library dependency for packagers, or they'll need to take the > conscious step to --disable-tirpc when they configure. or have the configure script dump a warning whenever libtirpc is not used ... > We could make it so that configure looks for libtirpc and if it's not > available, configures the build against legacy RPC interfaces. I think > this is a bad idea however. While it should "just work" either way, > there are some small behavioral differences when TIRPC support is built > in. I think it's probably better to make enabling and disabling TIRPC a > conscious step. i think this is the correct behavior for unspecified configure flags -mike
Attachment:
signature.asc
Description: This is a digitally signed message part.
