Including a subset of the Bluez package in our build


We have a MIPS (ar71xx) based device which is similar in architecture to a TP-LINK MR3020 router, but has enlarged RAM (64MB) and FLASH (16MB). It's used to monitor energy meters and solar inverters. We have been successfully using OpenWrt 14 (Barrier Breaker) for some years on this device and now want to get OpenWrt 18 running on it. Most of the work is done; we can build and install firmware with the required packages (including our own "solarmon" package which implements our monitoring software) and the device boots and runs.

The issue is Bluetooth, caused by the way the Bluez package is structured and built. One of the functions of our device is to monitor SMA solar inverters via their Bluetooth interface. For that, we need bluez-lib and the hciconfig and hcitool utilities provided by Bluez.

If I configure the firmware build (via Menuconfig) to include bluez-utils, the resulting firmware image is huge (about 8MB) due to bluez-utils requiring GLib2. But the Bluetooth kernel modules, runtime library (libbluetooth) and hcitool/hciconfig utilities don't require the Glib2 runtime; I can delete that from the running system without causing any problems.

So I'm looking for any suggestions as to how I can include hcitool and hciconfig in our firmware image without having to also include Glib2. I noticed that the Bluez package builds hcitool and hciconfig even if bluez-utils is not selected in Menuconfig, and I can copy those two programs to our device and they work, without the GLib2 runtime being present.

Is there some way the Makefile for my own "solarmon" package to reference those files?

Split it into different packages? I don't think bluez offers a very granual way of specifying binaries that you want to compile so you should probably set glib as a build requirement and specify it per package.

If there's like only one binary or such that requires glib (haven't checked) I'd prefer if we all lump them together as one package instead of breaking it down for every file/binary.

Hi Dizzy,

I like the idea of splitting into separate packages.
The present bluez-utils builds 17 programs of which only 3 require Glib2.
I achieved the result I need by modifying the Bluez Makefile as described below.

I still have a couple of questions about the build process.

  1. I noticed the Makefile defines PKG_HASH at the top, I assume this is for code signing or tamper detection purposes. How is it generated? (The build seemed to work fine with this commented out.)
  2. What is the difference between using $(CP) and $(INSTALL_BIN) for copying executable programs to /usr/bin ?

Here are my changes to the Makefile.

I replaced the existing Package/bluez-utils definition by this:

define Package/bluez-utils
$(call Package/bluez/Default)
  TITLE+= utilities

define Package/bluez-utils-extra
$(call Package/bluez/Default)
  TITLE+= utilities
  DEPENDS:=+bluez-libs +libpthread +librt +glib2 +libncurses +libreadline $(INTL_DEPENDS) $(ICONV_DEPENDS) +dbus

and replaced the existing Package/bluez-utils/install by this:

define Package/bluez-utils/install
        $(INSTALL_DIR) $(1)/usr/bin
        $(CP) $(PKG_INSTALL_DIR)/usr/bin/bccmd $(1)/usr/bin/
        $(CP) $(PKG_INSTALL_DIR)/usr/bin/bluemoon $(1)/usr/bin/
        $(CP) $(PKG_INSTALL_DIR)/usr/bin/btattach $(1)/usr/bin/
        $(CP) $(PKG_INSTALL_DIR)/usr/bin/btmon $(1)/usr/bin/
        $(CP) $(PKG_INSTALL_DIR)/usr/bin/ciptool $(1)/usr/bin/
        $(CP) $(PKG_INSTALL_DIR)/usr/bin/hciattach $(1)/usr/bin/
        $(CP) $(PKG_INSTALL_DIR)/usr/bin/hciconfig $(1)/usr/bin/
        $(CP) $(PKG_INSTALL_DIR)/usr/bin/hcidump $(1)/usr/bin/
        $(CP) $(PKG_INSTALL_DIR)/usr/bin/hcitool $(1)/usr/bin/
        $(CP) $(PKG_INSTALL_DIR)/usr/bin/hex2hcd $(1)/usr/bin/
        $(CP) $(PKG_INSTALL_DIR)/usr/bin/l2ping $(1)/usr/bin/
        $(CP) $(PKG_INSTALL_DIR)/usr/bin/l2test $(1)/usr/bin/
        $(CP) $(PKG_INSTALL_DIR)/usr/bin/rctest $(1)/usr/bin/
        $(CP) $(PKG_INSTALL_DIR)/usr/bin/rfcomm $(1)/usr/bin/

define Package/bluez-utils-extra/install
        $(INSTALL_DIR) $(1)/usr/bin
        $(CP) $(PKG_BUILD_DIR)/tools/btmgmt $(1)/usr/bin/
        $(CP) $(PKG_INSTALL_DIR)/usr/bin/mpris-proxy $(1)/usr/bin/
        $(CP) $(PKG_INSTALL_DIR)/usr/bin/sdptool $(1)/usr/bin/
        $(INSTALL_BIN) $(PKG_BUILD_DIR)/attrib/gatttool $(1)/usr/bin/

and added

$(eval $(call BuildPackage,bluez-utils-extra))

Further to my comments above, I found that PKG_HASH is required if building from a clean slate i.e. newly downloaded into an empty directory tree:

SHELL= flock /clients/Suntrix/Firmware/build_V4/openwrt/tmp/.bluez-5.49.tar.xz.flock -c '  	/clients/Suntrix/Firmware/build_V4/openwrt/scripts/ "/clients/Suntrix/Firmware/build_V4/openwrt/dl" "bluez-5.49.tar.xz" "x" "" "@KERNEL/linux/bluetooth/"    '
Cannot find appropriate hash command, ensure the provided hash is either a MD5 or SHA256 checksum.
Makefile:178: recipe for target '/clients/Suntrix/Firmware/build_V4/openwrt/dl/bluez-5.49.tar.xz' failed
make[3]: *** [/clients/Suntrix/Firmware/build_V4/openwrt/dl/bluez-5.49.tar.xz] Error 255

If I need to update PKG_HASH in my Makefile, how do I do so?


PKG_HASH is the SHA256 checksum of the downloaded source tarball
Also, can you do a PR against the current version which is 5.50?

$(CP) shouldn't be used for binaries and should be replaced by $(INSTALL_BIN), missed that by mistake when bumping.

I've not done a Pull Request for OpenWrt before but it looks straightforward enough.
Is there a naming convention for these, or would Bluez-extra be OK?

Sounds fine to me, thanks!

I've committed the change to my local Git repository but Github won't let me push it to OpenWrt/packages:

remote: Permission to openwrt/packages.git denied to JeremySTX.

The instructions at indicate all I have to do to create a pull request is clone the repository, commit my change locally, then push back to origin (Github). Is that not correct?

No, you don't have write access to the openwrt repo :slight_smile:

Don't forget to bump PKG_RELEASE

Don't forget to setup git before doing commits so you get proper automatic sign-off etc.
git config --global "My Real Name"
git config --global ""
git config --global core.editor "nano" - Whatever you prefer



When the inevitable happens and someone wants a change:

cd source
git checkout branch
vi files 
git add files 
git commit --amend
git push origin branch --force

your pull request commits are automatically updated.

Iā€™m definitely up for a lighter weight Bluetooth package and appreciate the work here!

That'll create another commit which isn't usually the desired outcome.

  • Do changes
  • Commit
    git commit -a -s -m "Dummy" -m "Dummy"
  • Squash ("merge") the last commit into the previous one
    git rebase -i HEAD~2
  • Change last commit to squash
  • Edit log so there's only one commit message, add additional information if needed
  • Push to GitHub
    git push --force

Don't think so, or at least it has always worked correctly for me.

Edit: correctly meaning squashed commit.

I've prepared a new commit, rebased and edited as suggested, and pushed it to my forked repository on Github. Do I need to create a new Pull Request?

Hi, it's been pushed and fails to compile.... (see GitHub)

If you go to your PR --> buildpr --> details --> build (under Workflow) --> Hover pointer over the black "cli-like" window and you'll see an arrow appearing in the top right corner --> At the bottom you'll see "Download the full output as a file." --> Download --> Open --> Near the bottom

Package bluez-daemon is missing dependencies for the following libraries: