| Age | Commit message (Collapse) | Author | Files |
|---|
|
Fix an issue on a multilib configuration that contains more then 1 multilib.
I.e. on MIPS64:
DEFAULTTUNE = "mips64"
MULTILIBS = "lib32n:mips64_n32 lib32:mips32"
While normally you'd use 'libn32', the above is legal.
With the startswith code, the system will look to expand the 'lib32' element
and find the 'lib32n' instead, and will result in a warning:
lib32 doesn't have a corresponding tune. Skipping...
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
|
Drop patches which are already available in 4.9.1
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
|
The gcc-ar.o, gcc-nm.o, gcc-ranlib.o and errors.o included
config.h which was a generated file. But no explicity rule
to clarify the dependency. There was potential building
failure while parallel make.
For gcc-ar.o, gcc-nm.o and gcc-ranlib.o, they were compiled from one C
source file gcc-ar.c, we add them to ALL_HOST_BACKEND_OBJS, so the
'$(ALL_HOST_OBJS) : | $(generated_files)' rule could work for these
objects.
For errors.o, it is part of gengtype, and the gengtype generator program
is special: Two versions are built. One is for the build machine, and one
is for the host. We refered what gengtype-parse.o did (which also is part
of gengtype).
[YOCTO #6568]
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
|
In subdir 'gcc', Most C source files included config.h which was
generated by a rule. But no related prerequisites was added to
the C source compiling rule. There was potential building failure
while makefile enabled parallel.
The C source compiling rule used suffix rule '.c.o', but the suffix
rule doesn't support prerequisites.
https://www.gnu.org/software/make/manual/html_node/Suffix-Rules.html
We used the pattern rule '%.o : %.c' to instead, and add the config.h
as its prerequisite
We also moved the '%.o : %.c' rule down to the 'build/%.o :' rule, which
makes '%.o : %.c' rule doesn't override 'build/%.o :'.
[YOCTO #6568]
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
MULTILIB_OPTIONS takes the parameters which trigger a given multilib to be
selected. It supports *one* option per multilib, '/' separated. Spaces
separate options used to generate additional multilib combinations.
Adding in all of CFLAGS to this is therefore clearly a really bad idea
but how do we fix things?
The best option I've come up with so far is a list of whitelist variables
to use to trigger the multilibs. Its populated with the standard multilibs
we support, anyone setting up an advanced multilib can populate the variable
with the correct trigger parameters.
This has the advantage of simplifying the code and allowing us to remove
the code filtering blocks since there is no longer option duplication. Testing
after this change shows a much improved sdk toolchain functionality.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
* GLIBC_DYNAMIC_LINKER64 reglex does not work for rs6000/linux64.h,
update it.
* it turns out that UCLIBC_DYNAMIC_LINKER reglex will strip the 32/64
chars from UCLIBC_DYNAMIC_LINKER64/UCLIBC_DYNAMIC_LINKER32, add '\b'.
my two PCs: Centos 6.5 (python 2.7.5) and Fedora 13 (python 2.7.3)
Signed-off-by: Ting Liu <ting.liu@freescale.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
It was observed that code using STLport 4.6 fails to compile under the
SDK with the following error message:
.../includes/cstddef:38:46: fatal error: ../4.7.2/cstddef: No such file
or directory
STLport 4.6 (screwily) assumes that the C++ system headers live in a
gcc-versioned subdirectory, for gcc>=3.0; cf
http://sourceforge.net/p/stlport/code/ci/STLport-4.6-patch/tree/stlport/config/stl_gcc.h#l269.
This assumption is *almost always* valid, because that matches the
default setting of --with-gxx-include-dir. We can match that behavior by
appending "/${BINV}" to our own --with-gxx-include-dir settings.
Natinst-CAR-ID: 446449
Natinst-Reviewboard-ID: 57209
Acked-by: Ken Sharp <ken.sharp@ni.com>
Acked-by: Ben Shelton <ben.shelton@ni.com>
Signed-off-by: Richard Tollerton <rich.tollerton@ni.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
|
When enabling a lib32-gcc in a 64 bit build, without doing any
other configuration, the mutilib dir is unspecified, which is
represented internally in gcc as "." and as such uncovers an
invalid free on a non-malloc'd pointer.
As suggested by the gcc folks, simply make sure the "." case
is also stored in a malloc'd pointer, so that the intended
runtime behaviour of the code remains unchanged.
Patch has been accepted by upstream maintainers of gcc.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
While we're not going to package the libgcc component as part of the SDK,
we do need to generate it to get the unwind, and quadmath headers. Without
this change it is not possible to build eglibc or other components that
require these headers with the SDK toolchain.
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The gengtype patch we apply to gcc aims to ensure that the build and host
config headers don't get confused. We're seeing build failures where
both headers have been included, likely due to a race over the configuration
files.
It seems the gengtype-lex.c file isn't being regenerated when it should
and the unconditional inclusion of bconfig.h is resulting in these issues.
The fix is therefore to remove the file, forcing its regeneration.
[YOCTO #6393]
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The do_configure_prepend was duplicated in gcc-4.X.inc and
gcc-configure-common.inc leading to confusion when reading the resulting
do_configure task where the file was processed twice.
The only difference was the removal of the include line for gcc 4.8/4.9.
On mingw were were seeing two issues, firstly that the if statements meant
the values we wanted weren't being set, the second that the include
paths were still wrong as there was no header path set.
To fix the first issue, the #ifdef conditionals were removed, we want
to set these things unconditionally. The second issue is addressed by
setting the NATIVE_SYSTEM_HEADER_DIR variable here (it was already
set in t-oe).
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
[OE-core bug #6270] - https://bugzilla.yoctoproject.org/show_bug.cgi?id=6270
Signed-off-by: Alexandru-Cezar Sardan <alexandru.sardan-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Fixes [YOCTO #4497]
Usage of FILESPATH is discouraged, since it can make recipes harder to
bbappend. Instead FILESEXTRAPATHS should be used to extend the path.
Signed-off-by: Petter Mabäcker <petter@technux.se>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
We need to handle the UCLIBC_* linker variables in the same way
as we do the GLIBC_* ones to allow uclibc multilib to work properly.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
(From OE-Core rev: f051216ea373f166016b15bbd2a2a6f136430372)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
There is a fix about to go into bitbake to ensure that datastores
being accessed with a name other than "d" are correctly reflected
in checksums. This will cause this function to add in a number of
dependencies we don't want.
These do need to be properly unravelled in due course but would
only really affect multilib builds. For now therefore just exclude
the variables as per the old behaviour.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The class itself currently does nothing. The idea is to mark all recipes that
make use of the texinfo utilities. In the future, this class could be used to
suppress the generation/formatting of documentation for performance,
explicitly track dependencies on these utilities, and eliminate Yocto's
current dependency on the host system's texinfo utilities.
Signed-off-by: Max Eliaser <max.eliaser@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Within the OE build environment, we supply the correct fpu settings. These
only need to be spelt out for the on-target gcc.
Doing this means the checksums for the core compiler don't depend on the fpu
settings. We exclude the compiler tunes for similar reasons, it doesn't need
to influence the compiler build.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Since we no longer build target libs within gcc-cross, we can drop the
TARGET_CC_ARCH flags and hence make it independent of tune.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
As far as I can tell this variable is now completely unneeded. It would
only ever get used in target builds and these are now correctly done
in the target environment namespace, not any of our cross environments.
As such, CC and other variables contain the correct compilers and other
tune options and these are correctly picked up when building libgcc,
libstdc++ and others.
I tried to figure out where else these would make any sense and couldn't
find anything. Builds appear fine without them so lets drop the complexity
including the patch adding in this flag to gcc.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
This command modifies ${S} and can race against other tasks running do_configure and
having the scripts disappear from under them. To avoid this move to its own
task and work on the shared work directory as a common task.
It needs to be a python task to avoid lots of shell exported variables as
dependencies.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Currently the gcc builds are building copies of the target libraries
that we never use (it isn't installed in do_install). This is a rather
pointless waste of cpu time.
Instead just compile the host targets. Comparing the package output of
this compared to a previous build shows that the unwind.h header is
missing since its provided by gcc. Fix this simply by copying it in.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
This allows them to co-exist together in the native sysroot, with one
set of cross tools per target architecture.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The base_contains is kept as a compatibility method and we ought to
not use it in OE-Core so we can remove it from base metadata in
future.
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
BitBake has the exact same code as oe.utils.contains so there's no
reason to duplicate it. We now rely on the bb.utils.contains code for
metadata.
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Its useful to separate out the native (cross) binaries from the target
compilation. We already do this for libgcc, this now takes the same
approach for -initial.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Rather than building the whole of libgcc to obtain the unwind.h header
file, simply configure it and then install the file. This avoids copying
chunks of data around when we don't need to and building the same thing
twice.
After doing this we need to make sure the target build directory exists
in the libgcc case since it will no longer be created automatically.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Prepare the ground for the creation of libgcc-initial by splitting common
libgcc code into a libgcc-common.inc file.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
There are two places unwind.h is installed, even by the Makefile's admission.
Disable one of them to prevent build failure races.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Signed-off-by: Alexandru-Cezar Sardan <alexandru.sardan@freescale.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
* it uses autotools but doesn't call autotools_do_install
* fixes QA warning:
gcc-4.8.2: The /usr/share/info/dir file is not meant to be shipped in a particular package.
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Duplicate parameters in the tune args are repeated in the
MULTILIB_OPTIONS variable. This leads to incorrect configurations
if the order of the parameters is bad.
(Eg. "mhard-float m32/mhard-float m64" leads to an incorrect config)
This patch finds the common parameters and removes the duplicates.
Signed-off-by: Alexandru-Cezar Sardan <alexandru.sardan@freescale.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
GCC 4.8 includes a new runtime library, libatomic, which supports
atomic operations not supported by hardware or the OS. Build it,
so other packages can link against it, if needed.
Signed-off-by: Cosmin Paraschiv <cosmin.paraschiv@freescale.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Instead of using oe.path.relative, use the Python Standard Library function
os.path.relpath.
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
|
When adding extra symlinks, we have to make sure that the directory
that the links are created in is valid. Added a check for this.
This is an incremental addition to commit
97f2a81d6796ddaf7bbaab86c2ab9039673c732c
Signed-off-by: Alexandru-Cezar Sardan <alexandru.sardan@freescale.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
|
Fix for internal compiler error hit when building lttng-tools_4.2.0:
kernel-consumer.c:324:1: internal compiler error: in gen_movsi, at
config/arm/arm.md:5539
Signed-off-by: Tom Zanussi <tom.zanussi@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
[ADT bug #5761] -- https://bugzilla.yoctoproject.org/show_bug.cgi?id=5761
Also this patch adds symlinks to libgcc such that a GCC configured
by passing the target parameter without LIBCEXTENSION and ABIEXTENSION
specifiers to find the correct startup files from a libgcc configured
with these variables.
Signed-off-by: Alexandru-Cezar Sardan <alexandru.sardan@freescale.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
|
GCC 4.8.0, 4.8.1 and 4.8.2 can generate broken epilogues for the
ABI used by the kernel. Apply the patch that is included for GCC
4.8.3 from http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854.
The issue was found on Yocto/Dora and the patch should be backported
to this branch. A kernel built with Dora's GCC 4.8.1 misbehaved on:
while true;
do
(for i in `seq 1 100`;
do
echo "Log message... $RANDOM";
done) | logger;
done
busybox's syslogd would from time to read a huge negative value and
then exit, strace would get stuck waiting on a syscall. After this
patch it appears to work better.
Signed-off-by: Holger Hans Peter Freyther <holger@moiji-mobile.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
We've had 4.8 around for a while now, I'm not aware of any issues with
it so we can drop the older 4.7 version.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Fix statement indenting and spacing issues that I happened to notice.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
A lot of our recipes had short one-line DESCRIPTION values and no
SUMMARY value set. In this case it's much better to just set SUMMARY
since DESCRIPTION is defaulted from SUMMARY anyway and then the SUMMARY
is at least useful. I also took the opportunity to fix up a lot of the
new SUMMARY values, making them concisely explain the function of the
recipe / package where possible.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
Currently the code has problems differentiating between "gcc-cross" and "gcc-cross-initial"
sstate files. We could add in a ton of special casing but tests show this isn't scaling
well. Using a more unique separator resolves the issue.
The choice of which separator to use is a hard one. We need something which isn't commonly
used in PN, PV, PR, *_OS and *_ARCH which rules out '-', '_' and it needs to work ok with
webservers/http which makes ';' and '%' harder.
The change also sets SSTATE_SWSPEC globally since writing out differently named siginfo
files for the fetch/unpack/patch tasks is a waste of diskspace, the hashes match for
all PN in the majority of cases and if they don't, its not a big issue as the hash is
different. This makes the results from sstate debugging more understandable.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
For a shared workdir, any one of the fetch/unpack/patch tasks may run yet the
PN and architecture fields in SSTATE_PKGSPEC may differ. This makes looking up
the appropriate siginfo file near impossible.
I've tried several different ways of resolving this and this is the neatest
solution I could find, its still rather ugly. I believe the usefulness of
better sstate debugging outweighs the ugliness of the code.
This patch also changes the sstate_checkhashes() code to look for siginfo
files rather than the actual sstate packages themselves. This means the
function can be used in other contexts to find info files for tasks that
may not have sstate data. It is assumed that sstate mirrors will have both
files available. This is done to allow bitbake to query whether tasks have
matching signatures in sstate directories or not.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
We had disabled the sdt from configure, let's also disable it from
confgure.ac to keep them compatible.
BTW, the libstdc++-v3 of gcc-4.7 doesn't use the sdt, so we don't need
to edit libstdc++-v3/configure as gcc-4.8.
NOTE, this commit edit the patch gcc-4.7/disablesdt.patch directly.
[YOCTO #5657]
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
We may meet such an error when building gcc/libstdc++-v3:
gcc-4.8.1/libstdc++-v3/libsupc++/unwind-cxx.h:41:21: fatal error:
sys/sdt.h: No such file or directory
We already have a patch to disable the sdt for gcc, we also need disable
it for libstdc++-v3.
BTW, we need edit both configure.ac and configure to make them keep
compatible.
NOTE, this commit edit the patch gcc-4.8/0031-Disable-sdt.patch directly.
[YOCTO #5657]
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Without this sstate builds can fail with missing dependencies.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
gcc 4.8 fortran presents some challenges:
* libquadmath headers need to be in the libexec include dir. It turns out
to be easiest just to manually do this.
* libgfortran configure needs libquadmath to be compiled. This means
a separate recipe is needed (the alternative is gross hacks)
* the libtool uses to link libgfortran doesn't have our improved rpath
handling and puts bogus RPATHS into the libraries. We can avoid this
by tweaking libtool with sed.
This patch resolves those issues. Any user of fortran does need to DEPEND
on libgfortran in order to trigger it to build but this shouldn't be a major
issue.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
