From owner-freebsd-current@FreeBSD.ORG Tue Sep 23 06:53:25 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1D74B16A4B3; Tue, 23 Sep 2003 06:53:25 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id E4BBC43F85; Tue, 23 Sep 2003 06:53:23 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id h8NDrMgG003335; Tue, 23 Sep 2003 09:53:22 -0400 (EDT) Date: Tue, 23 Sep 2003 09:53:22 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Scott Long In-Reply-To: <3F6FCD7E.4070301@freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Doug Barton cc: Freebsd Current Subject: Re: Fixing -pthreads (Re: ports and -current) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: deischen@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2003 13:53:25 -0000 On Mon, 22 Sep 2003, Scott Long wrote: > Daniel Eischen wrote: > > This is about 3rd party applications built outside of > > ports. The only possible problem you are going to > > have is on the link command, and it should be obvious > > that you're missing a link to the threads library. > > This is trivial to fix. It's not like we're making > > someone change their code to accomodate library or > > kernel interface changes. > > > > This is exactly the case the is going to cause the problems, though. > For you, compiling a 3rd party app and dealing with failures in the > linker is easy to deal with. For someone else, it might not be. If > they go to compile an app and it compiles and runs fine on linux but > fails on FreeBSD with linker errors, it will likely leave a negative > impression in their mind. > > I'm comparing my arguments to linux because a lot more apps are written > with linux in mind than with solaris in mind these days. People who are > writing for linux or switching from linux might not know that > '-lpthread' is a requirement, but they are more likely to know that > '-pthread' will take care of all of that magic for them. This argument > really comes down to ease of use and user experience. Steering away > from de-facto standards steers us away from a positive user and > developer experience. > > I'm perfectly happy to support the libkse->libpthread switch, and I'm > perfectly happy to support making libpthread be the default threading > library. But, I strongly believe that we need to also treat -pthread > sanely. I stand by my opinion. Also, you may end up breaking more things if -pthread causes libpthread to be linked in. Applications that want to link with libthread (1:1), libc_r, or libthr and use -pthread with -lpthread1:1, -lc_r, or -lthr will break. And it won't be obvious until weird things happen when they run. You guys are assuming this is going to cause large problems. Just wait and see. -- Dan Eischen