This variable is used to ensure the proper version of --with-float=FOO
is passed to gcc's configure script. gcc also has a --with-fpu=FOO
option that means something different. To avoid confusion, change the
names to be consistent.
(From OE-Core rev: c17d883fa99b6967d83c3796d22fc0c1dbe704e6)
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(From OE-Core rev: 9ec30be63ad6d991646a7ce0ee22acdad7a81184)
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Consistent use of whitespace in multi-line assignment, with special
focus on OECONF modifications. Quotes on separate lines, four-space
indentation, one value per line.
(From OE-Core rev: d971db8b2259e4c35b871cccf130fba193849560)
Signed-off-by: Peter A. Bigot <pab@pabigot.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>
(From OE-Core rev: 5a2ff3e8f7cd7a47a5ab4e581847ecc4df87fca3)
Signed-off-by: Richard Tollerton <rich.tollerton@ni.com>
Signed-off-by: Saul Wold <sgw@linux.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.
(From OE-Core rev: ce1f3fd20d81545d6d5dfc68f86f9fddf8ac9bbf)
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.
(From OE-Core rev: 5484596f4252e707ff791feedf143a72dbb613f6)
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.
(From OE-Core rev: 19448a50c106684ee7e3862f759418c982363a29)
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.
(From OE-Core rev: 0b62f8b012d8a128f34bd85a26aa97ea939cbf64)
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>
The --enable-dependency-tracking option was added to workaround build
issues in libatomic. This fixes that build problem properly and removes
the flag since the dependency tracking code appears to be full of races
which are much deeper and harder to fix.
As per the automake manual, dependency tracking is only useful and worth
the build performance cost if you are doing more than one compile of the same
source code which in most cases we are not so this is a good thing anyway.
(From OE-Core rev: a3b665a80abed4c0659925e1cceb1568af023711)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add packaging for libgfortran and libquadmath as well as tweak the packaging
for libmudflap since it was broken.
(From OE-Core rev: 8a726d14a345ef35c6d8d8e369bf3691cee879bf)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
