Reusing OpenWrt-based toolchain as external toolchain

For Developers
1

Hi,

I'm trying to reuse the OpenWrt-based toolchain (in openwrt-19.07) by configuring it as an external toolchain to save build time. First I build the toolchain be enabling CONFIG_MAKE_TOOLCHAIN and installing the generated openwrt-toolchain-*.tar.bz2 in /opt/toolchains/. Then configuring the CONFIG_EXTERNAL_TOOLCHAIN and other required configs to point to the external toolchain (using the ext-toolchain.sh script).

However I face the below error while building several packages (ubus, dropbear, busybox etc.) that are using LTO (-flto flag) :

"ar: plugin needed to handle lto object"

The error makes sense if we look at the rules.mk:

ifeq ($(CONFIG_EXTERNAL_TOOLCHAIN),)
  TARGET_AR:=$(TARGET_CROSS)gcc-ar
  TARGET_RANLIB:=$(TARGET_CROSS)gcc-ranlib
  TARGET_NM:=$(TARGET_CROSS)gcc-nm
else
  TARGET_AR:=$(TARGET_CROSS)ar
  TARGET_RANLIB:=$(TARGET_CROSS)ranlib
  TARGET_NM:=$(TARGET_CROSS)nm
endif

In case of external toolchain, it does not use the gcc-ar that passes the required plugin for lto (if I understand correctly). If I replace {ar,ranlib,nm} with gcc-{ar,ranlib,nm}, I no longer get the "plugin needed" error but get the below error instead while compiling the libjson-c:

"ar: two different operation options specified"

Is there something else that has to be done to use the openwrt toolchain as an external toolchain?

Thanks,
Mohsin

3 Likes
2

I am facing the same now. It looks like ar cannot find the lto-plugin directory.

3

I am facing the same issue now when using external toolchain. All packages which Makefile involve -lto will issue
"plugin needed to handle lto object"
alert when AR do archives cause rules.mk will use $(TARGET_CROSS)gcc-ar for internal toolchain, but for external toolchain, $(TARGET_CROSS)ar can't find plugin.

packages such as dropbear, ubus, swconfig, hostapd, busybox which declare -lto will has this issue.

No solution found currently.

4

I met the same issue no matter chip vendor or openwrt self external toolchain. Packages like ubus droppbear busybox which involve -lto will block at this point.
if possible appending the liblto_plugin.so.0.0.0 from external toolchain to ar command.

  • Thanks,
    QG
5

This issue is really annoying.
However I was able to build an openwrt image using external, precompiled openwrt toolchain for gateworks newport platform when changing the rules.mk to use gcc- variants of ar, ranlib and nm:

ifeq ($(CONFIG_EXTERNAL_TOOLCHAIN),)
  TARGET_AR:=$(TARGET_CROSS)gcc-ar
  TARGET_RANLIB:=$(TARGET_CROSS)gcc-ranlib
  TARGET_NM:=$(TARGET_CROSS)gcc-nm
else
  TARGET_AR:=$(TARGET_CROSS)gcc-ar
  TARGET_RANLIB:=$(TARGET_CROSS)gcc-ranlib
  TARGET_NM:=$(TARGET_CROSS)gcc-nm
endif
6

Anyone got this working? I'm still trying to get the pre-build toolchain offered on downloads.openwrt.org to work - but it crashes.

7

I had a similar situation. I needed to use an external toolchain myself (crosstools-aarch64-gcc-5.5-linux-4.1-glibc-2.26-binutils-2.28.1).
Editing the rules.mk file made things worse for me, I could no longer compile static libraries (.a files). Some error about -O is not an option. I suspect the gcc-ar wrapper script in staging_dir/toolchain*/bin has mistakenly got cflags in it (cflags to gcc-ar ?).

Anyway the solution I found was to simply remove -flto from package/system/ubus/Makefile. Since I'm only building packages, that was sufficient for me, but if you are building firmware, there might be other openwrt Makefiles that add TARGET_CFLAGS += -flto
I wonder if you could make an gcc-ar wrapper under staging_dir/toolchain*/bin that filters out -flto before passing it on to gcc-ar. (in ext-toolchain, used when you write make toolchain/install)
Perhaps the best way would be if openwrt packages would check for LTO capability before adding the -flto flag.