From owner-svn-src-all@FreeBSD.ORG Thu May 27 05:44:38 2010 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9CD9F1065674; Thu, 27 May 2010 05:44:38 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from monday.kientzle.com (kientzle.com [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id 698E68FC13; Thu, 27 May 2010 05:44:38 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.3/8.14.3) id o4R5itMf021500; Thu, 27 May 2010 05:44:55 GMT (envelope-from kientzle@freebsd.org) Received: from horton.x.kientzle.com (fw2.kientzle.com [10.123.1.2]) by kientzle.com with SMTP id dv7v6nb3fwsgyf3fgsq66nfhme; Thu, 27 May 2010 05:44:54 +0000 (UTC) (envelope-from kientzle@freebsd.org) Message-ID: <4BFE06C3.6040704@freebsd.org> Date: Wed, 26 May 2010 22:44:35 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.23) Gecko/20100314 SeaMonkey/1.1.18 MIME-Version: 1.0 To: Kostik Belousov References: <201005251748.o4PHmI5T093246@svn.freebsd.org> <4BFD6F80.8030700@delphij.net> <20100526191502.GG83316@deviant.kiev.zoral.com.ua> In-Reply-To: <20100526191502.GG83316@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: svn-src-head@freebsd.org, Garrett Cooper , svn-src-all@freebsd.org, Rob Farmer , src-committers@freebsd.org Subject: Re: svn commit: r208545 - in head/release: amd64 i386 ia64 pc98 powerpc sparc64 sun4v X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 05:44:38 -0000 Kostik Belousov wrote: >> On 2010/05/26 11:47, Garrett Cooper wrote: >>> On Wed, May 26, 2010 at 11:28 AM, Rob Farmer wrote: >>>> Does the order of the libs entries matter? ... >>>> >>> In theory it shouldn't because the linker should be smart enough >>> to evaluate the dependencies and link everything properly, but our >>> copy of binutils isn't intelligent enough to determine the appropriate >>> order from what I've seen. > > Comments about "linker not being smart enough" are nonsense. In fact, library link ordering is quite critical in some places, since it allows you to override functions provided by later libraries. Many people use this to override the system malloc() (for debugging or code size purposes) by simply linking against another library before libc. I've also used this trick to override getpwnam() so as to avoid the 1/2 megabyte of libc networking code that gets pulled in by the standard implementation. Tim