All versions of sys-libs/db-6.0, which have apparently just been unmasked en-mass, fail to build because of the bogus line at lang/sql/sqlite/src.shell.c:62:22, i.e: #ifdef HAVE_EDITLINE && HAVE_EDITLINE == 1 this is with gcc 4.8.3, earlier versions may well have ignored the EOL garbage (starting with the &&). It would be easy to patch out "&& HAVE_EDITLINE..." but it looks like the intent of the author was actually to have the C compiler do: #if HAVE_EDITLINE == 1 (i.e. removed the unnecessary "def HAVE_EDITLINE &&" characters which actually mean that the code is selected regardless of the value of HAVE_EDITLINE.) Reproducible: Always
Created attachment 382336 [details] emerge --info '=sys-libs/db-6.0.30-r1'
Created attachment 382338 [details] complete build log
Created attachment 382340 [details] emerge -pqv '=sys-libs/db-6.0.30-r1::gentoo'
Created attachment 382342 [details] ebuild environment file
(In reply to John Bowler from comment #0) > All versions of sys-libs/db-6.0, which have apparently just been unmasked > en-mass, fail to build because of the bogus line at > lang/sql/sqlite/src.shell.c:62:22, i.e: > > #ifdef HAVE_EDITLINE && HAVE_EDITLINE == 1 > That's a warning, not an error. The error is this: /home/gentoo/build/portage/sys-libs/db-6.0.30-r1/work/db-6.0.30/lang/sql/generated/sqlite3.c:20895:3: error: #error SQLite will not work correctly with the -ffast-math option of GCC. # error SQLite will not work correctly with the -ffast-math option of GCC. ^
(In reply to Mike Gilbert from comment #5) > (In reply to John Bowler from comment #0) > > All versions of sys-libs/db-6.0, which have apparently just been unmasked > > en-mass, fail to build because of the bogus line at > > lang/sql/sqlite/src.shell.c:62:22, i.e: > > > > #ifdef HAVE_EDITLINE && HAVE_EDITLINE == 1 > > > > That's a warning, not an error. The error is this: No, it's an error - see the build.log that I posted. If you want I'll raise another bug since you seem to have hijacked this one.
The log says: /home/gentoo/build/portage/sys-libs/db-6.0.30-r1/work/db-6.0.30/lang/sql/sqlite/src/shell.c:62:22: warning: extra tokens at end of #ifdef directive [enabled by default] #ifdef HAVE_EDITLINE && HAVE_EDITLINE==1 ^ Note the word "warning" not "error".
(In reply to John Bowler from comment #6) > No, it's an error - see the build.log that I posted. I just quoted your build.log, twice. > If you want I'll raise another bug since you seem to have hijacked this one. Fixing the minor syntax problem you stated in comment 0 is something that should be addressed upstream.
Oh, ok. My apologies; I got -j4'ed (the error precedes the warning). The ffast-math problem is well known to me. There's still an error here, but you are correct, it only produces a compiler warning.
Ok, changing summary back to the original problem reported.
The #ifdef problem is fixed in the latest versions of sqlite, I guess at some point the db developers will merge in a new sqlite (though the one in the source looks very old, so maybe not.) The -ffast-math problem that arises when using -Ofast has a simple user-level fix (i.e. it doesn't need any change to the ebuild); I simply add -fno-fast-math to the end of either CFLAGS or CXXFLAGS. So, to do this every build, I have /etc/portage/env/c-no-fast-math which contains this: CFLAGS="${CFLAGS} -fno-fast-math" (and I have another file when CXXFLAGS is affected; I've yet to find a case where both are required.) Then in /etc/portage/package.env/* for each affected package I add something appropriate, e.g. in this case: >=sys-libs/db-6.0.30 c-no-fast-math The problem seems intractible for upstream. gcc -Ofast, despite the innocuous name, "disregards standards" (they use the weasel words "strict standards", I guess strict ones are the ones they don't like.)
I upstreamed it on the SUN/Oracle forum. Sorry, information lost - network connection problems.
