1 Feb
2012
1 Feb
'12
10:29 a.m.
Hey,
On Sun, January 29, 2012 18:03, E. Liddell wrote:
*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.) Probably an arch-dependant error.. i can test this
again on x86 this week
and then report upstream/open a bug-report.
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.
Well.. the only other possibility would be to
set up a clean overlay, put
the existing cmake ebuilds there and fill in the rest like kaffeine etc.
and then slowly convert them as serghei or someone else seems fit to do
so.
But for this we need first some documentation/specification about
paths/names etc... i don't think it is a good idea to put trinity into the
old /usr/kde/3.5 path we should use sth. like /usr/tde or /opt/tde i am
not sure what really is FSFE compliant.
Btw. what is the correct location for qt3? Is it really /usr/qt/3? I think
i remember qt4 installs to /usr/lib/qt4 That should also be fixed...
Just some thoughts...
I have setup an empty github repository which i wanted to start fresh and
add correct mirrors etc. before commiting anything else.
If you want, we could put our efforts into that repo (
https://github.com/strowi/tde )
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 . . .
Maybe we should post this to the
gentoo-desktop list (which i really need
to re-subscribe) i think i remember that there was at least one other
person that was interested in this (not sure if it was a dev).
Say, which arch are you on?
I'm on
amdfam10. 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.
After looking into the eclass i found that there is a QTDIR-variable.
That
one should be responsible for the qt-stuff. I will check that also.
greetings,
Roman
--