Page MenuHomePhabricator

[lld] Support building shared libLLD.so
AbandonedPublic

Authored by mgorny on Aug 5 2020, 12:08 AM.

Details

Summary

Support building a single shared library in addition to split libraries.
The concept and code is copied from clang's libclang-cpp.so. This will
permit building external tools against LLD without having to resort
to static linking or BUILD_SHARED_LIBS.

Support linking LLD to the dylib to avoid duplication.

Diff Detail

Event Timeline

mgorny created this revision.Aug 5 2020, 12:08 AM
mgorny requested review of this revision.Aug 5 2020, 12:08 AM

@ruiu, any chance you could review this?

mgorny added a subscriber: thakis.

@thakis, you seem to have been touching lld recently.

MaskRay added inline comments.Dec 4 2020, 9:26 AM
lld/tools/lld-shlib/CMakeLists.txt
16

Hmm. I think LLVM_BUILD_LLVM_DYLIB & CLANG_BUILD_CLANG_DYLIB are incompatible with BUILD_SHARED_LIBS

24

libclang-cpp.so?

27

Minimum CMake version has been bumped

lld/tools/lld-shlib/lld-shlib.cpp
1

Can you just merge lld-shlib/* to the main CMakeLists.txt to avoid a directory?

mgorny added inline comments.Dec 4 2020, 9:30 AM
lld/tools/lld-shlib/lld-shlib.cpp
1

I suppose I could but is this really desirable?

From what I understand, linking lld as a shared library is an explicit non-goal of lld. It trusts inputs and crashes on bad inputs, since it's designed to be run as a separate process.

Can you say more about what you want this for? It seems like something we don't want to do.

mgorny added a comment.Dec 4 2020, 3:37 PM

From what I understand, linking lld as a shared library is an explicit non-goal of lld. It trusts inputs and crashes on bad inputs, since it's designed to be run as a separate process.

Can you say more about what you want this for? It seems like something we don't want to do.

It's for zig. It apparently tries to link to LLD's static libraries, and we really don't want to install static libraries on Gentoo.

From what I understand, linking lld as a shared library is an explicit non-goal of lld. It trusts inputs and crashes on bad inputs, since it's designed to be run as a separate process.

Can you say more about what you want this for? It seems like something we don't want to do.

We ship the lld libraries and headers in Fedora too, and this change would be an improvement (1 shared library is better than having many). As @mgorny said there is at least one project already using lld this way. If lld is really not meant to be used as a library, then this needs to be formalized some way with documentation and by removing the install targets for the libraries and headers. I don't personally have an opinion about whether or not lld should be used as a library, but if we do have libraries I prefer libLLD.so over what we have now.

I think this could be simplified by using object libraries like this patch: https://reviews.llvm.org/D95727 does for libLLVM.so

mgorny abandoned this revision.Jun 4 2021, 8:18 AM

I'm not going to put any more effort into this. If you have time and motivation to work on this, feel free to take it over.