Reid Spencer
2007-Apr-13 19:22 UTC
[LLVMdev] [llvm-commits] CVS: llvm/lib/Transforms/Hello/Makefile
Chris, On Fri, 2007-04-13 at 12:39 -0700, Chris Lattner wrote:> On Fri, 13 Apr 2007, Devang Patel wrote: > >> I think libhello should drop its use of SlowOperationInformer. > > > > That'll fix Hello example. However, anyone trying to load their custom > > pass will likely to run into this again. > > It is a long-standing issue. The deal is that libsupport (and many > others) are .a files. If one of the .o files in the .a file is used by a > plugin, but not by the tool, they will get link errors. There isn't a > good solution to this, I'd rather keep libhello as a santity test rather > than a test for a complete solution. :) > > For any specific client, they can do things to link the needed .o files > in. For example, we could make opt reference a symbol in > slowoperationinformer. I don't think it's important enough to do this > though.I actually disagree with this. For those tools that offer a "-load" option (and only those tools), the tool should guarantee its clients a reasonably trouble free linkage by ensuring that all the symbols from VMCore, System and Support are available. The writer of the loadable module should never link against these libraries so the symbol references are left undefined in the module. This will solve 99% of the loading issues we have.> > -Chris >
Reid Spencer
2007-Apr-13 20:23 UTC
[LLVMdev] [llvm-commits] CVS: llvm/lib/Transforms/Hello/Makefile
On Fri, 2007-04-13 at 13:33 -0700, Chris Lattner wrote:> On Fri, 13 Apr 2007, Reid Spencer wrote: > > I actually disagree with this. For those tools that offer a "-load" > > option (and only those tools), the tool should guarantee its clients a > > reasonably trouble free linkage by ensuring that all the symbols from > > VMCore, System and Support are available. The writer of the loadable > > module should never link against these libraries so the symbol > > references are left undefined in the module. This will solve 99% of the > > loading issues we have. > > Sounds fine. How do you propose we do that?Well, that's another issue. The *right* way to do it is to tell the linker to suck in all of those libraries when linking these programs. However, we went down that road once before and found portability issues. I think it just needs to be hacked on until it works. At the *very* worst we unpack those three .a files and link all the .o on the command line. I think we can do better, however.> > -Chris >
Chris Lattner
2007-Apr-13 20:33 UTC
[LLVMdev] [llvm-commits] CVS: llvm/lib/Transforms/Hello/Makefile
On Fri, 13 Apr 2007, Reid Spencer wrote:> I actually disagree with this. For those tools that offer a "-load" > option (and only those tools), the tool should guarantee its clients a > reasonably trouble free linkage by ensuring that all the symbols from > VMCore, System and Support are available. The writer of the loadable > module should never link against these libraries so the symbol > references are left undefined in the module. This will solve 99% of the > loading issues we have.Sounds fine. How do you propose we do that? -Chris -- http://nondot.org/sabre/ http://llvm.org/
Reasonably Related Threads
- [LLVMdev] [llvm-commits] CVS: llvm/lib/Transforms/Hello/Makefile
- [LLVMdev] [llvm-commits] CVS: llvm/lib/Transforms/Hello/Makefile
- [LLVMdev] [llvm-commits] CVS: llvm/lib/Transforms/Hello/Makefile
- [LLVMdev] [llvm-commits] CVS: llvm/lib/Transforms/Hello/Makefile
- [LLVMdev] [llvm-commits] CVS: llvm/lib/Transforms/Hello/Makefile