Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262671AbTEOFaL (ORCPT ); Thu, 15 May 2003 01:30:11 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S263340AbTEOFaL (ORCPT ); Thu, 15 May 2003 01:30:11 -0400 Received: from pizda.ninka.net ([216.101.162.242]:34721 "EHLO pizda.ninka.net") by vger.kernel.org with ESMTP id S262671AbTEOFaK (ORCPT ); Thu, 15 May 2003 01:30:10 -0400 Date: Wed, 14 May 2003 22:42:14 -0700 (PDT) Message-Id: <20030514.224214.42791773.davem@redhat.com> To: jmorris@intercode.com.au Cc: alex14641@yahoo.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: link error building kernel with gcc-3.3 From: "David S. Miller" In-Reply-To: References: <20030514202941.39519.qmail@web40503.mail.yahoo.com> X-FalunGong: Information control. X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 863 Lines: 26 From: James Morris Date: Thu, 15 May 2003 15:38:15 +1000 (EST) I wonder, does this mean that the compiler failed to inline the function? Removing __inline__ is not the correct solution. I already posted what the correct fix is :-) And this is already pushed to 2.5.x Inlining is not guarenteed, and: extern inline ... foo(...) means "inline if you can, I have a compiled-in implementation in some object somewhere" whereas: static inline ... foo(...) means "inline if you can, if there is a case where you cannot emit this as a function into the current module" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/