I see that this problem persists in ToT. Perhaps it bites only those of us who try to dynamically load our own pass libraries under Darwin?

I never had any problems on linux.

I never had any problems on linux.

Me either, but I'm writing a cross-platform set of passes that I don't want to try to fold into mainline (they're too specialized to a specific domain). Optimization passes as shared libraries are an awesome idea.

I guess the objection would be that KEEP_SYMBOLS would make the opt executable too big?

Well, I'm kind of worried that this is a bandaid, and that the fundamental
problem hasn't been understood.

I do not think this problem is linux-specific, but AFAIR linux builds are shared by default, thus the problem does not show there. For some reason, Darwin builds are static (but can be --enable-shared).

The fundamental problem as I see it is that dynamically loading modules into a statically-build opt (or any other tool for the matter) might not work. Example:

libLLVMxxx.a defines global symbol G.
opt links against libLLVMxxx.a links to use G.
opt is stripped (G is no longer visible in opt).

test_module.so uses G, so it links against libLLVMxxx.a. Now, when opt loads test_module.so, module's "G" is not the same as opt "G", which it should be as it is a global symbol. It will not give duplicated symbols error because opt symbols were stripped, but it might not work properly.

My proposal is not to strip opt, therefore the modules do not need to be linked because "opt" will have all the required symbols. This effectively bundles a shared library containing all LLVM symbols into opt. I do not think there is another way of allowing module loading reliably.

Another option is entirely disabling module loading in opt for static builds.

On linux opt is also statically linked with the LLVM libraries by default.

On linux opt is also statically linked with the LLVM libraries by default.

Ok, I remembered otherwise, haven't build LLVM on linux for a while.

Strange that the problem does not show, then. Are you linking your modules statically against LLVM libraries?

I have seen this happening with different symbols, but the actual symbol giving problems when I reported the bug can be seen here:

http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-June/050689.html

in point 1).

so, '__ZN4llvm10ModulePass17assignPassManagerERNS_7PMStackENS_15PassManagerTypeE'.

Probably it was not only this one, I would need to replicate the scenario to be sure (now I got a LLVM built with KEEP_SYMBOLS in opt and with gcc instead of clang to avoid the second problem I stated in the mail).