On 10/29/19 9:56 AM, Douglas R. Reno via blfs-support wrote:
On 10/29/19 12:51 AM, Trent via blfs-support wrote:
On 10/28/19 11:31 PM, Douglas R. Reno via blfs-support wrote:
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
Bit of an update. I tried "export NINJAJOBS=1" and it was just too
painfully slow, so I bumped it up to "export NINJAJOBS=2." I am here
to report the compile has made it past the point of failure from the
previous attempts.
That is some good news.
Though I would still like to know about adding a swap partition.
I am considering using a very low power Mini-ITX board I got with 8GB
of RAM. The problem is that is has a Celeron N3050 (Asus N3050M-E).
While it is rather newer than all the other available lower power
systems I got available, it for some reason does not support any MMX,
or SSE extensions. I tried running Windows 10 on it. According to the
resource meter, Windows 10 has both cores (no hyper threading) pegged
in the 90 percentile range constantly. Meanwhile, the current Atom
board I am using now, actually runs Windows 10 decently.
Anyone know how good, or bad this would do once I got a desktop
environment going?
Thanks again everyone!
Hi Trent,
When you add a swap partition, you should be good to go. Desktop
environment should run okay on either of those depending on what it
is, X is really light. I had GNOME running on my 32-bit machine, and
that's where I'm headed right now on that one (fixing some 32-bit
compilation problems). It ran pretty well considering it only had an
Intel 945GM for a GPU. Plasma didn't run though but at least started.
I got the most performance out of XFCE on that one, although because
of my vision it was very painful to use at times.
Any of those machines that you have should do a good job! Although
your Celeron N3050 will severely struggle without MMX or SSE support
in anything that requires heavy graphics rendering - but something
like Fluxbox or IceWM would probably work good on it. I'd honestly
stay with the Atom if you can though.
Yeah, I think I will stick with old Intel Atom board for now. What I
find odd on the Asus N3050M-E, is while the CPU on board does not even
support SSE, nor MMX, it does support 4K graphics, and the Asus site
mentions "gaming" on their site for it. Not sure what Asus and Intel
were thinking when coming up with that contraption.
Thanks again!
Trent
--
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
