[llvm-commits] CVS: llvm/lib/Transforms/Hello/Makefile

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 :wink:

thoughts ?

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 :wink:

I think libhello should drop its use of SlowOperationInformer.

-Chris

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. :slight_smile:

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

ok. I did not realize that this is related to .o files not used by 'opt'.
I'll remove SlowerOperationInformer from Hello.

Chris,

>> 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. :slight_smile:

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.

Sounds fine. How do you propose we do that?

-Chris

> 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.