On 10/28/19 11:17 PM, Trent via blfs-support wrote:
On 10/28/19 8:53 PM, Ken Moffat via blfs-support wrote:
On Mon, Oct 28, 2019 at 07:47:50PM -0500, Trent via blfs-support wrote:
On 10/28/19 5:25 PM, Ed Batalha wrote:
Trent via blfs-support wrote:
On 10/28/19 3:41 PM, Bruce Dubbs via blfs-support wrote:
On 10/28/19 3:02 PM, Trent via blfs-support wrote:
[8/1352] Building CXX object
tools/clang/lib/ASTMatch...CMakeFiles/clangDynamicASTMatchers.dir/Registry.cpp.o
FAILED:
tools/clang/lib/ASTMatchers/Dynamic/CMakeFiles/clangDynamicASTMatchers.dir/Registry.cpp.o
/usr/bin/g++ -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
-Itools/clang/lib/ASTMatchers/Dynamic
-I../tools/clang/lib/ASTMatchers/Dynamic
-I../tools/clang/include -Itools/clang/include
-I/usr/include/libxml2 -Iinclude -I../include -fPIC
-fvisibility-inlines-hidden -Werror=date-time -std=c++11
-Wall -Wextra -Wno-unused-parameter -Wwrite-strings
-Wcast-qual -Wno-missing-field-initializers -pedantic
-Wno-long-long -Wimplicit-fallthrough
-Wno-maybe-uninitialized -Wno-class-memaccess
-Wno-noexcept-type -Wdelete-non-virtual-dtor
-Wno-comment -fdiagnostics-color -ffunction-sections
-fdata-sections -fno-common -Woverloaded-virtual
-fno-strict-aliasing -O3 -DNDEBUG-fno-exceptions -MD -MT
tools/clang/lib/ASTMatchers/Dynamic/CMakeFiles/clangDynamicASTMatchers.dir/Registry.cpp.o
-MF
tools/clang/lib/ASTMatchers/Dynamic/CMakeFiles/clangDynamicASTMatchers.dir/Registry.cpp.o.d
-o
tools/clang/lib/ASTMatchers/Dynamic/CMakeFiles/clangDynamicASTMatchers.dir/Registry.cpp.o
-c ../tools/clang/lib/ASTMatchers/Dynamic/Registry.cpp
g++: fatal error: Killed signal terminated program cc1plus
compilation terminated.
A signal that kills the program usually is not releated to a failed
compilation - those more usually Error although with cmake anythong
is possible. I associate compilations which are killed by a signal
with segmentation faults (hardware problems).
[13/1352] Building CXX object
tools/clang/lib/Sema/CMakeFiles/clangSema.dir/SemaExpr.cpp.o
ninja: build stopped: subcommand failed.
That sounds more normal. But on a recent -j8 verbose Release build
using my own CFLAGS and CXXFLAGS my compile of SemaExpr.cpp was *much*
later, and building all the parts I was compiling far more targets
than you were:
[1923/3276] /usr/bin/g++ -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Itools/clang/lib/Sema
-I../tools/clang/lib/Sema -I../tools/clang/include
-Itools/clang/include -I/usr/include/libxml2 -Iinclude -I../include
-O3 -march=native -D_FORTIFY_SOURCE=2 -fstack-protector-strong
-D_GLIBCXX_ASSERTIONS -fPIC -fvisibility-inlines-hidden
-Werror=date-time -std=c++11 -Wall -Wextra -Wno-unused-parameter
-Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic
-Wno-long-long -Wimplicit-fallthrough -Wno-maybe-uninitialized
-Wno-class-memaccess -Wno-noexcept-type -Wdelete-non-virtual-dtor
-Wno-comment -fdiagnostics-color -ffunction-sections -fdata-sections
-fno-common -Woverloaded-virtual -fno-strict-aliasing -O3 -DNDEBUG
-fno-exceptions -MD -MT
tools/clang/lib/Sema/CMakeFiles/clangSema.dir/SemaExprMember.cpp.o
-MF
tools/clang/lib/Sema/CMakeFiles/clangSema.dir/SemaExprMember.cpp.o.d
-o tools/clang/lib/Sema/CMakeFiles/clangSema.dir/SemaExprMember.cpp.o
-c ../tools/clang/lib/Sema/SemaExprMember.cpp
All I can really say is that something in what you are doing seems
to be different.
Only thing I am doing is following the guide as shown.
After some research, I was finally able to find the build
log ( CMakeFiles/CMakeError.log)
Run Build Command(s):/usr/bin/ninja cmTC_4c78c && [1/2]
Building CXX object CMakeFiles/cmTC_4c78c.dir/src.cxx.o
FAILED: CMakeFiles/cmTC_4c78c.dir/src.cxx.o
/usr/bin/g++ -fPIC -fvisibility-inlines-hidden
-Werror=date-time -std=c++11 -Wall -Wextra
-Wno-unused-parameter>
g++: error: unrecognized command line option '-Wthread-safety'
g++: error: unrecognized command line option '-Wthread-safety'
ninja: build stopped: subcommand failed.
Anyone know anything about this unrecognized command?
I'm not familiar with it but doing some searching it appears to
be clang only. Are you exporting CC=gcc CXX=g++? Tests probably
shouldn't be run with those set.
-- Bruce
When we build llvm for the first time, we have to set CC and CXX to
use gcc, g++. I don't seem to have any test logs for that (I mostly
only run llvm tests if I'm upgrading the version in the book), but
the error looks as if it is in the main build, not the tests.
I am doing as shown in the link (
http://www.linuxfromscratch.org/blfs/view/stable-systemd/general/llvm.html
):
=====================================================================
CC=gcc CXX=g++ \
cmake -DCMAKE_INSTALL_PREFIX=/usr \
-DLLVM_ENABLE_FFI=ON \
-DCMAKE_BUILD_TYPE=Release \
-DLLVM_BUILD_LLVM_DYLIB=ON \
-DLLVM_LINK_LLVM_DYLIB=ON \ -DLLVM_ENABLE_RTTI=ON \
-DLLVM_TARGETS_TO_BUILD="host;AMDGPU;BPF" \
-DLLVM_BUILD_TESTS=ON \
You have spaces after the backslashes. This is not right, the \ should
be the last characters on the lines.
Likewise this "YLIB=ON \ -DLLVM" does not seem correct.
Don't know if this is what is causing your problems, but I would
correct
that and try again.
-Wno-dev -G Ninja .. &&
ninja
=====================================================================
Should I remove the DLLVM_BUILD_TESTS=ON, or set it to OFF?
Trent
Cheers,
Ed
Thanks for spotting that Ed, but that is a editing issue on here when I
pasted it into the email client. It was very malformed. I just
missed that .
When pasting into SSH , it came out fine.
All I can suggest at this point is "Are you sure?" By that I mean
that you should use 'history | less' in bash to see what you
actually ran. Hmm, building desktop packages in ssh (for me, llvm
is only needed for desktop packages) - that's something I leave to
Bruce.
ĸen
It's last command I entered. I only needed to press up arrow once.
I went back and removed all the excess spaces and entered:
CC=gcc CXX=g++ cmake -DCMAKE_INSTALL_PREFIX=/usr -DLLVM_ENABLE_FFI=ON
-DCMAKE_BUILD_TYPE=Release -DLLVM_BUILD_LLVM_DYLIB=ON
-DLLVM_LINK_LLVM_DYLIB=ON -DLLVM_ENABLE_RTTI=ON
-DLLVM_TARGETS_TO_BUILD="host;AMDGPU;BPF" -DLLVM_BUILD_TESTS=OFF
-Wno-dev -G Ninja ..
It went through the configure fine.
I then started ninja. Another failure.
Did you miss the previous post where I put added in some log information?
Run Build Command(s):/usr/bin/ninja cmTC_4c78c && [1/2] Building CXX
object CMakeFiles/cmTC_4c78c.dir/src.cxx.o
FAILED: CMakeFiles/cmTC_4c78c.dir/src.cxx.o
/usr/bin/g++ -fPIC -fvisibility-inlines-hidden -Werror=date-time
-std=c++11 -Wall -Wextra -Wno-unused-parameter>
g++: error: unrecognized command line option '-Wthread-safety'
g++: error: unrecognized command line option '-Wthread-safety'
ninja: build stopped: subcommand failed.
On one note, it could be hardware related. I am booting it up using an
old Intel Atom board with only 4GB of RAM, and when the compiling gets
to a certain point, the system becomes nearly unresponsive, and the HD
light stays lit constantly rather than flashing (despite being an
SSD). This is my indication the compile has failed. It does take a
while for the system to get out of this state and the message
I do have few of other systems I could try to run it on. HP desktop
with Core 2 Q9650, and an old HP laptop with an i7-720QM. Even a more
recent dual core Celeron N3050 to try out.
However, I do not think a hardware problem would explain the g++:
error: unrecognized command line option '-Wthread-safety' issue, but I
could be wrong.
Thanks again!
Trent
I can't really offer much on this thread other than advice to change
hardware. You're running into an Out-of-memory condition and the OOM
reaper is killing processes to prevent the rest of the system from
crumbling down. You can tell that based off the unresponsiveness of
commands combined with the hard drive LED being stuck on. Because
there's no swap, it'll comb through the running processes and give them
a score to determine which one is the safest to kill. I don't think
that's the cause of your g++ problem, but it certainly could be. You
might want to do "export NINJAJOBS=1" before running it again, that'll
prevent it from running 4 jobs at once which will most certainly drain
your resources extremely quickly if it's trying to run more than one or
two jobs at a time (I have a Phenom II X2 system that has this problem -
2 cores, 4GB of RAM, and swap or OOM conditions when running more than
two jobs at a time).
When the system has successfully killed a process (normally the one
consuming the most memory), the rest of the system will slowly recover,
sometimes this happens instantaneously and sometimes it takes a while.
You can confirm that as well by running a 'dmesg'.
Either the Q9650 that you mentioned (I have one of those - very nice
chips! Although they were rather expensive last time I checked) or that
i7-720QM should do just fine, as long as you've got more RAM in those
systems or limit it to a suitable number of jobs.
On that note, with the Atom, try running "export NINJAJOBS=1" and then
running ninja. That'll confirm it's not an OOM condition (I built LLVM
on an Intel Core Duo with 4GB of RAM (it's a 32-bit machine, not a
Core2Duo which is 64-bit) recently and never got into swap on that one,
but that's an anecdote for another time).
- Doug
--
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
