I'm following the advice of Zimano on using the Bluez client as an example to implement Bluetooth in my Linux application.
I have installed:
libbluetooth-dev
libglib2.0-dev
libdbus-1-dev
The Bluez client example uses a D-Bus helper library that is included as part of Bluez in a gdbus folder when the soure code is downloaded.
I have looked at it for a few hours and I think if I want to follow the Bluez client example, I need to add and compile the gdbus source from the Bluez source with my program. My question is, do I have that wrong? Is that gdbus included elsewhere? The naming is so close to files in glib-2.0/gio that I am concerned that I am missing something.
GDBus is part of GIO, which is distributed with GLib.
Based on the package names you've provided I'm guessing you are using a Debian-derived distribution, so libglib2.0-dev is the package you need.
This is indeed quite a mess for naming. It appears to be that:
Official Glib Dbus library is named "GDBus", BUT it is part of "GIO" => thus you would (*) need (<glib.h> and) <gio/gio.h> , not <gdbus.h>
Bluez "gdbus.h" is their completely own local support library not found anywhere in binary form as such, also their license is restrictive for free inclusion.
(*) But of course the Bluez client still remains dependent on their own "gdbus.h" support library.
Related
A third party vendor is releasing a prebuilt security library to me and I do not have access to it`s code or makefiles. This library is compiled against specific versions of openssl & protobuf. Problem is, the app I work on, chromium, is also using modified versions of these 2 libraries (well, technically boringssl is not openssl; but they share symbols). They are being compiled with the chromium source and being linked in statically. When I add the security library to chromium, I end up with 2 conflicting versions of the libraries and objects that are compiled against different headers. This of course leads to runtime crashes and unpredictable results. Is there anything I can do to make sure that everything is linked properly and symbols do not clash?
Is there anything I can do to make sure that everything is linked properly and symbols do not clash?
Your only real choices are:
Use dlopen(..., RTLD_LOCAL); on the 3rd-party library
Ask the vendor to give you a version built against Chromium tree.
Stop using this 3rd party library altogether.
The solution proposed by Petesh -- link openssl and protobuf statically into the 3rd party library and hide their symbols -- looks like another possibility, but has licensing implications. It looks like both protobuf and openssl allow for binary redistribution, so this may actually work, but IANAL.
In order to understand ICU and its APIs, I wrote a sample program and the libraries this code would link against are -licuuc and -licui18n. The libraries were available because the libicu-devel.x86_64 package was installed on the test system.
In my quest to understand how to integrate ICU library with my application that is targeted for a centOS platform, I stumbled across this page, which says:
For simple use of ICU's predefined data, this section on data management can safely be skipped. The data is built into a library that is loaded along with the rest of ICU. No specific action or setup is required of either the application program or the execution environment.
This indicates that if the application has no intention of adding its own data, the data available in the libraries can be used. On my test system where ICU is installed, these are the files:
$ sudo find . -name "*icu*"
./opt/rbt_boost/include/boost/regex/icu.hpp
./lib64/libicui18n.so.42
./lib64/libicui18n.so.42.1
./lib64/libicuuc.so.42.1
./lib64/libicuuc.so.42
./usr/lib64/libicui18n.so.42
./usr/lib64/libicule.so
./usr/lib64/libicuio.so.42
./usr/lib64/libicutu.so
./usr/lib64/libiculx.so.42.1
./usr/lib64/pkgconfig/icu.pc
./usr/lib64/libicui18n.so
./usr/lib64/libicui18n.so.42.1
./usr/lib64/libicule.so.42.1
./usr/lib64/libicuuc.so.42.1
./usr/lib64/libiculx.so
./usr/lib64/libicuuc.so.42
./usr/lib64/libicuio.so.42.1
./usr/lib64/icu
./usr/lib64/libicudata.so.42
./usr/lib64/libicule.so.42
./usr/lib64/libicutu.so.42.1
./usr/lib64/libicuio.so
./usr/lib64/libicudata.so
./usr/lib64/libicudata.so.42.1
./usr/lib64/libiculx.so.42
./usr/lib64/libicutu.so.42
./usr/lib64/libicuuc.so
./usr/bin/icu-config
./usr/share/icu
./usr/share/man/man1/icu-config.1.gz
./var/lib/yum/yumdb/l/e59bf24facac0acba1622a5180d0e2a22dda69c8-libicu-devel-4.2.1-9.1.el6_2-x86_64
./var/lib/yum/yumdb/l/7062f72703a5afbf894d617b94db3d4769fe643d-libicu-4.2.1-9.1.el6_2-x86_64
Questions:
Which of these ICU libraries (and files) should be packaged with the application for ICU data to be available at run time? As mentioned earlier, I used libicui18n and libicuuc libraries for linking, so these need to be present.
Aside from the above two libraries, libicudata, going by the name, seems to be the obvious candidate. Correct?
Is there a static version of libicui18n and libicuuc libraries available for use or does one have to build it?
In general, what is the process followed for integrating ICU with a product?
Thanks!
ICU always needs to link against its data library.
Here's a very general discussion about which libraries you ened.
ICU has to be built with the --enable-static option to allow static linkage.
Ideally you will want to use pkg-config to manage your linkage against ICU.
If you are on centOS, rather than linking statically (with its headaches), you might consider just compiling against the libicu-devel package (using pkg-config as mentioned above) and then at run time your users can just include the appropriate libicu package.
I just tried to run a vala bluez example (found in the DbusClientSamples page) and I got this error:
GDBus.Error:org.freedesktop.DBus.Error.UnknownObject:
Method "DiscoverDevices" with signature "" on interface "org.bluez.Adapter"
doesn't exist
Is the sample using deprecated API? If yes, where can I find an updated document about bluez's DBUS API? All documents I find (by googling) contain the DiscoverDevices method, so I'm quite confused.
AFAICT org.bluez.Adapter is gone (I don't see it on my Fedora 20 system, running bluez-5.12). In its place is org.bluez.Adapter1. You can get all the latest documentation for the bluez D-Bus API at https://git.kernel.org/cgit/bluetooth/bluez.git/tree/doc
The best way to get the BlueZ DBus documentation is to download the source from the BlueZ web site, unpack it, then look in the doc directory. All of the current DBus APIs are listed there.
I've been using those documents a lot lately. You could ask for better, but they're good enough. It is mostly obvious, and the most non-obvious issues are explained.
The official BlueZ site also provides a blog post for BlueZ 5 API introduction and porting guide, that provides some descriptions on their DBus APIs. At the top of the page they wrote:
The BlueZ 5 D-Bus API contains significant changes compared to BlueZ
4. The bulk of the changes are due to the following features in BlueZ 5:
...
Introduction of interface versions (e.g. org.bluez.Adapter1). When new versions are introduced we’ll try to keep supporting at least the two latest versions simultaneously.
...
There is a section that discusses the DBus Object Manager:
Instead, an application would discover the available adapters by performing a ObjectManager.GetManagedObjects call and look for any returned objects with an “org.bluez.Adapter1″ interface.
Also, aside from checking out the docs directory of the BlueZ source code (as mentioned in the this and this answers), I find it also helpful to check the sample source codes in the test directory (https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/test).
Here are parts of the example-advertisement code:
BLUEZ_SERVICE_NAME = 'org.bluez'
LE_ADVERTISING_MANAGER_IFACE = 'org.bluez.LEAdvertisingManager1'
DBUS_OM_IFACE = 'org.freedesktop.DBus.ObjectManager'
DBUS_PROP_IFACE = 'org.freedesktop.DBus.Properties'
...
def main(timeout=0):
...
adapter_props = dbus.Interface(bus.get_object(BLUEZ_SERVICE_NAME, adapter),
"org.freedesktop.DBus.Properties")
adapter_props.Set("org.bluez.Adapter1", "Powered", dbus.Boolean(1))
I've built a Name Service Switch Module for Red Hat Linux.
Using strace, I've determined that the OS looks for the library in various directories, but only for files with the extension .so.2 (e.g. libnss_xxx.so.2, where xxx is the service name)
Why doesn't it look for .so or .so.1 libraries? Is there any guarantee that it won't stop looking for .so.2 libraries and start looking for .so.3 libraries in future?
EDIT: http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html, says that the 2 is 'a version number that is incremented whenever the interface changes'.
So I guess that:
The version of NSS requires version 2 of the libraries.
An OS update with an updated NSS might require a different version number.
Can someone confirm whether that is true?
You're assumption is generally true with a minor edit:
The version of NSS requires a version of the libraries with interface version 2.
An OS update with an updated NSS might require a different version number.
The version of an interface does not necessarily need to change with the version of the library, i.e. a newer version of the library might still provide the same interface.
There are two types of so files: shared libraries (loaded and scanned for symbols at compile time, loaded again and linked at program startup time) and modules (loaded and linked at run time). The idea of shared libraries is that your program requires a certain version of the library. This version is determined at compile time. Once the program is compiled, it should continue to work even if a new (incompatible) version of the library is installed. This means that the new version must be a different file, so old programs can still use the old library while newer (or more recently compiled) programs use the newer version.
To properly use this system, your program must somehow make sure that the library version it needs will continue to be installed. This is one of the tasks of a distribution's packaging system. The package containing your program must have a dependency on the required version of the library package.
However, you seem to be talking about modules. Things are different there. They do not carry such a version, because ld.so (which takes care of loading shared libraries) isn't the one loading them. Your program should be bundled with those modules, so the module versions are always compatible with the program using them. This works for most programs.
But it doesn't work if your program allows third party modules. So they can come up with their own versioning system. This seems to be what nss has done (I'm not familiar with it, though). This means that they have defined a protocol version (currently 2), which specifies what a module should look like: which symbols need to be defined, what arguments do functions expect, these sort of things. If you create a module following version 2 of the protocol, you should name your module .so.2 (because that's their way of checking your supported version). If they create a new incompatible protocol 3, they will start looking for .so.3. Your module will no longer be found, and that's a good thing, because it will also not support the new protocol.
I need to get similar information on the current windows and virtual desktops as that provided by the command-line app wmctrl. I s there some (C/C++) API header & lib-files that I can use?
If it must be in C/C++, i think libxcb-wm is the most prominent one: very mature, still actively developed, and from Freedesktop, the same organization that created the EWMH spec.
On Debian/Ubuntu you have the binary packages libxcb-ewmh2 (run-time library) and libxcb-ewmh-dev (development headers), both from source package xcb-util-wm:
sudo apt install libxcb-ewmh-dev # also pulls libxcb-ewmh2, as usual
And official Documentation and Tutorial from Xorg
Download the source code of wmctrl and study it. If you are making some free software with the same or compatible GPLv2 license you could take some code from it.
There is only one source file main.c and it seems to do ordinary Xlib calls, notably XGetWindowProperty calls wrapped in get_property
I'm very surprised you asked the question here. With free software, it is so much simpler and quicker to download the source code and study it.