llvm dev - Apr 2007 - [LLVMdev] [llvm-commits] CVS: llvm/lib/Transforms/Hello/Makefile

On Apr 13, 2007, at 12:28 PM, Chris Lattner wrote:
> On Fri, 13 Apr 2007, Devang Patel wrote:
>> And this brings back CommandLine Error: Arugment blah defined more
>> than once!
>>
>> And without this, opt -load .../LLVMHello.dylib -hello does not work
>> on Darwin because dyld is not able to find SlowerOperationInformer ;)
>
> 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.

-
Devang

On Apr 13, 2007, at 12:39 PM, 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.  :)
ok. I did not realize that this is related to .o files not used by  
'opt'.
I'll remove SlowerOperationInformer from Hello.

-
Devang
>
>
> 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.
>
> -Chris
>
> -- 
> http://nondot.org/sabre/
> http://llvm.org/
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

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
>

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.

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/