[LLVMdev] -fPIC troubles on Linux x86 (32 bit)

Andrew Haley aph at redhat.com
Tue May 19 05:29:45 PDT 2009

Albert Graef wrote:

> I noticed that now that --enable-pic is the default in svn, there's also
> some logic in Makefiles.rules to eliminate -fPIC for the case of mingw
> and cygwin:
>   ifeq ($(ENABLE_PIC),1)
>     ifeq ($(OS), $(filter $(OS), Cygwin MingW))
>       # Nothing. Win32 defaults to PIC and warns when given -fPIC
>     else
>   ...
> I would suggest that it should be done this way (i.e., eliminating
> -fPIC) not only for win32, but for all 32 bit x86 systems. Or has anyone
> seen any kind of x86 system where the -fPIC is indeed required?

It's not strictly required, as the runtime system will fix them up, but of
course the fixed-up parts of the "shared libraries" are no longer shared,
which rather defeats the point.

> The problem with using -fPIC on x86 is not only the speed of the
> generated code, I also get JIT-related segfaults in the Pure interpreter
> (on Linux). See, e.g.:
> http://code.google.com/p/pure-lang/issues/detail?id=9
> (That specific bug report relates to the Ubuntu Jaunty LLVM 2.5 package,
> which is (mis)configured with --enable-pic on all architectures
> including x86. But the issue is exactly the same with current svn, as
> has been reported for various different x86 Linux systems by other Pure
> users. The segfaults go away if LLVM is compiled with --disable-pic on
> x86. I don't have a minimal test example, but I'm pretty sure that the
> bug is in LLVM, not in the Pure interpreter, as the interpreter passes
> its test suite just fine if LLVM is compiled with --disable-pic.)
> Note that -fPIC is *not* required to build shared libraries on 32 bit
> x86, in fact AFAICT it's recommended to *not* use -fPIC there.

That's not true for Fedora, where non-PIC shared libraries will fail
rpmlint and SELinux may (depending on how it's configured) refuse to load

The real solution is to fix the bug.


More information about the llvm-dev mailing list