After updating to jpeg-7, and recompiling various packages, I came across this whilst re-emerging xbmc: /usr/include/jpeglib.h:1125:55: error: jpegint.h: No such file or directory Which then causes the build to fail. Reproducible: Always Steps to Reproduce: 1. Update system to media-libs/jpeg-7 2. Attempt to re-emerge xbmc Actual Results: Build fails and emerge exits. Expected Results: Package builds.
Issue can be worked around by unpacking jpegsrc.v7.tar.gz and copying jepgint.h to /usr/include
Stupid program to demo the issue (NB: I am not a coder): #include <stdio.h> #include <stdlib.h> #define JPEG_INTERNALS = 1; #include <jpeglib.h> int main (void) { return 0; }
Will include emerge --info etc if requested, but I don't think it's needed here.
jpegint.h is a private header and should not be used by any package: http://archives.gentoo.org/gentoo-dev/msg_59838379c87130d1930264324586870b.xml Please tell us which packages are failing.
media-tv/xbmc-9.04
Output from where xbmc build fails: gcc -O2 -fPIC -D_LINUX -c -o tif_ojpeg.o tif_ojpeg.c In file included from tif_ojpeg.c:35: /usr/include/jpeglib.h:1125:55: error: jpegint.h: No such file or directory tif_ojpeg.c: In function ‘OJPEGPreDecode’: tif_ojpeg.c:1414: error: dereferencing pointer to incomplete type tif_ojpeg.c:1424: error: dereferencing pointer to incomplete type tif_ojpeg.c:1425: error: dereferencing pointer to incomplete type tif_ojpeg.c:1426: error: dereferencing pointer to incomplete type tif_ojpeg.c:1428: error: ‘DSTATE_INHEADER’ undeclared (first use in this function) tif_ojpeg.c:1428: error: (Each undeclared identifier is reported only once tif_ojpeg.c:1428: error: for each function it appears in.) tif_ojpeg.c:1508: error: dereferencing pointer to incomplete type make[2]: *** [tif_ojpeg.o] Error 1 make[2]: Leaving directory `/var/tmp/portage/media-tv/xbmc-9.04/work/XBMC_9.04_Babylon-linux-osx-win32/xbmc/lib/cximage-6.0/tiff' make[1]: *** [tiff/tiff.a] Error 2 make[1]: Leaving directory `/var/tmp/portage/media-tv/xbmc-9.04/work/XBMC_9.04_Babylon-linux-osx-win32/xbmc/lib/cximage-6.0' make: *** [imagelib] Error 2
(In reply to comment #2) > Stupid program to demo the issue (NB: I am not a coder): > > #include <stdio.h> > #include <stdlib.h> > > #define JPEG_INTERNALS = 1; > #include <jpeglib.h> > > int main (void) > { > return 0; > } > Because jpeglib.h has the following, /* * The JPEG library modules define JPEG_INTERNALS before including this file. * The internal structure declarations are read only when that is true. * Applications using the library should not include jpegint.h, but may wish * to include jerror.h. */ #ifdef JPEG_INTERNALS #include "jpegint.h" /* fetch private declarations */ #include "jerror.h" /* fetch error codes too */ #endif It's clearly not meant to be used and that's why only jerror.h is installed into the system.
Sorry... :/ Just trying to help, if this is not a bug or is stupid in some way, feel free to close.
(In reply to comment #8) > Just trying to help, if this is not a bug or is stupid in some way, feel free > to close. It's a bug in xbmc :)
Here's the XBMC bug report: http://xbmc.org/trac/ticket/7096 XBMC isn't being particular cooperative in fixing this issue, so if a Gentoo developer (or anyone else) wants to submit a patch, that would be quite amazing.
(In reply to comment #10) > Here's the XBMC bug report: http://xbmc.org/trac/ticket/7096 XBMC isn't being > particular cooperative in fixing this issue, so if a Gentoo developer (or > anyone else) wants to submit a patch, that would be quite amazing. > At http://xbmc.org/trac/ticket/7096 a patch was posted, could this one easily be included into the official ebuild build process?
if the patch is correct, it'll get merged soon. if it isnt, then i'm not adding it to the ebuild.
If the bug hasn't been fixed, shouldn't the bug report not be closed? I agree that you shouldn't include the patch in the ebuild, but isn't this bug report still valid, and should remain open, until the problem is actually solved?
it is resolved: get it fixed upstream. i'm not adding anything to the live svn ebuild because as soon as they add it upstream, it'll get included automatically.
*** Bug 284597 has been marked as a duplicate of this bug. ***
*** Bug 288128 has been marked as a duplicate of this bug. ***
Shouldn't xbmc-9.04.1 depend on <jpeg-7 then for now?
*** Bug 289877 has been marked as a duplicate of this bug. ***
(In reply to comment #17) > Shouldn't xbmc-9.04.1 depend on <jpeg-7 then for now? > No. The downgrade-upgrade cycle would break pkgs over and over again. The patch is correct in http://xbmc.org/trac/ticket/7096, except it should be for Makefile.am instead of Makefile.in. Sabayon is applying it that way, and it works.
*** Bug 289966 has been marked as a duplicate of this bug. ***
Created attachment 207805 [details] Use system libraries to avoid defining JPEG_INTERNALS which is causing jpegint.h to be wanted. http://gitweb.sabayonlinux.org/?p=overlay.git;a=tree;f=media-tv/xbmc/files;hb=HEAD
For your information, I am still getting this error on amd64.
Any news regarding this bug? I have JUST sync'ed my box (and it's 11/18 already) and it fails to compile XBMC due to that very problem. No patch submitted yet? I mean like, I never really know what steps to go through to patch installation files. It's hard for me to remember and I always forget to write a self documentation for doing that. :-) What I mean is: when will this be solved inside portage, so that I just hit "emerge xbmc" and it patches what has to be patched all by itself and I just get a good'old updated XBMC? Regards!
This bug was fixed upstream. If you're running xbmc-9999, you should be fine.
(In reply to comment #24) > This bug was fixed upstream. If you're running xbmc-9999, you should be fine. Oh, I see. I have been trying to compile 9.04. :-) One question, though: I've read on the web that even people that got it working, said that it takes some time to load the images inside xbmc (a.k.a poor performance). Do you know anything about that? I'm asking this (instead of checking it right away) exactly because I'm 300km away from my box. Will go to my home town only on Saturday! :-)
*** Bug 293842 has been marked as a duplicate of this bug. ***
Can someone please explain what happens from here? Does "resolved upstream" mean there will be no fix for 9.04.1? If not, what is the best way install xbmc-9999? Unmasking it in /etc/portage does not work. Instructions would be great. Can we expect a build of 9.11 beta or will a new build appear after 9.11 final? Cheers.
*** Bug 295299 has been marked as a duplicate of this bug. ***
I'd really appreciate someone telling me how to install 9999 without hacking up an overlay. The 9999 build doesn't unmask like a normally masked package, the ebuild needs some tweaking before it even looks like working. As it stands, unless someone knows to put jpegint.h into /usr/include the 9.04.1 build is broken. I don't understand how "resolved upstream" means that this is ok for ~x86 users now that media-libs/jpeg-7 is stable. I am happy to stand corrected, but I fail to see how this is fixed without further explanation.
(In reply to comment #29) > I'd really appreciate someone telling me how to install 9999 without hacking up > an overlay. > > The 9999 build doesn't unmask like a normally masked package, the ebuild needs > some tweaking before it even looks like working. You need to add the following to package.keywords. Note the ** which is explained in the portage man page. media-tv/xbmc **
(In reply to comment #30) > You need to add the following to package.keywords. Note the ** which is > explained in the portage man page. > > media-tv/xbmc ** Adding media-tv/xbmc to package.keywords does not cause xbmc-9999 to appear as an update.
(In reply to comment #31) > Adding media-tv/xbmc to package.keywords does not cause xbmc-9999 to appear as > an update. It should work since I have no problem with installing xbmc-9999. Did you add exactly what I posted previously to package.keywords, including the ** ? Do not remove or replace ** with your arch as doing so will not allow you to install xbmc-9999. You need to do this since xbmc-9999 has not been keyworded and the ** notation causes KEYWORDS to be ignored. If you still have issues with this you should post to the Gentoo forum since xbmc-9999 does work and this is not the best place to discuss your problem.
(In reply to comment #32) > remove or replace ** with your arch as doing so will not allow you to install > xbmc-9999. You need to do this since xbmc-9999 has not been keyworded and the > ** notation causes KEYWORDS to be ignored. Apologies for not fully reading the man page, this has worked exactly as you describe. I've been a Gentoo user for ~5 years and have never seen or used it. > If you still have issues with this you should post to the Gentoo forum since > xbmc-9999 does work and this is not the best place to discuss your problem. I'd still like to know what the future of this package is, as I said the 9.04.1 build is still broken and only by un-keywording as you describe above allows someone to get xbmc installed.
(In reply to comment #33) > Apologies for not fully reading the man page, this has worked exactly as you > describe. I've been a Gentoo user for ~5 years and have never seen or used it. No problem. I'm guessing many users wouldn't know about this syntax since it's only really needed when a package hasn't been keyworded. > I'd still like to know what the future of this package is, as I said the 9.04.1 > build is still broken and only by un-keywording as you describe above allows > someone to get xbmc installed. Since I've only used xbmc-9999 I don't know if the 9.04.1 ebuild is working. If it isn't, then I guess you should use this bug. Hopefully the dev responsible will notice it.
this is not a support forum. if you dont know how to install packages, go ask on a user mailing list / forum. xbmc-9999 builds just fine for me. if someone wants to put together a simple patch for 9.04.1, i'll add it. otherwise i'm inclined to simply punt that version. perhaps Samuli's works, so someone should test it and report success/failure
Failure (used -j1 to make sure bug 284588 was not a problem): make[2]: Leaving directory `/mnt/gentoo/build/portage/media-tv/xbmc-9.04.1/work/9.04.1_Babylon-linux-osx-win32/XBMC/xbmc/lib/cximage-6.0/zlib' x86_64-pc-linux-gnu-g++ -shared -o ../../../system/ImageLib-x86_64-linux.so -Wl,--whole-archive -lpng -ljasper -ljpeg -ljbig -ltiff \ CxImage/cximage.a raw/raw.a zlib/libz.a -Wl,--no-whole-archive \ `cat ../../cores/DllLoader/exports/wrapper.def` \ ../../cores/DllLoader/exports/wrapper.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -ljbig collect2: ld returned 1 exit status make[1]: *** [../../../system/ImageLib-x86_64-linux.so] Error 1 make[1]: Leaving directory `/mnt/gentoo/build/portage/media-tv/xbmc-9.04.1/work/9.04.1_Babylon-linux-osx-win32/XBMC/xbmc/lib/cximage-6.0' make: *** [imagelib] Error 2
then install jbig
Then add it to dependencies ;) Installing jbigkit with patch from this bug solved the issue for me.
adding the dep to the current ebuild makes no sense at all. if you want to actually test the patch, you must emerge the new dependencies yourself.
Created attachment 213032 [details] XBMC error log from attempted emerge on 12/14/09 Attempted to emerge XBMC today, failed. Attached is the build.log file.
xbmc-9.04* has been punted
