From owner-freebsd-arch Sun Jan 28 20:20:13 2001 Delivered-To: freebsd-arch@freebsd.org Received: from green.dyndns.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id D7D6837B400; Sun, 28 Jan 2001 20:19:51 -0800 (PST) Received: from localhost (green@localhost [127.0.0.1]) by green.dyndns.org (8.11.1/8.11.1) with ESMTP id f0T4Jnf09875; Sun, 28 Jan 2001 23:19:49 -0500 (EST) (envelope-from green@FreeBSD.org) Message-Id: <200101290419.f0T4Jnf09875@green.dyndns.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Daniel Eischen Cc: arch@FreeBSD.org Subject: Re: libc_r badness In-Reply-To: Message from Daniel Eischen of "Sun, 28 Jan 2001 22:32:56 EST." From: "Brian F. Feldman" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 28 Jan 2001 23:19:36 -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Daniel Eischen 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? > > 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. -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message