From owner-freebsd-ports@FreeBSD.ORG Tue Mar 7 20:54:59 2006 Return-Path: X-Original-To: ports@freebsd.org Delivered-To: freebsd-ports@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4717516A420 for ; Tue, 7 Mar 2006 20:54:59 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id A778943D45 for ; Tue, 7 Mar 2006 20:54:58 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (localhost.xcllnt.net [127.0.0.1]) by ns1.xcllnt.net (8.13.4/8.13.4) with ESMTP id k27KstKV012051; Tue, 7 Mar 2006 12:54:57 -0800 (PST) (envelope-from marcel@ns1.xcllnt.net) Received: (from marcel@localhost) by ns1.xcllnt.net (8.13.4/8.13.4/Submit) id k27Kstbb012050; Tue, 7 Mar 2006 12:54:55 -0800 (PST) (envelope-from marcel) Date: Tue, 7 Mar 2006 12:54:55 -0800 From: Marcel Moolenaar To: pfgshield-freebsd@yahoo.com Message-ID: <20060307205455.GA11840@ns1.xcllnt.net> References: <20060307192606.GA56153@xor.obsecurity.org> <20060307195849.70339.qmail@web32714.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060307195849.70339.qmail@web32714.mail.mud.yahoo.com> User-Agent: Mutt/1.4.2.1i Cc: ports@freebsd.org, Kris Kennaway Subject: Re: amd64 and -fPIC X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2006 20:54:59 -0000 On Tue, Mar 07, 2006 at 08:58:49PM +0100, pfgshield-freebsd@yahoo.com wrote: > > An honest question: I would like to know what other modern architectures > require this, I heard (but I'm not sure) that it's a consequence of the > architecture running both 64 and 32 bit code so.. SPARC64 and ia64 need it too? Yes, ia64 has the same link constraints. I don't think sparc64 has the same problems, but that doesn't mean anything. A shared object has to be position independent and any object files that constitute the shared object have to be constructed in such a way. For C/C++ and GCC this means that -fPIC is required. Some platforms (i.e. i386) don't generate different code for -fPIC, so the omission of -fPIC when it is necessary doesn't result in problems. This is just a quirk of the platform, not the norm. Also, linking an archive library into a shared object is perfectly valid, provided of course that all object files in the archive library are compiled for inclusion in a shared object. This of course means that they must be position independent and thus compiled with -fPIC (or equivalent). As such, you must determine up front for what purpose you create an archive library (linking into an executable or linking into a shared object) or create 2 variants: one non-PIC and one PIC. A generic port that only builds archive libraries better be PIC to cover all bases. Performance cannot really be a concern when you're working with generic parts. If performance is a concern, customization is pretty much a given and the use of generic parts is almost always abandoned. The kicker: With the introduction of the __thread keyword to define thread local storage, i386 now also requires the correct use of -fPIC, because the code generated for thread local storage is different for PIC and non-PIC. As far as I know, *NO* architecture can link shared objects without proper use of -fPIC when thread local storage is to be considered. Beware!!!!! -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net