[LLVMdev] -fPIC troubles on Linux x86 (32 bit)
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
> 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.:
> (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