From owner-freebsd-current@FreeBSD.ORG Mon Sep 22 21:35:37 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 8802216A4B3 for ; Mon, 22 Sep 2003 21:35:37 -0700 (PDT) Received: from smtp.mho.com (smtp.mho.net [64.58.4.6]) by mx1.FreeBSD.org (Postfix) with SMTP id DF04544005 for ; Mon, 22 Sep 2003 21:35:34 -0700 (PDT) (envelope-from scottl@freebsd.org) Received: (qmail 51475 invoked by uid 1002); 23 Sep 2003 04:35:34 -0000 Received: from unknown (HELO freebsd.org) (64.58.1.252) by smtp.mho.net with SMTP; 23 Sep 2003 04:35:34 -0000 Message-ID: <3F6FCD7E.4070301@freebsd.org> Date: Mon, 22 Sep 2003 22:35:10 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: deischen@FreeBSD.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 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 04:35:37 -0000 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. Scott