dbus-cxx-users — For those using the dbus-cxx library in their applications

Re: [Dbus-cxx-users] compile problem

[Daren S. W. <da...@da...>]

On 06/25/10 10:08, Rick L. Vinyard, Jr. wrote:
>
> In dbus-cxx-config.h between these three, which is defined?
>
> /* If defined, boost library smart pointers will be used */
> /* #undef DBUS_CXX_USE_BOOST_SMART_POINTER */
>
> /* If defined c++0x smart pointers will be used */
> #ifndef DBUS_CXX_USE_CXX0X_SMART_POINTER
> #define DBUS_CXX_USE_CXX0X_SMART_POINTER  /**/
> #endif
>
> /* If defined TR1 smart pointers will be used */
> /* #undef DBUS_CXX_USE_TR1_SMART_POINTER */
>
>
>
>    

DBUS_CXX_USE_BOOST_SMART_POINTER is defined (but not given a value).  The other two are not.

Re: [Dbus-cxx-users] compile problem

[Rick L. V. Jr. <rvi...@cs...>]

Daren Scot Wilson wrote:
> --
>
> Daren Scot Wilson
> Orlando FL^H^H^H^H^H^H^H^H^H^H Socorro NM
>
>
> On 06/24/10 08:50, Rick L. Vinyard, Jr. wrote:
>>
>> Hmmm... not sure on this one. It looks like it's not pulling in the
>> header
>> that has uint8_t. That should be in stdint.h which came in with C99.
>>
>> You might check dbus-cxx-config.h and see if the stdint.h line is
>> included.
>>
>>
>
>
> /* Define to 1 if you have the <stdint.h> header file. */
> #ifndef DBUS_CXX_HAVE_STDINT_H
> #define DBUS_CXX_HAVE_STDINT_H  1
>
> I don't see anything anywhere to define this symbol in any way.  But,
> more interesting, I don't see any use of this preprocessor variable -
> expecting to see an "#if" in a .h or .cpp file.

dbus-cxx-config.h is generated by autoconf. That's one of the default
symbols.

>> You might also try adding one of the following to types.h:
>>
>> #include<cstdint>
>>
>> or
>>
>> #include<stdint.h>
>>
>> If that works I'll add it to the next release.
>>
> Adding #include <stdint.h> to types.h solved the problem.  I just stuck
> it in plain before all other #includes, though I suppose in real life it
> ought be be wrapped in an #if/#endif.  I'll leave that to you!
>
> Still it didn't compile but at least it goes much further and presents a
> fresh error:
>     ../dbus-cxx/signal_base.h:107:38: error: field 'm_connection' has
> incomplete type
>

In dbus-cxx-config.h between these three, which is defined?

/* If defined, boost library smart pointers will be used */
/* #undef DBUS_CXX_USE_BOOST_SMART_POINTER */

/* If defined c++0x smart pointers will be used */
#ifndef DBUS_CXX_USE_CXX0X_SMART_POINTER
#define DBUS_CXX_USE_CXX0X_SMART_POINTER  /**/
#endif

/* If defined TR1 smart pointers will be used */
/* #undef DBUS_CXX_USE_TR1_SMART_POINTER */

Re: [Dbus-cxx-users] compile problem

[Daren S. W. <da...@da...>]

-- 

Daren Scot Wilson
Orlando FL^H^H^H^H^H^H^H^H^H^H Socorro NM


On 06/24/10 08:50, Rick L. Vinyard, Jr. wrote:
>
> Hmmm... not sure on this one. It looks like it's not pulling in the header
> that has uint8_t. That should be in stdint.h which came in with C99.
>
> You might check dbus-cxx-config.h and see if the stdint.h line is included.
>
>    


/* Define to 1 if you have the <stdint.h> header file. */
#ifndef DBUS_CXX_HAVE_STDINT_H
#define DBUS_CXX_HAVE_STDINT_H  1

I don't see anything anywhere to define this symbol in any way.  But, 
more interesting, I don't see any use of this preprocessor variable - 
expecting to see an "#if" in a .h or .cpp file.
> You might also try adding one of the following to types.h:
>
> #include<cstdint>
>
> or
>
> #include<stdint.h>
>
> If that works I'll add it to the next release.
>    
Adding #include <stdint.h> to types.h solved the problem.  I just stuck 
it in plain before all other #includes, though I suppose in real life it 
ought be be wrapped in an #if/#endif.  I'll leave that to you!

Still it didn't compile but at least it goes much further and presents a 
fresh error:
    ../dbus-cxx/signal_base.h:107:38: error: field 'm_connection' has 
incomplete type


>
>    

Re: [Dbus-cxx-users] compile problem

[Rick L. V. Jr. <rvi...@cs...>]

Daren Scot Wilson wrote:
> I'm trying to compile dbus-cxx but get a compile error.   Configure ran
> okay, at least I saw no errors, and it made a Makefile.
> Using gcc 4.5.0, on 64-bit Arch Linux.   AFIK, I have all dependencies
> and tools, libs etc are reasonably up to date.  My hunch is either I
> need to feed ./configure some magic cookie, or there's some other dbus
> binding installed with an interfering header file.
>
>
> make  all-am
> make[3]: Entering directory `/usr/local/src/dbus-cxx-0.7.0/dbus-cxx'
> /bin/sh ../libtool --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H -I.
> -I.. -I../. -I../. -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include
> -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include      -g -O2 -MT
> callmessage.lo -MD -MP -MF .deps/callmessage.Tpo -c -o callmessage.lo
> callmessage.cpp
> libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I.. -I../. -I../.
> -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include
> -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -g -O2 -MT
> callmessage.lo -MD -MP -MF .deps/callmessage.Tpo -c callmessage.cpp
> -fPIC -DPIC -o .libs/callmessage.o
> In file included from ../dbus-cxx/types.h:26:0,
>                   from ../dbus-cxx/messageiterator.h:21,
>                   from ../dbus-cxx/message.h:26,
>                   from callmessage.h:19,
>                   from callmessage.cpp:19:
> ../dbus-cxx/signature.h:90:33: error: 'DBus::signature' declared as an
> 'inline' variable
> ../dbus-cxx/signature.h:90:33: error: 'uint8_t' was not declared in this
> scope
> ...
>
>
>
> Dozens of errors follow...   It attempts to compile other files, and
> every one gives errors.  A typical one:
>
> ../dbus-cxx/messageiterator.h:224:16: error: expected type-specifier
> before 'uint8_t'
>

Hmmm... not sure on this one. It looks like it's not pulling in the header
that has uint8_t. That should be in stdint.h which came in with C99.

You might check dbus-cxx-config.h and see if the stdint.h line is included.

You might also try adding one of the following to types.h:

#include <cstdint>

or

#include <stdint.h>

If that works I'll add it to the next release.


-- 

Rick

Re: [Dbus-cxx-users] examples outside dbus-cxx source tree?

[Rick L. V. Jr. <rvi...@cs...>]

camillo sir wrote:
> Hi there,
>
> i' m quite new to dbus / dbus-cxx and currently start to work on a
> prototyping project where i intend to use dbus-cxx. i've installed the
> usual
> way on a debian system
> (./configure - make - make install) and installation including provided
> examples worked well (with exception of the tools folder where make doesnt
> do anything, but i currently dont need this so its no issue for me now).
> however i run into troubles when setting up an autotools project living
> independent of the source tree of dbus-cxx itself since configure.ac /
> automake.am's of development tree and examples are highly interconnected.
> googling for examples didnt point me to anything except the examples
> provided with the dbus-cxx tarball.
> can anyone point me to some examples which only assume dbus-cxx,  sigc++,
> dbus itself and boost are installed on the system but without
> interdependencies to the development tree? help would be greatly
> appreciated.
>

I have two other projects that are out of the dbus-cxx that use dbus-cxx,
so you may want to dig through their Makefile.am and configure.ac files
for examples.

The projects are conexus (http://conexus.sf.net) and g13
(http://g13.sf.net). The g13 library isn't released yet, so you'll have to
dig through the subversion repo, but the autotools stuff is probably
simpler than conexus.

The key thing is the pkgconfig stuff to pull in the dependencies. Make
sure you also look at the Makefile.am in the conexus-dbus subdirectory
since that's where the specific lib pulls in the CFLAGS and LIBS from
pkgconfig.

-- 

Rick

[Dbus-cxx-users] compile problem

[Daren S. W. <da...@da...>]

I'm trying to compile dbus-cxx but get a compile error.   Configure ran 
okay, at least I saw no errors, and it made a Makefile.
Using gcc 4.5.0, on 64-bit Arch Linux.   AFIK, I have all dependencies 
and tools, libs etc are reasonably up to date.  My hunch is either I 
need to feed ./configure some magic cookie, or there's some other dbus 
binding installed with an interfering header file.


make  all-am
make[3]: Entering directory `/usr/local/src/dbus-cxx-0.7.0/dbus-cxx'
/bin/sh ../libtool --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H -I. 
-I.. -I../. -I../. -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include 
-I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include      -g -O2 -MT 
callmessage.lo -MD -MP -MF .deps/callmessage.Tpo -c -o callmessage.lo 
callmessage.cpp
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I.. -I../. -I../. 
-I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include 
-I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -g -O2 -MT 
callmessage.lo -MD -MP -MF .deps/callmessage.Tpo -c callmessage.cpp  
-fPIC -DPIC -o .libs/callmessage.o
In file included from ../dbus-cxx/types.h:26:0,
                  from ../dbus-cxx/messageiterator.h:21,
                  from ../dbus-cxx/message.h:26,
                  from callmessage.h:19,
                  from callmessage.cpp:19:
../dbus-cxx/signature.h:90:33: error: 'DBus::signature' declared as an 
'inline' variable
../dbus-cxx/signature.h:90:33: error: 'uint8_t' was not declared in this 
scope
...



Dozens of errors follow...   It attempts to compile other files, and 
every one gives errors.  A typical one:

../dbus-cxx/messageiterator.h:224:16: error: expected type-specifier 
before 'uint8_t'

-- 
Daren Scot Wilson
Orlando FL

[Dbus-cxx-users] examples outside dbus-cxx source tree?

[camillo s. <cam...@gm...>]

Hi there,

i' m quite new to dbus / dbus-cxx and currently start to work on a
prototyping project where i intend to use dbus-cxx. i've installed the usual
way on a debian system
(./configure - make - make install) and installation including provided
examples worked well (with exception of the tools folder where make doesnt
do anything, but i currently dont need this so its no issue for me now).
however i run into troubles when setting up an autotools project living
independent of the source tree of dbus-cxx itself since configure.ac /
automake.am's of development tree and examples are highly interconnected.
googling for examples didnt point me to anything except the examples
provided with the dbus-cxx tarball.
can anyone point me to some examples which only assume dbus-cxx,  sigc++,
dbus itself and boost are installed on the system but without
interdependencies to the development tree? help would be greatly
appreciated.

thx+regards
camillo

[Dbus-cxx-users] Bug with popt

[Anatoliy B. <a...@be...>]

Hi there,

i've just compiled dbus-cxx 0.7 and there is no check for libpopt inside
configure script, which causes an error when making.

Regards

Anatoliy Belsky

[Dbus-cxx-users] New quick start guide on dbus-cxx-xml2cpp

[Rick L. V. Jr. <rvi...@cs...>]

I added a quick start guide to dbus-cxx-xml2cpp and cleaned up the doxygen
generated output for the previous quick start guide.

I also added a small section on using pkgconfig as well as the
ax_dbus_cxx_xml2cpp.m4 macro.

It's available on the dbus-cxx website at sourceforge and will also be in
the docs when the next dbus-cxx release happens.

-- 

Rick

[Dbus-cxx-users] dbus-cxx 0.7.0 released

[Rick L. V. Jr. <rvi...@cs...>]

dbus-cxx is a C++ wrapper for the dbus library
http://dbus-cxx.sourceforge.net

===== 0.7.0 =====

This release primarily features code cleanup, but in doing so there were
several minor feature additions, added documentation, bug fixes and minor
API changes.

== New Documentation and Tutorial ==
A quickstart guide has been added to the documentation. This will take you
through a simple client/server example.

The quickstart tutorial can be found in the documentation or on the
dbus-cxx website here:
   http://dbus-cxx.sourceforge.net/quick_start.html

Also, documentation has been added for many of the m4 generated templates.

== Cleanup ==
A significant portion of the cleanup related to the headers. As the
library grew and evolved the headers became messy, from old includes that
are no longer needed to templates that had very touchy include orders.
These have been significantly cleaned up and several key template headers
have been split into two parts with the first part declarations and the
second part definitions and specializations.

The utility.h header had also grown to include many things beyond simple
utility functions. The dbus typing functions have been split out into
types.h and the introspect() function has been properly incorporated into
the DBus::Connection class.

The functions related to signatures in utility.h have been moved into the
header signature.h along where DBus::Signature is.

== New API ==
* In cleaning up the macros that generate the sigc++ slot based
DBus::Method  templates support for void methods has been added.

* A force parameter was added to DBus::Object::add_child() to allow a
child with a similar name to be forced into the hierarchy replacing the
old child

== Key API Changes ==
* DBus::Dispatcher's constructor is now protected; use
DBus::Dispatcher::create() to allocate a smart pointer

* When a named object interface doesn't handle an incoming message, the
default interface is tried before failing.

-- 

Rick

[Dbus-cxx-users] dbus-cxx cleanup

[Rick L. V. Jr. <rvi...@cs...>]

dbus-cxx has developed some cruft as recent things have been added.

An example of this is the introspect() method in utility.h which really
belongs as a method of the Connection class.

Another example is the state of the headers. There are some very intricate
interdependencies with the templates and the m4 generation code doesn't
help matters.

I've started cleaning things up a bit, and I'll gradually be committing
code to the repository. In general I'll try not to break compilation of
the svn repo, but there may be a few times I do.

As things progress, feedback and testing are welcome.

-- 

Rick

Re: [Dbus-cxx-users] Sending Calls Over System Bus

[Rick L. V. Jr. <rvi...@cs...>]

Josh Kohlbach wrote:
> Hi,
>
> I'm having some troubles developing a program to utilize the system bus.
> I have developed a server application which listens for incoming method
> calls and that works fine. It even asynchronously sends a method call
> back to a method in the client application which is received by the
> client. This proves that sending communication permissions are right in
> the system dbus settings.
>
> My problem is, in the client program, when I execute the first method
> call it blocks on that call even when the method has no return type. I
> think it's expecting a reply that is never going to come.
>
> Is there a way to adjust the system DBUS settings to either:
> a. Allow the method return
> or;
> b. Send this method call without expecting a reply.
>
> My interface for the server has one method which has one "in" parameter.
> Likewise on the client.
>
> Thanks in advance for any help you can lend.
>

What version are you using?

-- 

Rick

[Dbus-cxx-users] Sending Calls Over System Bus

[Josh K. <jo...@es...>]

Hi,

I'm having some troubles developing a program to utilize the system bus. 
I have developed a server application which listens for incoming method 
calls and that works fine. It even asynchronously sends a method call 
back to a method in the client application which is received by the 
client. This proves that sending communication permissions are right in 
the system dbus settings.

My problem is, in the client program, when I execute the first method 
call it blocks on that call even when the method has no return type. I 
think it's expecting a reply that is never going to come.

Is there a way to adjust the system DBUS settings to either:
a. Allow the method return
or;
b. Send this method call without expecting a reply.

My interface for the server has one method which has one "in" parameter. 
Likewise on the client.

Thanks in advance for any help you can lend.

Josh

Re: [Dbus-cxx-users] [Dbus-cxx-devel] dbus-cxx 0.6.0 released

[Rick L. V. Jr. <rvi...@cs...>]

Oliver Kowalke wrote:
> May I ask you for what reasons yout  throw exceptions as smart-pointers?
>
> thx and best regards,
> Oliver
>

Hello,

The dbus-cxx class DBus::Error wraps the dbus C struct DBusError. The
constructor takes care of calling dbus_error_init() and the destructor
takes care of dbus_error_free().

The problem with the previous implementation is that there was no
reference counting to the underlying C object, so a copy of DBus::Error
resulted in a premature dbus_error_free() of the underlying C object
because DBus::Error doesn't have a reference counting mechanism (neither
does DBusError).

The alternatives would be to add a reference counting mechanism to
DBus::Error (fairly trivial) or use the smart pointer's reference
mechanism.

I chose the latter because all the other classes in dbus-cxx should have
protected constructors with static public create() methods. This brings
DBus::Error in line with the others syntactically and uses a standardized
reference counting mechanism.

---

Rick

Re: [Dbus-cxx-users] [Dbus-cxx-devel] dbus-cxx 0.6.0 released

[Oliver K. <oli...@se...>]

May I ask you for what reasons yout  throw exceptions as smart-pointers?

thx and best regards,
Oliver

Rick L. Vinyard, Jr. schrieb:
> dbus-cxx is a C++ wrapper for the dbus library
> http://dbus-cxx.sourceforge.net
>
> ===== 0.6.0 =====
>
> This release is primarily a bug fix release. However, this resulted in
> significant changes to the error handling so I have bumped the minor
> release number.
>
> The dbus error wrapper was modified to provide smart pointers for all error
> objects. The reference counting of the smart pointers will prevent an issue
> that resulted in double freeing dbus errors in the previous error
> implementation.
>
> Errors thrown are now smart pointer instances of error objects and can be
> accessed as Error::pointer. This keeps the syntax for errors inline with the
> other smart pointers used throughout dbus-cxx.
>
> This also means that simple boolean tests such as the following are no longer
> valid:
>   Error error;
>   if (error) ...
>
> This would test the smart pointer rather than test for the error. To test
> whether an error is set you would need to test the is_set() method of
> the error class as in the following:
>   Error::pointer error;
>   if (error->is_set()) ...
>
> Thanks to Tyler Conant for hunting down the double free Error class issue.
>
> Fixed logic error in CallMessage::expects_reply()
>
> Thanks to Julien Bonjean for catching this one
>
>
> ------------------------------------------------------------------------------
> Throughout its 18-year history, RSA Conference consistently attracts the
> world's best and brightest in the field, creating opportunities for Conference
> attendees to learn about information security's most important issues through
> interactions with peers, luminaries and emerging and established companies.
> http://p.sf.net/sfu/rsaconf-dev2dev
> _______________________________________________
> Dbus-cxx-devel mailing list
> Dbu...@li...
> https://lists.sourceforge.net/lists/listinfo/dbus-cxx-devel
>
>   

[Dbus-cxx-users] dbus-cxx 0.6.0 released

[Rick L. V. Jr. <rvi...@cs...>]

dbus-cxx is a C++ wrapper for the dbus library
http://dbus-cxx.sourceforge.net

===== 0.6.0 =====

This release is primarily a bug fix release. However, this resulted in
significant changes to the error handling so I have bumped the minor
release number.

The dbus error wrapper was modified to provide smart pointers for all error
objects. The reference counting of the smart pointers will prevent an issue
that resulted in double freeing dbus errors in the previous error
implementation.

Errors thrown are now smart pointer instances of error objects and can be
accessed as Error::pointer. This keeps the syntax for errors inline with the
other smart pointers used throughout dbus-cxx.

This also means that simple boolean tests such as the following are no longer
valid:
  Error error;
  if (error) ...

This would test the smart pointer rather than test for the error. To test
whether an error is set you would need to test the is_set() method of
the error class as in the following:
  Error::pointer error;
  if (error->is_set()) ...

Thanks to Tyler Conant for hunting down the double free Error class issue.

Fixed logic error in CallMessage::expects_reply()

Thanks to Julien Bonjean for catching this one

[Dbus-cxx-users] dbus-cxx 0.5.1 released

[Rick L. V. Jr. <rvi...@cs...>]

dbus-cxx is a C++ wrapper for the dbus library
http://dbus-cxx.sourceforge.net

===== 0.5.1 =====
This release fixes a bug in the append iterator when
a second child container is used. Thanks to Tyler Conant
for hunting this one down.

Re: [Dbus-cxx-users] GPLV3

[Kees J. <kee...@gm...>]

On Mon, Oct 5, 2009 at 12:28 PM, Meier, Andreas
<and...@sc...> wrote:
>> Hi,
>>
>> I would like to use the dbus-cxx bindings in a commercial app.
>> while libdbus is released under a more permissive license (LGPLV2)
>> allowing it to link against close source components the cxx bindings
> are
>> license under GPLV3 (not LGPL) was that a conscious choice? are there
> other
>> licensing option available?
>>
>> Greetings
>
> I do have the exact same question.

Hi this is the answer I did get:
The answer is that this is not possible as the code needs to work with
other gplv3 code. It's such a shame this code can't be shared.

Greetings

Re: [Dbus-cxx-users] GPLV3

[Meier, A. <and...@sc...>]

> Hi,
>
> I would like to use the dbus-cxx bindings in a commercial app.
> while libdbus is released under a more permissive license (LGPLV2)
> allowing it to link against close source components the cxx bindings
are
> license under GPLV3 (not LGPL) was that a conscious choice? are there
other
> licensing option available?
>
> Greetings

I do have the exact same question.

Have a good day,
Andreas

[Dbus-cxx-users] dbus-cxx 0.5.0 released

[Rick L. V. Jr. <rvi...@cs...>]

dbus-cxx is a C++ wrapper for the dbus library
http://dbus-cxx.sourceforge.net

===== 0.5.0 =====
This release has some new features, some bug fixes and some added support for
older versions of GCC and dbus, and new Ubuntu builds on Launchpad.

One of the new features is preliminary support for arrays of fixed types. An
example can be found in the signal examples directory and the two example
programs are name signal_emitter_array and signal_receiver_array.

Many of the template functions have been changed and are now generated by
M4 to support older versions of GCC that don't recognize default template
function parameters.

Checks have been added and conditional code added to allow building
against dbus 1.1 (and possibly dbus 1.0; only dbus 1.1 was tested). This
change, combined with the GCC support changes, mean that dbus-cxx can
now be compiled on RHEL 5. Builds will be available in Fedora shortly
for the EPEL 5 (RHEL 5, CentOS 5) family.

Finally, there are numerous minor bug cleanups which should significantly
reduce the amount of compile warnings generated.

Re: [Dbus-cxx-users] dbus-cxx cross compilation for arm

[Rick L. V. Jr. <rvi...@cs...>]

DEEPESH SINGH wrote:
> thanks rick i got uor
> respones but i have a question
> in my cross compilation toolchain i have TR1 support then why should we
> need
 boost .
> can't we go ahead without boost . boost seems bulky .

I think boost is very heavy just to get smart pointer support.

Last week on the dbus-cxx-devel list Ramin Yaghoubzadeh posted some
patches fixing TR1 support for some versions of gcc.

Some of those changes are already in SVN and the rest should follow
shortly. You might check and see if the header changes match your
architecture.

---

Rick

[Dbus-cxx-users] Ubuntu Launchpad PPA

[Rick L. V. Jr. <rvi...@cs...>]

I have set up an Ubuntu Launchpad PPA with builds of the latest dbus-cxx
for Jaunty on i386, amd64 and lpia.

More info on the dbus-cxx project page: http://dbus-cxx.sourceforge.net

Re: [Dbus-cxx-users] Cross compiling dbus-cxx for ARM

[Rick L. V. Jr. <rvi...@cs...>]

chandraiah gobburu wrote:
> Hello,
>
> I am trying to compile dbus-cxx-0.4.2 for ARM. I have cross compiled
> libsigc++-2.2.0. I have also compiled boost_1.40.2 for ARM.
>
> I am getting the following error when I executed make command.
>

> connection.cpp:145: error: invalid use of incomplete type 'struct
> boost::weak_ptr<DBus::Connection>'
> /usr/sol/include/boost/smart_ptr/shared_ptr.hpp:62: error: declaration of
> 'struct boost::weak_ptr<DBus::Connection>'
> connection.cpp: In static member function 'static
> boost::shared_ptr<DBus::Connection>
> DBus::Connection::self(DBusConnection*)':

This looks like one of the boost library header includes is missing in
pointer.h. I noticed that the #include for weak_ptr.hpp is commented out,
but I don't remember why since I haven't used the boost libraries in a
very long time.

You might try uncommenting that line (or adjusting it as necessary) to
ensure that weak pointers are included. Once that part is fixed the rest
may fall in line.

[Dbus-cxx-users] Cross compiling dbus-cxx for ARM

[chandraiah g. <cha...@gm...>]

Hello,

I am trying to compile dbus-cxx-0.4.2 for ARM. I have cross compiled
libsigc++-2.2.0. I have also compiled boost_1.40.2 for ARM.

I am getting the following error when I executed make command.

make  all-recursive
make[1]: Entering directory `/home/targetshare/chandra/dbus-cxx-0.4.2'
Making all in dbus-cxx
make[2]: Entering directory
`/home/targetshare/chandra/dbus-cxx-0.4.2/dbus-cxx'
m4 dbus_signal.h.m4  > dbus_signal.h
m4 signal_proxy.h.m4  > signal_proxy.h
m4 method.h.m4  > method.h
m4 method_impl.h.m4  > method_impl.h
m4 interface.h.m4  > interface.h
m4 object.h.m4  > object.h
m4 objectproxy.h.m4  > objectproxy.h
m4 methodproxybase.h.m4  > methodproxybase.h
m4 methodproxy.h.m4  > methodproxy.h
make  all-am
make[3]: Entering directory
`/home/targetshare/chandra/dbus-cxx-0.4.2/dbus-cxx'
/bin/sh ../libtool --tag=CXX   --mode=compile arm-linux-g++ -DHAVE_CONFIG_H
-I. -I.. -I../. -I../. -I/usr/sol/include/dbus-1.0
-I/usr/sol/lib/dbus-1.0/include -I/usr/sol//include/sigc++-2.0
-I/usr/sol//lib/sigc++-2.0/include    -I/usr/sol/include/
-I/usr/local/arm/4.2.2-eabi/usr/include/
-I//usr/local/arm/4.2.2-eabi/include/  -g -O2 -MT callmessage.lo -MD -MP -MF
.deps/callmessage.Tpo -c -o callmessage.lo callmessage.cpp
libtool: compile:  arm-linux-g++ -DHAVE_CONFIG_H -I. -I.. -I../. -I../.
-I/usr/sol/include/dbus-1.0 -I/usr/sol/lib/dbus-1.0/include
-I/usr/sol//include/sigc++-2.0 -I/usr/sol//lib/sigc++-2.0/include
-I/usr/sol/include/ -I/usr/local/arm/4.2.2-eabi/usr/include/
-I//usr/local/arm/4.2.2-eabi/include/ -g -O2 -MT callmessage.lo -MD -MP -MF
.deps/callmessage.Tpo -c callmessage.cpp  -fPIC -DPIC -o .libs/callmessage.o
callmessage.cpp: In function 'void DBus::callmsg_wp_deleter(void*)':
callmessage.cpp:88: warning: possible problem detected in invocation of
delete operator:
callmessage.cpp:87: warning: 'wp' has incomplete type
/usr/sol/include/boost/smart_ptr/shared_ptr.hpp:62: warning: declaration of
'struct boost::weak_ptr<DBus::CallMessage>'
callmessage.cpp:88: note: neither the destructor nor the class-specific
operator delete will be called, even if they are declared when the class is
defined.
libtool: compile:  arm-linux-g++ -DHAVE_CONFIG_H -I. -I.. -I../. -I../.
-I/usr/sol/include/dbus-1.0 -I/usr/sol/lib/dbus-1.0/include
-I/usr/sol//include/sigc++-2.0 -I/usr/sol//lib/sigc++-2.0/include
-I/usr/sol/include/ -I/usr/local/arm/4.2.2-eabi/usr/include/
-I//usr/local/arm/4.2.2-eabi/include/ -g -O2 -MT callmessage.lo -MD -MP -MF
.deps/callmessage.Tpo -c callmessage.cpp -o callmessage.o >/dev/null 2>&1
mv -f .deps/callmessage.Tpo .deps/callmessage.Plo
/bin/sh ../libtool --tag=CXX   --mode=compile arm-linux-g++ -DHAVE_CONFIG_H
-I. -I.. -I../. -I../. -I/usr/sol/include/dbus-1.0
-I/usr/sol/lib/dbus-1.0/include -I/usr/sol//include/sigc++-2.0
-I/usr/sol//lib/sigc++-2.0/include    -I/usr/sol/include/
-I/usr/local/arm/4.2.2-eabi/usr/include/
-I//usr/local/arm/4.2.2-eabi/include/  -g -O2 -MT connection.lo -MD -MP -MF
.deps/connection.Tpo -c -o connection.lo connection.cpp
libtool: compile:  arm-linux-g++ -DHAVE_CONFIG_H -I. -I.. -I../. -I../.
-I/usr/sol/include/dbus-1.0 -I/usr/sol/lib/dbus-1.0/include
-I/usr/sol//include/sigc++-2.0 -I/usr/sol//lib/sigc++-2.0/include
-I/usr/sol/include/ -I/usr/local/arm/4.2.2-eabi/usr/include/
-I//usr/local/arm/4.2.2-eabi/include/ -g -O2 -MT connection.lo -MD -MP -MF
.deps/connection.Tpo -c connection.cpp  -fPIC -DPIC -o .libs/connection.o
In file included from ../dbus-cxx/interface.h:16,
                 from ../dbus-cxx/object.h:15,
                 from connection.h:33,
                 from connection.cpp:21:
../dbus-cxx/method.h: In member function 'virtual DBus::HandlerResult
DBus::Method<T_return, T_arg1, T_arg2, T_arg3, T_arg4, T_arg5, T_arg6,
T_arg7>::handle_call_message(boost::shared_ptr<DBus::Connection>,
boost::shared_ptr<const DBus::CallMessage>)':
../dbus-cxx/method.h:66: error: no match for 'operator<<' in 'connection <<
retmsg'
../dbus-cxx/signature.h:92: note: candidates are: std::ostream&
operator<<(std::ostream&, const DBus::Signature&)
../dbus-cxx/method.h: In member function 'virtual DBus::HandlerResult
DBus::Method<T_return, sigc::nil, sigc::nil, sigc::nil, sigc::nil,
sigc::nil, sigc::nil,
sigc::nil>::handle_call_message(boost::shared_ptr<DBus::Connection>,
boost::shared_ptr<const DBus::CallMessage>)':
../dbus-cxx/method.h:156: error: no match for 'operator<<' in 'connection <<
retmsg'
../dbus-cxx/signature.h:92: note: candidates are: std::ostream&
operator<<(std::ostream&, const DBus::Signature&)
../dbus-cxx/method.h: In member function 'virtual DBus::HandlerResult
DBus::Method<T_return, T_arg1, sigc::nil, sigc::nil, sigc::nil, sigc::nil,
sigc::nil,
sigc::nil>::handle_call_message(boost::shared_ptr<DBus::Connection>,
boost::shared_ptr<const DBus::CallMessage>)':
../dbus-cxx/method.h:247: error: no match for 'operator<<' in 'connection <<
retmsg'
../dbus-cxx/signature.h:92: note: candidates are: std::ostream&
operator<<(std::ostream&, const DBus::Signature&)
../dbus-cxx/method.h: In member function 'virtual DBus::HandlerResult
DBus::Method<T_return, T_arg1, T_arg2, sigc::nil, sigc::nil, sigc::nil,
sigc::nil,
sigc::nil>::handle_call_message(boost::shared_ptr<DBus::Connection>,
boost::shared_ptr<const DBus::CallMessage>)':
../dbus-cxx/method.h:340: error: no match for 'operator<<' in 'connection <<
retmsg'
../dbus-cxx/signature.h:92: note: candidates are: std::ostream&
operator<<(std::ostream&, const DBus::Signature&)
../dbus-cxx/method.h: In member function 'virtual DBus::HandlerResult
DBus::Method<T_return, T_arg1, T_arg2, T_arg3, sigc::nil, sigc::nil,
sigc::nil,
sigc::nil>::handle_call_message(boost::shared_ptr<DBus::Connection>,
boost::shared_ptr<const DBus::CallMessage>)':
../dbus-cxx/method.h:435: error: no match for 'operator<<' in 'connection <<
retmsg'
../dbus-cxx/signature.h:92: note: candidates are: std::ostream&
operator<<(std::ostream&, const DBus::Signature&)
../dbus-cxx/method.h: In member function 'virtual DBus::HandlerResult
DBus::Method<T_return, T_arg1, T_arg2, T_arg3, T_arg4, sigc::nil, sigc::nil,
sigc::nil>::handle_call_message(boost::shared_ptr<DBus::Connection>,
boost::shared_ptr<const DBus::CallMessage>)':
../dbus-cxx/method.h:532: error: no match for 'operator<<' in 'connection <<
retmsg'
../dbus-cxx/signature.h:92: note: candidates are: std::ostream&
operator<<(std::ostream&, const DBus::Signature&)
../dbus-cxx/method.h: In member function 'virtual DBus::HandlerResult
DBus::Method<T_return, T_arg1, T_arg2, T_arg3, T_arg4, T_arg5, sigc::nil,
sigc::nil>::handle_call_message(boost::shared_ptr<DBus::Connection>,
boost::shared_ptr<const DBus::CallMessage>)':
../dbus-cxx/method.h:631: error: no match for 'operator<<' in 'connection <<
retmsg'
../dbus-cxx/signature.h:92: note: candidates are: std::ostream&
operator<<(std::ostream&, const DBus::Signature&)
../dbus-cxx/method.h: In member function 'virtual DBus::HandlerResult
DBus::Method<T_return, T_arg1, T_arg2, T_arg3, T_arg4, T_arg5, T_arg6,
sigc::nil>::handle_call_message(boost::shared_ptr<DBus::Connection>,
boost::shared_ptr<const DBus::CallMessage>)':
../dbus-cxx/method.h:732: error: no match for 'operator<<' in 'connection <<
retmsg'
../dbus-cxx/signature.h:92: note: candidates are: std::ostream&
operator<<(std::ostream&, const DBus::Signature&)
In file included from ../dbus-cxx/dbus_signal.h:10,
                 from ../dbus-cxx/interface.h:17,
                 from ../dbus-cxx/object.h:15,
                 from connection.h:33,
                 from connection.cpp:21:
../dbus-cxx/signal_base.h: At global scope:
../dbus-cxx/signal_base.h:107: error: field 'm_connection' has incomplete
type
In file included from ../dbus-cxx/object.h:15,
                 from connection.h:33,
                 from connection.cpp:21:
../dbus-cxx/interface.h:75: error: default template arguments may not be
used in function templates
../dbus-cxx/interface.h:201: error: default template arguments may not be
used in function templates
In file included from connection.h:33,
                 from connection.cpp:21:
../dbus-cxx/object.h:393: error: default template arguments may not be used
in function templates
../dbus-cxx/object.h:405: error: default template arguments may not be used
in function templates
In file included from ../dbus-cxx/objectproxy.h:15,
                 from connection.h:34,
                 from connection.cpp:21:
../dbus-cxx/interfaceproxy.h:75: error: default template arguments may not
be used in function templates
../dbus-cxx/interfaceproxy.h:105: error: default template arguments may not
be used in function templates
In file included from connection.h:34,
                 from connection.cpp:21:
../dbus-cxx/objectproxy.h:243: error: default template arguments may not be
used in function templates
../dbus-cxx/objectproxy.h:251: error: default template arguments may not be
used in function templates
In file included from connection.cpp:21:
connection.h:288: error: default template arguments may not be used in
function templates
connection.h:297: error: default template arguments may not be used in
function templates
connection.h:328: error: default template arguments may not be used in
function templates
connection.h:336: error: default template arguments may not be used in
function templates
connection.cpp: In function 'void DBus::conn_wp_deleter(void*)':
connection.cpp:74: warning: possible problem detected in invocation of
delete operator:
connection.cpp:73: warning: 'wp' has incomplete type
/usr/sol/include/boost/smart_ptr/shared_ptr.hpp:62: warning: declaration of
'struct boost::weak_ptr<DBus::Connection>'
connection.cpp:74: note: neither the destructor nor the class-specific
operator delete will be called, even if they are declared when the class is
defined.
connection.cpp: In static member function 'static
boost::shared_ptr<DBus::Connection>
DBus::Connection::create(DBusConnection*, bool)':
connection.cpp:85: error: invalid use of incomplete type 'struct
boost::weak_ptr<DBus::Connection>'
/usr/sol/include/boost/smart_ptr/shared_ptr.hpp:62: error: declaration of
'struct boost::weak_ptr<DBus::Connection>'
connection.cpp:86: error: invalid use of incomplete type 'struct
boost::weak_ptr<DBus::Connection>'
/usr/sol/include/boost/smart_ptr/shared_ptr.hpp:62: error: declaration of
'struct boost::weak_ptr<DBus::Connection>'
connection.cpp: In static member function 'static
boost::shared_ptr<DBus::Connection> DBus::Connection::create(DBus::BusType,
bool)':
connection.cpp:102: error: invalid use of incomplete type 'struct
boost::weak_ptr<DBus::Connection>'
/usr/sol/include/boost/smart_ptr/shared_ptr.hpp:62: error: declaration of
'struct boost::weak_ptr<DBus::Connection>'
connection.cpp:103: error: invalid use of incomplete type 'struct
boost::weak_ptr<DBus::Connection>'
/usr/sol/include/boost/smart_ptr/shared_ptr.hpp:62: error: declaration of
'struct boost::weak_ptr<DBus::Connection>'
connection.cpp: In static member function 'static
boost::shared_ptr<DBus::Connection> DBus::Connection::create(const
DBus::Connection&)':
connection.cpp:119: error: invalid use of incomplete type 'struct
boost::weak_ptr<DBus::Connection>'
/usr/sol/include/boost/smart_ptr/shared_ptr.hpp:62: error: declaration of
'struct boost::weak_ptr<DBus::Connection>'
connection.cpp:120: error: invalid use of incomplete type 'struct
boost::weak_ptr<DBus::Connection>'
/usr/sol/include/boost/smart_ptr/shared_ptr.hpp:62: error: declaration of
'struct boost::weak_ptr<DBus::Connection>'
connection.cpp: In member function 'boost::shared_ptr<DBus::Connection>
DBus::Connection::self()':
connection.cpp:145: error: invalid use of incomplete type 'struct
boost::weak_ptr<DBus::Connection>'
/usr/sol/include/boost/smart_ptr/shared_ptr.hpp:62: error: declaration of
'struct boost::weak_ptr<DBus::Connection>'
connection.cpp: In static member function 'static
boost::shared_ptr<DBus::Connection>
DBus::Connection::self(DBusConnection*)':
connection.cpp:160: error: invalid use of incomplete type 'struct
boost::weak_ptr<DBus::Connection>'
/usr/sol/include/boost/smart_ptr/shared_ptr.hpp:62: error: declaration of
'struct boost::weak_ptr<DBus::Connection>'
make[3]: *** [connection.lo] Error 1
make[3]: Leaving directory
`/home/targetshare/chandra/dbus-cxx-0.4.2/dbus-cxx'
make[2]: *** [all] Error 2
make[2]: Leaving directory
`/home/targetshare/chandra/dbus-cxx-0.4.2/dbus-cxx'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/targetshare/chandra/dbus-cxx-0.4.2'
make: *** [all] Error 2


Can anybody suggest me how can I procede further for successful compilation.


-- 
Thanks and regards,
Chandraiah

Re: [Dbus-cxx-users] dbus-cxx-xml2cpp Bug ?

[Rick L. V. Jr. <rvi...@cs...>]

Although DBus allows as many parameters as you want, I had to limit the
bindings to a maximum of 7 due to the fact that sigc++ has a build
limitation on the templates to a return type and 7 parameters.

One way to get around this would be to manually create your call messages
similar to the caller_raw and callee_raw examples.

Perhaps you could also change it to send 2 messages... such as a
PreStartRMNode followed by a StartRMNode.

In essence, there's nothing in dbus-cxx that will prevent you from packing
more than 7 parameters into a call, but it gets ugly because you then have
to deal with the low-level stuff instead of using the higher-level
templated code like create_method<...>().

vas...@gm... wrote:
> Hello,
>
> I'm trying to generate some bindings from the xml attached and the
> StartRMNode method is ignored and the code for it is
> not present in the controller_proxy, controller_adapter. If I remove any
> three parameters from the method the generation
> works fine.
>
> Best,
> Vasile
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9&#45;12, 2009. Register
> now&#33;
> http://p.sf.net/sfu/devconf_______________________________________________
> Dbus-cxx-users mailing list
> Dbu...@li...
> https://lists.sourceforge.net/lists/listinfo/dbus-cxx-users
>