29 Jan
2012
29 Jan
'12
5:03 p.m.
On Sun, 29 Jan 2012 16:45:28 +0100
"roman" <lists(a)hasnoname.de> wrote:
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.)
On Sun, January 29, 2012 16:38, E. Liddell wrote:
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 . . .
You are
right about the organized effort.
Yeah. Problem is that no one seems to want the job of organizer
(including
me!). 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? 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.