linux/poky.git/meta/recipes-devtools/gcc/gcc-source.inc, branch kirkstone

gcc-source: Ensure deploy_source_date_epoch sstate hash doesn't change

2022-11-24T15:30:01+00:00

Currently if you switch machines, gcc-source do_deploy_source_date_epoch would re-run as the stamps are tune specific. This hasn't caused much of an issue until now, however if we fix the gcc recipes to reuse the timestamp from this task, it does then create problems. Copy code from allarch to ensure this task hash doesn't change between machines/tunes. (From OE-Core rev: 1511cb3bae2d6e2dad48269108e68967ae302efc) Signed-off-by: Richard Purdie Signed-off-by: Alexandre Belloni (cherry picked from commit 7e052d03464ba5e880a6c5a0e45ff2f467ef97e8) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

gcc-source: Drop gengtype manipulation

2022-11-24T15:30:01+00:00

Whilst we patch gengtype.cc, we don't patch gengtype-lex.cc which would be the file which would trigger regeneration of files. The real bug that was likely the cause for this fix is probably SDE issues with gcc shared workdir so this code can now be dropped. (From OE-Core rev: 8a49626bb32b40a2cf97fd8b80564b494ae38698) Signed-off-by: Richard Purdie Signed-off-by: Alexandre Belloni (cherry picked from commit 7ab82b5db2a737c2a0266280b15d343a27c0e1d5) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

gcc-source: Fix gengtypes race

2022-11-24T15:30:01+00:00

gcc renamed .c files to .cc files: https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=5c69acb32329d49e58c26fa41ae74229a52b9106 but we didn't fix this reference which meant we re-introduced a race around gengtypes-lex.c. This lead to the race reappearing on the autobuilder. Fix the naming to avoid the problem again. [YOCTO #14953] (From OE-Core rev: ac7d5ea832c880002fd466360294ffb357e9c56c) Signed-off-by: Richard Purdie Signed-off-by: Alexandre Belloni (cherry picked from commit dbca40ed399405b663dbc3894e35596a2615f47d) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

gcc-source: Fix incorrect task dependencies from ${B}

2022-06-22T22:46:29+00:00

Some tasks may reference ${B} for gcc-source which in general would not exist. It has dependencies on HOST_SYS and TARGET_SYS which are not appropriate for a shared recipe like gcc-source. This causes problems for the archiver and multiconfigs in particlar. Set B to something else to avoid these task hash issues. Acked-by: Jose Quaresma (From OE-Core rev: 7211a6fb51ef0e7f5c919f98a33eaf8094b9c814) Signed-off-by: Richard Purdie Signed-off-by: Alexandre Belloni Signed-off-by: Richard Purdie (cherry picked from commit beb2a76c591e985c6fc7ed473abd1bee27f955a2) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

gcc-source: add comment explaining why a function is Python

2017-03-04T23:18:19+00:00

(From OE-Core rev: ead8a8e9695ea47ecf8c8eba9cd06cc1a12cc289) Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

gcc/gcc-source: Move libcc1 manipulation into gcc-source

2017-01-26T10:44:27+00:00

Currently there is a race where if you build -cross-canadian without building gcc (target) you see QA errors about RPATHS. I've tracked this down to this manipulation where the target gcc recipe changes libcc1 in the shared sources directory. As long as you build things in the right order, the problem doesn't occur. Since its changing ${S} move it to gcc-source and avoid the race, saving RP some head scratching about why unrelated changes failed to build cleanly. (From OE-Core rev: 626064c69b6fd1b5cead6995097f99e5fbda3f19) Signed-off-by: Richard Purdie

gcc-source.inc: cleanly disable do_rm_work

2017-01-19T22:47:20+00:00

Using "deltask" assumes that do_rm_work has been added already, which won't be the case anymore in the upcoming improved rm_work.bbclass, because then an anonymous python method will add do_rm_work. Setting RM_WORK_EXCLUDE works with the current and upcoming rm_work.bbclass and is the API that is meant to be used for excluding recipes from cleaning, so use that. (From OE-Core rev: 1f2a3cdadac1560b0e03a7be25f452ad48c27ddb) Signed-off-by: Patrick Ohly Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

nopackages: Add class for recipes which don't generate packages

2015-12-14T22:30:57+00:00

It turns out writing the same list of packaging tasks multiple times in multiple places is error prone. Move this to a new class 'nopackages", migrate existing users and add glibc-initial and libgcc-initial since we don't want packages for those recipes. This means the sstate for those recipes won't be installed, saving small amounts of build time and bandwidth. A reference to the old package_write task is also dropped. (From OE-Core rev: cece583d58f82a50c3a4eac876eb326ac3b8f5e5) Signed-off-by: Richard Purdie

gcc-source.inc: fix STAMPCLEAN to avoid race issue

2015-06-11T22:59:18+00:00

Fixed race issue when build more than one gcc-source and inherit rm_work, for example: $ bitbake gcc-source-4.9.2 gcc-source-5.1.0 File "/path/to/bitbake/lib/bb/build.py", line 512, in exec_task return _exec_task(fn, task, d, quieterr) File "/path/to/bitbake/lib/bb/build.py", line 489, in _exec_task make_stamp(task, localdata) File "/path/to/bitbake/lib/bb/build.py", line 599, in make_stamp os.unlink(name) OSError: [Errno 2] No such file or directory: '/path/to/tmp/stamps/work-shared/gcc-4.9.2-r0.do_rm_work_all.02cf1ed9b79d4edb0a51d3b913b7f9ba' This is because make_stamp() uses glob.glob() to remove the old stamps before create the new one, when gcc-source-5.1.0 removes gcc-4.9.2-r0's stamp, we may get the error. We can't use deltask do_rm_work_all as do_rm_work since it is a recrdeptask, otherwise: ERROR: Command execution failed: Traceback (most recent call last): File "/path/to/bitbake/lib/bb/command.py", line 102, in runAsyncCommand commandmethod(self.cmds_async, self, options) File "/path/to/bitbake/lib/bb/command.py", line 324, in generateDotGraph command.cooker.generateDotGraphFiles(pkgs_to_build, task) File "/path/to/bitbake/lib/bb/cooker.py", line 847, in generateDotGraphFiles depgraph = self.generateTaskDepTreeData(pkgs_to_build, task) File "/path/to/bitbake/lib/bb/cooker.py", line 672, in generateTaskDepTreeData rq.rqdata.prepare() File "/path/to/bitbake/lib/bb/runqueue.py", line 587, in prepare generate_recdeps(dep) File "/path/to/bitbake/lib/bb/runqueue.py", line 575, in generate_recdeps add_resolved_dependencies([taskData.tasks_fnid[t]], tasknames, newdeps) TypeError: list indices must be integers, not NoneType Update STAMPCLEAN to contain ${PV} to fix the problem. (From OE-Core rev: 9099d46a46ee511d1b7e496472c5b973e8e8feaf) Signed-off-by: Robert Yang Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

gcc-source.inc: set PATH for gnu-configize, not for cd

2015-05-29T09:17:15+00:00

Setting OE's PATH for the 'cd' command has no real effect. In the normal case it has no effect for the gnu-configize command either (since OE's PATH is already set in the context which runs do_preconfigure) but it may be useful when manually re-running a failed gnu-configize commandline copied from an error log, etc. (From OE-Core rev: 4321fce801daea50baaaae9ed6a141c6e7712834) Signed-off-by: Andre McCurdy Signed-off-by: Richard Purdie