Provide options in LTO to build a PIC object file for linking into a shared library.

[chandlerc]

Bugzilla Link	1105
Resolution	FIXED
Resolved on	Feb 08, 2009 14:17
Version	trunk
OS	Linux
CC	@lattner,@nlewycky

Extended Description

One of the desirable things for a linker integrated with LLVM's LTO library to
provide is linking of shared libraries from bytecode. This requires (on some
platforms/OSes) building PIC in the object file with a special flag in the
assembly step of the LTO. Once PIC can be requested from the LTO library, GNU ld
(for example) should be able to check when it is generating a shared library,
and pass along the correct options.

[chandlerc]

assigned to @chandlerc

[lattner]

To solve this, all the code linked into the LTO shared library needs to be built PIC. This is a substantial
chunk of LLVM.

We should just build all of LLVM PIC. We already implicitly do this on darwin.

-Chris

[chandlerc]

I think we're talking about something different. This isn't about linking
libLLVMlto as a shared object into GNU ld, but about allowing bytecode being
linked by GNU ld to be linked into a shared library with native objects (all
of which would need to be PIC).

I think getting the LTO lib to be a shared object, and the whole PIC / non-PIC
issue is a separate one I think. Would you like me to open a separate bug for
supporting building some of the LLVM libraries as shared libraries? Or are these
two issues related in a way I don't see?

[lattner]

Ahhh, I get it. liblto should provide knobs for tweaking codegen. You're right. I think there is already a
bugzilla about building liblto itself pic.

[nlewycky]

libLTO offers lto_codegen_set_pic_model(lto_code_gen_t). We use this in the gold plugin to turn on PIC when building a .o or .so, and off when building a .exe.

Do we need anything more?

[chandlerc]

Nope, that's specifically what this bug was about. I'll go ahead and close it, thanks Nick!