Matthew Dillon wrote:
:At some point, are we going to want to remove libc_r as part of the :upgrade process? (I'm assuming that's going to force recompilation of :many 3rd-party apps). I can imagine it can make troubleshooting more :difficult if we're going to have some people with libc_r and libthread_xu :and it won't have been a conscious decision in either case.Well, we have libpthread.so which is what all recently compiled programs should be linked against, so no new builds will ever be directly linked to libc_r any more (or shouldn't be). This means we can simply relink libpthread.so to libthread_xu (i.e. have 'make upgrade' do that), declare libc_r deprecated, and stop building and installing it. Doing that now, in HEAD, might be a good idea.
I don't see any benefit in removing libc_r. Maybe somebody wants to use it for certain things. I'd just keep it around.
cheers simon -- Serve - BSD +++ RENT this banner advert +++ ASCII Ribbon /"\ Work - Mac +++ space for low €€€ NOW!1 +++ Campaign \ / Party Enjoy Relax | http://dragonflybsd.org Against HTML \ Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \
