Re: [OpenWrt-Devel] -Werror=format-nonliteral and musl
On Sat, Mar 16, 2019 at 2:51 PM W. Michael Petullo wrote:
>
> While trying to update the gst1-plugins-base package, I came across a
> compiler error:
>
> CC libgsttag_1.0_la-gstxmptag.lo
> In file included from gstxmptag.c:42:0:
> /home/mike/Source/openwrt-build-flyn.org/openwrt-herald/staging_dir/toolchain-x86_64_gcc-7.4.0_musl/include/fortify/stdio.h:
> In function 'snprintf':
> /home/mike/Source/openwrt-build-flyn.org/openwrt-herald/staging_dir/toolchain-x86_64_gcc-7.4.0_musl/include/fortify/stdio.h:101:2:
> error: format not a string literal, argument types not checked
> [-Werror=format-nonliteral]
> return __orig_snprintf(__s, __n, __f, __builtin_va_arg_pack());
> ^~
> /home/mike/Source/openwrt-build-flyn.org/openwrt-herald/staging_dir/toolchain-x86_64_gcc-7.4.0_musl/include/fortify/stdio.h:
> In function 'sprintf':
> /home/mike/Source/openwrt-build-flyn.org/openwrt-herald/staging_dir/toolchain-x86_64_gcc-7.4.0_musl/include/fortify/stdio.h:110:3:
> error: format not a string literal, argument types not checked
> [-Werror=format-nonliteral]
>__r = __orig_snprintf(__s, __b, __f, __builtin_va_arg_pack());
>^~~
> /home/mike/Source/openwrt-build-flyn.org/openwrt-herald/staging_dir/toolchain-x86_64_gcc-7.4.0_musl/include/fortify/stdio.h:114:3:
> error: format not a string literal, argument types not checked
> [-Werror=format-nonliteral]
>__r = __orig_sprintf(__s, __f, __builtin_va_arg_pack());
>^~~
> cc1: all warnings being treated as errors
> make[9]: *** [Makefile:856: libgsttag_1.0_la-gstxmptag.lo] Error 1
>
> It seems this follows from the use of -Werror=format-nonliteral. The
> definition in musl's stdio.h is as follows:
>
> _FORTIFY_FN(snprintf) int snprintf(char *__s, size_t __n, const char *__f,
> ...)
> {
> size_t __b = __builtin_object_size(__s, 0);
>
> if (__n > __b)
> __builtin_trap();
> return __orig_snprintf(__s, __n, __f, __builtin_va_arg_pack());
> }
>
> Other packages address this locally by setting TARGET_CFLAGS to include
> -Wno-format-nonliteral. See for example the commit "package/elfutils:
> add CFLAG -Wno-format-nonliteral."
>
> Is there a more global way to address this?
The issue is probably missing __attribute__((format(printf, x, x))) in
function declarations in fortify-headers. I can whip up a patch if
you'd like.
>
> --
> Mike
>
> :wq
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] -Werror=format-nonliteral and musl
While trying to update the gst1-plugins-base package, I came across a
compiler error:
CC libgsttag_1.0_la-gstxmptag.lo
In file included from gstxmptag.c:42:0:
/home/mike/Source/openwrt-build-flyn.org/openwrt-herald/staging_dir/toolchain-x86_64_gcc-7.4.0_musl/include/fortify/stdio.h:
In function 'snprintf':
/home/mike/Source/openwrt-build-flyn.org/openwrt-herald/staging_dir/toolchain-x86_64_gcc-7.4.0_musl/include/fortify/stdio.h:101:2:
error: format not a string literal, argument types not checked
[-Werror=format-nonliteral]
return __orig_snprintf(__s, __n, __f, __builtin_va_arg_pack());
^~
/home/mike/Source/openwrt-build-flyn.org/openwrt-herald/staging_dir/toolchain-x86_64_gcc-7.4.0_musl/include/fortify/stdio.h:
In function 'sprintf':
/home/mike/Source/openwrt-build-flyn.org/openwrt-herald/staging_dir/toolchain-x86_64_gcc-7.4.0_musl/include/fortify/stdio.h:110:3:
error: format not a string literal, argument types not checked
[-Werror=format-nonliteral]
__r = __orig_snprintf(__s, __b, __f, __builtin_va_arg_pack());
^~~
/home/mike/Source/openwrt-build-flyn.org/openwrt-herald/staging_dir/toolchain-x86_64_gcc-7.4.0_musl/include/fortify/stdio.h:114:3:
error: format not a string literal, argument types not checked
[-Werror=format-nonliteral]
__r = __orig_sprintf(__s, __f, __builtin_va_arg_pack());
^~~
cc1: all warnings being treated as errors
make[9]: *** [Makefile:856: libgsttag_1.0_la-gstxmptag.lo] Error 1
It seems this follows from the use of -Werror=format-nonliteral. The
definition in musl's stdio.h is as follows:
_FORTIFY_FN(snprintf) int snprintf(char *__s, size_t __n, const char *__f, ...)
{
size_t __b = __builtin_object_size(__s, 0);
if (__n > __b)
__builtin_trap();
return __orig_snprintf(__s, __n, __f, __builtin_va_arg_pack());
}
Other packages address this locally by setting TARGET_CFLAGS to include
-Wno-format-nonliteral. See for example the commit "package/elfutils:
add CFLAG -Wno-format-nonliteral."
Is there a more global way to address this?
--
Mike
:wq
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v2] iwinfo: Complete device IDs for Ubiquiti airOS XM/XW devices
This commit includes all power offsets and subsystem device IDs for Ubiquiti XM and XW devices. The device ID is wildcarded. Consistency has been tested among all Ubiquiti platforms. These values seem to be PA gains and likely do not include antenna gains. I expect the antenna gains to be defined in ART- partitions. Signed-off-by: Vincent Wiemann --- hardware.txt | 103 --- 1 file changed, 98 insertions(+), 5 deletions(-) diff --git a/hardware.txt b/hardware.txt index f36c476..727c607 100644 --- a/hardware.txt +++ b/hardware.txt @@ -17,6 +17,99 @@ 0x 0x 0x 0xc1055 0 "Ubiquiti" "NanoStation Loco5" 0x 0x 0x 0xc202 10 0 "Ubiquiti" "Bullet2" 0x 0x 0x 0xc2055 0 "Ubiquiti" "Bullet5" +0x168c 0x 0x0777 0xe0026 0 "Ubiquiti" "airOS XM" +0x168c 0x 0x0777 0xe0033 0 "Ubiquiti" "airOS XM" +0x168c 0x 0x0777 0xe0055 0 "Ubiquiti" "NanoStation M5" /* airOS XM */ +0x168c 0x 0x0777 0xe0065 0 "Ubiquiti" "airOS XM" +0x168c 0x 0x0777 0xe0096 0 "Ubiquiti" "NanoStation Loco M9" /* airOS XM */ +0x168c 0x 0x0777 0xe012 10 0 "Ubiquiti" "NanoStation M2" /* airOS XM */ +0x168c 0x 0x0777 0xe0353 0 "Ubiquiti" "NanoStation M3" /* airOS XM */ +0x168c 0x 0x0777 0xe0a22 0 "Ubiquiti" "NanoStation Loco M2" /* airOS XM */ +0x168c 0x 0x0777 0xe0a51 0 "Ubiquiti" "NanoStation Loco M5" /* airOS XM */ +0x168c 0x 0x0777 0xe1026 0 "Ubiquiti" "airOS XM" +0x168c 0x 0x0777 0xe1055 0 "Ubiquiti" "Rocket M5" /* airOS XM */ +0x168c 0x 0x0777 0xe112 10 0 "Ubiquiti" "airOS XM" +0x168c 0x 0x0777 0xe1153 0 "Ubiquiti" "airOS XM" +0x168c 0x 0x0777 0xe1a33 0 "Ubiquiti" "airOS XM" +0x168c 0x 0x0777 0xe1a55 0 "Ubiquiti" "PowerBridge M5" /* airOS XM */ +0x168c 0x 0x0777 0xe1b2 10 0 "Ubiquiti" "airOS XM" +0x168c 0x 0x0777 0xe1b33 0 "Ubiquiti" "airOS XM" +0x168c 0x 0x0777 0xe1b55 0 "Ubiquiti" "Rocket M5" /* airOS XM */ +0x168c 0x 0x0777 0xe1b65 0 "Ubiquiti" "airOS XM" +0x168c 0x 0x0777 0xe1b96 0 "Ubiquiti" "Rocket M9" /* airOS XM */ +0x168c 0x 0x0777 0xe1c2 10 0 "Ubiquiti" "airOS XM" +0x168c 0x 0x0777 0xe1c33 0 "Ubiquiti" "Rocket M3" /* airOS XM */ +0x168c 0x 0x0777 0xe1c55 0 "Ubiquiti" "Rocket M5 GPS" /* airOS XM */ +0x168c 0x 0x0777 0xe1c55 0 "Ubiquiti" "airOS XM" +0x168c 0x 0x0777 0xe1d2 10 0 "Ubiquiti" "Rocket M2 Titanium" /* airOS XM/XW */ +0x168c 0x 0x0777 0xe1d33 0 "Ubiquiti" "airOS XM" +0x168c 0x 0x0777 0xe1d55 0 "Ubiquiti" "airOS XM/XW" +0x168c 0x 0x0777 0xe1d96 0 "Ubiquiti" "airOS XM" +0x168c 0x 0x0777 0xe1e33 0 "Ubiquiti" "airOS XM" +0x168c 0x 0x0777 0xe1e55 0 "Ubiquiti" "airOS XM" +0x168c 0x 0x0777 0xe202 12 0 "Ubiquiti" "Bullet M2" /* airOS XM */ +0x168c 0x 0x0777 0xe2056 0 "Ubiquiti" "Bullet M5" /* airOS XM */ +0x168c 0x 0x0777 0xe2121 0 "Ubiquiti" "AirGrid M2" /* airOS XM */ +0x168c 0x 0x0777 0xe2151 0 "Ubiquiti" "AirGrid M5" /* airOS XM */ +0x168c 0x 0x0777 0xe2322 0 "Ubiquiti" "NanoBridge M2" /* airOS XM */ +0x168c 0x 0x0777 0xe2333 0 "Ubiquiti" "airOS XM" +0x168c 0x 0x0777 0xe2351 0 "Ubiquiti" "NanoBridge M5" /* airOS XM */ +0x168c 0x 0x0777 0xe2396 0 "Ubiquiti" "NanoBridge M9" /* airOS XM */ +0x168c 0x 0x0777 0xe2429 0 "Ubiquiti" "AirGrid M2 HP" /* airOS XM */ +0x168c 0x 0x0777 0xe2433 0 "Ubiquiti" "NanoBridge M3" /* airOS XM */ +0x168c 0x 0x0777 0xe2456 0 "Ubiquiti" "AirGrid M5 HP" /* airOS XM */ +0x168c 0x 0x0777 0xe2529 0 "Ubiquiti" "AirGrid M2 HP" /* airOS XM */ +0x168c 0x 0x0777 0xe2556 0 "Ubiquiti" "AirGrid M5 HP" /* airOS XM */ +0x168c 0x 0x0777 0xe2a33 0 "Ubiquiti" "airOS XM" +0x168c 0x 0x0777 0xe2a55 0 "Ubiquiti" "airOS XM" +0x168c 0x 0x0777 0xe2b2 10 0 "Ubiquiti" "airOS XM" +0x168c 0x 0x0777 0xe2b51 0 "Ubiquiti" "NanoBridge M5" /* airOS XM */ +0x168c 0x 0x0777 0xe2b96 0 "Ubiquiti" "airOS XM" +0x168c 0x 0x0777 0xe2c2 10 0 "Ubiquiti" "NanoBeam M2 Int" /* airOS XW */ +0x168c 0x 0x0777 0xe2c36 0 "Ubiquiti" "Bullet M2 XW" /* airOS XW */ +0x168c 0x 0x0777 0xe2c46 0 "Ubiquiti" "airOS XW" +0x168c 0x 0x0777 0xe2d2 12 0 "Ubiquiti" "Bullet M2 Titanium HP" /* airOS XM */ +0x168c 0x 0x0777 0xe2d46 0 "Ubiquiti" "airOS XW" +0x168c 0x 0x0777 0xe2d56 0 "Ubiquiti" "airOS XM" +0x168c 0x 0x0777 0xe2e54 0 "Ubiquiti" "airOS XM" +0x168c 0x 0x0777 0xe302 12 0 "Ubiquiti"
Re: [OpenWrt-Devel] Meson/Ninja build system
On 16.03.2019 19:52, W. Michael Petullo wrote: A number of upstream projects are beginning to use the Meson/Ninja build system. OpenWrt's sound/mpc and libs/libmpdclient kludge around this, and I would like to update the glib2 package. The latest version of glib2 uses Meson/Ninja. Is there any plan to build the Meson/Ninja environment into the OpenWrt build system? fyi https://github.com/openwrt/openwrt/pull/1912 Regards ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Meson/Ninja build system
A number of upstream projects are beginning to use the Meson/Ninja build system. OpenWrt's sound/mpc and libs/libmpdclient kludge around this, and I would like to update the glib2 package. The latest version of glib2 uses Meson/Ninja. Is there any plan to build the Meson/Ninja environment into the OpenWrt build system? -- Mike :wq ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] About 802.11s mesh on IPQ4019, ath10k-ct and ct-firmware
On Saturday, 16 March 2019 13:18:48 CET Xuebing Wang wrote: [...] > 1) Firmware inside QSDK (QCA closed source?) for AP-DK04.1-C1 based > routers. > 2) Firmware from kvalo/linux-firmware > > Are these "2 lines" of firmware essentially the same? They should at least be quite similar. Maybe Kalle knows more about it. But I am not sure whether he is allowed to disclose this information to the public. Kind regards, Sven signature.asc Description: This is a digitally signed message part. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] About 802.11s mesh on IPQ4019, ath10k-ct and ct-firmware
On 2019/3/10 下午4:22, Sven Eckelmann wrote: > On Sunday, 10 March 2019 05:52:00 CET Xuebing Wang wrote: > [...] >> Are there anyone building 802.11s routers based on tag 18.06.1, 18.06.2 >> or branch openwrt-18.06? > > Most(?) companies and community projects just throw the 802.11s forwarding/ > routing part away and are running their preferred Layer2/Layer3 mesh protocol > (bmxd/6/7, olsrd(2), babeld, batman-adv, ...) over it. But yes, they are still > require the meshpoint interface support in ath10k+firmware. > > A project I am more familiar (and is using 18.06.x) is freifunk-gluon [1]. > They just select the ath10k-firmware-* (from kvalo/linux-firmware) for > meshpoint setups and ath10k-firmware*-ct for IBSS setups. > > As far as I know, this will still be possible with OpenWrt 19.xx). And this > should also work the same when you want to run 802.11s+HWMP over it. Hi Sven, Thank you very much for your reply. One advantage I can think of using 802.11s+HWMP is that theoretically it can mesh with other 802.11s standard-conforming routers. From IPQ4019 firmware perspective, I see "2 lines" (for lack of a better word) of firmware: 1) Firmware inside QSDK (QCA closed source?) for AP-DK04.1-C1 based routers. 2) Firmware from kvalo/linux-firmware Are these "2 lines" of firmware essentially the same? Thanks again. Xuebing Wang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
