llvm dev - Nov 2011 - [LLVMdev] 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: createAndVerifyFunctionTest.cpp
Type: application/octet-stream
Size: 1771 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20111107/abd4965d/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: externalVerify.cpp
Type: application/octet-stream
Size: 594 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20111107/abd4965d/attachment-0001.obj>
-------------- next part --------------