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
