[LLVMdev] libLTO on linux
Chandler Carruth
chandlerc at gmail.com
Sun Nov 30 00:55:34 PST 2008
On Sat, Nov 29, 2008 at 10:56 PM, Chris Lattner <clattner at apple.com> wrote:
>
> On Nov 29, 2008, at 10:44 PM, Chandler Carruth wrote:
>
>>>
>>> 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?
>
> I'd love to rip out libtool. What benefit does it provide?
Several that seem worth noting (although none seem like show stoppers):
- management of the linker options (this is simplified by the
presence of "g{cc,++} -shared" driver-based linking)
- "automatic" library naming rules (lib- prefix, .so versioning, etc,
nothing terrible here)
- automatic LD_LIBRARY_PATH setup for binaries build against shared
libraries and executed prior to the libraries' installation into a
system path
The last one is probably the most relevant, but even then, the
solution is horribly ugly: libtool produces shell scripts rather than
actual programs that setup the LD_LIBRARY_PATH variables and then
execute a hidden executable. Ugh. For a *shared* library, I've never
understood why you wouldn't just re-link the executable upon install
(and have the build tree variant be linked explicitly against the full
path to the .so). Re-linking an executable's shared libraries should
be extremely fast.
My 2 cents. This isn't trivial, but it also gives you freedom (as
evidenced by Nick's issues above). It could also be done
incrementally, as you probably don't need all of that all at once as
LLVM is primarily built as static libraries today. The first
increments shouldn't be too rough.
-Chandler
>
> -Chris
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
More information about the llvm-dev
mailing list