tutorial for Windows

Ralf Habacker ralf.habacker at freenet.de
Fri Mar 4 08:09:39 PST 2011


Am 03.03.2011 08:21, schrieb Vincent Torri:
>
>
> On Thu, Mar 3, 2011 at 1:15 AM, Romain Pokrzywka 
> <romain.pokrzywka at kdab.com <mailto:romain.pokrzywka at kdab.com>> wrote:
>
>
>     On Tuesday 01 March 2011 09:01:09 Vincent Torri wrote:
>     > Hey,
>     >
>     > On Tue, Mar 1, 2011 at 2:04 AM, Romain Pokrzywka
>     >
>     > <romain.pokrzywka at kdab.com <mailto:romain.pokrzywka at kdab.com>>wrote:
>     > > On Monday 28 February 2011 12:07:40 Vincent Torri wrote:
>     > > > Hey,
>     > > >
>     > > > On Mon, Feb 28, 2011 at 4:59 PM, Romain Pokrzywka
>     > > > <romain.pokrzywka at kdab.com <mailto:romain.pokrzywka at kdab.com>
>     > > >
>     > > > > wrote:
>     > > > >
>     > > > > Hi Vincent,
>     > > > >
>     > > > > If you just want to make sure the bus starts up correctly,
>     you can
>     > > > > open
>     > >
>     > > a
>     > >
>     > > > > console and go to the bin folder where dbus
>     > > > > was build, then try running:
>     > > >
>     > > > they are in my PATH.
>     > > >
>     > > > > dbus-daemon.exe --session
>     > > >
>     > > > done
>     > > >
>     > > > > which starts up the bus, then :
>     > > > >
>     > > > > dbus-monitor
>     > > > >
>     > > > > It should print out some info, that means your bus is up
>     and running,
>     > >
>     > > and
>     > >
>     > > > > ready to register services objects.
>     > > >
>     > > > actually, no. I have:
>     > > >
>     > > > $ dbus-monitor.exe
>     > > > Failed to open connection to session bus: Failed to get
>     autolaunch
>     > >
>     > > address
>     > >
>     > > > from launched dbus-daemon
>     > > >
>     > > > in the Task manager, I see one dbus-daemon launch by
>     dbus-daemon.exe
>     > > > --session. Then when i launch bus-monitor.exe, I see 2 others
>     > > > dbus-daemon.exe processes, one terminated almost immediatly
>     (so it
>     > >
>     > > remains
>     > >
>     > > > 2 dbus-daemon.exe processes running).
>     > > >
>     > > > That's all I can say.
>     > >
>     > > Thanks for the info.
>     > > Weird, that sounds like dbus-monitor was built with a
>     different version
>     > > than dbus-daemon. The symptoms you describe
>     > > indicate that dbus-monitor doesn't recognize the running
>     daemon, which is
>     > > normally a built-in mechanism.
>     > > I suppose you don't have any other dbus builds in your path,
>     or previous
>     > > installations, and that you didn't modify the
>     > > file etc/session.conf  ?
>     >
>     > I have no other dbus installation. It didn't even know there was a
>     > session.conf. This file is located /usr/local/etc/dbus-1
>     >
>     > > Otherwise it sounds like a problem related to the options
>     passed (or not)
>     > > when building dbus. Can you provide us with
>     > > the following :
>     > >
>     > > - which source version you used (1.4.x ?)
>     >
>     > 1.4.6
>     >
>     > > - what build tool you used : cmake or automake
>     >
>     > autotools
>     >
>     > > - which command line options you passed it
>     >
>     > --with-xml=libxml
>     >
>     > I have libxml2, and there was no error messages during
>     configuration.
>     > Should I use expat ?
>     >
>     > Vincent Torri
>
>     Ok, thanks for the additional info.
>
>     I personally use expat, but I think libxml should work fine too.
>
>
> I tried with expat, same problem
>
>     My gut feeling is that there is a wrong default in the autotools
>     build options, so the resulting dbus-daemon doesn't
>     work out-of-the-box. Could you try building with cmake instead maybe ?
>
>
> I've never succeeded in using cmake on Windows. Anyway, if there is a 
> problem with the autotools, it must be fixed.
>
>
>     Also, it looks like you're using msys or cygwin as the shell to
>     build and run the tests, as you mention
>     /usr/local/etc/dbus-1. I'm not sure this is a supported/tested
>     scenario, especially with the path-based scoping
>     mechanism for the daemon and clients.
>
>
> On Windows, The autotools can be used only with MSYS or cygwin. I use 
> MSYS.
>
> If this is not a supported scenario, where should I copy the data 
> (sessions.conf and other data files) ?
>
> Anyway, I just remarked that there is a README.win. He talks about 
> unit test. I enabled them (configure command: ./configure 
> --with-xml=expat --enable-tests --enable-verbose-mode). I tried 
> dbus-test check
>
> the README.win says that dbus-test.exe is installed in some bin/ 
> directory. It is not the case. It seems normal as in dbus/Makefile.am, 
> there is a noinst_PROGRAMS=$(TESTS) and no hook is done to install it 
> in another directory
>
> I run it from top level dir :
>
> ./dbus/.libs/dbus-test test/data
>
> and I get
>
> ----------------
>
> torri at CARO-50BC2B3960 ~/tmp/dbus-1.4.6
> $ ./dbus/.libs/dbus-test.exe test/data
> Test data in test/data
> dbus-test: running string tests
> dbus-test: checking for memleaks
> dbus-test: running sysdeps tests
> dbus-test: checking for memleaks
> dbus-test: running data-slot tests
> dbus-test: checking for memleaks
> dbus-test: running misc tests
> dbus-test: checking for memleaks
> dbus-test: running address tests
> dbus-test: checking for memleaks
> dbus-test: running server tests
> dbus-test: checking for memleaks
> dbus-test: running object-tree tests
> dbus-test: checking for memleaks
> dbus-test: running signature tests
> dbus-test: checking for memleaks
> dbus-test: running marshalling tests
> dbus-test: checking for memleaks
> recursive marshal tests disabled
> dbus-test: running byteswap tests
>   120 blocks swapped from order 'l' to 'B'
>   120 blocks swapped from order 'B' to 'l'
> dbus-test: checking for memleaks
> dbus-test: running memory tests
> dbus-test: checking for memleaks
> dbus-test: running mem-pool tests
> dbus-test: checking for memleaks
> dbus-test: running list tests
> dbus-test: checking for memleaks
> dbus-test: running marshal-validate tests
> dbus-test: checking for memleaks
> dbus-test: running marshal-header tests
> dbus-test: checking for memleaks
> dbus-test: running message tests
> process 3508: dbus message iterator looks uninitialized or corrupted
> Backtrace:
> 3       KiIntSystemCall+0x6
> 3       WaitForSingleObject+0x12
> 2       dbus-test.exe+0x21875
> 2       dbus-test.exe+0xb897
> 2       dbus-test.exe+0x2c65c
> 2       dbus-test.exe+0x1e42c
> 2       dbus-test.exe+0x1e392
> 2       dbus-test.exe+0x37bdd
> 2       dbus-test.exe+0x1faa5
> 2       dbus-test.exe+0x44e0d
> 2       dbus-test.exe+0x36422
> 2       dbus-test.exe+0x42906
> 2       dbus-test.exe+0x10db
> 2       dbus-test.exe+0x1178
> 3       RegisterWaitForInputIdle+0x49
>
> This application has requested the Runtime to terminate it in an 
> unusual way.
> Please contact the application's support team for more information.
>
> ----------------
>
> I tried with a MSYS terminal or a Windows console, same result. I stop 
> here as it seems that there is a seg fault, here, which is very bad. 
> Is there any way to debug that ?

execute in a command shell

set DBUS_VERBOSE=1

before running any dbus related apps.

BTW: In <build-root>/bus  shere should be a session.conf, which includes 
the address where dbus-daemon is listening to. Normally this will be 
installed somewhere. like .../etc/dbus-1

Ralf


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/dbus/attachments/20110304/c5913667/attachment-0001.htm>


More information about the dbus mailing list