r139934 requires (correct?) code organization changes

I've tracked down a problem I've been having with llvm code ensconced in shared
libraries that priori to r139934, on OS X 10.7.1-10.7.2 worked fine. Since r139934,
which involves a configure change (and configure.ac), resulting in the default clang
compiler to be used when building clang, and llvm, it seems I can no longer deposit
llvm code involving jit, and IR gen functionality into shared libraries, if the translation
unit containing main also contains such features. For example using the attached
files, place externalVerify.cpp into a dynamic shared library, and build createAndVerifyFunctionTest.cpp
against it. Running it (with asserts on) creates:

Two passes with the same argument (-domtree) attempted to be registered!
UNREACHABLE executed at <root dir>/llvm/include/llvm/Support/PassNameParser.h:73!

Prior to patch r139934 (prior to the default platform's installed clang building clang
and llvm), this example works fine. From a llvm pass internals perspective this is
because PassNameParser::passRegistered(...) tries to add a new option containing
info for a pass; in this case the DominatorTree pass. The state of the system asserts
because a DominatorTree pass option has already been created. This is perplexing since
this means that the atomic compare and swap operation on static var "initialized"
contained in CALL_ONCE_INITIALIZATION(...) did not prevent the pass's associated
initialize""PassOnce(...) function from being invoked more than once. Logically, baring
other knowledge, the only way this can happen is that CALL_ONCE_INITIALIZATION(...)
is instantiated in at least two places. Although I forced the example to exemplify the issue
for the DominatorTree pass, this problem has nothing to do with this pass specifically.

Given that when directly linking the example's createAndVerifyFunctionTest.o with
externalVerify.o, does not manifest the issue, the above means that using a shared
library, with such a main, is the incorrect way to organize such projects. Is this correct?
Should I be now using static libs instead? Please note that the example is NOT
directly registering a pass, in fact up till now, for this example, I've only be able to generate
this pass registration conflict by having the main translation unit include llvm/ExecutionEngine/JIT.h.
As doing the manual svn bijection effort to locate the commit was a slow process, I
thought I would go to the list for help (I have real code which organizes its files with
shared libraries), to short cut to a solution--finding out why a clang (platform dependent?),
built clang/llvm manifests the issue would be another long effort.

My platform's (OS X 10.7.2), default clang is:

Apple clang version 3.0 (tags/Apple/clang-211.10.1) (based on LLVM 3.0svn)
Target: x86_64-apple-darwin11.2.0
Thread model: posix

The clang/llvm I used to build my example is at (r143900)

Thanks in advance

Garrison

createAndVerifyFunctionTest.cpp (1.73 KB)

externalVerify.cpp (594 Bytes)