From kde-core-devel  Fri Apr 20 17:46:04 2001
From: Waldo Bastian <bastian () kde ! org>
Date: Fri, 20 Apr 2001 17:46:04 +0000
To: kde-core-devel
Subject: Re: Problems starting kde 2.1 on Cygwin/Win32
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=98779357825394

On Thursday 20 April 2000 02:18, Ralf Habacker wrote:
> Hi,
> I'm porting kde2.1 with cygwin and Xfree68 on Windows 2000 with (at now) a
> static compiled version compiled. (KDE1.1.2 ist running in an alpha state
> on Windows 2000.)
>
> Now I have problem to start kde. Dcopserver is running, but kdeinit could
> not communcate with kded (see message later)
>
> My question is where I can found informations to get minimal requirements

Here on this list :-)

> (application, files,..) and verifying steps to get running kde and how to
> debug if problems. I have called some test programms shipped with kdelibs
> and kdebase , but I don't know which i have to run first, second, next and
> so one.

There are two important things that you need to get going. DCOP communication 
and shared libraries.

DCOP is the easiest to start with because it doesn't depend on anything else.
Once you have built dcopserver, you should be able to compile & run 
"testdcop". If you have two terminal windows open, you should be able to 
start "testdcop" in one, and if you then start "testdcop" in the other, you 
should see that the first one gets called. You probably want to have a look 
at how testdcop behaves on Unix machine first, so that you know what to 
expect.

As far as shared libraries go. You must be able to compile KDE modules and 
libraries as shared libraries. This is mostly a matter of fixing libtool. 
Once you have done that you should be able to start "kdeinit" and then 
kdeinit should be able to load e.g. "dcopserver.la".

kdeinit always tries to load an applications as a shared module first, if 
that doesn't work, it will try to execute a normal executable.

Eg. in your log you have:
"Could not dlopen library dcopserver.la: no symbols defined
 Could not load library! Trying exec...."

This means that it tries to open "dcopserver.la" as a module first. However 
that fails, and then it falls back to running the "dcopserver" executable.

"kdeinit: Launched DCOPServer, pid = 3192 result = 0
_IceTransmkdir: Owner of /tmp/.ICE-unix should be set to root"

The above is an indication that running the "dcopserver" executable indeed 
worked and that it is running. The second line is a harmless warning.

"Could not dlopen library klauncher.la: no symbols defined
 Could not load library! Trying exec....
 kdeinit: Launched KLauncher, pid = 2736 result = 0"

This is the same sequence, but now for klauncher. First it tries to open a 
shared module "klauncher.la" but that doesn't work. Then it falls back to 
running the "klaucnher" executable, which works.

"Could not dlopen library kded.la: no symbols defined
 Could not load library! Trying exec....
 kdeinit: Launched KDED, pid = 2348 result = 0"

Same for kded.

" ??? kdeinit: Communication error with launcher. Exiting!"

This is bad. Normally kdeinit starts new processes by forking and then 
loading a shared modules or executing the binary. It gets told by klauncher 
when and what applicatins to start. It uses a pipe between kdeinit and 
klauncher to communicate. This error indicates that this pipe is broken. A 
reason for that could be that klauncher crashed.
 
"Debug: DCOP: register 'anonymous-3124' -> number of clients is now 1"
 
This is good. This is an indication that clients can actually communicate 
with the dcopserver.

"??? Very strange! got a DCOPReply opcode, but we were not waiting for a
 reply!"

Are you using the released sources of KDE 2.1 cq. 2.1.1? I have seen this 
error when using the wrong ICE major opcode for DCOP communication. Both X 
Session Management (XSM) as well as DCOP are based on ICE. XSM should get 
major opcode 0 and DCOP should get opcode 1. This normally works fine if you 
register Session Management first and then DCOP. However, if you don't do 
session management, you tend to get major opcode 0 for DCOP. To workaround 
this situation there is a hack in the DCOPServer constructor that registers 
XSM if it wasn't already registered.

Please also note that for KDE 2.2 we are using a modified implementation of 
ICE (instead of the systems libICE) for DCOP to solve some buffering problems.
You might get better/worse/different results with that one.

Cheers,
Waldo
-- 
bastian@kde.org | SuSE Labs KDE Developer | bastian@suse.com