On 2019-May-19, at 11:06, Dimitry Andric <dim at FreeBSD.org> wrote: > On 19 May 2019, at 16:56, Mark Millard via freebsd-toolchain > <freebsd-toolchain at freebsd.org> wrote: >> This was in a poudriere bulk build on a head -r347549 based powerpc64 >> system with system clang 8 for cc and c++ and base/binutils >> for the likes of ld. (The system has the llvm libunwind patches >> for powerpc64 so throwing c++ exceptions work.) >> >> [4397/4552] : && /usr/bin/c++ -fPIC -O2 -pipe -DNDEBUG >> -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing >> -DNDEBUG -isystem /usr/local/include -fPIC -fvisibility-inlines-hidden >> -Werror=date-time -Werror=unguarded-availability-new -std=c++11 -Wall -W >> -Wno-unused-parameter -Wwrite-strings -Wcast-qual >> -Wmissing-field-initializers -pedantic -Wno-long-long >> -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor >> -Wstring-conversion -fcolor-diagnostics -ffunction-sections -fdata-sections >> -O2 -pipe -DNDEBUG -fstack-protector-strong -isystem /usr/local/include >> -fno-strict-aliasing -DNDEBUG -isystem /usr/local/include >> -fstack-protector-strong -Wl,-z,origin -Wl,-O3 -Wl,--gc-sections >> -Wl,--version-script,/wrkdirs/usr/ports/devel/llvm60/work/.build/tools/lto/LTO.exports >> -shared -Wl,-soname,libLTO.so.6 -o lib/libLTO.so.6.0.1 >> tools/lto/CMakeFiles/LTO.dir/LTODisassembler.cpp.o >> tools/lto/CMakeFiles/LTO.dir/lto.cpp.o -L/usr/local/lib -Wl,-rpath,"\$ORIGIN/ ../ >> lib:/usr/local/lib" lib/libLLVM-6.0.so && : >> FAILED: lib/libLTO.so.6.0.1 >> : && /usr/bin/c++ -fPIC -O2 -pipe -DNDEBUG -fstack-protector-strong -isystem >> /usr/local/include -fno-strict-aliasing -DNDEBUG -isystem >> /usr/local/include -fPIC -fvisibility-inlines-hidden -Werror=date-time >> -Werror=unguarded-availability-new -std=c++11 -Wall -W -Wno-unused-parameter >> -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic >> -Wno-long-long -Wcovered-switch-default -Wnon-virtual-dtor >> -Wdelete-non-virtual-dtor -Wstring-conversion -fcolor-diagnostics >> -ffunction-sections -fdata-sections -O2 -pipe -DNDEBUG >> -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing >> -DNDEBUG -isystem /usr/local/include -fstack-protector-strong >> -Wl,-z,origin -Wl,-O3 -Wl,--gc-sections >> -Wl,--version-script,/wrkdirs/usr/ports/devel/llvm60/work/.build/tools/lto/LTO.exports >> -shared -Wl,-soname,libLTO.so.6 -o lib/libLTO.so.6.0.1 >> tools/lto/CMakeFiles/LTO.dir/LTODisassembler.cpp.o >> tools/lto/CMakeFiles/LTO.dir/lto.cpp.o -L/usr/local/lib >> -Wl,-rpath,"\$ORIGIN/../lib:/usr/ loc >> al/lib" lib/libLLVM-6.0.so && : >> /usr/bin/powerpc64-unknown-freebsd13.0-ld: BFD (GNU Binutils) 2.32 assertion >> fail elflink.c:2935 >> /usr/bin/powerpc64-unknown-freebsd13.0-ld: BFD (GNU Binutils) 2.32 assertion >> fail elflink.c:2935 > > See <https://bugs.freebsd.org/237068>. I think this is a BFD ld bug, > but I still haven't been able to come up with a small test case. Any > help appreciated. :-) I've put the evidence leading to the following in the bugzilla report. The problem is tied to "seed" in: /wrkdirs/usr/ports/devel/llvm60/work/llvm-6.0.1.src/include/llvm/ADT/Hashing.h 's: . . . namespace llvm { . . . // All of the implementation details of actually computing the various hash // code values are held within this namespace. These routines are included in // the header file mainly to allow inlining and constant propagation. namespace hashing { namespace detail { . . . /// \brief A global, fixed seed-override variable. /// /// This variable can be set using the \see llvm::set_fixed_execution_seed /// function. See that function for details. Do not, under any circumstances, /// set or read this variable. extern size_t fixed_seed_override; inline size_t get_execution_seed() { // FIXME: This needs to be a per-execution seed. This is just a placeholder // implementation. Switching to a per-execution seed is likely to flush out // instability bugs and so will happen as its own commit. // // However, if there is a fixed seed override set the first time this is // called, return that instead of the per-execution seed. const uint64_t seed_prime = 0xff51afd7ed558ccdULL; static size_t seed = fixed_seed_override ? fixed_seed_override : (size_t)seed_prime; return seed; } It ends up with *h in the reported BFD_ASSERT failures having: _ZZN4llvm7hashing6detail18get_execution_seedEvE4seed@@LLVM_6.0 root.type = bfd_link_hash_defweak is_weakalias = 1 And *h->u.alias having: __bss_start@@LLVM_6.0 root.type = bfd_link_hash_indirect is_weakalias = 0 That means in the BFD_ASSERT: def->root.type==bfd_link_hash_indirect which fails the assert's: def->root.type == bfd_link_hash_defined === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "[email protected]"
Re: FYI: Unable to build -r501994 ports' devel/llvm60 on clang 8 based powerpc64 system: "BFD (GNU Binutils) 2.32 assertion fail elflink.c:2935"
Mark Millard via freebsd-toolchain Sun, 19 May 2019 14:45:07 -0700
- FYI: Unable to build -r501994 ports' de... Mark Millard via freebsd-toolchain
- Re: FYI: Unable to build -r501994 ... Dimitry Andric
- Re: FYI: Unable to build -r501... Mark Millard via freebsd-toolchain
- Re: FYI: Unable to build -r501... Mark Millard via freebsd-toolchain
- Re: FYI: Unable to build -... Mark Millard via freebsd-toolchain
