Relocation "Thing" against "wotsit" can not be used when making a shared object; recompile with -fPIC

Sometimes when building a shared library you may come across an error like: Relocation "Thing" against "wotsit" can not be used when making a shared object; recompile with -fPIC.

There are numerous possible causes for this listed on various other web pages, but none of them seem to include this one. I know this because I have just been bitten by this error while trying to build gcc-4.4 for cross-compilation to MIPS under amd64. Every time it got as far as building libstdc++-v3 it would choke on s_asinh.o and s_atan.o from libm and throw errors like this.

This was especially arsulous because it bears a strong but misleading similarity to this bug report which led me into spending hours fucking around trying different versions of binutils to see if it made any difference and finding that the only difference it made was in the swear words I uttered on finding that it didn't work again.

It turned out that the cause was much simpler: it was a fucking broken symlink. When converting the MIPS libraries with dpkg-cross in preparation for the compilation, the bastard thing shifted the files to their new places but did not update all the symlinks to suit. This is because dpkg-cross is one of the buggiest pieces of shit in existence and nobody at Debian is interested in fixing it, on the grounds that it is supposed to cease to exist soon; on top of that, what fixes they do bother with are all oriented towards its disappearance and replacement, and so are not usable anyway since I am trying to stick with the nice tidy pre-multiarch setup that sticks all the foreign arch stuff under /usr/<foreign-arch> instead of the new shit that uses a bunch of different .../<foreign-arch> directories in loads of different places and still doesn't work properly. (Fettling dpkg-cross and ranting about the fucking mess that is multiarch in Debian will be the subject of another web page in DUKE HORSE).

The result of this was that ld was failing to find and instead of producing an error message at this point was falling back to libm.a, which does not work because you can't make a relocatable shared object with stuff out of a static library. Why the fuck it even tried to use the static library for a purpose for which it is not usable instead of throwing a sensible error first off I have no idea, but that is what it did, and the result was me spending fucking hours thinking the cause of the problem was something a lot more complicated than it really was.

It is a shit error message anyway because it entirely fails to make it clear which fucking thing it is wanting you to recompile with -fPIC. I got several instances of it all at about the same point in the compilation process (because of having 8 build threads running); in some of them "Thing" was from libm and "wotsit" from the local file, in others it was "wotsit" that was from libm and "Thing" from the local file, but regardless of which one of them it was considering to be "wrong" the error message was otherwise the same, so it was distinctly obscure as to whether it was "Thing" or "wotsit" that it didn't like.

So then, here is another thing to check if you are getting these sort of errors: make sure that all your symlinks to shared libraries are correct and are not pointing to the wrong place, whether this may be caused by spastic-arsed multiple architecture shite or anything else.

Back to Pigeon's Nest

Be kind to pigeons

Valid HTML 4.01!