From owner-svn-ports-head@freebsd.org Thu Feb 16 19:11:03 2017 Return-Path: Delivered-To: svn-ports-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 117E4CE080E; Thu, 16 Feb 2017 19:11:03 +0000 (UTC) (envelope-from tijl@freebsd.org) Received: from mailrelay102.isp.belgacom.be (mailrelay102.isp.belgacom.be [195.238.20.129]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (Client CN "relay.skynet.be", Issuer "GlobalSign Organization Validation CA - SHA256 - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A48221500; Thu, 16 Feb 2017 19:11:01 +0000 (UTC) (envelope-from tijl@freebsd.org) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2BTAwC+96VY/1fag21eGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgygpQRAQeBGNYXKRHSkBlQmCDCqFeAKCDkAYAQIBAQEBAQEBYiiEcQE?= =?us-ascii?q?FOhwjEAsOBAYJGgsPKhAOBhOJcAqzBItUAQEBAQEBAQMBAQEBAQEBIYs7gxeHI?= =?us-ascii?q?gWbf4Zwixp2gWWOOEiSUB84gQA0KgiFOYFJPzUBijYBAQE?= X-IPAS-Result: =?us-ascii?q?A2BTAwC+96VY/1fag21eGgEBAQECAQEBAQgBAQEBgygpQRA?= =?us-ascii?q?QeBGNYXKRHSkBlQmCDCqFeAKCDkAYAQIBAQEBAQEBYiiEcQEFOhwjEAsOBAYJG?= =?us-ascii?q?gsPKhAOBhOJcAqzBItUAQEBAQEBAQMBAQEBAQEBIYs7gxeHIgWbf4Zwixp2gWW?= =?us-ascii?q?OOEiSUB84gQA0KgiFOYFJPzUBijYBAQE?= Received: from 87.218-131-109.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([109.131.218.87]) by relay.skynet.be with ESMTP; 16 Feb 2017 20:09:48 +0100 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.15.2/8.15.2) with ESMTP id v1GJ9mJh098318; Thu, 16 Feb 2017 20:09:48 +0100 (CET) (envelope-from tijl@FreeBSD.org) Date: Thu, 16 Feb 2017 20:09:47 +0100 From: Tijl Coosemans To: Mark Felder Cc: Mark Linimon , ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org Subject: Re: svn commit: r433767 - in head: archivers/fastjar audio/audiere biology/p5-AcePerl comms/libfec devel/dcmtk devel/p5-subversion devel/py-ode games/abuse_sdl games/quake2-relay graphics/py-soya3d lan... Message-ID: <20170216200947.163419d8@kalimero.tijl.coosemans.org> In-Reply-To: <1486771811.2623949.877399408.0B6A1AA4@webmail.messagingengine.com> References: <201702091853.v19IrCxs010112@repo.freebsd.org> <20170210152955.197774a6@kalimero.tijl.coosemans.org> <1486771811.2623949.877399408.0B6A1AA4@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: svn-ports-head@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for the ports tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 19:11:03 -0000 On Fri, 10 Feb 2017 18:10:11 -0600 Mark Felder wrote: > Could you provide some guidelines or documentation to help people solve > this problem correctly if adding -fPIC is not correct? I certainly > wouldn't understand how to fix it or why this has any affect. I've gone over all ports in this commit now and the proper fix was almost always different so it's not that easy to write general guidelines. One thing is that code needs to be position independent or not on all architectures. It's never an architecture specific thing so things like CFLAGS_+=-fPIC are always wrong. Also the compiler error always says which file is causing a problem and this can belong to a dependency of the port, and then the problem needs to be fixed there. Sometimes upstream provides a switch to enable building with -fPIC. Sometimes the problem is caused by the port Makefile overriding upstream CFLAGS or by port patches that break something. With old code there may be a problem with the upstream build system because on i386 it's often possible to link non-pic object files into a shared library without the compiler complaining about that. The resulting library then contains text relocations (objdump -p libfoo.so | grep TEXTREL), which means the code needs to be modified at runtime, which means the memory holding the code cannot be shared between processes, which kind of defeats the purpose of shared libraries. The upstream build system needs to be patched then. Sometimes a port only provides library archives (libfoo.a). If another port then tries to link these into a shared library the archive needs to be compiled with -fPIC. Sometimes upstream provides a switch to enable shared libraries (libfoo.so) that other ports can use instead of libfoo.a. If that's not available -fPIC can be added to CFLAGS, preferably with a comment explaining why it's needed. It all depends on what the real cause of the problem is. Just don't follow compiler advice blindly. The one that says "recompile with -fPIC" is a particularly nasty one, because it looks like complicated mumbo jumbo followed by simple advice. It works like some sort of mind virus that makes you stop thinking. You can even see one committer put up some resistance at first but then he gets infected by another committer: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213866 And there are hundreds of ports with -fPIC in their Makefile so there are probably dozens of committers affected by this. As a committer you should always know what you're doing such that when you make mistakes you know how to fix them. When there's any doubt just ask someone who knows for confirmation.