Date: Thu, 16 Feb 2017 20:09:47 +0100 From: Tijl Coosemans <tijl@FreeBSD.org> To: Mark Felder <feld@FreeBSD.org> Cc: Mark Linimon <linimon@FreeBSD.org>, 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 10 Feb 2017 18:10:11 -0600 Mark Felder <feld@FreeBSD.org> 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_<ARCH>+=-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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170216200947.163419d8>