Message: previous - next
Month: January 2012

Re: [trinity-users] kaffeine-3.5.13 compilation error

From: "E. Liddell" <ejlddll@...>
Date: Sun, 29 Jan 2012 12:03:09 -0500
On Sun, 29 Jan 2012 16:45:28 +0100
"roman" <lists@...> wrote:

> On Sun, January 29, 2012 16:38, E. Liddell wrote:
> >> You are right about the organized effort.
> >
> > Yeah.  Problem is that no one seems to want the job of organizer
> > (including
> > me!).
> Well.. i don't want it because i don't really have enough knowledge about
> c/c++,cmake,automake etc.. to be competent enough.
> Also the mix from automake/cmake seems to be the biggest to not
> remove/rewrite the eclasses from ground up.
> Maybe we should start with a clean cmake-only overlay to get things
> streamlined? It might take some time to get everything in there, but seems
> to be the only clean solution.

That means we're not going to get anywhere until Serghei finishes
porting, though, which means several more versions of Trinity (and
likely a couple of years) will go by.

I'm not good with C/C++ or their build systems either--I'm a Java/Perl/PHP
programmer by inclination.

The most annoying part is that I'm very, very close to getting this working 
(at least for x86).  I got half of kdetoys to work, frex, but the other half is 
getting hit with what I think is an --as-needed breakage in kdelibs.  If we
could rope in even one competent dev . . .

> >>The ebuild also came down to the following error which seems
> >> to be an code-error?
> >>
> >> kxinewidget.cpp:2641:66: error: invalid conversion from ‘const char*
> >> const*’ to ‘char**’ [-fpermissive]
> >
> > Looks like a code error to me, too . . .  Pointer casting like this is one
> > of
> > the reasons I hate C/C++--in a sane language, that would never have
> > compiled to begin with, and the original coder would have had to fix it.
> >
> > Say, which arch are you on?
> I'm on amdfam10.

*Ah.*  While my actual machine is also amdfam10, the virtual machine
I've been using to test Trinity is set up as x86, not x86_64.  So we may
be seeing a pointer cast that works under 32bit but breaks with 64bit.
(And if I were just a bit better with this, that might be enough to tell me
how to fix it . . .  Grrr.)
> BTW it also seems that there are problems detecting the correct qt-path
> when qt4 is installed (just tried installing sopcast, to watch the
> handball-em final, it's not being broadcasted in germany;( ).

I think there have been reports of that being a problem on other distros
as well, probably from the Slackware packager.  It might be possible to
filter the QT4 directory out of the path before building (it doesn't seem
to install to /lib, thankfully), but it's going to take some work to figure
out how.