Can something be done with the "inconsistency in registered CommandLine options" error


If one searches for“inconsistency+in+registered+CommandLine+options”

There are a lot of matches spanning various graphical applications, from the zig programming language to LibreOffice, Darktable, Blender, to various other things using Flatpak, AppImage, etc.

The most common reason for this issue is that an application uses its own statically-linked version of LLVM, likely to JIT-compile something, while the user’s graphics driver likely links against the graphics driver,, which for users of either Intel or AMD (or any other Mesa-based) drivers, links against the distro’s

But there does not seem to be any consensus about how to solve that meaningfully, and allowing an application to be built a single time, e.g. against a static LLVM-10 because it has been updated to LLVM-10 API, and still run on a wide range of linux distros.

Proposing to add the software to the Linux repos does not cut it - what if I make a new software tomorrow ? There are still plenty of people on Ubuntu 16.04/18.04/20.04 for instance - they should be able to use that software, especially considering that this is a non-issue on macOS and Windows.

Neither does “rebuilding the app for each distro” - if an app uses LLVM 10 API, how many distros can be targeted today ? Pretty much only Arch Linux and similar.

So, is there a way ? A special option to set while building LLVM ? Is this issue on the radar of the LLVM team ?

Thanks !

I believe you need your application to either be packaged for the distro (and so linked against the LLVM present in the distribution repo), or embed LLVM inside your application with private visibility so that the copy of LLVM you embed won’t interact with the rest of the distribution (like the graphic drivers).

What if this happens on an out-of-source pass running in opt? I have specific case where i am using the Linker in a pass. If i link the Linker lib e.g:

add_library(LinkRT SHARED ${LinkRT_Sources})
set_target_properties(LinkRT PROPERTIES COMPILE_FLAGS "-fno-rtti")
target_link_libraries(LinkRT LLVMLinker)

I get in opt:
opt: CommandLine Error: Option 'debug-pass' registered more than once!

if i don’t link the Linker lib i get:
opt: symbol lookup error: lib/Transforms/ undefined symbol: _ZN4llvm6Linker11linkModulesERNS_6ModuleESt10unique_ptrIS1_St14default_deleteIS1_EEjSt8functionIFvS2_RKNS_9StringSetINS_15MallocAllocatorEEEEE

Any ideas?

What I managed to do is add a linker script when linking my app that puts every symbol (including the statically-linked LLVM symbols) in a namespace.
The script looks like :

FOOBAR_1.0 {
local: *;

Hi @eeGx i run into the same situation as you except that when link with LLVMLinker, my opt error is:

opt: CommandLine Error: Option 'asm-macro-max-nesting-depth' registered more than once!

without linking, the error is exactly same as yours.

May I check if you manage to solve or make any headway in this issue? Thanks in advance. :blush: