[llvm-dev] Problem with the way BUILD_SHARED_LIBS=ON handled in llvm 3.8

[Chris Bieneman via llvm-dev]

There was a really big debate about the naming of that option when it went in. The problem is that we support three platforms and they all refer to libraries using different terminology. Linux calls them shared objects referring to the distribution method, but Darwin and Windows both refer to them as dynamic referring to how they are loaded. Sadly there is no good name.

All platforms see performance implications of dynamically linking libraries as opposed to statically linking them. I don’t know whether that hits Darwin or Linux worse, but I believe Darwin’s two-level name spacing actually makes Darwin better than Linux. If I understand correctly it hits windows worst of all because of how Windows handles weak symbol resolution.

On all platforms I would expect the many shared libraries to be way worse relative to one shared library. I expect that would be the case because one of the complications of C++ is a lot of weak exports. Those come from functions implemented in headers which are then compiled into each generated object file. At static link time the linker resolves the duplicates down to a single implementation. If you are linking one dynamic library you will have way less symbols than if you are linking multiple libraries because each library will have its own copy of the duplicated symbols.

-Chris

> On Jan 30, 2016, at 3:21 PM, Jack Howarth <howarth.mailing.lists at gmail.com> wrote:
> 
> On Wed, Jan 27, 2016 at 3:18 AM, Ismail Donmez via llvm-dev
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>> Hi,
>> 
>> On Tue, Jan 26, 2016 at 6:57 PM, ChrisBieneman <beanz at apple.com> wrote:
>>> Yes, I'm aware of the change that caused this. It was when I stopped setting SOVERSION as a target property on all shared libraries. That change was deliberate in order to match functionality between CMake and the autoconf build.
>>> 
>>> In the autoconf build we didn't actually set the SOVERSION on libraries. Instead we include the version in the name of libLLVM, and we didn't version libLTO (except on Darwin).
>>> 
>>> I believe we are coming back to the point that BUILD_SHARED_LIBS=On should never be used when building a distribution, so the libraries shouldn't be versioned. The only reason to use libLTO is if your system linker is slow and you want to improve iteration times.
>>> 
>>> A clang built with BUILD_SHARED_LIBS=On will be significantly slower than one built against a single LLVM dynamic library, and in turn that is significantly slower than a clang built against static libraries. On Darwin process launch for a clang built against an LLVM dynamic library takes 2ms longer to launch than clang built against static libraries.
>>> 
>>> The fix here is not to make BUILD_SHARED_LIBS work the way it used to. The fix is to make LLVM_LINK_LLVM_DYLIB work with out-of-tree builds.
>> 
>> Since I am the only one complained about this so far, I'll revert this
>> change locally for 3.8 packaging and work on getting
>> LLVM_LINK_LLVM_DYLIB work as expected so we can use it for packaging
>> 3.9.
> 
> Other than the darwin-specific name choice, shouldn't
> LLVM_LINK_LLVM_DYLIB also be usable on linux to link against a
> libLLVM.so? Or is there a speed difference, on the faster dynamic
> library loading on linux, between loading many shared libraries, of
> smaller aggregate size, rather than loading one larger sized shared
> library.
>                    Jack
> 
>> 
>> Thanks,
>> ismail
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160201/2f14772d/attachment.html>