I’ve tried porting KDE to the RTP just for the fun of it, Qt and
kdelibs compiled and build without too much hassles (well, minus the
hassles inflicted with only half the sockets functionality available as
in missing socketpair() etc). Qt even went thru the test suite with
flying colors, thats were kde came to a screeching halt. Any of the test
application crashes with a SIGSEGV, when running thru gdb it doesn’t
even make it into main().
Gdb, when asked to set a break at main() reports “internal error: no
C/C++ fundamental type 1”, but sets the breakpoint. When asked to cont
the application receives a SIGSEGV.
Any ideas ? Anyone got success getting that beast to run ?
: I’ve tried porting KDE to the RTP just for the fun of it, Qt and
: kdelibs compiled and build without too much hassles (well, minus the
: hassles inflicted with only half the sockets functionality available as
: in missing socketpair() etc). Qt even went thru the test suite with
: flying colors, thats were kde came to a screeching halt. Any of the test
: application crashes with a SIGSEGV, when running thru gdb it doesn’t
: even make it into main().
: Gdb, when asked to set a break at main() reports “internal error: no
: C/C++ fundamental type 1”, but sets the breakpoint. When asked to cont
: the application receives a SIGSEGV.
: Any ideas ? Anyone got success getting that beast to run ?
Internally the mighty cburgess has managed to get almost all
of the KDE environment going (I think that the filemanager
was a bit of a show stopper since it required unix domain
socket support … which we are working on!). If anyone
is able to comment it will be him, don’t despair though, it
is certainly possible.
: I’ve tried porting KDE to the RTP just for the fun of it, Qt and
: kdelibs compiled and build without too much hassles (well, minus the
: hassles inflicted with only half the sockets functionality available as
: in missing socketpair() etc). Qt even went thru the test suite with
: flying colors, thats were kde came to a screeching halt. Any of the test
: application crashes with a SIGSEGV, when running thru gdb it doesn’t
: even make it into main().
: Gdb, when asked to set a break at main() reports “internal error: no
: C/C++ fundamental type 1”, but sets the breakpoint. When asked to cont
: the application receives a SIGSEGV.
: Any ideas ? Anyone got success getting that beast to run ?
Internally the mighty cburgess has managed to get almost all
of the KDE environment going (I think that the filemanager
was a bit of a show stopper since it required unix domain
socket support … which we are working on!). If anyone
is able to comment it will be him, don’t despair though, it
is certainly possible.
: I’ve tried porting KDE to the RTP just for the fun of it, Qt and
: kdelibs compiled and build without too much hassles (well, minus the
: hassles inflicted with only half the sockets functionality available as
: in missing socketpair() etc). Qt even went thru the test suite with
: flying colors, thats were kde came to a screeching halt. Any of the test
: application crashes with a SIGSEGV, when running thru gdb it doesn’t
: even make it into main().
: Gdb, when asked to set a break at main() reports “internal error: no
: C/C++ fundamental type 1”, but sets the breakpoint. When asked to cont
: the application receives a SIGSEGV.
: Any ideas ? Anyone got success getting that beast to run ?
Internally the mighty cburgess has managed to get almost all
of the KDE environment going (I think that the filemanager
was a bit of a show stopper since it required unix domain
socket support … which we are working on!). If anyone
is able to comment it will be him, don’t despair though, it
is certainly possible.
What, even kdevelop ? I’ll pay a 2 month supply of beer to anyone who has a
working version of kdevelop under RTP and is willing to share. Just to get to
satisfy the Micros~1 weenies in our company…
: I’ve tried porting KDE to the RTP just for the fun of it, Qt and
: kdelibs compiled and build without too much hassles (well, minus the
: hassles inflicted with only half the sockets functionality available as
: in missing socketpair() etc). Qt even went thru the test suite with
: flying colors, thats were kde came to a screeching halt. Any of the test
: application crashes with a SIGSEGV, when running thru gdb it doesn’t
: even make it into main().
: Gdb, when asked to set a break at main() reports “internal error: no
: C/C++ fundamental type 1”, but sets the breakpoint. When asked to cont
: the application receives a SIGSEGV.
: Any ideas ? Anyone got success getting that beast to run ?
Internally the mighty cburgess has managed to get almost all
of the KDE environment going (I think that the filemanager
was a bit of a show stopper since it required unix domain
socket support … which we are working on!). If anyone
is able to comment it will be him, don’t despair though, it
is certainly possible.
What, even kdevelop ? I’ll pay a 2 month supply of beer to anyone who has a
working version of kdevelop under RTP and is willing to share. Just to get to
satisfy the Micros~1 weenies in our company…
I’ve tried porting KDE to the RTP just for the fun of it, Qt and
kdelibs compiled and build without too much hassles (well, minus the
hassles inflicted with only half the sockets functionality available as
in missing socketpair() etc). Qt even went thru the test suite with
flying colors, thats were kde came to a screeching halt. Any of the test
application crashes with a SIGSEGV, when running thru gdb it doesn’t
even make it into main().
Gdb, when asked to set a break at main() reports “internal error: no
C/C++ fundamental type 1”, but sets the breakpoint. When asked to cont
the application receives a SIGSEGV.
If it’s crashing before main, then the most likely problem is that
you have accidentally built one of the shared libraries without
the -fpic or -shared option. This will cause a relocation to made
on the text, which is read-only, and thus will SIGSEGV.
The easiest way to check your libs is to use objdump
objdump -x libkdecore.so | less
and look for rel.rodata or something like that. If you have them,
then that is the problem.
Apart from the lack of SVR4 shm functions (for the audio stuff) and
the UNIX domain sockets (yay Thomasf!), the only annoying problems
where getrlimit (used for setting the max to select - the code
wasn’t checking the return value, and getting garbage), and
mmap (some of the edit dialog stuff uses mmap to map into a file,
and we don’t support synced mmap - you need MAP_NOSYNCFILE).
However, the code didn’t actually need it to be properly synced, they
copied it later, so adding the missing flag fixed that.
Once Thomasf has PF_UNIX going, kfm should work fine - I had it hacked
up to use local PF_INET sockets, but it was a pretty gross hack.
What, even kdevelop ? I’ll pay a 2 month supply of beer to anyone who has a
working version of kdevelop under RTP and is willing to share. Just to get to
satisfy the Micros~1 weenies in our company…
What, even kdevelop ? I’ll pay a 2 month supply of beer to anyone who has a
working version of kdevelop under RTP and is willing to share. Just to get to
satisfy the Micros~1 weenies in our company…
Mmmmmmmm, beer!
Yes, I have kdevelop. It seems to work reasonably well.
The main things that are missing are the doc building utils (seem to
be hard to find other than linux binaries, and I don’t have a lot
of spare time).
I don’t really have the time to look after the KDE port - but if anyone
wants to take over, I’m more than happy to help with issues, and share
the things I found whilst porting it.
kdevelop was actually pretty easy to get up and running, and apart
from the dialog editor co-exists happily with the root-less Xphoton.
What, even kdevelop ? I’ll pay a 2 month supply of beer to anyone who has a
working version of kdevelop under RTP and is willing to share. Just to get to
satisfy the Micros~1 weenies in our company…
Mmmmmmmm, beer!
Yes, I have kdevelop. It seems to work reasonably well.
The main things that are missing are the doc building utils (seem to
be hard to find other than linux binaries, and I don’t have a lot
of spare time).
I don’t really have the time to look after the KDE port - but if anyone
wants to take over, I’m more than happy to help with issues, and share
the things I found whilst porting it.
I did QNX4 port a while ago, so I could probably try to polish your
port. I also remember doing a “gross hack” to use PF_INET as well
As for SYSV IPC I think Steve McPolin wrote a class to encapsulate it
and replaced it with Mqueue. I was using it in my port.
That said, I believe if someone really wants KDE he probably wants to
use it in rooted X. Which means, not to use Photon. The reason I still
did not my own port of KDE is, I wanted to use Photon
I did QNX4 port a while ago, so I could probably try to polish your
port. I also remember doing a “gross hack” to use PF_INET as well >
Eww!!! ;v)
As for SYSV IPC I think Steve McPolin wrote a class to encapsulate it
and replaced it with Mqueue. I was using it in my port.
Yeah - I heard some rumours about this. I will investigate.
That said, I believe if someone really wants KDE he probably wants to
use it in rooted X. Which means, not to use Photon. The reason I still
did not my own port of KDE is, I wanted to use Photon >
Exactly. However, a lot of the kde utils are handy in the rootless
photon.
