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

Albert Graef Dr.Graef at t-online.de
Tue May 19 05:00:58 PDT 2009


Hi all,

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?

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. The
workaround is obvious: we just tell users to build LLVM with
--disable-pic on x86 systems (and to avoid broken binary x86 packages
like the one in Jaunty). But of course it would make things easier for
packagers and end users if this worked out of the box.

Thanks,
Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr.Graef at t-online.de, ag at muwiinfa.geschichte.uni-mainz.de
WWW:    http://www.musikinformatik.uni-mainz.de/ag




More information about the llvm-dev mailing list