On Apr 21, 12:54am, Bill Studenmund wrote:
} On Fri, 4 Jan 2002, John Nemeth wrote:
} > On Apr 20, 10:58pm, Bill Studenmund wrote:
} 
} > } While I agree the need for such things won't be common, the places where
} > } they will be needed will probably have a hard requirement. So if we can,
} > } being able to add modules to an otherwise static init would be nice.
} >
} >      Personally, I would like to see option 2 (static programs being
} > able to use dlopen()).  That sounds like the most complete and correct
} > solution to me.  And, it would certainly solve this problem (i.e. init
} > would be statically linked, but it could pull in an authentication
} > module if really needed).  It also makes the system recovery problem go
} > away.  However, I expect based on what I have seen so far, we'll be
} > going to full dynamic linking.
} 
} From what I gather, adding dlopen() to static will cause lots of problems
} as the ELF spec doesn't like it. So unfortunatly it's not really an
} option. :-(

     I thought NetBSD was about doing the "right" thing first, and
following specs second.  I realise that certain specs are needed for
interoperability such as POSIX and TCP/IP, however ELF doesn't fall in
that category.  I do realise that using something like ELF gives the
ability to use precanned tools such as GCC, GDB, Binutils, etc. instead
of having to roll our own, as well as making it easier to handle
binaries from other OSes.  However, is there any reason that we need to
adhere to this particular aspect of the ELF spec?  So far, the only
objection I have seen is the problem with conflicts between dynamic
symbols and static symbols.  Is this really a showstopper?  Is there
any other technical reason (following specs is a political reason) that
it can't be done?

}-- End of excerpt from Bill Studenmund