Sent: Friday, October 07, 2016 at 6:26 PM From: "Bruce Dubbs" <[email protected]> To: "BLFS Support List" <[email protected]> Subject: Re: [blfs-support] Solid failure in Frameworks-5.25.0 Cliff McDiarmid wrote: > Sent: Friday, October 07, 2016 at 11:01 AM > From: "Cliff McDiarmid" <[email protected]> > To: [email protected] > Subject: Re: [blfs-support] Solid failure in Frameworks-5.25.0 > Sent: Thursday, October 06, 2016 at 1:05 PM > From: akhiezer <[email protected]> > To: "BLFS Support List" <[email protected]> > Subject: Re: [blfs-support] Solid failure in Frameworks-5.25.0 >> From: "Cliff McDiarmid" <[email protected]> >> Date: Thu, 6 Oct 2016 12:17:19 +0200 >> Subject: Re: [blfs-support] Solid failure in Frameworks-5.25.0 >> >> Sent: Wednesday, October 05, 2016 at 11:29 PM >> From: "Ken Moffat" <[email protected]> >> To: "BLFS Support List" <[email protected]> >> Subject: Re: [blfs-support] Solid failure in Frameworks-5.25.0 >> On Wed, Oct 05, 2016 at 09:50:30PM +0100, akhiezer wrote: >>>> From: "Cliff McDiarmid" <[email protected]> >>>> Date: Wed, 5 Oct 2016 20:35:36 +0200 >>>> Subject: [blfs-support] Solid failure in Frameworks-5.25.0 >>>> >>>> Hi >>>> >>>> Does anyone know what's causing this when building Solid as part of >>>> Frameworks? Or has anyone seen this before? >>>> >>>> >>>> [ 40%] Building C object >>>> src/solid/CMakeFiles/KF5Solid_static.dir/predicate_lexer.c.o >>>> /mnt/home/cliffys/frameworks-5.26.0/solid-5.25.0/build/src/solid/predicate_lexer.c: >>>> In function âSolidensure_buffer_stackâ: >>>> /mnt/home/cliffys/frameworks-5.26.0/solid-5.25.0/build/src/solid/predicate_lexer.c:1587:21: >>>> error: C++ style comments are not allowed in ISO C90 >>>> num_to_alloc = 1; // After all that talk, this was set to 1 anyways... >>>> ^ >>> >>> Dealing with the info 'in isolation' - haven't gone back and looked at book >>> pages: >>> >>> either: >>> ==== >>> * change that line, in: >>> /mnt/home/cliffys/frameworks-5.26.0/solid-5.25.0/build/src/solid/predicate_lexer.c >>> , to: >>> num_to_alloc = 1; /* After all that talk, this was set to 1 anyways... */ >>> But you might hit similar issue in other files: so ref following option, >>> below. >>> >>> * or: >>> tell the compiler to use an appropriate C version later than 'ISO C90'; or >>> at least to be relaxed about such '// ...' comment styles. >>> ==== >>> >> >>> Yes, it seems strange that it is setting things up as if for an old >>> compiler. >> >> Not exactly old - Solid-5.25.0 on mine reported >> >> -- The C compiler identification is GNU 6.1.0 >> -- The CXX compiler identification is GNU 6.1.0 >> -- Check for working C compiler: /usr/bin/cc >> -- Check for working C compiler: /usr/bin/cc -- works >> -- Detecting C compiler ABI info >> -- Detecting C compiler ABI info - done >> -- Detecting C compile features >> -- Detecting C compile features - done >> -- Check for working CXX compiler: /usr/bin/c++ >> -- Check for working CXX compiler: /usr/bin/c++ -- works >> -- Detecting CXX compiler ABI info >> -- Detecting CXX compiler ABI info - done >> -- Detecting CXX compile features >> -- Detecting CXX compile features - done >> >> >>> In 7.9-rc1 I had similar output with 5.18, except the compiler was >>> 5.3.0. I can't go back and compare that source to 5.25.0 because >>> http://download.kde.org/stable/frameworks/ has nothing before 5.20, >>> but I will be very surprised if '//' comments are a recent addition. >> >>> So, which compiler are you using, and what does cmake think it is >>> when trying to build solid ? Or did you accidentally use some >>> CFLAGS or CXXFLAGS to force the version ? >> >> I would have thought GCC 6.1 would have been fine. Not using CFLAGS or >> CXXFLAGS, I use to use them don't anymore. >> > > >> It's not so much the gcc version per se: it's which 'C' standard it's >> trying to conform to - ref e.g.: >> * >> https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html[https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html][https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html[https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html]][https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html[https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html][https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html[https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html]]] >> (& sub-ref: >> https://gcc.gnu.org/onlinedocs/gcc/Standards.html#Standards[https://gcc.gnu.org/onlinedocs/gcc/Standards.html#Standards][https://gcc.gnu.org/onlinedocs/gcc/Standards.html#Standards[https://gcc.gnu.org/onlinedocs/gcc/Standards.html#Standards]][https://gcc.gnu.org/onlinedocs/gcc/Standards.html#Standards[https://gcc.gnu.org/onlinedocs/gcc/Standards.html#Standards][https://gcc.gnu.org/onlinedocs/gcc/Standards.html#Standards[https://gcc.gnu.org/onlinedocs/gcc/Standards.html#Standards]]]) >> - see the top two items, '-ansi' & '-std='; & incl the examples they >> give re '//'-style comments. > --- >> Basically, you may have some command-line switch &/or environment-var >> that is reaching as far as the gcc cmdline, and causing the problem.
> Just as an aside. Are these sort of messages typical when building KF5? They > appear in various forms in many packages. >Warnings are not a problem. They often occur because the compiler used >upstream is a little older than the one we use. You really only need to >be concerned about error messages. > I can find nothing in envs or in profile etc that would account for this. > Have made the alteration in the file in question and am going forward on that > basis at the moment. > Incidently, Solid 5.25.0 is also failing at that stage and yet I know I > compiled this several months ago without errors. >Which version of flex are you using, >predicate_lexer.c is generated by flex from a template >if you are using 2.6.0 , it needs a patch attached(courtesy of Arch), >2.6.1 is ok >Martin That's it. Upgraded to Flex 2.6.1 and gcc behaves. Many thanks Martin and to everyone else. Cliff -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
