Hi! On Sat, 2010-06-12 at 22:01 +0200, [email protected] wrote:
> I can compile VLC without the Qt4 GUI, making cvlc work. The reason is very simple: the developers migrate to newer distributions that ship newer Qt that comes with new features and bug fixes. The interface resource files format is not backwards compatible, so it's a constant pain to make sure that things still work on older distributions. No developers use RHEL 5 anymore, so they just don't care whether it still works there or not. > I started changing and backporting the failing QT4 code, but stopped > again. I guess the code was changed for a reason and I have no clue > what impact changing the code from Qt 4.4.0 back to Qt 4.2.1 code > (from vlc 0.9.8). This is something I did for SMPlayer when I was still using CentOS for multimedia and wanted a decent recent mplayer front-end. It's a heroic effort and you need some expertise. If you want to go this route I'd rather had a look at 0.9.9a instead. > BTW: is the GUI working in the vlc-test version in RPMforge (I can see > Dag has produced the vlc-test package). That code is vlc 1.1.0-rc1 and > the backporting from my 1.1.0-rc2 might not be to big a task? No, it doesn't even compile because of some libvorbis incompatibility (I guess), not sure whether this can be fixed. I think the most practical solution would be in fact to come up with static builds of VLC against latest Qt. This is something I did for rtorrent (which requires newer libcurl, but it's simply impossible to provide it for EL5 since it will require the rebuild of the whole system, too many things depend upon Curl). However, this is not exactly trivial and also will take *a lot* time to build (I did build static versions of Qt before...). Probably in an ideal world someone would backport latest Qt to EL5 to install the static libraries into some obscure location (this has to be discussed with knowledgeable people). Dynamic linking is just not an option, since it will be pure hell to fiddle with DYDL_PATHs or hardcoding RPATHs... Then, we would be able to switch all the packages that require newer Qt to buildrequire this package and statically link against its libraries, which will be kind of Qt backporting framework. However, I don't have time and energy do mess with it. I don't need it anymore for myself and I'm not gonna get paid for it. If you want to have a go at it I wish you best of luck... :-) -- Sincerely yours, Yury V. Zaytsev _______________________________________________ suggest mailing list [email protected] http://lists.rpmforge.net/mailman/listinfo/suggest
