[LLVMbugs] [PATCH] Remove useless workaround from llvm-config
emk.lists at gmail.com
Fri Mar 24 10:51:56 PST 2006
On Mar 24, 2006, at 1:07 PM, Reid Spencer wrote:
> I am assuming there's some kind of ordering or cyclic-dependency
> 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
Actually, these results are really close to working.
> Debug/HowToUseJIT.o: In function `ForceInterpreterLinking':
> 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
The new "LinkInInterpreter/LinkInJIT" stuff should probably be
conditionalized on TARGET_HAS_JIT so we can pull in one or the other
> /proj/install/llvm2/lib/libLLVMSystem.a(Mutex.o): In function `Mutex':
> /proj/llvm/llvm2/lib/System/Mutex.cpp:69: undefined reference to
> 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` -
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-
>>> 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
> 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.
More information about the llvm-bugs