Date: Sat, 18 Feb 2017 07:11:56 +0100 From: Michal Meloun <melounmichal@gmail.com> 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: <42c782dd-7dda-52d7-dec8-fe2be490b29f@freebsd.org> In-Reply-To: <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. Well, if you want be multiplatform, the rule is very simple. Iv short: 'Each object file ending in shared library must be compile with -fpic' Period, *no other way*. This is only way, known to me, witch ensures correct building of shared library on all supported platforms. Longer story is: For each CPU architecture, compiler can emit wide range various relocation records . While static linker can process any one, realtime linker (rtld) can process only (mostly small) subset of them. When shared library gets finally linked, the static linker can convert some of unsupported (by rtld) relocation's to supported ones, but not all types are convertible. And this is exact reason, why each source file for portable multiplatform library must be compiled with -fpic. Michal
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?42c782dd-7dda-52d7-dec8-fe2be490b29f>