[LLVMdev] libLTO on linux
chandlerc at gmail.com
Sat Nov 29 22:44:41 PST 2008
On Sat, Nov 29, 2008 at 9:17 PM, Nick Lewycky <nicholas at mxc.ca> wrote:
> I'm looking into the possibility of building the libLTO plugin on Linux,
> and got tangled up in the build system.
> Currently, tools/Makefile only includes 'lto' when the OS equals Darwin,
> while tools/lto/Makefile has an if-statement that builds libLTO as a
> static library on non-Darwin systems.
> If I try to build libLTO as a dynamic library on Linux, it works fine,
> but I get an enormous warning from libtool:
> *** Warning: Linking the shared library
> /home/nicholas/llvm-commit/Debug/lib/libLTO.la against the non-libtool
> *** objects /home/nicholas/llvm-commit/Debug/lib/LLVMCppBackend.o
> /home/nicholas/llvm-commit/Debug/lib/LLVMX86CodeGen.o is not portable!
> If we're going to build a .so file, we need those .o's to be built with
> -fPIC. As far as I can see, configuring LLVM with --enable-pic actually
> does that already, so perhaps we can make it the default.
> But that warning isn't about PIC, it's about the fact that the .o's
> weren't compiled with libtool. It's looking for the matching .lo files.
My question is this, why use libtool to build the .so? I don't see
what libtool helps with here, and it is a nightmare to use in general.
Why not directly use the gcc driver?
> It's not clear to me what we ought to do here. Put 'lto' inside an if
> ENABLE_PIC and suppress the warning? Build everything in LLVM with
> libtool --mode=compile? Is there a simple way to limit that to just the
> .o files we end up installing?
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
More information about the llvm-dev