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...

[Tijl Coosemans]

On Fri, 10 Feb 2017 18:10:11 -0600 Mark Felder <feld at 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.