llvm dev - Apr 2014 - [LLVMdev] "lazy symbol binding failed" with dynamically loaded pass in opt

Hi Tim, Dear List,

Am 18.04.2014 um 10:08 schrieb Tim Northover <t.p.northover at
gmail.com>:
> One common problem (the only one I really know about, unfortunately)
> is trying to load a module into Xcode's copy of "opt" rather
than one
> from the same tree as your module.
I just double-checked that I use the opt executable from the same tree I use to
build the module.

This tree is configured as a Debug+Asserts build, and compiled by the system
compiler (which identifies itself as "Apple LLVM version 5.1
(clang-503.0.40) (based on LLVM 3.4svn)“. Would compiling the LLVM tree with
another compiler, e.g., a recent GCC, make any difference?

I tried various combinations of linking my passes with the related libraries via
USEDLIBS, LLVMLIBS and LINK_COMPONENTS with no success. The outcome is either
that opt does not load the module at all because of duplicated symbols, or that
my custom passes don’t register properly at runtime (e.g., they’re not visible
in „opt --help“)

Cheers,
Julian

On 2014-Apr-18, at 5:32, Julian Oppermann <oppermann at
esa.informatik.tu-darmstadt.de> wrote:
> Hi Tim, Dear List,
> 
> Am 18.04.2014 um 10:08 schrieb Tim Northover <t.p.northover at
gmail.com>:
>> One common problem (the only one I really know about, unfortunately)
>> is trying to load a module into Xcode's copy of "opt"
rather than one
>> from the same tree as your module.
> 
> I just double-checked that I use the opt executable from the same tree I
use to build the module.
> 
> This tree is configured as a Debug+Asserts build, and compiled by the
system compiler (which identifies itself as "Apple LLVM version 5.1
(clang-503.0.40) (based on LLVM 3.4svn)“. Would compiling the LLVM tree with
another compiler, e.g., a recent GCC, make any difference?
Seems unlikely to help.  We use Apple's clang all the time.
> I tried various combinations of linking my passes with the related
libraries via USEDLIBS, LLVMLIBS and LINK_COMPONENTS with no success. The
outcome is either that opt does not load the module at all because of duplicated
symbols, or that my custom passes don’t register properly at runtime (e.g.,
they’re not visible in „opt --help“)
Are you using the same configure line on both Linux and Darwin?

What build system are you using?  (cmake vs. configure)

Is it the same build system you were using on Linux?
> Cheers,
> Julian
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

Hi Duncan, Dear List,

Am 19.04.2014 um 00:32 schrieb Duncan P. N. Exon Smith <dexonsmith at
apple.com>:
> Are you using the same configure line on both Linux and Darwin?
yes, just a bare ./configure.
> What build system are you using?  (cmake vs. configure)
The configure/make system.
> Is it the same build system you were using on Linux?
Yes.

In the meantime, I had a closer look on which particular symbol was missing. It
turned out that the llvm::Calculate template (used by
DominatorTreeBase::recalculate, which I call in my pass) is declared in
llvm/Analysis/Dominators.h, but is implemented in DominatorInternals.h. *) When
I include that header directly as a workaround, my pass works fine.

Cheers,
Julian

*) I forgot to mention that I'm still using the release_33 branch; in the
trunk, the dominator tree computation code has been restructured, and no longer
causes this linker problem in my example.