Post by Wayne BlaszczykPost by Christopher GregorySent: Saturday, June 09, 2018 at 5:00 AM
Subject: Re: [blfs-support] Cups-2.2.7 with clang 6 installed
Post by Bruce DubbsPost by Wayne BlaszczykI build llvm and clang separately and use slightly different parameters to the book, hence why I didn't report this issue myself.
But looking at the configure script, (and I'm not expert reading these scripts), but to me it looks like if it finds clang++, it will use it rather than g++.
checking for gcc option to accept ISO C89... none needed
checking how to run the C preprocessor... gcc -E
checking for clang++... clang++
checking whether we are using the GNU C++ compiler... yes
checking whether clang++ accepts -g... yes
checking for ranlib... ranlib
checking for ar... /usr/bin/ar
checking for chmod... /bin/chmod
Yes, I have the identical sequence on my log.
As a long-time radeon user, what is in the book works for me too.
My LLVM uses
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_TARGETS_TO_BUILD="host;AMDGPU" \
-Wno-dev ..
and I do not build cups until after Xorg (but before the gtk
toolkits).
With systemd disabled and just passing CC=gcc to configure, the
config.status: creating config.h
Using ARCHFLAGS=
Using ALL_CFLAGS=-I.. -D_CUPS_SOURCE -O2 -march=native -I/usr/include/libusb-1.0 -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -DDBUS_API_SUBJECT_TO_CHANGE -I/usr/include/p11-kit-1
-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE -D_REENTRANT
Using ALL_CXXFLAGS=-I.. -D_CUPS_SOURCE -O2 -march=native -I/usr/include/p11-kit-1 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE -D_REENTRANT
Using CC=gcc
Using CXX=gcc
Using DSOFLAGS=-L../cups -Wl,-soname,all -shared -Wall -Wno-format-y2k -Wunused -fPIC -Os -g -fstack-protector -Wno-unused-result -Wsign-conversion -Wno-tautological-compare -Wno-format-
truncation -D_GNU_SOURCE
Using LDFLAGS=-L../cgi-bin -L../cups -L../filter -L../ppdc -L../scheduler -fPIE -pie -Wall -Wno-format-y2k -Wunused -fPIC -Os -g -fstack-protector -Wno-unused-result -Wsign-conversion -Wno-
tautological-compare -Wno-format-truncation -D_GNU_SOURCE
Using LIBS=-lcups -lgnutls -lz -lpthread -lm -lcrypt -lz
Making all in cups...
Curious why it doesn't work for you.
ĸen
--
Keyboard not found, Press F1 to continue
--
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Hello Ken,
Your not the only one who is curious by this. It makes no sense that giving the exact same tar ball, and using the exact same method of building that two people get exactly the same error.
Wayne, what version of the book are you using? ie is it systemd or sysv? I am just wondering if having systemd installed is some how or other messing things up. I have had to use this CC=gcc
CXX=g++ on quite a few packages this time round.
Regards,
Christopher.
Hi Christopher,
You mentioned you need to do on other packages. Can you list them please.
I did a quick search and found that icu is another package I had to specify CC=gcc CXX=g++.
Looking at my commit history, I added this on the 7th April. Looking at that (weekly) build and the previous build, I can see the build order had changed. icu was built after llvm/clang whereas the
previous build icu was build before llvm/clang. There were no other changes to package versions between the two builds that I could see that would have impacted this.
Regards,
Wayne.
I've narrowed down the issue with building icu.
The build failure is due to the clang++ test.
The test is compiling conftest.cpp .
====
/* confdefs.h */
#define PACKAGE_NAME "ICU"
#define PACKAGE_TARNAME "International Components for Unicode"
#define PACKAGE_VERSION "61.1"
#define PACKAGE_STRING "ICU 61.1"
#define PACKAGE_BUGREPORT "http://icu-project.org/bugs"
#define PACKAGE_URL "http://icu-project.org"
#define SIZEOF_VOID_P 0
/* end confdefs.h. */
int
main ()
{
;
return 0;
}
====
clang++ -c -O2 -W -Wall -pedantic -Wpointer-arith -Wwrite-strings -Wno-long-long conftest.cpp
This causes a stack dump.
By removing the -O2 parameter fixes this issue.
wblaszcz [ ~/tmp/clangTest ]$ clang++ -c -O2 -W -Wall -pedantic -Wpointer-arith -Wwrite-strings -Wno-long-long conftest.cpp
#0 0x0000000001409f6a llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/usr/bin/clang-6.0+0x1409f6a)
#1 0x0000000001407fa6 llvm::sys::RunSignalHandlers() (/usr/bin/clang-6.0+0x1407fa6)
#2 0x00000000014080d8 SignalHandler(int) (/usr/bin/clang-6.0+0x14080d8)
#3 0x00007f5aceb7cf10 __restore_rt (/lib/libpthread.so.0+0x11f10)
#4 0x0000000000f60f15 llvm::PMTopLevelManager::addImmutablePass(llvm::ImmutablePass*) (/usr/bin/clang-6.0+0xf60f15)
#5 0x0000000000f62d9a llvm::PMTopLevelManager::schedulePass(llvm::Pass*) (/usr/bin/clang-6.0+0xf62d9a)
#6 0x00007f5accdfe4a2 llvm::PassManagerBuilder::addInitialAliasAnalysisPasses(llvm::legacy::PassManagerBase&) const (/usr/bin/../lib/libLLVM-6.0.so+0x119c4a2)
#7 0x00007f5accdfe5c6 llvm::PassManagerBuilder::populateFunctionPassManager(llvm::legacy::FunctionPassManager&) (/usr/bin/../lib/libLLVM-6.0.so+0x119c5c6)
#8 0x00000000015f0219 (anonymous namespace)::EmitAssemblyHelper::EmitAssembly(clang::BackendAction, std::unique_ptr<llvm::raw_pwrite_stream, std::default_delete<llvm::raw_pwrite_stream> >)
(/usr/bin/clang-6.0+0x15f0219)
#9 0x00000000015f2245 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&,
llvm::DataLayout const&, llvm::Module*, clang::BackendAction, std::unique_ptr<llvm::raw_pwrite_stream, std::default_delete<llvm::raw_pwrite_stream> >) (/usr/bin/clang-6.0+0x15f2245)
#10 0x0000000001ef5e7f clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) (/usr/bin/clang-6.0+0x1ef5e7f)
#11 0x00000000021bc76a clang::ParseAST(clang::Sema&, bool, bool) (/usr/bin/clang-6.0+0x21bc76a)
#12 0x0000000001ef4e71 clang::CodeGenAction::ExecuteAction() (/usr/bin/clang-6.0+0x1ef4e71)
#13 0x00000000019d65b6 clang::FrontendAction::Execute() (/usr/bin/clang-6.0+0x19d65b6)
#14 0x000000000199f3cc clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/usr/bin/clang-6.0+0x199f3cc)
#15 0x0000000001a886fb clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/usr/bin/clang-6.0+0x1a886fb)
#16 0x00000000007cc118 cc1_main(llvm::ArrayRef<char const*>, char const*, void*) (/usr/bin/clang-6.0+0x7cc118)
#17 0x0000000000788ff5 main (/usr/bin/clang-6.0+0x788ff5)
#18 0x00007f5acaf98a57 __libc_start_main /opt/wbBuild/var/sources/glibc-2.27/csu/../csu/libc-start.c:342:0
#19 0x00000000007c992a _start /opt/wbBuild/var/sources/glibc-2.27/csu/../sysdeps/x86_64/start.S:122:0
Stack dump:
0. Program arguments: /usr/bin/clang-6.0 -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -disable-free -disable-llvm-verifier -discard-value-names -main-file-name conftest.cpp -mrelocation-
model static -mthread-model posix -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64 -dwarf-column-info -debugger-tuning=gdb -momit-leaf-frame-pointer
-coverage-notes-file /home/wblaszcz/tmp/clangTest/conftest.gcno -resource-dir /usr/lib/clang/6.0.0 -internal-isystem /usr/bin/../lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../include/c++/7.3.0
-internal-isystem /usr/bin/../lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../include/c++/7.3.0/x86_64-pc-linux-gnu -internal-isystem /usr/bin/../lib/gcc/x86_64-pc-linux-
gnu/7.3.0/../../../../include/c++/7.3.0/backward -internal-isystem /usr/local/include -internal-isystem /usr/lib/clang/6.0.0/include -internal-externc-isystem /include -internal-externc-isystem
/usr/include -O2 -W -Wall -Wpointer-arith -Wwrite-strings -Wno-long-long -pedantic -fdeprecated-macro -fdebug-compilation-dir /home/wblaszcz/tmp/clangTest -ferror-limit 19 -fmessage-length 169 -fobjc-
runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops -vectorize-slp -o conftest.o -x c++ conftest.cpp
1. <eof> parser at end of file
clang-6.0: error: unable to execute command: Segmentation fault (core dumped)
clang-6.0: error: clang frontend command failed due to signal (use -v to see invocation)
clang version 6.0.0 (tags/RELEASE_600/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
clang-6.0: note: diagnostic msg: PLEASE submit a bug report to and include the crash backtrace, preprocessed source, and associated run script.
clang-6.0: note: diagnostic msg:
********************
PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang-6.0: note: diagnostic msg: /tmp/conftest-92489a.cpp
clang-6.0: note: diagnostic msg: /tmp/conftest-92489a.sh
clang-6.0: note: diagnostic msg:
********************
wblaszcz [ ~/tmp/clangTest ]$ clang++ -c -W -Wall -pedantic -Wpointer-arith -Wwrite-strings -Wno-long-long conftest.cpp
wblaszcz [ ~/tmp/clangTest ]$
So the question is, why is clang++ failing with the -O2 option.
As mentioned before, my llvm/clang build is different to the book.
And I do not have any issues with building rust, mesa, or firefox.
Stepping back a bit, the bottom line is that if CC=gcc and/or CXX=g++ is not specified, then cups and icu will use clang instead of gcc if available.
Something that should be mentioned in the book?
Regards,
Regards,
Wayne
--
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page