Error building hotspot with shark/zero (original) (raw)

Neale Ferguson neale at sinenomine.net
Wed Feb 5 07:20:05 PST 2014

Getting closer with LLVM 3.4 and openJDK. Everything compiles cleanly now but I now crap out with:

Linking vm... sharedRuntime_zero.o: In function SharedRuntime::generate_stubs()': sharedRuntime_zero.cpp:(.text+0x3bc): multiple definition of SharedRuntime::generate_stubs()' sharedRuntime.o:sharedRuntime.cpp:(.text+0x1328): first defined here sharedRuntime_zero.o:(.bss+0x18): multiple definition of SharedRuntime::_wrong_method_blob' sharedRuntime.o:(.bss+0x0): first defined here sharedRuntime_zero.o:(.bss+0x20): multiple definition of SharedRuntime::_ic_miss_blob' sharedRuntime.o:(.bss+0x8): first defined here sharedRuntime_zero.o:(.bss+0x28): multiple definition of SharedRuntime::_resolve_opt_virtual_call_blob' sharedRuntime.o:(.bss+0x10): first defined here sharedRuntime_zero.o:(.bss+0x30): multiple definition of SharedRuntime::_resolve_virtual_call_blob' sharedRuntime.o:(.bss+0x18): first defined here sharedRuntime_zero.o:(.bss+0x38): multiple definition of SharedRuntime::_resolve_static_call_blob' sharedRuntime.o:(.bss+0x20): first defined heresharedRuntime_zero.o:(.bss+0x8): multiple definition of SharedRuntime::_polling_page_safepoint_handler_blob'sharedRuntime.o:(.bss+0x38): first defined heresharedRuntime_zero.o:(.bss+0x10): multiple definition of SharedRuntime::_polling_page_return_handler_blob'sharedRuntime.o:(.bss+0x40): first defined heresharedRuntime_zero.o:(.bss+0x0): multiple definition of SharedRuntime::_deopt_blob'sharedRuntime.o:(.bss+0x28): first defined herecollect2: ld returned 1 exit statusln: accessing libjvm.so.1': Too many levels of symbolic links/usr/bin/chcon: failed to get security context of libjvm.so': Too many levels of symbolic linksERROR: Cannot chcon libjvm.so make[6]: stat: libjvm.so: Too many levels of symbolic links

Both sharedRuntime.cpp and sharedRuntime_zero.cpp have generate_stubs defined and there doesn't appear to be conditional logic that needs to be triggered to stop it, so is it a Makefile thing? As for the "too many levels of symbolic links", because the link failed the symlink ends up pointing to itself.

Neale

On Feb 3, 2014, at 7:08 PM, Christian Thalinger wrote:

I haven’t tried LLVM 3.4 yet (compiling it right now) but it seems some method signatures have changed. Let’s see if I can make it work...

On Feb 3, 2014, at 11:50 AM, Neale Ferguson <neale at sinenomine.net> wrote:

Hi, I'm attempting build openJDK7 with SHARK/ZERO and am encountering the following when using llvm-3.4:

In file included from /home/neale/openjdk7/hotspot/src/share/vm/shark/llvmValue.hpp:30, from /home/neale/openjdk7/hotspot/src/share/vm/shark/sharkBlock.cpp:29: /home/neale/openjdk7/hotspot/src/share/vm/shark/sharkContext.hpp: In member function 'llvm::Constant* SharkContext::getexternal(const char*, const llvm::FunctionType*)': /home/neale/openjdk7/hotspot/src/share/vm/shark/sharkContext.hpp:72: error: invalid conversion from 'const llvm::FunctionType*' to 'llvm::FunctionType*' /home/neale/openjdk7/hotspot/src/share/vm/shark/sharkContext.hpp:72: error: initializing argument 2 of 'llvm::Constant* llvm::Module::getOrInsertFunction(llvm::StringRef, llvm::FunctionType*)' line 72 looks like: llvm::Constant* getexternal(const char* name, const llvm::FunctionType* sig) { return module()->getOrInsertFunction(name, sig); } Before I go too far with this I thought I'd find out if this was a known issue. I note there were other issues getting this far, like where 3.4 keeps its include files (in /usr/include/llvm/IR/...) so there are probably other changes of significance. Neale

More information about the hotspot-dev mailing list