Summary: | media-libs/mlt-0.8.0 - kdenlivetitle_wrapper.cpp:23:24: fatal error: QtGui/QImage: No such file or directory | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Jan-Erik Skata <jeskata> |
Component: | [OLD] Library | Assignee: | Gentoo Media-video project <media-video> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | konstantin, M4rkusXXL, thomas |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | Build log |
Description
Jan-Erik Skata
2012-07-21 18:12:47 UTC
While the first error is: kdenlivetitle_wrapper.cpp:23:24: fatal error: QtGui/QImage: No such file or directory I'd say it's INVALID due to: /usr/qt/3/include/qvaluelist.h:91:13: error: 'ptrdiff_t' does not name a type (and similar). This must be the reason; "Qt version 3.x detected, will compile Qt3 qimage producer", and no Qt 3 is installed. I had the directory /usr/qt/3 left on my system, renamed it while I compiled mlt and now it worked. This bug should not be closed as resolved invalid. It is a bug in mlt to try to compile against a qt it can't work with. I have a working qt3 on my system and I need it so removing it is not an option. Temporarily renaming is good as a workaround but not as a solution. When mlt tries to compile against qt3 and fails, then it should be patched to not try this. So please reopen this bug. (In reply to comment #3) > It is a bug in mlt to try > to compile against a qt it can't work with. I have a working qt3 on my > system and I need it so removing it is not an option. This is an upstream bug, please report it at the mlt developers. From the Gentoo side we don't support Qt3 anymore. (In reply to comment #4) > (In reply to comment #3) > > It is a bug in mlt to try > > to compile against a qt it can't work with. I have a working qt3 on my > > system and I need it so removing it is not an option. > > This is an upstream bug, please report it at the mlt developers. > From the Gentoo side we don't support Qt3 anymore. +1 at least in any case the old way Gentoo used to put Qt3 directly in /usr is definately not supported. that path is long gone. if user reallyreally still needs Qt3 for some application, he should put it in, for example, /home/user/Qt3 and then point apps to it by LD_LIBRARY_PATH and so forth so it's out of the way for anything coming from Portage (In reply to comment #4) > (In reply to comment #3) > This is an upstream bug, please report it at the mlt developers. > From the Gentoo side we don't support Qt3 anymore. Yes, it's an upstream bug but one of portages virtues is the ability to patch things as needed and patching upstream shortcomings is what every other ebuild does ;-). I could contact upstream but who knows if and when they will fix this. So providing a patch is probably a more effective way. (In reply to comment #5) > (In reply to comment #4) > at least in any case the old way Gentoo used to put Qt3 directly in /usr is > definately not supported. that path is long gone. > > if user reallyreally still needs Qt3 for some application, he should put it > in, for example, /home/user/Qt3 and then point apps to it by LD_LIBRARY_PATH > and so forth so it's out of the way for anything coming from Portage I might disagree there a little. IMHO a better way to have additional packages not in official portage is to have them in a portage overlay and not to dump them all over the system. So maintenance (revdep-rebuild etc.) works as expected and needed. By the way, I am managing the working environment in the company so having manual packages is really not an option. I still consider it a bug in an program/package/ebuild/... when it tries to use something it can't deal with. So saying like "it's out of official portage so we don't care" seems a bit short sighted to me. I know Jan-Erik and me are a very small fraction of the community but at least all using kde-sunset could be affected. On the other hand I could understand when you would say something like "as this affects only a minority the devs have no time to deal with it". In this case I can offer to provide a patch for this myself. So how do you want to proceed? Overlays follow the tree, not the otherway around, so any patches would go to Qt3 and altering it's installation so that it doesn't get in a way of anything installed from Portage (In reply to comment #6) > (In reply to comment #4) > > (In reply to comment #3) > > This is an upstream bug, please report it at the mlt developers. > > From the Gentoo side we don't support Qt3 anymore. > > Yes, it's an upstream bug but one of portages virtues is the ability to > patch things as needed and patching upstream shortcomings is what every > other ebuild does ;-). I could contact upstream but who knows if and when > they will fix this. So providing a patch is probably a more effective way. We prefer things like this to be reported upstream first, and see their reaction. If still necessary, we can apply a patch ourselves (or take one already applied in VCS upstream). That said, I have become the de facto maintainer of this package (tho anyone else can feel free to step up), but I use neither mlt nor Qt3. So we would rely on you to provide us a patch. (In reply to comment #9) > (In reply to comment #6) > We prefer things like this to be reported upstream first, and see their > reaction. If still necessary, we can apply a patch ourselves (or take one > already applied in VCS upstream). > > That said, I have become the de facto maintainer of this package (tho anyone > else can feel free to step up), but I use neither mlt nor Qt3. So we would > rely on you to provide us a patch. Thanks. Then I'll try to get some feedback from upstream and will report here. I can test the fix(es) as I'm using qt3 in x86 and amd64. |