32-bit powerpc system-clang based builds of devel/llvm40 and devel/llvm50: fails via "Host compiler appears to require libatomic, but cannot find it"
[I experiment with system-clang based buildworld and/or buildkernel based TARGET_ARCH=powerpc64 and TARGET_ARCH=powerpc environments.] For TARGET_ARCH=powerpc devel/llvm40 and devel/llvm50 get failure reports like: -- Looking for __atomic_load_8 in atomic - not found CMake Error at cmake/modules/CheckAtomic.cmake:74 (message): Host compiler appears to require libatomic, but cannot find it. Call Stack (most recent call first): cmake/config-ix.cmake:307 (include) CMakeLists.txt:582 (include) I had tried to avoid any need for 8-Byte atomics (among other things) by avoiding LIT, LLD, and LLDB: # more /usr/local/etc/poudriere.d/options/devel_llvm50/options # This file is auto-generated by 'make config'. # Options for llvm50-5.0.0_1 _OPTIONS_READ=llvm50-5.0.0_1 _FILE_COMPLETE_OPTIONS_LIST=CLANG DOCS EXTRAS LIT LLD LLDB OPTIONS_FILE_SET+=CLANG OPTIONS_FILE_SET+=DOCS OPTIONS_FILE_SET+=EXTRAS OPTIONS_FILE_UNSET+=LIT OPTIONS_FILE_UNSET+=LLD OPTIONS_FILE_UNSET+=LLDB # more /usr/local/etc/poudriere.d/options/devel_llvm40/options # This file is auto-generated by 'make config'. # Options for llvm40-4.0.1_1 _OPTIONS_READ=llvm40-4.0.1_1 _FILE_COMPLETE_OPTIONS_LIST=CLANG DOCS EXTRAS LIT LLD LLDB OPTIONS_FILE_SET+=CLANG OPTIONS_FILE_SET+=DOCS OPTIONS_FILE_SET+=EXTRAS OPTIONS_FILE_UNSET+=LIT OPTIONS_FILE_UNSET+=LLD OPTIONS_FILE_UNSET+=LLDB For clang-based buildworld avoiding such things prevents running into the 8-Byte atomics based build failures: WITH_LIBCPLUSPLUS= WITH_BINUTILS_BOOTSTRAP= WITH_ELFTOOLCHAIN_BOOTSTRAP= #WITH_CLANG_BOOTSTRAP= WITH_CLANG= WITH_CLANG_IS_CC= WITH_CLANG_FULL= WITH_CLANG_EXTRAS= WITH_LLD= # lldb requires missing atomic 8-byte operations for powerpc (non-64) WITHOUT_LLDB= # WITH_BOOT= (Note: buildkernel currently fails.) # clang++ --version FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on LLVM 5.0.0svn) Target: powerpc-unknown-freebsd12.0 Thread model: posix InstalledDir: /usr/bin # uname -apKU FreeBSD FBSDG4S 12.0-CURRENT FreeBSD 12.0-CURRENT r326192M powerpc powerpc 1200054 1200054 # svnlite info /usr/ports/ | grep "Re[plv]" Relative URL: ^/head Repository Root: https://svn.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 455204 Last Changed Rev: 455204 === Mark Millard markmi at dsl-only.net ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 223776] ports-mgmt/pkg: lld confuses shared library tracking
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223776 --- Comment #3 from Ed Maste --- This should be fixed in pkg 1.10.3 -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: 32-bit powerpc system-clang based builds of devel/llvm40 and devel/llvm50: fails via "Host compiler appears to require libatomic, but cannot find it"
The cmake test just tries to compile:
#include
std::atomic x;
int main() {
return x;
}
What happens if you try to compile this small code with your host compiler?
Roman
On Tue, Dec 05, 2017 at 10:42:49AM -0800, Mark Millard wrote:
> [I experiment with system-clang based
> buildworld and/or buildkernel based
> TARGET_ARCH=powerpc64 and
> TARGET_ARCH=powerpc environments.]
>
> For TARGET_ARCH=powerpc devel/llvm40 and
> devel/llvm50 get failure reports like:
>
> -- Looking for __atomic_load_8 in atomic - not found
> CMake Error at cmake/modules/CheckAtomic.cmake:74 (message):
> Host compiler appears to require libatomic, but cannot find it.
> Call Stack (most recent call first):
> cmake/config-ix.cmake:307 (include)
> CMakeLists.txt:582 (include)
>
>
> I had tried to avoid any need for 8-Byte atomics
> (among other things) by avoiding LIT, LLD, and LLDB:
>
> # more /usr/local/etc/poudriere.d/options/devel_llvm50/options
> # This file is auto-generated by 'make config'.
> # Options for llvm50-5.0.0_1
> _OPTIONS_READ=llvm50-5.0.0_1
> _FILE_COMPLETE_OPTIONS_LIST=CLANG DOCS EXTRAS LIT LLD LLDB
> OPTIONS_FILE_SET+=CLANG
> OPTIONS_FILE_SET+=DOCS
> OPTIONS_FILE_SET+=EXTRAS
> OPTIONS_FILE_UNSET+=LIT
> OPTIONS_FILE_UNSET+=LLD
> OPTIONS_FILE_UNSET+=LLDB
>
> # more /usr/local/etc/poudriere.d/options/devel_llvm40/options
> # This file is auto-generated by 'make config'.
> # Options for llvm40-4.0.1_1
> _OPTIONS_READ=llvm40-4.0.1_1
> _FILE_COMPLETE_OPTIONS_LIST=CLANG DOCS EXTRAS LIT LLD LLDB
> OPTIONS_FILE_SET+=CLANG
> OPTIONS_FILE_SET+=DOCS
> OPTIONS_FILE_SET+=EXTRAS
> OPTIONS_FILE_UNSET+=LIT
> OPTIONS_FILE_UNSET+=LLD
> OPTIONS_FILE_UNSET+=LLDB
>
> For clang-based buildworld avoiding such things
> prevents running into the 8-Byte atomics based
> build failures:
>
> WITH_LIBCPLUSPLUS=
> WITH_BINUTILS_BOOTSTRAP=
> WITH_ELFTOOLCHAIN_BOOTSTRAP=
> #WITH_CLANG_BOOTSTRAP=
> WITH_CLANG=
> WITH_CLANG_IS_CC=
> WITH_CLANG_FULL=
> WITH_CLANG_EXTRAS=
> WITH_LLD=
> # lldb requires missing atomic 8-byte operations for powerpc (non-64)
> WITHOUT_LLDB=
> #
> WITH_BOOT=
>
> (Note: buildkernel currently fails.)
>
> # clang++ --version
> FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on LLVM
> 5.0.0svn)
> Target: powerpc-unknown-freebsd12.0
> Thread model: posix
> InstalledDir: /usr/bin
>
> # uname -apKU
> FreeBSD FBSDG4S 12.0-CURRENT FreeBSD 12.0-CURRENT r326192M powerpc powerpc
> 1200054 1200054
>
> # svnlite info /usr/ports/ | grep "Re[plv]"
> Relative URL: ^/head
> Repository Root: https://svn.freebsd.org/ports
> Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
> Revision: 455204
> Last Changed Rev: 455204
>
>
> ===
> Mark Millard
> markmi at dsl-only.net
>
> ___
> freebsd-toolchain@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
> To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: 32-bit powerpc system-clang based builds of devel/llvm40 and devel/llvm50: fails via "Host compiler appears to require libatomic, but cannot find it"
On 2017-Dec-5, at 12:39 PM, Roman Divacky wrote:
> The cmake test just tries to compile:
>
> #include
> std::atomic x;
> int main() {
> return x;
> }
>
> What happens if you try to compile this small code with your host compiler?
>
> Roman
[I later show that it seems to be testing
with: std::atomic x (0) instead
and is also using a line the example does
not have (devel/llvm50 example):
uint64_t i = x.load(std::memory_order_relaxed);
.]
# uname -apKU
FreeBSD FBSDG4S 12.0-CURRENT FreeBSD 12.0-CURRENT r326192M powerpc powerpc
1200054 1200054
# more cpp_atomic.cpp
#include
std::atomic x;
int main() {
return x;
}
# clang++ -v cpp_atomic.cpp
FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on LLVM
5.0.0svn)
Target: powerpc-unknown-freebsd12.0
Thread model: posix
InstalledDir: /usr/bin
"/usr/bin/clang++" -cc1 -triple powerpc-unknown-freebsd12.0 -emit-obj
-mrelax-all -disable-free -main-file-name cpp_atomic.cpp -mrelocation-model
static -mthread-model posix -mdisable-fp-elim -masm-verbose
-mconstructor-aliases -target-cpu ppc -mfloat-abi hard -v -dwarf-column-info
-debugger-tuning=gdb -resource-dir /usr/lib/clang/5.0.0 -internal-isystem
/usr/include/c++/v1 -fdeprecated-macro -fdebug-compilation-dir /root/c_tests
-ferror-limit 19 -fmessage-length 200 -fno-signed-char -fobjc-runtime=gnustep
-fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o
/tmp/cpp_atomic-3b1ae2.o -x c++ cpp_atomic.cpp
clang -cc1 version 5.0.0 based upon LLVM 5.0.0svn default target
powerpc-unknown-freebsd12.0
#include "..." search starts here:
#include <...> search starts here:
/usr/include/c++/v1
/usr/lib/clang/5.0.0/include
/usr/include
End of search list.
"/usr/bin/ld" --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1
--enable-new-dtags -m elf32ppc_fbsd -o a.out /usr/lib/crt1.o /usr/lib/crti.o
/usr/lib/crtbegin.o -L/usr/lib /tmp/cpp_atomic-3b1ae2.o -lc++ -lm -lgcc
--as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed
/usr/lib/crtend.o /usr/lib/crtn.o
# ./a.out
#
So, the example works fine.
Nothing about that example program would seem to
match the note:
-- Looking for __atomic_load_8 in atomic
I would guess that the __atomic_load_8 test
is somewhat different. . .
Looking at an expansion of a wrkdirs' .tbz that
poudriere produced, CheckAtomic.cmake has . . .
. . .
# Check for 64 bit atomic operations.
if(MSVC)
set(HAVE_CXX_ATOMICS64_WITHOUT_LIB True)
else()
check_working_cxx_atomics64(HAVE_CXX_ATOMICS64_WITHOUT_LIB)
endif()
# If not, check if the library exists, and atomics work with it.
if(NOT HAVE_CXX_ATOMICS64_WITHOUT_LIB)
check_library_exists(atomic __atomic_load_8 "" HAVE_CXX_LIBATOMICS64)
if(HAVE_CXX_LIBATOMICS64)
list(APPEND CMAKE_REQUIRED_LIBRARIES "atomic")
check_working_cxx_atomics64(HAVE_CXX_ATOMICS64_WITH_LIB)
if (NOT HAVE_CXX_ATOMICS64_WITH_LIB)
message(FATAL_ERROR "Host compiler must support std::atomic!")
endif()
else()
message(FATAL_ERROR "Host compiler appears to require libatomic, but cannot
find it.")
endif()
endif()
. . .
>From this I get:
A) check_working_cxx_atomics64(HAVE_CXX_ATOMICS64_WITHOUT_LIB)
set: NOT HAVE_CXX_ATOMICS64_WITHOUT_LIB
B) check_library_exists(atomic __atomic_load_8 "" HAVE_CXX_LIBATOMICS64)
set: NOT HAVE_CXX_LIBATOMICS64
For (A), looking at the test code (found by
name-text matching):
function(check_working_cxx_atomics64 varname)
set(OLD_CMAKE_REQUIRED_FLAGS ${CMAKE_REQUIRED_FLAGS})
set(CMAKE_REQUIRED_FLAGS "-std=c++11 ${CMAKE_REQUIRED_FLAGS}")
CHECK_CXX_SOURCE_COMPILES("
#include
#include
std::atomic x (0);
int main() {
uint64_t i = x.load(std::memory_order_relaxed);
return 0;
}
" ${varname})
set(CMAKE_REQUIRED_FLAGS ${OLD_CMAKE_REQUIRED_FLAGS})
endfunction(check_working_cxx_atomics64)
I see:
#include
#include
std::atomic x (0);
int main() {
uint64_t i = x.load(std::memory_order_relaxed);
return 0;
}
Trying that example I see:
/tmp/cpp_atomic_64_test-1fa999.o: In function `main':
cpp_atomic_64_test.cpp:(.text+0xa8): undefined reference to `__atomic_load_8'
clang++: error: linker command failed with exit code 1 (use -v to see
invocation)
Details:
# more cpp_atomic_64_test.cpp
#include
#include
std::atomic x (0);
int main() {
uint64_t i = x.load(std::memory_order_relaxed);
return 0;
}
# clang++ -v cpp_atomic_64_test.cpp
FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on LLVM
5.0.0svn)
Target: powerpc-unknown-freebsd12.0
Thread model: posix
InstalledDir: /usr/bin
"/usr/bin/clang++" -cc1 -triple powerpc-unknown-freebsd12.0 -emit-obj
-mrelax-all -disable-free -main-file-name cpp_atomic_64_test.cpp
-mrelocation-model static -mthread-model posix -mdisable-fp-elim -masm-verbose
-mconstructor-aliases -target-cpu ppc -mfloat-abi hard -v -dwarf-column-info
-debugger-tuning=gdb -resource-dir /usr/lib/clang/5.0.0 -internal-isystem
/usr/include/c++/v1 -fdeprecated-macro -fdebug-compilatio
powerpc64 & system-clang vs. building the likes of lang/gcc7 (at least): vec_step name pollution causes compile failures, should gcc7 source code avoid the name?
[I experiment with clang-based worlds and kernels
on powerpc64 and powerpc. But I'm not sure that
such is the only type of context is required to
see the below problem.]
Attempting to build lang/gcc7 on a system-clang based
powerpc64 (world and kernel) gets:
/wrkdirs/usr/ports/lang/gcc7/work/gcc-7.2.0/gcc/tree-vect-loop.c:3835:27:
error: expected unqualified-id
tree new_vec, vec_init, vec_step, t;
^
/wrkdirs/usr/ports/lang/gcc7/work/gcc-7.2.0/gcc/tree-vect-loop.c:3835:26:
error: expected ';' at end of declaration
tree new_vec, vec_init, vec_step, t;
^
;
Well, it turns out that vec_step has the following
potential naming conflicts, one for powerpc64 FreeBSD
specifics, and one for clang specifics (for support of
OpenCL). . .
For powerpc64:
/usr/src/contrib/gcc/config/rs6000/altivec.h:#define vec_step(x)
__builtin_vec_step (* (__typeof__ (x) *) 0)
(I'm point the above out despite my clang-based context.)
For clang:
/usr/src/contrib/llvm/tools/clang/lib/Parse/ParseExpr.cpp:/// vec_step and we
are at the start of an expression or a parenthesized
/usr/src/contrib/llvm/tools/clang/lib/Parse/ParseExpr.cpp:/// [OpenCL 1.1
6.11.12] vec_step built-in function:
/usr/src/contrib/llvm/tools/clang/lib/Parse/ParseExpr.cpp:///
vec_step ( expressions )
/usr/src/contrib/llvm/tools/clang/lib/Parse/ParseExpr.cpp:///
vec_step ( type-name )
/usr/src/contrib/llvm/tools/clang/lib/Parse/ParseExpr.cpp: "Not a
typeof/sizeof/alignof/vec_step expression!");
/usr/src/contrib/llvm/tools/clang/lib/Parse/ParseExpr.cpp: "Not a
sizeof/alignof/vec_step expression!");
/usr/src/contrib/llvm/tools/clang/lib/Sema/SemaExpr.cpp: // [OpenCL 1.1
6.11.12] "The vec_step built-in function takes a built-in
/usr/src/contrib/llvm/tools/clang/lib/Sema/TreeTransform.h: /// \brief Build a
new sizeof, alignof or vec_step expression with a
/usr/src/contrib/llvm/tools/clang/include/clang/AST/Expr.h:/// vec_step (OpenCL
1.1 6.11.12).
/usr/src/contrib/llvm/tools/clang/include/clang/ASTMatchers/ASTMatchers.h:///
\brief Matches sizeof (C99), alignof (C++11) and vec_step (OpenCL)
/usr/src/contrib/llvm/tools/clang/include/clang/Basic/DiagnosticSemaKinds.td:
"invalid application of '%select{sizeof|alignof|vec_step}0' to a "
/usr/src/contrib/llvm/tools/clang/include/clang/Basic/DiagnosticSemaKinds.td:
"invalid application of '%select{sizeof|alignof|vec_step}0' to a void "
/usr/src/contrib/llvm/tools/clang/include/clang/Basic/DiagnosticSemaKinds.td:
"invalid application of
'%select{sizeof|alignof|vec_step|__builtin_omp_required_simd_align}0' to a void
type">;
/usr/src/contrib/llvm/tools/clang/include/clang/Basic/DiagnosticSemaKinds.td:
"invalid application of
'%select{sizeof|alignof|vec_step|__builtin_omp_required_simd_align}0' to an "
/usr/src/contrib/llvm/tools/clang/include/clang/Basic/DiagnosticSemaKinds.td:
"invalid application of
'%select{sizeof|alignof|vec_step|__builtin_omp_required_simd_align}0' to a "
/usr/src/contrib/llvm/tools/clang/include/clang/Basic/DiagnosticSemaKinds.td:
"'vec_step' requires built-in scalar or vector type, %0 invalid">;
/usr/src/contrib/llvm/tools/clang/include/clang/Basic/TokenKinds.def:KEYWORD(vec_step
, KEYOPENCL|KEYALTIVEC|KEYZVECTOR)
(The lists were extracted from a: grep -r "\" /usr/src/*
Some material was omitted from the reported matches.)
Given the clang extension for having vec_step for OpenCL,
it might be best if lang/gcc7 was updated to avoid the
name (upstream as well). devel/llvm50 likely has the
same vec_step as system-clang. I'm not sure about
devel/llvm40 .
This might be true of some other lang/gcc*'s: I just
happen to build lang/gcc7 but not the others (generally).
Context details:
# uname -apKU
FreeBSD FBSDG5L 12.0-CURRENT FreeBSD 12.0-CURRENT r326192M powerpc powerpc64
1200054 1200054
# svnlite info /usr/ports/ | grep "Re[plv]"
Relative URL: ^/head
Repository Root: svn://svn0.us-west.freebsd.org/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 455204
Last Changed Rev: 455204
(Last before FLAVORS is enabled.)
===
Mark Millard
markmi at dsl-only.net
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
