On Thu, 25 Aug 2011 14:06:21 -0300
Vinicius Costa Gomes [off-list ref] wrote:

[...]

quoted

quoted

diff --git a/Makefile.am b/Makefile.am
index 4bcff4d..ff33bf0 100644
--- a/Makefile.am
+++ b/Makefile.am

@@ -230,8 +230,10 @@ builtin_sources += thermometer/main.c \
 endif
 
 if SIXAXISPLUGIN
-builtin_modules += sixaxis
-builtin_sources += plugins/sixaxis.c
+plugin_LTLIBRARIES += plugins/sixaxis.la
+plugins_sixaxis_la_SOURCES = plugins/sixaxis.c
+plugins_sixaxis_la_LDFLAGS = -module -avoid-version -no-undefined @UDEV_LIBS@
+plugins_sixaxis_la_CFLAGS = -fvisibility=hidden @DBUS_CFLAGS@ @GLIB_CFLAGS@ @UDEV_CFLAGS@
 endif

This is not enough, the external plugin can be compiled but I can be used
at runtime because it is using functions from src/storage.c and others,
which seem to be embedded inside bluetoothd only, so I get:

bluetoothd[23459]: Can't load plugin \
  /home/ao2/Proj/PS3/PS3_sixaxis/bluez/plugins/.libs/playstation-peripheral.so: \
  /home/ao2/Proj/PS3/PS3_sixaxis/bluez/plugins/.libs/playstation-peripheral.so: \
  undefined symbol: write_device_name

I could link the needed object files like storage.o and company into the
plugin binary, but definitely this doesn't look OK. Should a shared library
provide those "utility" functions to bluetoothd _and_ external plugins?

This plugin is the first non-trivial external plugin I can see in the tree,
so maybe this problem has never showed up before.

The problem is the visibility of the symbols, src/bluetooth.ver defines
which symbols should[1] be visible to plugins. Every plugin should only
depend on those methods from the "core".

Indeed, adding the needed symbols to the linker script makes the plugin
work:

diff --git a/src/bluetooth.ver b/src/bluetooth.ver
index b71c70d..11fcd33 100644
--- a/src/bluetooth.ver
+++ b/src/bluetooth.ver

@@ -5,6 +5,19 @@
                info;
                error;
                debug;
+               manager_get_default_adapter;
+               adapter_get_address;
+               write_device_name;
+               record_from_string;
+               store_record;
+               sdp_record_free;
+               store_device_id;
+               write_trust;
+               dbus_bus_get;
+               adapter_get_device;
+               device_set_temporary;
+               device_set_name;
+               dbus_connection_unref;
        local:
                *;
 };

If we want to keep the sixaxis plugin external we need to make the
symbols it need visible, but I wonder if that is right solution.

If there was a public API for plugins to use with well defined prefixes,
the linking scripts could use those, I am thinking to something like:
	sdp_*;
	storage_*;
	device_*;
	dbus_*;

But you bluez people have to tell me if this is the way to go and if
you are willing to do that, of if I'd better have the plugin builtin for
now.

[1] Seems that with builtin plugins that visibility enforcement doesn't
work, right?

This seems to be the case indeed, a bluiltin plugin can use any (non
static?) symbol linked in the bluetoothd binary.

Thanks,
   Antonio

-- 
Antonio Ospite
http://ao2.it

PGP public key ID: 0x4553B001

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?