Commit e82fadab23 (gnupg2: bump to version 2.2.0) added a configure
option to keep the old 'gpg2' executable name to avoid conflict with the
gnupg package. It turns out that gnupg depends on !BR2_PACKAGE_GNUPG2
since commit 2cadb26e6d (gnupg: make gnupg and gnupg2 mutually
exclusive). Drop this configure option.
Rename the config option that controls the removal of gpgv2, now gpgv,
to match the new name. Add legacy config symbol handling.
Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The build was broken in 5.6.2 and was disabled.
It compiles fine since 5.6.3.
The two additional patches are useful at run-time.
The first one avoid the need to specify the path to the SSL certificate
directory (using an additional environment variable).
The second one is the same used in 5.9.x (plus resolved conflicts). It uses the
process's context to get handles on EGL and GLESv2 libraries. Those libraries
are linked to Qt WebEngine at compile time.
The patch is particularly usefull for RPI boards since the raspberrypi userland
package does not provide the libEGLv2.so.2 and libGLES.so.1 symlinks. Both
library paths are hardcoded in Qt WebEngine.
Signed-off-by: Gaël PORTAY <gael.portay@savoirfairelinux.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Building the target google-breakpad requires building the host variant
of google-breakpad. Just like the target google-breakpad only supports
a limited number of architectures, it is the same for the host
google-breakpad.
We therefore introduce a
BR2_PACKAGE_HOST_GOOGLE_BREAKPAD_ARCH_SUPPORTS option that is used
where necessary to prevent the user from choosing Google Breakpad when
building on unsupported host platforms.
Fixes:
http://autobuild.buildroot.net/results/c7c04483508f9e4d629efa54571afeb1feaa5f73/
(build on a powerpc64le machine)
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This is invisible because the timings make it excessively difficult to
hit, but the Makefile is inherently flawed for parallel build, as it
contains:
$(objects): atsc_psip_section.c atsc_psip_section.h
atsc_psip_section.c atsc_psip_section.h:
perl section_generate.pl atsc_psip_section.pl
and the perl script section_generate.pl will create both the .c and .h
files in one go, but given the construct above, there can be two such
script that run in parallel, which can clobber the generated .c and/or
.h files.
So, make dvb-apps a MAKE1 package.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
perl can't find a module that is located in the current directory,
so help it locate it.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Francois Perrad <francois.perrad@gadz.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
- Add a hash for the license file.
- PostgreSQL 10.0 and above will default to checking for /dev/urandom if an
SSL library is not found, which will fail when cross compiling.
Since /dev/urandom is guaranteed to be provided on Linux systems,
add ac_cv_file__dev_urandom=yes to the configure environment if a SSL library
is not selected.
Signed-off-by: Adam Duskett <Adamduskett@outlook.com>
[Thomas: minor tweaks to the /dev/urandom comment in the .mk file.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
linphone can optionally use libupnp, so this dependency should be
accounted for in linphone.mk. In addition, linphone is not compatible
with libupnp18, but misdetects it as a a proper libupnp, causing a
build failure.
The build failure with libupnp18 currently only happens on the next
branch (because libupnp18 has only been added there), but adding the
optional dependency on libupnp makes sense for the master branch
anyway.
Fixes:
http://autobuild.buildroot.net/results/473c686f9bc5335d25b720cf1b0c45389138a7b4
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This commit adds a patch to pdbg that fixes the build on the Blackfin
architecture. The build failure was due to the recently introduced
assembly code to embed the DTB into an object file. This code was not
taking into account the fact that Blackfin has a non-empty
__USER_LABEL_PREFIX__.
The patch has been submitted upstream.
Fixes:
http://autobuild.buildroot.net/results/2bf6f56303453fd2ba7e86882168d406ded4cc80/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Instead of overriding the _svn command and injecting --non-interactive,
change the default value of BR2_SVN to include this flag so the end user
can choose not to use the flag.
This change helps users behind corporate system rules which may not
allow them to locally cache credentials and require interactive mode.
Signed-off-by: Sam Voss <sam.voss@rockwellcollins.com>
[Originally implemented by]
CC: "Yann E. MORIN" <yann.morin.1998@free.fr>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Currently, wayland support is enabled when the wayland package is
enabled, not when the FreeRDP wayland client is enabled.
But the dependency on libxkbcomon is only enforced from Config.in
when the FreeRDP wayland client is enabled., but is added to build
dependencies when the wayland package is enabled.
As such, we can end up in a situation where the FreeRDP wayland
client is disabled, the wayland package is enabled, and the
libxkbcommon package is also disabled, which casues the build to
fail with:
Makefile:539: *** libxkbcommon is in the dependency chain of
freerdp that has added it to its _DEPENDENCIES variable without
selecting it or depending on it from Config.in. Stop.
Change the build dependency to actually be on the FreeRDP client
being enabled.
Fixes;
http://autobuild.buildroot.net/results/dc3e11f7076a8355f3d2f9cb49c6325dcf7084bd
Signed-off-by: Adam Duskett <Adamduskett@outlook.com>
Tested-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Diffconfig is a simple utility for comparing two configuration files.
See usage in the script for more info.
Borrowed from the Linux kernel source code and adapted to Buildroot.
Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Changed HOSTAPD_PATCH= to HOSTAPD_PATCH+= to keep previously added
patches.
Signed-off-by: Alexander Mukhin <alexander.i.mukhin@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The Qt community releases are not stored under submodules path
component.
Signed-off-by: Gaël PORTAY <gael.portay@savoirfairelinux.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The armv8.1a generation is a cumulative extension to armv8a. It adds new
extensions, and makes some previously optional ones now mandatory.
Since gcc correctly enables the appropriate extensions based on the core
name, we don't really need to introduce a separate config for armv8.1a,
and we can piggyback on armv8a.
All those new cores are aarch64 only (gcc fails to build in arm mode).
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Some need gcc-5, some gcc-6 and some gcc-7.
The thunderx familly does not build in 32-bit mode (gcc complains
that the CPU is unknown, and even gcc master only knows them as
aarch64-only).
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The cortex-A32 is an armv8a core, but it lacks the optional AArch64
extensions, so can only work in 32-bit mode.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
For armv8, there are different profiles: A, M and R, like there is for
armv7.
So, rename our internal symbol to mirror what we do for armv7.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Now that the cores are all oredered correctly, we can just enclose all
the non 64-bit cores inside a big if-block, rather than have each of
them have the dependency.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Currently, the logic for ordering the ARM cores in the choice is all
but obvious. ;-)
Reorder the choice by architecture generation, starting with armv4,
ending with armv8.
Add a comment before each generation, just for ease of use. Add a
separate comment for armv7a and armv7m.
Finally, order cores alphabetically inside the same generation (except
for armv7m cores, listed after all armv7a cores).
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
From sysdeps/unix/sysv/linux/mips/configure.ac in glibc:
if test -z "$arch_minimum_kernel"; then
if test x$libc_cv_mips_nan2008 = xyes; then
arch_minimum_kernel=4.5.0
fi
fi
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Romain Naour <romain.naour@openwide.fr>
Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Currently, the possibility to choose the floating point mode (32, xx or
64) is conditional on having a sufficiently recent gcc version.
Which means that the architecture selection depends on the gcc version.
But that's opposite to what we've always done in Buildroot: the software
versions are conditional to the architecture options. There is nothing
we can do about the hardware: it is there, we can't change it, while we
can restrict ourselves to using software that is working on said
hardware.
Thus, we inverse the logic, to move the condition onto the software
side: whenever mfpxx is selected, we restrict the toolchain selection to
at least a gcc-5.
And now, the blind BR2_TOOLCHAIN_HAS_MFPXX_OPTION symbol is no longer
needed, so we get rid of it.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Currently the possibility to choose the NaN encoding is conditional to
having a sufficiently recent gcc version.
Which means that the architecture selection depends on the gcc version.
But that's opposite to what we've always done in Buildroot: the software
versions are conditional to the architecture options. There is nothing
we can do about the hardware: it is there, we can't change it, while we
can restrict ourselves to using software that is working on said
hardware.
Thus, we inverse the logic, to move the condition onto the software
side: whenever NaN-2008 are selected, we restrict the toolchain
selection to at least a gcc-4.9.
But now, the option with the NaN type is always set, so we must enclose
the code in gcc.mk inside a HAS_NAN_OPTION condition, as is already done
for the external toolchain case.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Take the conditions currently specified in the gcc version choice.
Also, the conditions explained in the commit log for 78c2a9f7 were not
all properly applied, especially the a57-a53 combo needs gcc-6, but
78c2a9f7 forgot to add the condition to gcc-4.9.
gcc-4.9 was excluded for cortex-a17 and a72, but the CodeSourcery
external toolchain, which uses 4.8, was not excluded for those two
cores. Now it is.
Remove the arch condition from gcc and the external toolchains.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
We use the conditions currently expressed in the gcc version choice.
We leave the musl vs mips64 conditions in gcc, because the "fault"
really is on gcc, which does not recognise the mips64+musl tuples,
so the fix lies within gcc, and the current conditions are fitting.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Hide the toolchains if the arch requires a gcc version more recent
than the one they provide.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
When an architecture expresses a requirement on the gcc version, limit
the version choice in the custom external toolchain.
The rationale being that there is no point in offering that version to
the user if we know before-hand that the gcc version will not work for
that architecture.
All versions below the minimum we support is just made conditional to
that minimum as well, including the "older" entry.
However, this means that the "older" entry is no longer available when
the architecture requires a minimum gcc version. A user who wants to use
a toolchain with a gcc older than the minimum will have no choice but to
realise the toolchain is not suitable (or lie and we would catch that
when checking the gcc version anyway).
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Begin the conversion from hard-coded dependencies on architectures, to
architecture-specified version requirement, using the newly introduced
BR2_ARCH_NEEDS_GCC_AT_LEAST_XXX symbols.
Hard-coded dependencies will be removed progressively, as archs are
individually converted over to using the new symbols.
We do not change the architecture-specific versions for ARC and
OpenRISC, because there is no point in doing so for those, as they use
special, non-upstream versions anyway.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Some CPU variants require that a recent-enough gcc be selected. For
example, ARM's cortex-a35 requires gcc-5, while cortex-a73 requires
gcc-7. Same goes for other architectures, of course.
Currently, we hard-code every such conditions in the gcc version choice,
as well as in the individual external toolchains.
However, as we add even more CPU variants, the conditions are getting
more and more complex to write and maintain.
Introduce new symbols, that architectures can select if they have a
specific requirement on the gcc version. gcc and external toolchains
can then properly depend on those symbols.
The burden of maintaining the requirements on the gcc version now falls
down to the architeture, instead of being split up in gcc and all the
external toolchains.
As the oldest gcc version to handle, we can either choose gcc-4.9, as
the oldest version we support in our internal toolchain, or choose
gcc-4.8, as the oldest external toolchain we support (except for the
custom ones, but they'll be handled specifically in upcoming changes).
We choose to go back up to gcc-4.8.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Since kernel drivers for Realtek wireless chips use non-standard
interfaces, upstream hostapd does not support them. One have to apply
an external patch for hostapd to work with these chips. See:
https://github.com/pritambaral/hostapd-rtl871xdrv
A configuration option is added to enable support for Realtek chips,
and it's turned off by default.
Signed-off-by: Alexander Mukhin <alexander.i.mukhin@gmail.com>
Tested-by: Angelo Compagnucci <angelo.compagnucci@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Instead of letting auto-detection do its job, be explicit about the
fact that we want the JFFS2 and UBIFS utilities when building the host
variant of mtd.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
