Code Monkey home page Code Monkey logo

sdbusplus's Introduction

sdbusplus

sdbusplus contains two parts:

  1. A C++ library (libsdbusplus) for interacting with D-Bus, built on top of the sd-bus library from systemd.
  2. A tool (sdbus++) to generate C++ bindings to simplify the development of D-Bus-based applications.

Dependencies

The sdbusplus library requires sd-bus, which is contained in libsystemd.

The sdbus++ application requires Python 3 and the Python libraries mako and inflection.

Building

The sdbusplus library is built using meson.

meson build
cd build
ninja
ninja test
ninja install

Optionally, building the tests and examples can be disabled by passing -Dtests=disabled and -Dexamples=disabled respectively to meson.

The sdbus++ application is installed as a standard Python package using setuptools.

cd tools
./setup.py install

C++ library

The sdbusplus library builds on top of the sd-bus library to create a modern C++ API for D-Bus. The library attempts to be as lightweight as possible, usually compiling to exactly the sd-bus API calls that would have been necessary, while also providing compile-time type-safety and memory leak protection afforded by modern C++ practices.

Consider the following code:

auto b = bus::new_default_system();
auto m = b.new_method_call("org.freedesktop.login1",
                           "/org/freedesktop/login1",
                           "org.freedesktop.login1.Manager",
                           "ListUsers");
auto reply = b.call(m);

std::vector<std::tuple<uint32_t, std::string, message::object_path>> users;
reply.read(users);
    // or
auto users = reply.unpack<
    std::vector<std::tuple<uint32_t, std::string, message::object_path>>>();

In a few, relatively succinct, C++ lines this snippet will create a D-Bus connection to the system bus, and call the systemd login manager to get a list of active users. The message and bus objects are automatically freed when they leave scope and the message format strings are generated at compile time based on the types being read. Compare this to the corresponding server code within logind.

In general, the library attempts to mimic the naming conventions of the sd-bus library: ex. sd_bus_call becomes sdbusplus::bus::call, sd_bus_get_unique_name becomes sdbusplus::bus::get_unique_name, sd_bus_message_get_signature becomes sdbusplus::message::get_signature, etc. This allows a relatively straight-forward translation back to the sd-bus functions for looking up the manpage details.

Binding generation tool

sdbusplus also contains a bindings generator tool: sdbus++. The purpose of a bindings generator is to reduce the boilerplate associated with creating D-Bus server or client applications. When creating a server application, rather than creating sd-bus vtables and writing C-style functions to handle each vtable callback, you can create a small YAML file to define your D-Bus interface and the sdbus++ tool will create a C++ class that implements your D-Bus interface. This class has a set of virtual functions for each method and property, which you can overload to create your own customized behavior for the interface.

There are currently two types of YAML files: interface and error. Interfaces are used to create server and client D-Bus interfaces. Errors are used to define C++ exceptions which can be thrown and will automatically turn into D-Bus error responses.

[[D-Bus client bindings are not yet implemented. See openbmc/openbmc#851.]]

Generating bindings

How to use tools/sdbus++

The path of your file will be the interface name. For example, for an interface org.freedesktop.Example, you would create the files org/freedesktop/Example.interface.yaml and org/freedesktop/Example.errors.yaml] for interfaces and errors respectively. These can then be used to generate the server and error bindings:

sdbus++ interface server-header org.freedesktop.Example > \
    org/freedesktop/Example/server.hpp
sdbus++ interface server-cpp org.freedesktop.Example > \
    org/freedesktop/Example/server.cpp
sdbus++ error exception-header org.freedesktop.Example > \
    org/freedesktop/Example/error.hpp \
sdbus++ error exception-cpp org.freedesktop.Example > \
    org/freedesktop/Example/error.cpp

Markdown-based documentation can also be generated from the interface and exception files:

sdbus++ interface markdown org.freedesktop.Example > \
    org/freedesktop/Example.md
sdbus++ error markdown org.freedesktop.Example >> \
    org/freedesktop/Example.md

See the example/meson.build for more details.

Installing sdbusplus on custom distributions

Installation of sdbusplus bindings on a custom distribution requires a few packages to be installed prior. Although these packages are the same for several distributions the names of these packages do differ. Below are the packages needed for Ubuntu and Fedora.

Installation on Ubuntu

sudo apt install git meson libtool pkg-config g++ libsystemd-dev \
    python3 python3-pip python3-yaml python3-mako python3-inflection

Installation on Fedora

sudo dnf install git meson libtool gcc-c++ pkgconfig systemd-devel \
    python3 python3-pip python3-yaml python3-mako

Install the inflection package using the pip utility (on Fedora)

pip3 install inflection

sdbusplus's People

Contributors

aambroze avatar adamliyi avatar amboar avatar anoo1 avatar apandit avatar bradbishop avatar edtanous avatar feistjj avatar geissonator avatar gokulsvg avatar gtmills avatar jmbills avatar jonathan-doman avatar jwludzik avatar krzysztof-i avatar lxwinspur avatar manojkiraneda avatar milindur avatar mine260309 avatar msbarth avatar pstrinkle avatar vai-hanlo avatar vmauery avatar vsytch avatar wak-google avatar whame avatar williamspatrick avatar wltu avatar yongli3 avatar zhikuiren avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

sdbusplus's Issues

asio-example.cpp build failed:error: the value of ‘returnWithMsg’ is not usable in a constant expression

gcc version:gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0

gcc -std=c++17 -g -o example asio-example.cpp -lsdbusplus -lsystemd

In file included from asio-example.cpp:6:0:
/usr/local/include/sdbusplus/asio/connection.hpp: In member function ‘void sdbusplus::asio::connection::async_method_call(MessageHandler&&, const string&, const string&, const string&, const string&, const InputArgs& ...)’:
/usr/local/include/sdbusplus/asio/connection.hpp:136:70: error: the value of ‘returnWithMsg’ is not usable in a constant expression
typename utility::strip_first_n_args<returnWithMsg ? 2 : 1,
^
/usr/local/include/sdbusplus/asio/connection.hpp:126:24: note: ‘returnWithMsg’ used in its own initializer
constexpr bool returnWithMsg = {
^~~~~~~~~~~~~
/usr/local/include/sdbusplus/asio/connection.hpp:137:67: error: the value of ‘returnWithMsg’ is not usable in a constant expression
FunctionTupleType>::type;
^
/usr/local/include/sdbusplus/asio/connection.hpp:126:24: note: ‘returnWithMsg’ used in its own initializer
constexpr bool returnWithMsg = {
^~~~~~~~~~~~~
/usr/local/include/sdbusplus/asio/connection.hpp: In lambda function:
/usr/local/include/sdbusplus/asio/connection.hpp:141:13: error: ‘UnpackType’ was not declared in this scope
UnpackType responseData;
^~~~~~~~~~
/usr/local/include/sdbusplus/asio/connection.hpp:146:46: error: ‘responseData’ was not declared in this scope
utility::read_into_tuple(responseData, r);
^~~~~~~~~~~~
/usr/local/include/sdbusplus/asio/connection.hpp:146:46: note: suggested alternative: ‘epoll_data’
utility::read_into_tuple(responseData, r);
^~~~~~~~~~~~
epoll_data
/usr/local/include/sdbusplus/asio/connection.hpp:157:40: error: the value of ‘returnWithMsg’ is not usable in a constant expression
if constexpr (returnWithMsg)
^
/usr/local/include/sdbusplus/asio/connection.hpp:126:24: note: ‘returnWithMsg’ used in its own initializer
constexpr bool returnWithMsg = {
^~~~~~~~~~~~~
/usr/local/include/sdbusplus/asio/connection.hpp:161:58: error: ‘responseData’ was not declared in this scope
std::move(responseData));
^~~~~~~~~~~~
/usr/local/include/sdbusplus/asio/connection.hpp:161:58: note: suggested alternative: ‘response’
std::move(responseData));
^~~~~~~~~~~~
response
/usr/local/include/sdbusplus/asio/connection.hpp:167:58: error: ‘responseData’ was not declared in this scope
std::move(responseData));
^~~~~~~~~~~~
/usr/local/include/sdbusplus/asio/connection.hpp:167:58: note: suggested alternative: ‘response’
std::move(responseData));
^~~~~~~~~~~~
response
makefile:36: recipe for target 'example' failed
make: *** [example] Error 1

Better to use lowercase namespace for generated C++ code

The current generated code uses the path name as the namespace name, e.g. xyz/openbmc_project/Inventory/Item/MemoryBuffer.interface.yaml would generate namespace like:

namespace sdbusplus
{
namespace xyz
{
namespace openbmc_project
{
namespace Inventory
{
namespace Item
{
namespace server
{
...

Is it better to use lowercase for them? E.g. sdbusplus::xyz::openbmc_project::inventory::item::server::?

Note: our cpp-style-guide indicates that

Namespaces should be lower_snake_case.

Cannot extract errno from SdBusError

As it stands we expose the following public interfaces:

const char* name() const noexcept override;

const char* description() const noexcept override;

const char* what() const noexcept override;

and the sd_bus_error instance is private:

sd_bus_error error;

Which means if we want to extract and use the errno for anything we have to do something truly awful:

https://gerrit.openbmc-project.xyz/#/c/openbmc/openpower-host-ipmi-flash/+/12502/3/hiomap.cpp@62

Please fix the interface so we can extract errno without losing our sanity. The translation code in the patch above is beyond a joke.

boolean properties always have 'false' value.

Creating a YAML file with just a 'boolean' property results in the object always having a value of 'false' on the dbus.

This is due to the wrong sized pointer being passed to the underlying sdbus interfaces. sdbus requires 'boolean' to be an 'int' and not a 'bool'.

gdb failure when appending variant type to message

          auto message = bus.new_method_call(
            service_path_cstr,
            object_path_cstr,
            "org.freedesktop.DBus.Properties",
            "Set" );
          message.append( iface_name_cstr );
          message.append( property_name_cstr );
          message.append<sdbusplus::message::variant<bool>>( value );

          bus.call_noreply( message );

I am using gdb 7.12.1

When I try to remote debug my program containing a version of the code above, gdb terminates with an exit code of "1". To clarify, the gdbserver gives me no visible errors and doesn't terminate, but the host-side gdb fails immediately (doesn't even break at Main).

GNU gdb (GDB) 7.12.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-pc-linux-gnu --target=arm-buildroot-linux-gnueabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) 

If I comment out the line message.append<sdbusplus::message::variant<bool>>( value );, it then debugs just fine (breaks at Main, then continues with no errors).

GNU gdb (GDB) 7.12.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-pc-linux-gnu --target=arm-buildroot-linux-gnueabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) 0xb6fcfa40 in _start () from /home/peter/project/buildroot/output/host/usr/arm-buildroot-linux-gnueabi/sysroot/lib/ld-linux.so.3

Temporary breakpoint 2, main (argc=1, argv=0xbefffda4) at ../src/main.cpp:64
64        openlog( "my_program", LOG_NDELAY, LOG_USER );

I can run the program without the debugger even with that line and it functions as expected (successfully sets the property).

Parsing fails for multi-level containers.

Attempting to parse dict[string, dict[string, variant[int64, string]]] fails with the following:

RuntimeError: Invalid entry count for dict : ['string', 'dict', ['string', 'variant', ['int64', 'string']]]
Makefile.in:42: recipe for target 'xyz/openbmc_project/Inventory/Manager/server.cpp' failed

Problem building examples when cross compiling

When cross building, such as for an embedded platform, the sdbus++ code generation tool is often not needed on the cross target. It can be disabled with --disable-sdbuspp, which is quite useful in this situation. The cross target system might not have any need to generate code nor have python.

However, the build will still try to build the examples, and the calculator examples uses sdbus++ to generate code. Which fails if the necessary python modules are not present.

Changes needed to server::object::object with move constructor

I was composing the objects into server::object::object on stack and pushing them into vector but then when I tried to use the interfaces, process crashed.

I talked to Patrick about this and he mentioned that the objects have been moved over as part of pushing onto vector and hence the original 'this' that was registered with sd_bus_handler as part of instantiating it went invalid and that the fix is to disable the move constructor.

Enums are not working anymore

I just realised that the fix for #4 (e416398) breaks parsing enums. I am preparing a patch for this regression.

Unfortunately supporting enums within another container (e,.g. dict[string, enum[self.State]]) requires additional changes.

sdbusplus releases

Have you guys considered creating tags and making releases of sdbusplus? Preferably something based on the principles of semantic versioning (https://semver.org/). That would make packaging and reuse of this library easier.

message::read doesn't handle multiple enums in a variant

For interfaces with properties of different enum types (right now I'm working with xyz.openbmc_project.State.Host), the auto-generated binding contains a PropertiesVariant with multiple C++ enum types. But it seems like the underlying message::read infrastructure cannot properly distinguish between the enums because they all look like strings on D-Bus. So, for example, if you try to read out a PropertiesVariant on the org.freedesktop.DBus.Properties.PropertiesChanged signal message, it will (I think) try to convert all the strings to the first enum type in the variant, and throw an exception from the underlying convert_from_string.

I think most code just ignores the auto-generated enums and works with strings, so this is perhaps a rare edge case, but it would be nice to support if feasible. Maybe here, an error could be handled by trying the next type in the variant?

Unable to run configure (to generate example code)

This looks like a great project and possibly the only one I could find using the sd-bus D-Bus implementation. My goal is to generate the full example code for reference as I try to implement this library in my project. Specifically,

using Calculator_inherit = sdbusplus::server::object_t<sdbusplus::net::poettering::server::Calculator>;

and its inheritance by the Calculator struct seems to be hiding a LOT of code for setting up the server.

I couldn't find any options to just generate the examples, but it does appear that the sdbus++ tool is required for that so I tried going ahead and making the tool, but that won't work either. Here's what I'm trying (after running bootstrap.sh):

./configure --disable-libsdbusplus --enable-sdbuspp
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether make supports nested variables... (cached) yes
checking for g++... g++
checking whether the C++ compiler works... yes
checking for C++ compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking for style of include used by make... GNU
checking dependency style of g++... gcc3
checking for gcc... gcc
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking dependency style of gcc... gcc3
checking for ar... ar
checking the archiver (ar) interface... ar
checking whether make sets $(MAKE)... (cached) yes
checking for a Python interpreter with version >= 2.7... python
checking for python... /usr/bin/python
checking for python version... 2.7
checking for python platform... linux2
checking for python script directory... ${prefix}/lib/python2.7/dist-packages
checking for python extension module directory... ${exec_prefix}/lib/python2.7/dist-packages
./configure: line 4970: syntax error near unexpected token `newline'
./configure: line 4970: `AX_PKG_CHECK_MODULES('

./configure fails with "syntax error near unexpected token `noext'"

drogers@v2:~/Downloads/sdbusplus$ uname -a
Linux v2 4.4.138-respeaker-r0 #2 SMP Wed Jul 25 11:29:18 CST 2018 armv7l GNU/Linux
drogers@v2:~/Downloads/sdbusplus$ ./bootstrap.sh
+ AUTOCONF_FILES=Makefile.in aclocal.m4 ar-lib autom4te.cache compile         config.guess config.h.in config.sub configure depcomp install-sh         ltmain.sh missing *libtool test-driver
+ autoreconf -vfi
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force -I m4
autoreconf: configure.ac: tracing
autoreconf: running: libtoolize --copy --force
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'build-aux'.
libtoolize: copying file 'build-aux/ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltoptions.m4'
libtoolize: copying file 'm4/ltsugar.m4'
libtoolize: copying file 'm4/ltversion.m4'
libtoolize: copying file 'm4/lt~obsolete.m4'
autoreconf: running: /usr/bin/autoconf --force
autoreconf: running: /usr/bin/autoheader --force
autoreconf: running: automake --add-missing --copy --force-missing
configure.ac:25: installing 'build-aux/compile'
configure.ac:7: installing 'build-aux/missing'
Makefile.am: installing 'build-aux/depcomp'
autoreconf: Leaving directory `.'
+ echo Run "./configure ${CONFIGURE_FLAGS} && make"
Run "./configure ${CONFIGURE_FLAGS} && make"
drogers@v2:~/Downloads/sdbusplus$ ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether make supports nested variables... (cached) yes
checking for g++... g++
checking whether the C++ compiler works... yes
checking for C++ compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking for style of include used by make... GNU
checking dependency style of g++... gcc3
checking for gcc... gcc
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking dependency style of gcc... gcc3
checking for ar... ar
checking the archiver (ar) interface... ar
checking whether make sets $(MAKE)... (cached) yes
checking for a Python interpreter with version >= 2.7... python
checking for python... /usr/bin/python
checking for python version... 2.7
checking for python platform... linux2
checking for python script directory... ${prefix}/lib/python2.7/dist-packages
checking for python extension module directory... ${exec_prefix}/lib/python2.7/dist-packages
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for SYSTEMD... yes
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking systemd/sd-bus.h usability... yes
checking systemd/sd-bus.h presence... yes
checking for systemd/sd-bus.h... yes
./configure: line 5827: syntax error near unexpected token `noext'
./configure: line 5827: `  AX_CXX_COMPILE_STDCXX_17(noext)'

configure: Fixup cross compilation

Make sure we can build the native sdbus++ tool and use it with a cross compiled build to generate the example binaries for a target platform

Incorrect mappings in enums with On and Off

When I run sdbus++ on the yaml file that contains Off and On ( Physical.interface.yaml in phosphor-dbus-interfaces ), the generated code produces -

    enum class Action
    {
        False,
        True,
        Blink,
    };

What it needs to have is

    enum class Action
    {
        Off,,
        On,
        Blink,
    };

Signal property names are not exposed

I have configured a signal like this:

signals:
  - name: StatusChanged
    description: >
      Signal indicating that the status of the VPN connection changed
    properties:
      - name: OldStatus
        type: enum[self.State]
        description: >
          Identifies the actual state the VPN-Controller was in before this signal was sent.
      - name: OldTargetStatus
        type: enum[self.TargetState]
        description: >
          The current target state of the VPN-Controller before this signal was sent.
          Same as the 'TargetStatus' property.
      - name: OldDetails
        type: string
        description: >
          Contains additional infos before this signal was sent. Like up-/downtime or additional error messages when the
          `Status` return value is `Unknown` or `Error`
      - name: Status
        type: enum[self.State]
        description: >
          Identifies the actual state the VPN-Controller currently is in.
      - name: TargetStatus
        type: enum[self.TargetState]
        description: >
          The current target state of the VPN-Controller.
          Same as the 'TargetStatus' property.
      - name: Details
        type: string
        description: >
          Contains additional infos. Like up-/downtime or additional error messages when the `Status` return value is
          `Unknown` or `Error`

But when running the program and introspecting, the signal shows like this:

    signals:
      StatusChanged(s arg_0,
                    s arg_1,
                    s arg_2,
                    s arg_3,
                    s arg_4,
                    s arg_5);

Add method to sdbus++ objects to control all property signals.

Conversation with @bradbishop : https://discord.com/channels/775381525260664832/775381525260664836/784509529832292363

There is a method to change a property and it has a boolean to avoid sending signals, but it is likely not leveraged by many applications and is slightly cumbersome. The current expections of an application are:

The default implementations of an application, if it has properties it needs to change beyond the constructor is:

1. Call constructor with defer_emit.
2. Set N properties with signal=false.
3. Call object->emit_interface_added when done.

I think you're proposing there are two problems.

a. #2 should default to signal=false automatically at least in this sequence.
b. #2 and #3 should do nothing when service name isn't claimed.

We should come up with something better to give object-level control on property signals to avoid signal floods for typical use cases. Whatever is implemented we need to be careful to not break signals on existing applications that might be creating objects dynamically.

Build is getting failed with error code 2=“null” and 255=“null” in Windows 10 OS

Greetings,

We have recently migrated to Windows 10 from Windows 7.

When we are building our code in Windows 10, we are getting the build error such as 255="null" and 2="null".

We have no clue how to fix this build error.

We are facing this build error after we migrated to Windows 10.

Our Code was successfully built when we used Windows 7 OS.

Please see the build error in the below mentioned log.

Error:

2020-02-12 18:19:46 t-58 WARNING: Error: 255="null" when executing [C:\Clones\Exp\TSP_VOB\Build\bin\bldcomp.bat, libVAL, OSE]

2020-01-09 08:50:55 t-52 WARNING: Error: 2="null" when executing [G:\TSP_VOB\Build\bin\bldcomp.bat, libVAL, OSE]

Here bldcomp.bat is the batch file which will invoke the make file the make file inturn will invoke the make.exe,libVAL is the component to be build and the OSE is the configuration for which the build is done.

Here bldcomp.bat, libVAL and OSE is fed to the processbuilder java process as inputs, while the build is going on the build(processbuilder) is interrupted with the error code 2="null" and 255="null"

Please see the environment details below.

Rhapsody 8.0.5
Java Version 7
Visual studio 2005
gcc version 4.2.3
Windows Version : Windows 10

Note :

1)The configuration can be of any specific target such as OSE(arm),WinXP(Desktop simulation),WinCE and Lint.

2)The Component can be Utilities,SIM,OSAL,ARCOM,FD,VAL,TRF,SVAL and MSW

3)The build error is appearing in any component and in any configuration randomly(meaning issue place is not definite).

4)This build went through fine with out any issues on Windows 7 OS, now we are facing this build errors in Windows 10 OS.

Please help us to fix this issue.

Thanks in advance,

S.Parthasarathi

Interface enum example produces invalid tuple

In docs/interface.md, example methods have type: struct[enum[self.Suit], byte] which results in stdbus++ server.hpp output:

virtual void moveToTop(
            std::tuple<enum<self.Suit>, uint8_t> card) = 0;

When compiled with a trivial main.cc that includes the hpp fle, the error is:

g++ main.cc server.cc -o server
In file included from main.cc:15:0:
server.hpp:66:52: error: template argument 1 is invalid
         virtual std::tuple<enum<self.Suit>, uint8_t> lookAtTop(

Adding some instrumentation to tools/sdbusplus/property.py seems to show that cppTypeParam() is never called. This is the method in which the enum< and self. are removed.

running "make check" have error : ld returned 1 exit status

I'm running tests in SDK . In sdbusplus, follow the steps:
./bootstrap.sh
./configure ${CONFIGURE_FLAGS} --enable-oe-sdk
make check

when "make check", something wrong:

Making check in .
make[1]: Entering directory /home/root1/sdbusplus' make[1]: Leaving directory /home/root1/sdbusplus'
Making check in tools
make[1]: Entering directory /home/root1/sdbusplus/tools' running build make[1]: Leaving directory /home/root1/sdbusplus/tools'
Making check in example
make[1]: Entering directory /home/root1/sdbusplus/example' make check-am make[2]: Entering directory /home/root1/sdbusplus/example'
CXX list_users-list-users.o
CXXLD list-users
CXX calculator_server-calculator-server.o
CXX net/poettering/Calculator/calculator_server-server.o
CXXLD calculator-server
make[2]: Leaving directory /home/root1/sdbusplus/example' make[1]: Leaving directory /home/root1/sdbusplus/example'
Making check in test
make[1]: Entering directory /home/root1/sdbusplus/test' make bus_list_names bus_match exception_sdbus_error message_append message_read message_native_types message_types utility_tuple_to_array utility_type_traits vtable_vtable timer make[2]: Entering directory /home/root1/sdbusplus/test'
CXX bus/list_names.o
CXXLD bus_list_names
/home/root1/sdk/sysroots/x86_64-oesdk-linux/usr/libexec/arm-openbmc-linux-gnueabi/gcc/arm-openbmc-linux-gnueabi/9.2.0/real-ld: /home/root1/sdk/sysroots/armv5e-openbmc-linux-gnueabi/usr/lib/libgmock_main.a(gmock_main.cc.o): in function main': /usr/src/debug/googletest/1.8.1-r0/git/googlemock/src/gmock_main.cc:52: undefined reference to testing::InitGoogleMock(int*, char**)'
collect2: error: ld returned 1 exit status
make[2]: *** [bus_list_names] Error 1
make[2]: Leaving directory /home/root1/sdbusplus/test' make[1]: *** [check-am] Error 2 make[1]: Leaving directory /home/root1/sdbusplus/test'
make: *** [check-recursive] Error 1

Need support for tuple message type

I am not sure if this qualifies as a bug for sdbusplus or some other repo(bios-settings-mgr). I have been testing my code against https://gerrit.openbmc-project.xyz/c/openbmc/bios-settings-mgr/+/35563.

Here is my sample code :

#include <sdbusplus/bus.hpp>
#include <xyz/openbmc_project/BIOSConfig/Manager/server.hpp>
#include <cstdint>
#include <iostream>

int main()
{
    using namespace sdbusplus;

    auto b = bus::new_default_system();
    auto m =
        b.new_method_call("xyz.openbmc_project.BIOSConfigManager", "/xyz/openbmc_project/bios_config/manager",
                          "xyz.openbmc_project.BIOSConfig.Manager", "GetAttribute");
    m.append("vmi-hostname");
    auto reply = b.call(m);

std::tuple<xyz::openbmc_project::BIOSConfig::server::Manager::AttributeType,std::variant<int64_t,std::string>,std::variant<int64_t,std::string>> attributeMesg;
//    std::tuple<int64_t, std::variant<int64_t,std::string>, std::variant<int64_t,std::string>> attributeMesg;

    try
    {
        reply.read(attributeMesg);
    }
    catch (const sdbusplus::exception::SdBusError& e)
    {
            std::cout<< "Failed to read the dbus message into provided container" << e.what();
    }
    return 0;
}

I get this error when executing the binary:

root@witherspoon:/tmp# ./test 
Failed to read the dbus message into provided containersd_bus_message_enter_container tuple: System.Error.ENXIO:

But i see the underlying busctl call succeded - using busctl monitor

‣ Type=method_return  Endian=l  Flags=1  Version=1 Cookie=26  ReplyCookie=2
  Sender=:1.100  Destination=:1.108
  UniqueName=:1.100
  MESSAGE "svv" {
          STRING "xyz.openbmc_project.BIOSConfig.Manager.AttributeType.String";
          VARIANT "s" {
                  STRING "witherspoon";
          };
          VARIANT "x" {
                  INT64 0;
          };
  };

And the busctl call also seems to return fine:

root@witherspoon:/tmp# busctl call xyz.openbmc_project.BIOSConfigManager /xyz/openbmc_project/bios_config/manager xyz.openbmc_project.BIOSConfig.Manager GetAttribute s "vmi-hostname"
svv "xyz.openbmc_project.BIOSConfig.Manager.AttributeType.String" s "witherspoon" x 0

The message signature is svv -> so i was using a tuple<string,variant,variant> container to catch the dbus message. Am i doing something wrong ? or is the sdbusplus lacking support for tuple message type ?

configure: Improve c++ error when autoconf-archive is too old

We can use AX_CXX_COMPILE_STDCXX() instead of AX_CXX_COMPILE_STDCXX_1{4,7}()

We get errors like:
configure.ac:24: error: invalid first argument `20' to AX_CXX_COMPILE_STDCXX

Instead of:
./configure: line 5132: syntax error near unexpected token noext' ./configure: line 5132: AX_CXX_COMPILE_STDCXX_20(noext)'

[Suggestion] Use reference as function parameters

The generated server.hpp passes value as function parameters. This is OK for simple types, but could have performance issue when the parameter is a heavy-to-copy object.

E.g. code snippet of xyz/openbmc_project/Logging/Entry/server.hpp:

    virtual std::vector<std::string> additionalData(std::vector<std::string> value);

It could be better to generate code like:

    virtual std::vector<std::string> additionalData(std::vector<std::string>& value);

Generally I think it's OK, but I'm not sure if there are cases that passing reference could be wrong.

If the suggestion is accepted, it looks like the change could be as simple as to modify the two templates:

diff --git a/tools/sdbusplus/templates/interface.mako.server.cpp b/tools/sdbusplus/templates/interface.mako.server.cpp
index 50a6cad..cba0ed4 100644
--- a/tools/sdbusplus/templates/interface.mako.server.cpp
+++ b/tools/sdbusplus/templates/interface.mako.server.cpp
@@ -65,7 +65,7 @@ int ${classname}::_callback_get_${p.name}(
     return true;
 }

-auto ${classname}::${p.camelCase}(${p.cppTypeParam(interface.name)} value) ->
+auto ${classname}::${p.camelCase}(${p.cppTypeParam(interface.name)}& value) ->
         ${p.cppTypeParam(interface.name)}
 {
     if (_${p.camelCase} != value)
diff --git a/tools/sdbusplus/templates/interface.mako.server.hpp b/tools/sdbusplus/templates/interface.mako.server.hpp
index 1879fd8..b518847 100644
--- a/tools/sdbusplus/templates/interface.mako.server.hpp
+++ b/tools/sdbusplus/templates/interface.mako.server.hpp
@@ -62,7 +62,7 @@ ${ s.cpp_prototype(loader, interface=interface, ptype='header') }
         virtual ${p.cppTypeParam(interface.name)} ${p.camelCase}() const;
         /** Set value of ${p.name} */
         virtual ${p.cppTypeParam(interface.name)} \
-${p.camelCase}(${p.cppTypeParam(interface.name)} value);
+${p.camelCase}(${p.cppTypeParam(interface.name)}& value);
     % endfor

     % for e in interface.enums:

Feature: sdbusplus match object could allow owning captures

This feature requests is best described with code examples. When using a match today that uses lambdas, I have to write the following code:

std::function<void(sdbusplus::message::message&)> handler = [](sdbusplus::message::message& m){
   /// Do something with m.
};

sdbusplus::bus::match::match myMatch(bus, "MATCH EXPRESSION", handler);

This can be somewhat problematic as the handler variable needs its lifecycle managed elsewhere, which may or may not cause problems, and leads to quite a bit of boilerplate code that could be handled with RAII.

The code i WANT to write, is this:

sdbusplus::bus::match::match myMatch(bus, "MATCH EXPRESSION",  [](sdbusplus::message::message& m){
   /// Do something with m.
});

Where the handler lifetime has now been tied to the match object, and there's no explicit destruction or lifetime management required. This similar pattern is supported in a lot of the ASIO stuff, by type erasing the handler, and providing a template overload of the match object constructor, and storing the state internally in the match object. Another option would be to provide a std::function overload, although less efficient, would allow attaching any sort of state that's needed to the match object. When the match is destroyed, so is the handler.

Plans & Roadmap

I found this project a few days ago after searching for C++ bindings to D-Bus. Unfortunately I only found Qt (which I do not want to use at the moment), libdbus-c++ (which is incomplete and there are various forks/variants) and libdbus-cpp (which I also cannot use). Besides that the performance of sd-bus is much better than libdbus. So this project looks very promising in creating a full-featured C++ binding to the new/modern sd-bus library. Many thanks for your effort in this project so far.

What are your plans for the further development of this project? Do you, e.g., plan to also add code generation for the client side? How stable is the API of sdbusplus and the generated server stub code?

Add readonly property

Add a property that prevents the value from being changed by the client but can be changed by the application.

Making this as discussed on IRC.

match doesn't process errors from sd_bus_add_match

The sd_bus_add_match() method may return a lot of possible errors - ENOBUFS, ECHILD, EINVAL, etc. In sdbusplus/bus/match.hpp, in match() call the return code of sd_bus_add_match() is not checked, due to which the targeted watchers/listeners may silently fail without reporting anything to the end user.

For instance, some machine having a lot of sensors may have a lot of watchers for them.
However, after exceeding watcher/matchers limit it will not set up any new matches at all.

Another example: if there some typo in 'path', it will be silently eaten by sdbusplus interface.

automake: error: cannot open < aminclude_static.am: No such file or directory

Hello all,

unfortunately I can't even build the library. Any hint will be valuable.

$ git lol -1 
* 8cd7a4a (HEAD -> master, origin/master, origin/HEAD) Fix warnings in forward declarations
$ ./bootstrap.sh 
+ AUTOCONF_FILES='Makefile.in aclocal.m4 ar-lib autom4te.cache compile         config.guess config.h.in config.sub configure depcomp install-sh         ltmain.sh missing *libtool test-driver'
+ case $1 in
+ autoreconf -vfi
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force -Im4
aclocal: warning: couldn't open directory 'm4': No such file or directory
autoreconf: configure.ac: tracing
autoreconf: configure.ac: creating directory build-aux
autoreconf: running: libtoolize --copy --force
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'build-aux'.
libtoolize: copying file 'build-aux/ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltoptions.m4'
libtoolize: copying file 'm4/ltsugar.m4'
libtoolize: copying file 'm4/ltversion.m4'
libtoolize: copying file 'm4/lt~obsolete.m4'
autoreconf: running: /usr/bin/autoconf --force
autoreconf: running: /usr/bin/autoheader --force
autoreconf: running: automake --add-missing --copy --force-missing
configure.ac:27: installing 'build-aux/ar-lib'
configure.ac:26: installing 'build-aux/compile'
configure.ac:79: installing 'build-aux/config.guess'
configure.ac:79: installing 'build-aux/config.sub'
configure.ac:7: installing 'build-aux/install-sh'
configure.ac:7: installing 'build-aux/missing'
automake: error: cannot open < aminclude_static.am: No such file or directory
autoreconf: automake failed with exit status: 1

Handle time as a native type

Define a type specifier for times.
There are various units of times (seconds through microseconds) in different interfaces and it is going to cause an issue

Compilation failed

Trying to compile git master via openbmc/yocto using libsystemd 241 results in the following compilation error:

| arm-openbmc-linux-gnueabi-g++  -march=armv6 -marm -mtune=arm1176jz-s --sysroot=/srv/build/mw/openbmc-private/build/tmp/work/armv6-openbmc-linux-gnueabi/sdbusplus/1.0+git999-r1/recipe-sysroot -std=c++17 -DHAVE_CONFIG_H -I. -I../../../../../../../workspace/sources/sdbusplus/example -I..     -I../../../../../../../workspace/sources/sdbusplus -O2 -pipe -g -feliminate-unused-debug-types -fmacro-prefix-map=/srv/build/mw/openbmc-private/build/tmp/work/armv6-openbmc-linux-gnueabi/sdbusplus/1.0+git999-r1=/usr/src/debug/sdbusplus/1.0+git999-r1                      -fdebug-prefix-map=/srv/build/mw/openbmc-private/build/tmp/work/armv6-openbmc-linux-gnueabi/sdbusplus/1.0+git999-r1=/usr/src/debug/sdbusplus/1.0+git999-r1                      -fdebug-prefix-map=/srv/build/mw/openbmc-private/build/tmp/work/armv6-openbmc-linux-gnueabi/sdbusplus/1.0+git999-r1/recipe-sysroot=                      -fdebug-prefix-map=/srv/build/mw/openbmc-private/build/tmp/work/armv6-openbmc-linux-gnueabi/sdbusplus/1.0+git999-r1/recipe-sysroot-native=  -fvisibility-inlines-hidden -Wall -Werror -MT net/poettering/Calculator/calculator_server-error.o -MD -MP -MF net/poettering/Calculator/.deps/calculator_server-error.Tpo -c -o net/poettering/Calculator/calculator_server-error.o `test -f 'net/poettering/Calculator/error.cpp' || echo '../../../../../../../workspace/sources/sdbusplus/example/'`net/poettering/Calculator/error.cpp
| mv -f net/poettering/Calculator/.deps/calculator_server-error.Tpo net/poettering/Calculator/.deps/calculator_server-error.Po
| In file included from /srv/build/mw/openbmc-private/build/tmp/work/armv6-openbmc-linux-gnueabi/sdbusplus/1.0+git999-r1/recipe-sysroot/usr/include/systemd/sd-bus.h:113,
|                  from ../../../../../../../workspace/sources/sdbusplus/sdbusplus/sdbus.hpp:3,
|                  from net/poettering/Calculator/server.cpp:3:
| ../../../../../../../workspace/sources/sdbusplus/sdbusplus/vtable.hpp: In function 'constexpr sdbusplus::vtable::vtable_t sdbusplus::vtable::method(const char*, const char*, const char*, sd_bus_message_handler_t, uint64_t)':
| ../../../../../../../workspace/sources/sdbusplus/sdbusplus/vtable.hpp:128:12: error: could not convert '{_SD_BUS_VTABLE_METHOD, flags, {{member, signature, result, handler, 0}}}' from '<brace-enclosed initializer list>' to 'sdbusplus::vtable::vtable_t' {aka 'sd_bus_vtable'}
|      return SD_BUS_METHOD(member, signature, result, handler, flags);
|             ^~~~~~~~~~~~~
| ../../../../../../../workspace/sources/sdbusplus/sdbusplus/vtable.hpp: In function 'constexpr sdbusplus::vtable::vtable_t sdbusplus::vtable::method_o(const char*, const char*, const char*, sd_bus_message_handler_t, size_t, uint64_t)':
| ../../../../../../../workspace/sources/sdbusplus/sdbusplus/vtable.hpp:136:12: error: could not convert '{_SD_BUS_VTABLE_METHOD, flags, {{member, signature, result, handler, offset}}}' from '<brace-enclosed initializer list>' to 'sdbusplus::vtable::vtable_t' {aka 'sd_bus_vtable'}
|      return SD_BUS_METHOD_WITH_OFFSET(member, signature, result, handler, offset,
|             ^~~~~~~~~~~~~~~~~~~~~~~~~
| ../../../../../../../workspace/sources/sdbusplus/sdbusplus/vtable.hpp: In function 'constexpr sdbusplus::vtable::vtable_t sdbusplus::vtable::signal(const char*, const char*, uint64_t)':
| ../../../../../../../workspace/sources/sdbusplus/sdbusplus/vtable.hpp:143:12: error: could not convert '{_SD_BUS_VTABLE_SIGNAL, flags, {{member, signature}}}' from '<brace-enclosed initializer list>' to 'sdbusplus::vtable::vtable_t' {aka 'sd_bus_vtable'}
|      return SD_BUS_SIGNAL(member, signature, flags);
|             ^~~~~~~~~~~~~
| ../../../../../../../workspace/sources/sdbusplus/sdbusplus/vtable.hpp: In function 'constexpr sdbusplus::vtable::vtable_t sdbusplus::vtable::property(const char*, const char*, sd_bus_property_get_t, uint64_t)':
| ../../../../../../../workspace/sources/sdbusplus/sdbusplus/vtable.hpp:150:12: error: could not convert '{_SD_BUS_VTABLE_PROPERTY, flags, {{member, signature, get, 0, 0}}}' from '<brace-enclosed initializer list>' to 'sdbusplus::vtable::vtable_t' {aka 'sd_bus_vtable'}
|      return SD_BUS_PROPERTY(member, signature, get, 0, flags);
|             ^~~~~~~~~~~~~~~
| ../../../../../../../workspace/sources/sdbusplus/sdbusplus/vtable.hpp: In function 'constexpr sdbusplus::vtable::vtable_t sdbusplus::vtable::property(const char*, const char*, sd_bus_property_get_t, sd_bus_property_set_t, uint64_t)':
| ../../../../../../../workspace/sources/sdbusplus/sdbusplus/vtable.hpp:158:12: error: could not convert '{_SD_BUS_VTABLE_WRITABLE_PROPERTY, flags, {{member, signature, get, set, 0}}}' from '<brace-enclosed initializer list>' to 'sdbusplus::vtable::vtable_t' {aka 'sd_bus_vtable'}
|      return SD_BUS_WRITABLE_PROPERTY(member, signature, get, set, 0, flags);
|             ^~~~~~~~~~~~~~~~~~~~~~~~
| ../../../../../../../workspace/sources/sdbusplus/sdbusplus/vtable.hpp: In function 'constexpr sdbusplus::vtable::vtable_t sdbusplus::vtable::property_o(const char*, const char*, size_t, uint64_t)':
| ../../../../../../../workspace/sources/sdbusplus/sdbusplus/vtable.hpp:164:12: error: could not convert '{_SD_BUS_VTABLE_PROPERTY, flags, {{member, signature, nullptr, 0, offset}}}' from '<brace-enclosed initializer list>' to 'sdbusplus::vtable::vtable_t' {aka 'sd_bus_vtable'}
|      return SD_BUS_PROPERTY(member, signature, nullptr, offset, flags);
|             ^~~~~~~~~~~~~~~
| ../../../../../../../workspace/sources/sdbusplus/sdbusplus/vtable.hpp: In function 'constexpr sdbusplus::vtable::vtable_t sdbusplus::vtable::property_o(const char*, const char*, sd_bus_property_set_t, size_t, uint64_t)':
| ../../../../../../../workspace/sources/sdbusplus/sdbusplus/vtable.hpp:171:12: error: could not convert '{_SD_BUS_VTABLE_WRITABLE_PROPERTY, flags, {{member, signature, nullptr, set, offset}}}' from '<brace-enclosed initializer list>' to 'sdbusplus::vtable::vtable_t' {aka 'sd_bus_vtable'}
|      return SD_BUS_WRITABLE_PROPERTY(member, signature, nullptr, set, offset,
|             ^~~~~~~~~~~~~~~~~~~~~~~~
| In file included from /srv/build/mw/openbmc-private/build/tmp/work/armv6-openbmc-linux-gnueabi/sdbusplus/1.0+git999-r1/recipe-sysroot/usr/include/systemd/sd-bus.h:113,
|                  from ../../../../../../../workspace/sources/sdbusplus/sdbusplus/exception.hpp:3,
|                  from ./net/poettering/Calculator/error.hpp:3,
|                  from ../../../../../../../workspace/sources/sdbusplus/example/calculator-server.cpp:2:
| ../../../../../../../workspace/sources/sdbusplus/sdbusplus/vtable.hpp: In function 'constexpr sdbusplus::vtable::vtable_t sdbusplus::vtable::method(const char*, const char*, const char*, sd_bus_message_handler_t, uint64_t)':
| ../../../../../../../workspace/sources/sdbusplus/sdbusplus/vtable.hpp:128:12: error: could not convert '{_SD_BUS_VTABLE_METHOD, flags, {{member, signature, result, handler, 0}}}' from '<brace-enclosed initializer list>' to 'sdbusplus::vtable::vtable_t' {aka 'sd_bus_vtable'}
|      return SD_BUS_METHOD(member, signature, result, handler, flags);
|             ^~~~~~~~~~~~~
| ../../../../../../../workspace/sources/sdbusplus/sdbusplus/vtable.hpp: In function 'constexpr sdbusplus::vtable::vtable_t sdbusplus::vtable::method_o(const char*, const char*, const char*, sd_bus_message_handler_t, size_t, uint64_t)':
| ../../../../../../../workspace/sources/sdbusplus/sdbusplus/vtable.hpp:136:12: error: could not convert '{_SD_BUS_VTABLE_METHOD, flags, {{member, signature, result, handler, offset}}}' from '<brace-enclosed initializer list>' to 'sdbusplus::vtable::vtable_t' {aka 'sd_bus_vtable'}
|      return SD_BUS_METHOD_WITH_OFFSET(member, signature, result, handler, offset,
|             ^~~~~~~~~~~~~~~~~~~~~~~~~
| ../../../../../../../workspace/sources/sdbusplus/sdbusplus/vtable.hpp: In function 'constexpr sdbusplus::vtable::vtable_t sdbusplus::vtable::signal(const char*, const char*, uint64_t)':
| ../../../../../../../workspace/sources/sdbusplus/sdbusplus/vtable.hpp:143:12: error: could not convert '{_SD_BUS_VTABLE_SIGNAL, flags, {{member, signature}}}' from '<brace-enclosed initializer list>' to 'sdbusplus::vtable::vtable_t' {aka 'sd_bus_vtable'}
|      return SD_BUS_SIGNAL(member, signature, flags);
|             ^~~~~~~~~~~~~
| ../../../../../../../workspace/sources/sdbusplus/sdbusplus/vtable.hpp: In function 'constexpr sdbusplus::vtable::vtable_t sdbusplus::vtable::property(const char*, const char*, sd_bus_property_get_t, uint64_t)':
| ../../../../../../../workspace/sources/sdbusplus/sdbusplus/vtable.hpp:150:12: error: could not convert '{_SD_BUS_VTABLE_PROPERTY, flags, {{member, signature, get, 0, 0}}}' from '<brace-enclosed initializer list>' to 'sdbusplus::vtable::vtable_t' {aka 'sd_bus_vtable'}
|      return SD_BUS_PROPERTY(member, signature, get, 0, flags);
|             ^~~~~~~~~~~~~~~
| ../../../../../../../workspace/sources/sdbusplus/sdbusplus/vtable.hpp: In function 'constexpr sdbusplus::vtable::vtable_t sdbusplus::vtable::property(const char*, const char*, sd_bus_property_get_t, sd_bus_property_set_t, uint64_t)':
| ../../../../../../../workspace/sources/sdbusplus/sdbusplus/vtable.hpp:158:12: error: could not convert '{_SD_BUS_VTABLE_WRITABLE_PROPERTY, flags, {{member, signature, get, set, 0}}}' from '<brace-enclosed initializer list>' to 'sdbusplus::vtable::vtable_t' {aka 'sd_bus_vtable'}
|      return SD_BUS_WRITABLE_PROPERTY(member, signature, get, set, 0, flags);
|             ^~~~~~~~~~~~~~~~~~~~~~~~
| ../../../../../../../workspace/sources/sdbusplus/sdbusplus/vtable.hpp: In function 'constexpr sdbusplus::vtable::vtable_t sdbusplus::vtable::property_o(const char*, const char*, size_t, uint64_t)':
| ../../../../../../../workspace/sources/sdbusplus/sdbusplus/vtable.hpp:164:12: error: could not convert '{_SD_BUS_VTABLE_PROPERTY, flags, {{member, signature, nullptr, 0, offset}}}' from '<brace-enclosed initializer list>' to 'sdbusplus::vtable::vtable_t' {aka 'sd_bus_vtable'}
|      return SD_BUS_PROPERTY(member, signature, nullptr, offset, flags);
|             ^~~~~~~~~~~~~~~
| ../../../../../../../workspace/sources/sdbusplus/sdbusplus/vtable.hpp: In function 'constexpr sdbusplus::vtable::vtable_t sdbusplus::vtable::property_o(const char*, const char*, sd_bus_property_set_t, size_t, uint64_t)':
| ../../../../../../../workspace/sources/sdbusplus/sdbusplus/vtable.hpp:171:12: error: could not convert '{_SD_BUS_VTABLE_WRITABLE_PROPERTY, flags, {{member, signature, nullptr, set, offset}}}' from '<brace-enclosed initializer list>' to 'sdbusplus::vtable::vtable_t' {aka 'sd_bus_vtable'}
|      return SD_BUS_WRITABLE_PROPERTY(member, signature, nullptr, set, offset,
|             ^~~~~~~~~~~~~~~~~~~~~~~~
| Makefile:577: recipe for target 'calculator_server-calculator-server.o' failed
| make[3]: *** [calculator_server-calculator-server.o] Error 1
| make[3]: *** Waiting for unfinished jobs....
| Makefile:591: recipe for target 'net/poettering/Calculator/calculator_server-server.o' failed
| make[3]: *** [net/poettering/Calculator/calculator_server-server.o] Error 1
| mv -f .deps/list_users-list-users.Tpo .deps/list_users-list-users.Po
| make[3]: Leaving directory '/srv/build/mw/openbmc-private/build/tmp/work/armv6-openbmc-linux-gnueabi/sdbusplus/1.0+git999-r1/sdbusplus-1.0+git999/example'
| Makefile:452: recipe for target 'all' failed
| make[2]: *** [all] Error 2
| make[2]: Leaving directory '/srv/build/mw/openbmc-private/build/tmp/work/armv6-openbmc-linux-gnueabi/sdbusplus/1.0+git999-r1/sdbusplus-1.0+git999/example'
| Makefile:805: recipe for target 'all-recursive' failed
| make[1]: *** [all-recursive] Error 1
| make[1]: Leaving directory '/srv/build/mw/openbmc-private/build/tmp/work/armv6-openbmc-linux-gnueabi/sdbusplus/1.0+git999-r1/sdbusplus-1.0+git999'
| Makefile:554: recipe for target 'all' failed
| make: *** [all] Error 2
| ERROR: oe_runmake failed
| WARNING: exit code 1 from a shell command.
| WARNING: /srv/build/mw/openbmc-private/poky/bitbake/lib/bb/build.py:570: ResourceWarning: unclosed file <_io.TextIOWrapper name='/srv/build/mw/openbmc-private/build/workspace/sources/sdbusplus/singletask.lock' mode='a+' encoding='UTF-8'>
|   exec_func(task, localdata)
| 
| ERROR: Function failed: do_compile (log file is located at /srv/build/mw/openbmc-private/build/tmp/work/armv6-openbmc-linux-gnueabi/sdbusplus/1.0+git999-r1/temp/log.do_compile.19889)

Rewrite message tests to use googletest and no real dbus

The message tests are currently written using their own homegrown test layout and spawn a thread which hosts a dbus service for the tests to talk over a real dbus. These tests don't really need a real dbus so we should rewrite them down into a single test.

Using `const` flag results in build errors

If const flag is used as described in interface.md:

The only current supported value for flags is const, which corresponds to SD_BUS_VTABLE_PROPERTY_CONST, making the property read-only via D-Bus but still writable by the app implementing it.

then build fails like this:

| Traceback (most recent call last):
|   File "/home/spirit/src/vesnin/openbmc-alternate/build/tmp/work/armv5e-openbmc-linux-gnueabi/phosphor-dbus-interfaces/1.0-r1/recipe-sysroot-native/usr/bin/sdbus++", line 50, in <module>
|     main()
|   File "/home/spirit/src/vesnin/openbmc-alternate/build/tmp/work/armv5e-openbmc-linux-gnueabi/phosphor-dbus-interfaces/1.0-r1/recipe-sysroot-native/usr/bin/sdbus++", line 45, in main
|     instance = valid_types[args.typeName].load(args.item, args.rootdir)
|   File "/home/spirit/src/vesnin/openbmc-alternate/build/tmp/work/armv5e-openbmc-linux-gnueabi/phosphor-dbus-interfaces/1.0-r1/recipe-sysroot-native/usr/lib/python2.7/site-packages/sdbusplus/interface.py", line 21, in load
|     return Interface(**y)
|   File "/home/spirit/src/vesnin/openbmc-alternate/build/tmp/work/armv5e-openbmc-linux-gnueabi/phosphor-dbus-interfaces/1.0-r1/recipe-sysroot-native/usr/lib/python2.7/site-packages/sdbusplus/interface.py", line 25, in __init__
|     [Property(**p) for p in kwargs.pop('properties', [])]
|   File "/home/spirit/src/vesnin/openbmc-alternate/build/tmp/work/armv5e-openbmc-linux-gnueabi/phosphor-dbus-interfaces/1.0-r1/recipe-sysroot-native/usr/lib/python2.7/site-packages/sdbusplus/property.py", line 12, in __init__
|     super(Property, self).__init__(**kwargs)
|   File "/home/spirit/src/vesnin/openbmc-alternate/build/tmp/work/armv5e-openbmc-linux-gnueabi/phosphor-dbus-interfaces/1.0-r1/recipe-sysroot-native/usr/lib/python2.7/site-packages/sdbusplus/namedelement.py", line 8, in __init__
|     super(NamedElement, self).__init__(**kwargs)
|   File "/home/spirit/src/vesnin/openbmc-alternate/build/tmp/work/armv5e-openbmc-linux-gnueabi/phosphor-dbus-interfaces/1.0-r1/recipe-sysroot-native/usr/lib/python2.7/site-packages/sdbusplus/renderer.py", line 3, in __init__
|     super(Renderer, self).__init__(**kwargs)
| TypeError: object.__init__() takes no parameters

Specifically, the failure is triggered by this code block in a yaml interface file:

properties:
    - name: Whatever
      type: boolean
      default: false
      flags:
        - const

If I remove the flags, then phosphor-dbus-interfaces builds just fine.

Allow compiling library statically

Due to some restrictions and uncertainties on the target system, I'd like to be able to statically link this library into my program, so I can make sure it won't crash because the target system doesn't have the dynamic library files.

Alternatively a simple way (like a dpkg package) to distrubute the shared library files on the target system without having to compile them there would work for me too.

Build documentation

I saw you switched to the new meson build system.
Since that is not a common build system I highly recommend you add documentation on how to properly build the project.

request_name does not propagate error state/return code

I just noticed that if I try to request a name on dbus with sdbusplus::bus::request_name, I do not get a return code from the underlying implementation. This conveniently hid a bug with policy configuration in my case.
Is there a reason for doing so or might a simple return do the trick in the implementation?

Running example calculator crashes with: sd_bus_request_name: org.freedesktop.DBus.Error.InvalidArgs: Invalid argument

Hello there!

I'm not sure if that's an issue with the library or me not quite understanding how the dbus works.

So just running the example calculator crashes the program and it gives me this error message:

terminate called after throwing an instance of 'sdbusplus::exception::SdBusError'
  what():  sd_bus_request_name: org.freedesktop.DBus.Error.InvalidArgs: Invalid argument
Aborted

Investigating the error turns out the error is thrown right here:

void request_name(const char* service)
{
int r = _intf->sd_bus_request_name(_bus.get(), service, 0);
if (r < 0)
{
throw exception::SdBusError(-r, "sd_bus_request_name");
}
}
(line 234 to be exact)

I personally have the feeling that the bus name needs to be registered somewhere beforehand, before it can be used. If that's the case, would it be possible to add an example for that too?

long build directory paths cause sdbusplus compile failures

We've got a fairly lengthy jenkins build path in our downstream code and for some reason the latest poky or meta-openembedded bumps are now causing build failures in sdbusplus because of it.

| Assembler messages:
| Fatal error: can't create test/test-server.p/_home_fspcibld_openbmc-dev-jenkins_workspace_OpenBMC-Dev_build_github-private_ghe-openbmc-rebase-test-builds_label_x86-docker-builder_target_rainier_build_work_armv7ahf-vfpv4d16-openbmc-linux-gnueabi_sdbusplus_1.0+gitAUTOINC+2be0e17331-r1_build_test_server_Test_server.cpp.o: File name too long

It seems this sdbusplus test cases bases a generated file name off of the directory path. Any way we could shorten this up?

Test issue.

Creating a test issue for testing purposes.

undefined reference to `boost::thread_detail::commit_once_region(boost::once_flag&)

Pulled in latest upstream poky (https://gerrit.openbmc-project.xyz/c/openbmc/openbmc/+/33333/) and hit a new sdbusplus error. We discussed a bit in IRC and one thought was to add in context.so as a dependency. I did a quick try at that but it still failed. It was also noted that for some reason the build process is using the .a vs. .so version of the boost libraries.

https://openpower.xyz/job/build-openbmc/62209/console

15:53:01 | /usr/src/debug/boost/1.73.0-r0/boost_1_73_0/./boost/thread/pthread/once_atomic.hpp:123: undefined reference to `boost::thread_detail::enter_once_region(boost::once_flag&)'
15:53:01 | /tmp/openbmc/work/arm1176jzs-openbmc-linux-gnueabi/sdbusplus/1.0+gitAUTOINC+fa3137a78e-r1/recipe-sysroot-native/usr/bin/arm-openbmc-linux-gnueabi/../../libexec/arm-openbmc-linux-gnueabi/gcc/arm-openbmc-linux-gnueabi/10.1.0/ld: /usr/src/debug/boost/1.73.0-r0/boost_1_73_0/./boost/thread/pthread/once_atomic.hpp:138: undefined reference to `boost::thread_detail::commit_once_region(boost::once_flag&)'
15:53:01 | /tmp/openbmc/work/arm1176jzs-openbmc-linux-gnueabi/sdbusplus/1.0+gitAUTOINC+fa3137a78e-r1/recipe-sysroot-native/usr/bin/arm-openbmc-linux-gnueabi/../../libexec/arm-openbmc-linux-gnueabi/gcc/arm-openbmc-linux-gnueabi/10.1.0/ld: /tmp/openbmc/work/arm1176jzs-openbmc-linux-gnueabi/sdbusplus/1.0+gitAUTOINC+fa3137a78e-r1/recipe-sysroot/usr/lib/libboost_coroutine.a(stack_traits.o): in function `void boost::call_once<void (&)(unsigned int*), unsigned int*>(boost::once_flag&, void (&)(unsigned int*), unsigned int*&&)':
15:53:01 | /usr/src/debug/boost/1.73.0-r0/boost_1_73_0/./boost/thread/pthread/once_atomic.hpp:123: undefined reference to `boost::thread_detail::enter_once_region(boost::once_flag&)'
15:53:01 | /tmp/openbmc/work/arm1176jzs-openbmc-linux-gnueabi/sdbusplus/1.0+gitAUTOINC+fa3137a78e-r1/recipe-sysroot-native/usr/bin/arm-openbmc-linux-gnueabi/../../libexec/arm-openbmc-linux-gnueabi/gcc/arm-openbmc-linux-gnueabi/10.1.0/ld: /usr/src/debug/boost/1.73.0-r0/boost_1_73_0/./boost/thread/pthread/once_atomic.hpp:138: undefined reference to `boost::thread_detail::commit_once_region(boost::once_flag&)'
15:53:01 | /tmp/openbmc/work/arm1176jzs-openbmc-linux-gnueabi/sdbusplus/1.0+gitAUTOINC+fa3137a78e-r1/recipe-sysroot-native/usr/bin/arm-openbmc-linux-gnueabi/../../libexec/arm-openbmc-linux-gnueabi/gcc/arm-openbmc-linux-gnueabi/10.1.0/ld: /tmp/openbmc/work/arm1176jzs-openbmc-linux-gnueabi/sdbusplus/1.0+gitAUTOINC+fa3137a78e-r1/recipe-sysroot/usr/lib/libboost_coroutine.a(stack_traits.o): in function `void boost::call_once<void (&)(rlimit*), rlimit*>(boost::once_flag&, void (&)(rlimit*), rlimit*&&)':
15:53:01 | /usr/src/debug/boost/1.73.0-r0/boost_1_73_0/./boost/thread/pthread/once_atomic.hpp:123: undefined reference to `boost::thread_detail::enter_once_region(boost::once_flag&)'
15:53:01 | /tmp/openbmc/work/arm1176jzs-openbmc-linux-gnueabi/sdbusplus/1.0+gitAUTOINC+fa3137a78e-r1/recipe-sysroot-native/usr/bin/arm-openbmc-linux-gnueabi/../../libexec/arm-openbmc-linux-gnueabi/gcc/arm-openbmc-linux-gnueabi/10.1.0/ld: /usr/src/debug/boost/1.73.0-r0/boost_1_73_0/./boost/thread/pthread/once_atomic.hpp:138: undefined reference to `boost::thread_detail::commit_once_region(boost::once_flag&)'
15:53:01 | /tmp/openbmc/work/arm1176jzs-openbmc-linux-gnueabi/sdbusplus/1.0+gitAUTOINC+fa3137a78e-r1/recipe-sysroot-native/usr/bin/arm-openbmc-linux-gnueabi/../../libexec/arm-openbmc-linux-gnueabi/gcc/arm-openbmc-linux-gnueabi/10.1.0/ld: /usr/src/debug/boost/1.73.0-r0/boost_1_73_0/./boost/thread/pthread/once_atomic.hpp:123: undefined reference to `boost::thread_detail::enter_once_region(boost::once_flag&)'
15:53:01 | /tmp/openbmc/work/arm1176jzs-openbmc-linux-gnueabi/sdbusplus/1.0+gitAUTOINC+fa3137a78e-r1/recipe-sysroot-native/usr/bin/arm-openbmc-linux-gnueabi/../../libexec/arm-openbmc-linux-gnueabi/gcc/arm-openbmc-linux-gnueabi/10.1.0/ld: /usr/src/debug/boost/1.73.0-r0/boost_1_73_0/./boost/thread/pthread/once_atomic.hpp:138: undefined reference to `boost::thread_detail::commit_once_region(boost::once_flag&)'
15:53:01 | /tmp/openbmc/work/arm1176jzs-openbmc-linux-gnueabi/sdbusplus/1.0+gitAUTOINC+fa3137a78e-r1/recipe-sysroot-native/usr/bin/arm-openbmc-linux-gnueabi/../../libexec/arm-openbmc-linux-gnueabi/gcc/arm-openbmc-linux-gnueabi/10.1.0/ld: /usr/src/debug/boost/1.73.0-r0/boost_1_73_0/./boost/thread/pthread/once_atomic.hpp:123: undefined reference to `boost::thread_detail::enter_once_region(boost::once_flag&)'
15:53:01 | /tmp/openbmc/work/arm1176jzs-openbmc-linux-gnueabi/sdbusplus/1.0+gitAUTOINC+fa3137a78e-r1/recipe-sysroot-native/usr/bin/arm-openbmc-linux-gnueabi/../../libexec/arm-openbmc-linux-gnueabi/gcc/arm-openbmc-linux-gnueabi/10.1.0/ld: /usr/src/debug/boost/1.73.0-r0/boost_1_73_0/./boost/thread/pthread/once_atomic.hpp:138: undefined reference to `boost::thread_detail::commit_once_region(boost::once_flag&)'
15:53:01 | /tmp/openbmc/work/arm1176jzs-openbmc-linux-gnueabi/sdbusplus/1.0+gitAUTOINC+fa3137a78e-r1/recipe-sysroot-native/usr/bin/arm-openbmc-linux-gnueabi/../../libexec/arm-openbmc-linux-gnueabi/gcc/arm-openbmc-linux-gnueabi/10.1.0/ld: /usr/src/debug/boost/1.73.0-r0/boost_1_73_0/./boost/thread/pthread/once_atomic.hpp:123: undefined reference to `boost::thread_detail::enter_once_region(boost::once_flag&)'
15:53:01 | /tmp/openbmc/work/arm1176jzs-openbmc-linux-gnueabi/sdbusplus/1.0+gitAUTOINC+fa3137a78e-r1/recipe-sysroot-native/usr/bin/arm-openbmc-linux-gnueabi/../../libexec/arm-openbmc-linux-gnueabi/gcc/arm-openbmc-linux-gnueabi/10.1.0/ld: /usr/src/debug/boost/1.73.0-r0/boost_1_73_0/./boost/thread/pthread/once_atomic.hpp:138: undefined reference to `boost::thread_detail::commit_once_region(boost::once_flag&)'
15:53:01 | /tmp/openbmc/work/arm1176jzs-openbmc-linux-gnueabi/sdbusplus/1.0+gitAUTOINC+fa3137a78e-r1/recipe-sysroot-native/usr/bin/arm-openbmc-linux-gnueabi/../../libexec/arm-openbmc-linux-gnueabi/gcc/arm-openbmc-linux-gnueabi/10.1.0/ld: /tmp/openbmc/work/arm1176jzs-openbmc-linux-gnueabi/sdbusplus/1.0+gitAUTOINC+fa3137a78e-r1/recipe-sysroot/usr/lib/libboost_coroutine.a(coroutine_context.o): in function `boost::coroutines::detail::coroutine_context::coroutine_context(void (*)(boost::context::detail::transfer_t), boost::coroutines::detail::preallocated const&)':
15:53:01 | /usr/src/debug/boost/1.73.0-r0/boost_1_73_0/libs/coroutine/src/detail/coroutine_context.cpp:41: undefined reference to `make_fcontext'
15:53:01 | /tmp/openbmc/work/arm1176jzs-openbmc-linux-gnueabi/sdbusplus/1.0+gitAUTOINC+fa3137a78e-r1/recipe-sysroot-native/usr/bin/arm-openbmc-linux-gnueabi/../../libexec/arm-openbmc-linux-gnueabi/gcc/arm-openbmc-linux-gnueabi/10.1.0/ld: /tmp/openbmc/work/arm1176jzs-openbmc-linux-gnueabi/sdbusplus/1.0+gitAUTOINC+fa3137a78e-r1/recipe-sysroot/usr/lib/libboost_coroutine.a(coroutine_context.o): in function `boost::coroutines::detail::coroutine_context::jump(boost::coroutines::detail::coroutine_context&, void*)':
15:53:01 | /usr/src/debug/boost/1.73.0-r0/boost_1_73_0/libs/coroutine/src/detail/coroutine_context.cpp:68: undefined reference to `jump_fcontext'
15:53:01 | collect2: error: ld returned 1 exit status

sdbus++ generates invalid code for methods without return value

When defining an interface with a method without return value, e.g.

description: >
    An example interface
methods:
    - name: ping
      description: >
        Takes a string argument and returns nothing.
      parameters:
        - name: name
          type: string
          description: >
            The string argument.

the sdbus++ tool generates invalid code:

namespace details
{
namespace TestService
{
static const auto _param_Ping =
        utility::tuple_to_array(message::types::type_id<
                std::string>());
static const auto _return_Ping =
        utility::tuple_to_array(message::types::type_id<
                >());
}
}

_return_Ping has no associated type list. The error is

/home/anders05/Dev/sdbusplus/sdbusplus/message/types.hpp:198:72: error: no matching function for call to ‘type_id_multiple()’
         details::type_id_multiple<details::type_id_downcast_t<Args>...>(),
                                                                        ^
/home/anders05/Dev/sdbusplus/sdbusplus/message/types.hpp:187:56: note: candidate: template<class T, class ... Args> constexpr auto sdbusplus::message::types::details::type_id_multiple()
 template <typename T, typename ...Args> constexpr auto type_id_multiple()
                                                        ^
/home/anders05/Dev/sdbusplus/sdbusplus/message/types.hpp:187:56: note:   template argument deduction/substitution failed:
/home/anders05/Dev/sdbusplus/sdbusplus/message/types.hpp:198:72: note:   couldn't deduce template parameter ‘T’
         details::type_id_multiple<details::type_id_downcast_t<Args>...>(),
                                                                        ^
/home/anders05/Dev/dbus-examples/sdbusplus/src/.../.../.../TestService/server.cpp:64:20: error: invalid use of void expression
                 >());

Prevent functions and properties with reserved names.

A YAML file with an entry such as:

methods:
    - name: Delete

Will result in a C++ function being generated with the name delete. Since delete is a reserved word this does not work. Need to catch reserved words and come up with an alternative name (maybe delete_?)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.