Build rule omits -std=c99 in some files, this seems to cause the bool type left undeclared. The openjpeg.h file has a macro to declare this missing type in such case but it seems ineffective. Reproducible: Always Steps to Reproduce: 1.emerge openjpeg Actual Results: Build fails. Expected Results: Successful build. Add -std=c99 to all build rule in the openjpeg package.
It seems it's a gcc bug. See bug 293899 and the related upstream gcc bug. Feel free to provide additional input.
if you're talking about altivec, i dont see it being a bug in gcc. include the proper headers. bug-wranglers also need to get proper `emerge --info` and build logs before re-assigning to maintainers.
My point was that this header works fine on x86 (and probably on amd64 too). It works on pcc when compiled with g++, but it fails there if gcc is used. Though gcc version would be helpful.
the header working on one system doesnt mean it's correct. without any actual log files, i cant tell the errors, but presumably it shouldnt go tromping on standard types that are defined in specs by defining them in ways it thinks are "correct".
Then again, it may be a flaw in openjpeg.h design, that define block requires HAVE_STDBOOL_H to be defined to include stdbool.h, but on the other hand, why does the alternate block not work ?
As for the errors, look at http://bugs.freedesktop.org/attachment.cgi?id=31216 (attachment in that upstream poppler bug). Looks like bool doesn't get defined and the problem lies in that alternate block, as HAVE_STDBOOL_H is not defined during that test.
the openjpeg code is broken then. it shouldnt require external people to include headers or create arbitrary defines. the better thing would be to do: openjpeg.h.in:#if @HAVE_STDBOOL_H@ and have configure create openjpeg.h with it rewritten so that the installed header always looks like: #if 1
This looks very much like bug 296660.
(In reply to comment #8) > This looks very much like bug 296660. > Cause it's both the same and not the same. It's caused by the same thing: that alternate block seems to work fine on amd64/x86, but for some obscure reason (which I think may be a gcc bug) it fails on ppc.
Hi, thanks for reply. I decided to verify further, here is what I found so far. The openjpeg package builds OK when CFLAGS is empty, this lead to following experiment of which flags affects and I found that there is two problems really. First, if HAVE_STDBOOL_H was defined, the inclusion of stdbool.h header occurs and compilation succeeds. But, HAVE_STDBOOL_H is not defined in this situation, so the alternative macro block definition is attempted. The problem is that when -mcpu=G4 or equivalent ppc cpu, the macro statement #if !defined(bool) is false, that is, the bool keyword or type appears to be defined, but it does not mean that the source compile unless -std=gnu99 or c99. So, when !defined(bool) is false, the enclosed #define bool int statement is not precessed, leaving the bool type still undefined, causing undeclared type error. Why is that gcc with ppc altivec cpu makes defined(bool) valid but at same time an invalid type?
*** Bug 307555 has been marked as a duplicate of this bug. ***
- emerge --info & build.log in bug 307555 (openjpeg headers causing media-video/gpac to fail w/ ppc64 - also bug 296660 is same reopening
Looks like a similar issue to http://bugs.gentoo.org/show_bug.cgi?id=306881 #if defined(__ALTIVEC__) #undef bool #endif fixes that bug but may not be ideal.
-std=c99 is a better fix and also works for the faac issue.
(In reply to comment #14) > -std=c99 is a better fix and also works for the faac issue. > Well, that may be a better solution for a specific package, however far better would be a general fix for openjpeg, as that would make it work for all packages and (barring #ifdef-s) would not make it a gcc specific solution (even if the problem seems to be gcc specific).
should be fixed with openjpeg-1.3-r3
1.3-r3 does have the fix but the new 1.4 ebuild doesn't and is failing once again.
