upgrading arm6hf
bob prohaska
fbsd at www.zefox.net
Sat May 21 18:44:23 UTC 2016
On Sat, May 21, 2016 at 10:57:44AM -0600, Ian Lepore wrote:
>
> Do you have anything (expecially CFLAGS or CPUTYPE) in make.conf or
> src.conf?
>
> My buildworld died overnight on a clang segfault that seems to have
> nothing to do with anything, except maybe a kernel memory management
> bug or something. I started it up again and it has progressed past the
> segfault point, but hasn't gotten as far yet as where yours died.
Seemingly not,
root at www:/usr/src # svnlite status .
? buildscript
? buildworld.log
M share/i18n/esdb/DEC/DECHanyu.src
M share/i18n/esdb/KOI/KOI7-switched.src
M sys/arm/conf/RPI2
? sys/modules/Makefile.old
root at www:/usr/src #
My only tweak was to the kernel config file, adding ucom and uplcom
(which seemed to make absolutely no difference in pl2303 behavior).
I did try to update src to 300374 and restart buildworld. It stopped again
in (I think) a similar way:
/usr/include/c++/v1/vector:432: relocation truncated to fit: R_ARM_CALL against symbol `memset' defined in .text section in /usr/lib/libc.a(memset.o)
cc1_main.o: In function `~IntrusiveRefCntPtr':
/usr/src/usr.bin/clang/clang/../../../contrib/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h:53: relocation truncated to fit: R_ARM_CALL against symbol `__assert' defined in .text section in /usr/lib/libc.a(assert.o)
cc1_main.o: In function `clang::CompilerInstance::getInvocation()':
/usr/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/include/clang/Frontend/CompilerInstance.h:228: relocation truncated to fit: R_ARM_CALL against symbol `__assert' defined in .text section in /usr/lib/libc.a(assert.o)
cc1_main.o: In function `clang::CompilerInstance::getDiagnostics() const':
/usr/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/include/clang/Frontend/CompilerInstance.h:330: relocation truncated to fit: R_ARM_CALL against symbol `__assert' defined in .text section in /usr/lib/libc.a(assert.o)
cc1_main.o: In function `LLVMErrorHandler(void*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, bool)':
/usr/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/tools/driver/cc1_main.cpp:58: relocation truncated to fit: R_ARM_CALL against symbol `exit' defined in .text section in /usr/lib/libc.a(exit.o)
cc1_main.o: In function `clang::DiagnosticsEngine::Report(unsigned int)':
/usr/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/include/clang/Basic/Diagnostic.h:1119: relocation truncated to fit: R_ARM_CALL against symbol `__assert' defined in .text section in /usr/lib/libc.a(assert.o)
cc1_main.o: In function `ForcePassLinking':
/usr/src/usr.bin/clang/clang/../../../contrib/llvm/include/llvm/LinkAllPasses.h:55: relocation truncated to fit: R_ARM_CALL against symbol `getenv' defined in .text section in /usr/lib/libc.a(getenv.o)
cc1_main.o: In function `Twine':
/usr/src/usr.bin/clang/clang/../../../contrib/llvm/include/llvm/ADT/Twine.h:274:--More relocation truncated to fit: R_ARM_CALL against symbol `__assert' defined in .text section in /usr/lib/libc.a(assert.o)
cc1_main.o: In function `llvm::iplist<llvm::AliasSet, llvm::ilist_traits<llvm::AliasSet> >::remove(llvm::ilist_iterator<llvm::AliasSet>&)':
/usr/src/usr.bin/clang/clang/../../../contrib/llvm/include/llvm/ADT/ilist.h:485: relocation truncated to fit: R_ARM_CALL against symbol `__assert' defined in .text section in /usr/lib/libc.a(assert.o)
cc1_main.o: In function `llvm::MallocAllocator::Allocate(unsigned int, unsigned int)':
/usr/src/usr.bin/clang/clang/../../../contrib/llvm/include/llvm/Support/Allocator.h:95: additional relocation overflows omitted from the output
c++: error: linker command failed with exit code 1 (use -v to see invocation)
*** [clang.full] Error code 1
make[4]: stopped in /usr/src/usr.bin/clang/clang
1 error
make[4]: stopped in /usr/src/usr.bin/clang/clang
*** [all_subdir_usr.bin/clang/clang] Error code 2
make[3]: stopped in /usr/src/usr.bin/clang
1 error
Would it make any sense to back down to the pre-hardfloat kernel and try again?
My feeling is "no", but unless there's much to lose it's an easy experiment.
bob prohaska
More information about the freebsd-arm
mailing list