From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933094AbbLVRqM (ORCPT ); Tue, 22 Dec 2015 12:46:12 -0500 Received: from shards.monkeyblade.net ([149.20.54.216]:53509 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932320AbbLVRqK (ORCPT ); Tue, 22 Dec 2015 12:46:10 -0500 Date: Tue, 22 Dec 2015 12:46:06 -0500 (EST) Message-Id: <20151222.124606.1694650787450943904.davem@davemloft.net> To: cmetcalf@ezchip.com Cc: linux-kernel@vger.kernel.org, viro@ZenIV.linux.org.uk, jmorris@namei.org, akpm@linux-foundation.org, sudipm.mukherjee@gmail.com Subject: Re: [PATCH] lib/clz_tab.c: put in lib-y rather than obj-y From: David Miller In-Reply-To: <1450806084-26727-1-git-send-email-cmetcalf@ezchip.com> References: <1450806084-26727-1-git-send-email-cmetcalf@ezchip.com> X-Mailer: Mew version 6.6 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Tue, 22 Dec 2015 09:46:10 -0800 (PST) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Chris Metcalf Date: Tue, 22 Dec 2015 12:41:24 -0500 > The clz table (__clz_tab) in lib/clz_tab.c is also provided as part > of libgcc.a, and many architectures link against libgcc. To allow > the linker to avoid a multiple-definition link failure, clz_tab.o > has to be in lib/lib.a rather than lib/builtin.o. The specific > issue is that libgcc.a comes before lib/builtin.o on vmlinux.o's > link command line, so its _clz.o is pulled to satisfy __clz_tab, > and then when the remainder of lib/builtin.o is pulled in to satisfy > all the other dependencies, the __clz_tab symbols conflict. By > putting clz_tab.o in lib.a, the linker can simply avoid pulling > it into vmlinux.o when this situation arises. > > The definitions of __clz_tab are the same in libgcc.a and in the > kernel; arguably we could also simply rename the kernel version, > but it's unlikely the libgcc version will ever change to become > incompatible, so just using it seems reasonably safe. > > Signed-off-by: Chris Metcalf No objections from me: Acked-by: David S. Miller