LLVM Bugzilla is read-only and represents the historical archive of all LLVM issues filled before November 26, 2021. Use github to submit LLVM bugs

Bug 22952 - cl::opt + LLVM_BUILD_LLVM_DYLIB is completely broken
Summary: cl::opt + LLVM_BUILD_LLVM_DYLIB is completely broken
Status: REOPENED
Alias: None
Product: Build scripts
Classification: Unclassified
Component: Makefiles (show other bugs)
Version: trunk
Hardware: PC All
: P normal
Assignee: Unassigned LLVM Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-03-18 23:57 PDT by Justin Bogner
Modified: 2018-09-13 14:45 PDT (History)
10 users (show)

See Also:
Fixed By Commit(s):


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Justin Bogner 2015-03-18 23:57:28 PDT
Today I fought with a buildbot all evening, because adding a -color
option to llvm-cov caused it to emit the following error, only on that
bot:

    : CommandLine Error: Option 'color' registered more than once!
    LLVM ERROR: inconsistency in registered CommandLine options

Eventually I figured out that the bot used configure and
--enable-shared, for some reason, and reproduced the failure locally. It
turns out the configure build with shared creates a monolithic llvm lib
and links all the tools to that, and this causes *every tool* to have
*every cl::opt option* from every library in LLVM. This is pretty
broken.

The cmake build with BUILD_SHARED_LIBS doesn't have this problem, since
it builds multiple library and only links the ones the tool asks for.

I've worked around this by renaming my option for now, but that's really
terrible and it makes me sad.
Comment 1 Eric Christopher 2015-03-19 13:31:18 PDT
Yep.
Comment 2 İsmail Dönmez 2016-02-18 01:20:06 PST
This breaks the use case of LLVM_BUILD_LLVM_DYLIB=ON for lld/lldb-server at least, both fails to start with an assert due to duplicate options.
Comment 3 Chris Bieneman 2016-02-18 10:48:11 PST
Yep... The underlying problem here is that command line options use global initializers to register themselves in the system. If you link all the LLVM libraries together you get every option.

The long-term fix for this is actually something I was working on a year ago. We need to stop using static initializers to register options, and instead we need to have explicit initialization.

In the short-term there are two options. (1) Rename options so that there are no conflicts, (2) Exclude libraries with option conflicts from the LLVM combined library.

Option 2 would mean statically linking some LLVM content where it is needed, but should work today by using the LLVM_DYLIB_COMPONENTS CMake option.
Comment 4 Eric Christopher 2016-06-25 16:41:33 PDT
Going to call this resolved as it deals with configure and Justin says that cmake doesn't have this problem :)
Comment 5 Justin Bogner 2016-06-25 18:22:39 PDT
Well, cmake with BUILD_SHARED_LIBS doesn't have the problem, but you really shouldn't use that option - it has its own problems. The cmake feature that actually does something like --enable-shared did, LLVM_BUILD_LLVM_DYLIB, does exhibit this problem.
Comment 6 Eric Christopher 2016-06-25 18:34:47 PDT
Aha. Cool.
Comment 7 Tom Tromey 2018-09-11 05:32:32 PDT
We encountered this bug on macOS (I haven't been able to reproduce on
Linux) in Rust; when Rust switched to using LLVM_LINK_LLVM_DYLIB,
the rust-enabled lldb started crashing.
See https://github.com/rust-lang/rust/issues/54126

One option I'm looking at is hacking our clang and lldb builds
to use DISABLE_LLVM_LINK_LLVM_DYLIB everywhere.  Maybe that would
work.

LLVM_DYLIB_COMPONENTS seems to be the official way but this seems
to be hard to use in practice; AFAICT there's no way to get the list
of components one might want, or what they correspond to.  Nicer
would be a way to say "exclude anything from clang or lldb".

I wonder if there are other options available; as I'm also not too
keen to carry an ad hoc patch to all the cmake files.
Comment 8 Tom Tromey 2018-09-13 14:45:25 PDT
(In reply to Tom Tromey from comment #7)
> We encountered this bug on macOS (I haven't been able to reproduce on
> Linux) in Rust; when Rust switched to using LLVM_LINK_LLVM_DYLIB,
> the rust-enabled lldb started crashing.

This turned out to be somewhat self-induced: the installer was not
preserving symlinks properly, so lldb could end up loading two copies
of liblldb.dylib.  This doesn't mean there is no underlying bug here
though, just that I initially misdiagnosed the Rust problem.