Switch to xz tarball, there's no point pulling two different tarballs of the same source code (tools/libtool uses xz).
Signed-off-by: Daniel Engberg <daniel.engberg.lists@pyret.net>
luci using ustream-mbedtls is extremely slow vs ustream-polarssl.
polarssl alias mbedtls v1 is configured to use NIST prime speed
optimisation, so no longer disable the default optimisation for
mbedtls v2.
Compile & run tested: Archer C7v2
Signed-off-by: Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk>
[Jo-Philipp Wich: refresh patch to use common format]
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
* Change git packages to xz
* Update mirror checksums in packages where they are used
* Change a few source tarballs to xz if available upstream
* Remove unused lines in packages we're touching, requested by jow- and blogic
* We're relying more on xz-utils so add official mirror as primary source, master site as secondary.
* Add SHA256 checksums to multiple git tarball packages
Signed-off-by: Daniel Engberg <daniel.engberg.lists@pyret.net>
For 64-bit capable systems, a symbolic link is set up for /lib64 to point to
/lib, so make sure the installation goes into /lib, irrespective of where the C
library files come from in an external toolchain.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
A bug fix which included a CRL sanity check was added to OpenSSL 1.1.0
but was omitted from OpenSSL 1.0.2i. As a result any attempt to use
CRLs in OpenSSL 1.0.2i will crash with a null pointer exception.
Patches applied upstream:
* 301-fix_no_nextprotoneg_build.patch
* 302-Fix_typo_introduced_by_a03f81f4.patch
Security advisory: https://www.openssl.org/news/secadv/20160926.txt
Signed-off-by: Magnus Kroken <mkroken@gmail.com>
The default configuration might not be suitable for
every use case. Add options to enable/disable additional
options.
Signed-off-by: Andreas Schultz <aschultz@tpip.net>
The default configuration might not be suitable for
every use case. Add options to enable/disable additional
options.
Signed-off-by: Andreas Schultz <aschultz@tpip.net>
When PKG_CONFIG_LIBDIR was unset in the environment, the configure
script was deducing the PKG_CONFIG_LIBDIR from the location of the
pkg-config binary, which doesn't make a lot of sense, and isn't done
by other autotools based packages.
Patch imported from the Buildroot project:
https://github.com/buildroot/buildroot/blob/master/package/ncurses/0001-fixup-pkg-config-handling.patch
Also refresh patches while we're at.
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
Change the error message about missing SSL support to be more explicit by
mentioning required package names.
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
The patch needed for this commit has been sent upstream:
https://github.com/openssl/openssl/pull/1155
Signed-off-by: Dirk Feytons <dirk.feytons@gmail.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name> [add back bf and srp]
NPN has been superseded by ALPN so NPN is disabled by default
The patch has been sent to OpenSSL for inclusion, see
https://github.com/openssl/openssl/pull/1100
Signed-off-by: Dirk Feytons <dirk.feytons@gmail.com>
There seems to be a situation in which a rebuild of libpcap.so is triggered
in the install step of the libpcap Makefile. libpcap.so is the wrong
target, leading to the build failure reported in [1].
Fix the dependency of install-shared-so to $(SHAREDLIB) so the build can
succeed in this case.
[1] https://dev.openwrt.org/ticket/19894
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
This reverts commit abf0768131.
The description is wrong, there is no recursive dependency here. The
conditions were added intentionally to avoid bogus build dependencies.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Two variants incorrectly include themselves in
conditional depends on ssl libraries, which results
in a recursive dependency.
Signed-off-by: Daniel Dickinson <lede@daniel.thecshore.com>
This adds this commit from normal libnl to libnl-tiny:
2dbc1ca76c
commit 2dbc1ca76c5b82c40749e609eb83877418abb006
Author: dima <dima.ky@gmail.com>
Date: Wed Oct 13 17:53:34 2010 +0300
Generic Netlink multicast groups support
I have a patch against commit d378220c96c3c8b6f27dca33e7d8ba03318f9c2d
extending libnl with a facility to receive generic netlink messages sent
to multicast groups.
Essentially it add one new function genl_ctrl_resolve_grp which
prototype looks like this
int genl_ctrl_resolve_grp(struct nl_sock *sk, const char *family_name,
const char *grp_name)
It resolves the family name and the group name to group id. Then
the returned id can be used in nl_socket_add_membership to subscribe
to multicast messages.
Besides that it adds two more functions
uint32_t nl_socket_get_peer_groups(struct nl_sock *sk)
void nl_socket_set_peer_groups(struct nl_sock *sk, uint32_t groups)
allowing to modify the socket peer groups field. So it's possible to
multicast messages from the user space using the legacy interface.
Looks like there is no way (or I was not able to find one?) to modify
the netlink socket destination group from the user space, when the
group id is greater then 32.
Signed-off-by: Hauke Mehrtens <hauke.mehrtens@intel.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name> [cosmetic style fix]
