[LLVMbugs] [PATCH] Remove useless workaround from llvm-config

[Eric Kidd]

On Mar 24, 2006, at 1:07 PM, Reid Spencer wrote:
> I am assuming there's some kind of ordering or cyclic-dependency  
> problem
> within llvm-config and until I understand that script better, I  
> won't be
> able to fix this. So, we'll take a crack at it next week.

Hmm. I'm really concerned about those cyclic dependencies, especially  
among the *.a files--we're just asking for nasty link-time trouble.  
My workarounds seem to be sufficient for some cases (MacOS X linker,  
out-of-tree builds), but not for others.

Is your build clean?

> I tried this manually, as you stated above, and I got even worse
> results:

Actually, these results are really close to working.

> Debug/HowToUseJIT.o: In function `ForceInterpreterLinking':
> /proj/llvm/llvm2/include/llvm/ExecutionEngine/Interpreter.h:35:
> undefined reference to `llvm::LinkInInterpreter()'

I don't have LinkInInterpreter() yet. This was added yesterday  
afternoon, right? Because in my day-old tree, I can still produce a  
working HowToUseJIT.cpp without any LLVMInterpreter.o at all, which  
seems desirable.

The new "LinkInInterpreter/LinkInJIT" stuff should probably be  
conditionalized on TARGET_HAS_JIT so we can pull in one or the other  
intelligently.

> /proj/install/llvm2/lib/libLLVMSystem.a(Mutex.o): In function `Mutex':
> /proj/llvm/llvm2/lib/System/Mutex.cpp:69: undefined reference to
> `pthread_mutexattr_init'
...
> It looks like llvm-config is not providing the system libraries.

Yeah, there's no clean place for me to get that information right  
now--LLVM mixes together system libraries and libtool-specific stuff,  
the later of which arguably shouldn't be in llvm-config's output. I  
can probably fix this.

But for now, it looks like you need '-lpthread -ldl'. Try:

   g++ `llvm-config --ldflags` -o HowToUseJIT HowToUseJIT.o \
     `llvm-config --libs engine bcreader scalaropts interpreter` - 
lpthread -ldl

That should get you very close.

>>> Yes, that's an issue we'll have to ponder once this is working. The
>>> answer will likely be "no" which means we might need to make llvm-
>>> config
>>> a C/C++ program.
>>
>> Yeah, I've been leaning that way, too. Do we need to do this before
>> 1.7, or can it wait?
>
> It can wait, but we'll disable building of llvm-config directory in  
> that
> situation until all the issues are resolved.

Well, llvm-config only gets turned on if 'configure' can find a  
working, recent version of Perl. So I think we're OK on that front.

Personally, if the 1.7 release is close, I'd prefer to use the  
existing Makefile.rules logic for in-tree builds.

I'm sorry you're having so much trouble, and I wish I could do more  
to help. :-( We'll figure all this out next week.

Cheers,
Eric