Date: Mon, 29 Jan 2001 07:47:41 -0500 (EST) From: Daniel Eischen <eischen@vigrid.com> To: "Brian F. Feldman" <green@FreeBSD.org> Cc: arch@FreeBSD.org Subject: Re: libc_r badness Message-ID: <Pine.SUN.3.91.1010129074038.24975A-100000@pcnet1.pcnet.com> In-Reply-To: <200101290419.f0T4Jnf09875@green.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 28 Jan 2001, Brian F. Feldman wrote: > Daniel Eischen <eischen@vigrid.com> wrote: > > [ Why is this developers and not -current??? ] > > (Actually, it should be -arch. That's a lapse in my judgement. Moving > there...) > > > On Sun, 28 Jan 2001, Brian F. Feldman wrote: > > > The only problem I have is that libc_r still doesn't depend on libc, so ALL > > > old apps that are linked in what was previously the correct way immediately > > > break. However, chances are it's so hard to make a correctly compiled old > > > binary with just libc_r and not libc, there are likely to be many that don't > > > break ;) > > > > John Polstra made the -pthread option work for the new libc_r (so it > > automatically links in both libc_r and libc) a few days ago. This option > > should be deprecated eventually, so one shouldn't get used to it. But > > this will allow ports that haven't been modified yet to continue to work. > > > > This is -current, and a HEADS UP was sent saying that you have to rebuild > > your threaded apps. > > It's breaking it gratuitiously though. What's the reasoning behind not > having libc_r depend on libc? You can't use libc_r without libc, and you > certainly would have to go through a hell of a lot of trouble to replace > libc with something libc_r would link with. What good does libc_r do > linking standalone? This is true, but it still seems like another band-aid. The version bump in -current is only 2 months old. It's not like this is -stable and affecting a large user base. > > > Is there a good reason not to do this? > > > > Yes, because libc_r shouldn't contain libc. That was the whole point > > of the changes I recently made to libc and libc_r. > > That doesn't make it contain libc. It makes it depend on libc. Tell me, > why can't libc_r depend on libc, and what good does libc_r do without libc? > And, if libc_r is useless without libc, why can't it depend on libc > automatically? I still see the same benefit of having libc be modular > whether or not libc_r sticks it in the ELF library dependency section for > its own use. Libpthread does not depend on libc under Solaris. I am still against this change. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SUN.3.91.1010129074038.24975A-100000>