> Sent: Thursday, June 14, 2018 at 12:16 AM > From: "Wayne Blaszczyk" <[email protected]> > To: "BLFS Support List" <[email protected]> > Subject: Re: [blfs-support] Cups-2.2.7 with clang 6 installed > > On Sun, 2018-06-10 at 12:00 +1000, Wayne Blaszczyk wrote: > > On Sun, 2018-06-10 at 09:54 +1000, Wayne Blaszczyk wrote: > > > On Sat, 2018-06-09 at 11:46 +1000, Wayne Blaszczyk wrote: > > > > On Fri, 2018-06-08 at 22:16 +0200, Christopher Gregory wrote: > > > > > > Sent: Saturday, June 09, 2018 at 5:00 AM > > > > > > From: "Ken Moffat" <[email protected]> > > > > > > To: "BLFS Support List" <[email protected]> > > > > > > Subject: Re: [blfs-support] Cups-2.2.7 with clang 6 installed > > > > > > > > > > > > On Thu, Jun 07, 2018 at 09:56:05AM -0500, Bruce Dubbs wrote: > > > > > > > On 06/07/2018 05:04 AM, Wayne Blaszczyk wrote: > > > > > > > > > > > > > > > I 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++. > > > > > > > > I would be interested in your configure output around this area: > > > > > > > > > > > > > > > > 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 > > > > > > output from cups at the start of make is: > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > > > > > > I've narrowed down the issue with building icu. > > The build failure is due to the clang++ test. > > The test is compiling conftest.cpp . > > > > 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: > > ******************** > > 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 > > > > > > Hi All, > > I've fixed my clang issue. > I first removed -DCMAKE_SHARED_LINKER_FLAGS="-Wl,-Bsymbolic" from my llvm > build. > This did not fix anything, but in fact it broke my firefox build. > After a bit of digging around, I notice that Fedora, Arch, and Gentoo had a > lot of patches applied to their llvm builds, so I decided to patch as per the > Arch build. > So my cmake for llvm is now: > cmake \ > CC=gcc CXX=g++ \ > -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" \ > -Wno-dev \ > .. > and I've applied the following patches: > > patch -Np1 -i ../PR35947-export-LLVMInitializeInstCombine-as-extern-C.patch > patch -Np1 -i > ../PR36417-DebugInfo-discard-invalid-DBG_VALUE-instructions.patch > patch -Np1 -i > ../PR36417-fixup-for-rL326769-RegState-Debug-is-being-truncated.patch > patch -Np1 -i ../D44391-export-LLVM_DYLIB_COMPONENTS-in-LLVMConfig.cmake.patch > patch -Np0 -i ../D44420-cmake-fix-a-typo-in-llvm_config-macro.patch > > See https://git.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/llvm > > So now I can build icu without CC=gcc CXX=g++ > I can build cups without CC=gcc CXX=g++ (just to make it clear, It builds > without CC=gcc) > and firefox builds as it used to. > > Although, icu and cups still uses clang in preference to gcc. > I hope this helps others. > > As a side note, Arch uses ninja for their llvm build, something which I have > not tried out myself. > > Regards, > Wayne. > > > > > > > > > > > > > -- > http://lists.linuxfromscratch.org/listinfo/blfs-support > FAQ: http://www.linuxfromscratch.org/blfs/faq.html > Unsubscribe: See the above information page >
Well I too solved the issues. Not that anyone maintaining the book cares as it does not happen to THEM, but the easy fix and solution for me was to build the whole of llvm, clang and rt with make -j1. I do not care what the people with puffed up self-importance say, there is a RACE condition that occurs on SOME machines. Yes Wayne fixed the issue with patches and modified instructions from arch, but even arch are skirting round things. With my complete build notes, after I have completed this installation and made sure that none of the other packages that needed CC=gcc CXX=g++ require that any more, I will do another fresh installation using my notes and if it builds correctly again, I will know the reason that it failed was incomplete/inaccurate instructions on the LLVM page. Christopher. -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
