openembedded-core.git/meta/recipes-devtools/gcc/libgfortran.inc, branch uninative-1.5

gcc: Clean up unnecessary variable confusion

2017-01-26T10:41:09+00:00

SDKPKGSUFFIX could only really be "nativesdk" and TARGET_SYS never contains
that so the code manipulating TARGET_SYS is pointless. I suspect this once
worked against MULTIMACH_TARGET_SYS which would be a different question but
it no longer does. Its been cut and pasted everywhere.

This patch cleans up the variable references to make things a little more
readable.

Signed-off-by: Richard Purdie

gcc: Split builddir saving into its own sstate task

2017-01-26T10:41:08+00:00

When we stashed the gcc build directory for use in generating the various runtimes
we were being lazy and just used the staging directory. With recipe specific
sysroots this means we're copying a large chunk of data around with the cross
compiler which we don't really need in most cases.

Separate out the data into its own task and inject this into the configure
step. We have to do that here since autotools will wipe out ${B} if it thinks
we're rebuilding and we therefore have to time its recreation after that.

This also takes the opportunity to remove some pointless (as far as I can tell)
conditionals from the do_install code.

Signed-off-by: Richard Purdie

meta: remove True option to getVar calls

2016-12-16T08:30:03+00:00

getVar() now defaults to expanding by default, thus remove the True
option from getVar() calls with a regex search and replace.

Search made with the following regex: getVar ?\(( ?[^,()]*), True\)

Signed-off-by: Joshua Lock 
Signed-off-by: Ross Burton

gcc: use relative path for configure script

2016-02-28T11:32:33+00:00

The absolute path (/path/to/configure) caused __FILE__ to be
an absolute path.

If 'assert' invoked, it uses __FILE__, and build path would be in elf files.
In assert.h
...
.# define assert(expr)                                                   \
  ((expr)                                                               \
   ? __ASSERT_VOID_CAST (0)                                             \
   : __assert_fail (__STRING(expr), __FILE__, __LINE__, __ASSERT_FUNCTION))
...

Which triggered buildpaths QA issue:
...
| libgcc-5.3.0: File work/core2-64-poky-linux/libgcc/5.3.0-r0/packages-split/
libgcc-dev/usr/lib64/x86_64-poky-linux/5.3.0/libgcc.a in package contained
reference to tmpdir [buildpaths]
...

Use relative path to run configure can fix the problem.

[YOCTO #7058]

Signed-off-by: Hongxu Jia 
Signed-off-by: Ross Burton

gcc: poison default sysroot path

2014-10-24T20:59:42+00:00

Various pieces of the code assume that the --sysroot option gets passed
into the compiler tools. By having a "sane" default, we don't always
spot when this occurs and this can later show up as breakage in sstate,
or in usage of the external toolchain.

We've long since talked about poisoning the default such that it will
break unless the correct option is specified. This patch does just that.

If this patch causes something to fail to build, it most likely means
the various compiler flags and commands are not correctly being passed
through to the underlying piece of software and that there is a real
problem that needs fixing, its not the fault of this patch.

Signed-off-by: Richard Purdie

gcc: recipe whitespace changes

2014-08-15T17:19:51+00:00

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.

Signed-off-by: Peter A. Bigot 
Signed-off-by: Richard Purdie

binutils/gcc/gdb: Add TARGET_ARCH to PN for all cross recipes

2014-04-30T15:33:26+00:00

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

gcc: Convert to use hardlinkdir

2014-04-25T16:10:57+00:00

Signed-off-by: Richard Purdie

gcc: Allow fortran to build successfully in 4.8

2013-12-05T12:32:11+00:00

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