From owner-freebsd-current@FreeBSD.ORG Mon Sep 22 22:18:55 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 9075416A4B3; Mon, 22 Sep 2003 22:18:55 -0700 (PDT) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9F61844001; Mon, 22 Sep 2003 22:18:54 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) h8N5IsOH099497; Mon, 22 Sep 2003 22:18:54 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost)h8N5IsV3099496; Mon, 22 Sep 2003 22:18:54 -0700 (PDT) (envelope-from sgk) Date: Mon, 22 Sep 2003 22:18:54 -0700 From: Steve Kargl To: Scott Long Message-ID: <20030923051854.GA99363@troutmask.apl.washington.edu> References: <3F6FCD7E.4070301@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F6FCD7E.4070301@freebsd.org> User-Agent: Mutt/1.4.1i cc: deischen@freebsd.org 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 05:18:55 -0000 On Mon, Sep 22, 2003 at 10:35:10PM -0600, 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. > If the behavior of -pthread is documented in the man pages, then your argument holds no water. If the link stage fails, one would hope that the user can read the documention. -- Steve