<feed xmlns='http://www.w3.org/2005/Atom'>
<title>buildroot/toolchain/toolchain-wrapper.c, branch 2017.11</title>
<subtitle>OpenPOWER buildroot sources</subtitle>
<id>https://git.raptorcs.com/git/buildroot/atom?h=2017.11</id>
<link rel='self' href='https://git.raptorcs.com/git/buildroot/atom?h=2017.11'/>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/buildroot/'/>
<updated>2017-10-22T14:10:37+00:00</updated>
<entry>
<title>toolchain/wrapper: fake __DATE_ and __TIME__ for older gcc</title>
<updated>2017-10-22T14:10:37+00:00</updated>
<author>
<name>Yann E. MORIN</name>
<email>yann.morin.1998@free.fr</email>
</author>
<published>2017-10-21T20:31:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/buildroot/commit/?id=6393b6904b6a2ee429e60cf3a107eb7eb8b7e0c3'/>
<id>urn:sha1:6393b6904b6a2ee429e60cf3a107eb7eb8b7e0c3</id>
<content type='text'>
Starting with version 7, gcc automatically recognises and enforces the
environment variable SOURCE_DATE_EPOCH, and fakes __DATE__ and __TIME__
accordingly, to produce reproducible builds (at least in regards to date
and time).

However, older gcc versions do not offer this feature.

So, we use our toolchain wrapper to force-feed __DATE__ and __TIME__ as
macros, which will take precedence over those that gcc may compute
itself. We compute them according to the specs:
    https://reproducible-builds.org/specs/source-date-epoch/
    https://gcc.gnu.org/onlinedocs/cpp/Standard-Predefined-Macros.html

Since we define macros otherwise internal to gcc, we have to tell it not
to warn about that. The -Wno-builtin-macro-redefined flag was introduced
in gcc-4.4.0. Therefore, we make BR2_REPRODUCIBLE depend on GCC &gt;= 4.4.

gcc-7 will ignore SOURCE_DATE_EPOCH when __DATE__ and __TIME__ are
user-defined. Anyway, this is of no consequence: whether __DATE__ and
__TIME__ or SOURCE_DATE_EPOCH takes precedence, it would yield the
exact same end result since we use the same logic to compute it. Note
that we didn't copy the code for it from gcc so using the same logic
doesn't imply that we're inheriting GPL-3.0.

Signed-off-by: "Yann E. MORIN" &lt;yann.morin.1998@free.fr&gt;
Cc: Jérôme Pouiller &lt;jezz@sysmic.org&gt;
Cc: Thomas Petazzoni &lt;thomas.petazzoni@free-electrons.com&gt;
Cc: Arnout Vandecappelle &lt;arnout@mind.be&gt;
Cc: Peter Korsgaard &lt;peter@korsgaard.com&gt;
[Arnout: rewrite commit message]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) &lt;arnout@mind.be&gt;
Reviewed-by: "Yann E. MORIN" &lt;yann.morin.1998@free.fr&gt;
Signed-off-by: Peter Korsgaard &lt;peter@korsgaard.com&gt;
</content>
</entry>
<entry>
<title>arch/mips: add support for MIPS32 FP mode</title>
<updated>2017-07-16T14:45:22+00:00</updated>
<author>
<name>Vicente Olivert Riera</name>
<email>Vincent.Riera@imgtec.com</email>
</author>
<published>2017-06-28T15:17:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/buildroot/commit/?id=9a0a0a976bc1094719556065ab5e982c6ca27563'/>
<id>urn:sha1:9a0a0a976bc1094719556065ab5e982c6ca27563</id>
<content type='text'>
MIPS32 support different FP modes (32,xx,64), so give the user the
opportunity to choose between them. That will cause host-gcc to be built
using the --with-fp-32=[32|xx|64] configure option. Also the
-mfp[32|xx|64] gcc option will be added to TARGET_CFLAGS and to the
toolchain wrapper.

FP mode option shouldn't be used for soft-float, so we add logic in the
toolchain wrapper if -msoft-float is among the arguments in order to not
append the -fp[[32|xx|64] option, otherwise the compilation may fail.

Information about FP modes here:

- https://sourceware.org/binutils/docs/as/MIPS-Options.html
- https://dmz-portal.imgtec.com/wiki/MIPS_O32_ABI_-_FR0_and_FR1_Interlinking#5._Generating_modeless_code

Signed-off-by: Vicente Olivert Riera &lt;Vincent.Riera@imgtec.com&gt;
Signed-off-by: Thomas Petazzoni &lt;thomas.petazzoni@free-electrons.com&gt;
</content>
</entry>
<entry>
<title>arch/mips: add support for MIPS NaN</title>
<updated>2017-07-16T14:35:39+00:00</updated>
<author>
<name>Vicente Olivert Riera</name>
<email>Vincent.Riera@imgtec.com</email>
</author>
<published>2017-06-28T15:17:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/buildroot/commit/?id=2d8f3fc430fe4f16c570097cf3dc33aa78ccb702'/>
<id>urn:sha1:2d8f3fc430fe4f16c570097cf3dc33aa78ccb702</id>
<content type='text'>
MIPS supports two different NaN encodings, legacy and 2008. Information
about MIPS NaN encodings can be found here:

  https://sourceware.org/binutils/docs/as/MIPS-NaN-Encodings.html

NaN legacy is the only option available for R2 cores and older.
NaN 2008 is the only option available for R6 cores.
R5 cores can have either NaN legacy or NaN 2008, depending on the
implementation. So, if the user selects a generic R5 target architecture
variant, we show a choice menu with both options available. For well
known R5 cores we directly select the NaN enconding they use.

Signed-off-by: Vicente Olivert Riera &lt;Vincent.Riera@imgtec.com&gt;
Signed-off-by: Thomas Petazzoni &lt;thomas.petazzoni@free-electrons.com&gt;
</content>
</entry>
<entry>
<title>toolchain-wrapper: remove remaining references to HOST_DIR/usr</title>
<updated>2017-07-10T15:46:11+00:00</updated>
<author>
<name>Arnout Vandecappelle</name>
<email>arnout@mind.be</email>
</author>
<published>2017-07-09T23:21:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/buildroot/commit/?id=2a47bd37b59403f044920f090fe2ea21bb9380f4'/>
<id>urn:sha1:2a47bd37b59403f044920f090fe2ea21bb9380f4</id>
<content type='text'>
Commit 14151d77af20ec50eeba6e30465debf87b35faaa that eliminated
$(HOST_DIR)/usr seriously missed the toolchain-wrapper - only a single
reference was updated, the other three were missed. Commit
015d68c84c9c6ad6f6d41f181d19d813f309088b removed one more. This commit
finally removes the two remaining ones.

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) &lt;arnout@mind.be&gt;
Signed-off-by: Thomas Petazzoni &lt;thomas.petazzoni@free-electrons.com&gt;
</content>
</entry>
<entry>
<title>toolchain-wrapper: fix breakage after host/usr removal</title>
<updated>2017-07-07T07:57:14+00:00</updated>
<author>
<name>Arnout Vandecappelle</name>
<email>arnout@mind.be</email>
</author>
<published>2017-07-07T07:43:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/buildroot/commit/?id=015d68c84c9c6ad6f6d41f181d19d813f309088b'/>
<id>urn:sha1:015d68c84c9c6ad6f6d41f181d19d813f309088b</id>
<content type='text'>
The toolchain wrapper, when called through PATH, strips the last three
levels of /proc/self/exe to find HOST_DIR. However, after the host/usr
removal, this should be just two levels.

The toolchain wrapper has different logic for when it is called with a
full path (i.e. $HOST_DIR/usr/bin/arm-linux-gcc) then when it is called
through the PATH (i.e. just arm-linux-gcc). The latter is never used
internally in Buildroot, that's why this wasn't discovered through
testing.

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) &lt;arnout@mind.be&gt;
Cc: Mark Jackson &lt;mpfj-list@newflow.co.uk&gt;
Signed-off-by: Thomas Petazzoni &lt;thomas.petazzoni@free-electrons.com&gt;
</content>
</entry>
<entry>
<title>Eliminate $(HOST_DIR)/usr</title>
<updated>2017-07-05T09:45:35+00:00</updated>
<author>
<name>Arnout Vandecappelle</name>
<email>arnout@mind.be</email>
</author>
<published>2017-07-04T14:03:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/buildroot/commit/?id=14151d77af20ec50eeba6e30465debf87b35faaa'/>
<id>urn:sha1:14151d77af20ec50eeba6e30465debf87b35faaa</id>
<content type='text'>
We currently use $(HOST_DIR)/usr as the prefix for host packages. That
has a few disadvantages:

- There are some things installed in $(HOST_DIR)/etc and
  $(HOST_DIR)/sbin, which is inconsistent.

- To pack a buildroot-built toolchain into a tarball for use as an
  external toolchain, you have to pack output/host/usr instead of the
  more obvious output/host.

- Because of the above, the internal toolchain wrapper breaks which
  forces us to work around it (call the actual toolchain executable
  directly). This is OK for us, but when used in another build system,
  that's a problem.

- Paths are four characters longer.

To allow us to gradually eliminate $(HOST_DIR)/usr while building
packages, replace it with a symlink to .

The symlinks from $(HOST_DIR)/usr/$(GNU_TARGET_NAME) and
$(HOST_DIR)/usr/lib that were added previously are removed again.

Note that the symlink creation will break when $(HOST_DIR)/usr
already exists as a directory, i.e. when rebuilding in an existing
output directory. This is necessary: if we don't break it now, the
following commits (which remove the usr part from various variables)
_will_ break it.

At the same time as creating this symlink, we have to update the
external toolchain wrapper and the external toolchain symlinks to go
one directory less up. Indeed, $(HOST_DIR) is one level less up than
it was before.

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) &lt;arnout@mind.be&gt;
Reviewed-by: Romain Naour &lt;romain.naour@smile.fr&gt;
Signed-off-by: Thomas Petazzoni &lt;thomas.petazzoni@free-electrons.com&gt;
</content>
</entry>
<entry>
<title>Revert "reproducible: fix DATE/TIME macros in toolchain-wrapper"</title>
<updated>2017-02-20T22:26:05+00:00</updated>
<author>
<name>Yann E. MORIN</name>
<email>yann.morin.1998@free.fr</email>
</author>
<published>2017-02-20T17:16:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/buildroot/commit/?id=1c8c0d91a431fda2c052072af87e0de35bd3b953'/>
<id>urn:sha1:1c8c0d91a431fda2c052072af87e0de35bd3b953</id>
<content type='text'>
This reverts commit 76838f63412a30a358210e457dda4b79f7730624.

The commit referenced above explicitly states that the function was
copied as-is from the gcc source code at the time. And indeed that is
exactly how the function appeared in gcc in commit
e3e8c48c4a494d9da741c1c8ea6c4c0b7c4ff934.

However, our toolchain wrapper is "GPLv2 only", while the file this function
was copied from is "GPLv3 or later".  As such we can't include that function
and still comply to both licenses.

Furthermore, the code is far from optimum.

Since this feature is not release-critical, revert it until we re-implement
it.

Signed-off-by: "Yann E. MORIN" &lt;yann.morin.1998@free.fr&gt;
Cc: Jérôme Pouiller &lt;jezz@sysmic.org&gt;
Cc: Samuel Martin &lt;s.martin49@gmail.com&gt;
Cc: Peter Korsgaard &lt;peter@korsgaard.com&gt;
Cc: Thomas Petazzoni &lt;thomas.petazzoni@free-electrons.com&gt;
Cc: Arnout Vandecappelle &lt;arnout@mind.be&gt;
Signed-off-by: Peter Korsgaard &lt;peter@korsgaard.com&gt;
</content>
</entry>
<entry>
<title>reproducible: fix DATE/TIME macros in toolchain-wrapper</title>
<updated>2017-02-07T20:45:01+00:00</updated>
<author>
<name>Jérôme Pouiller</name>
<email>jezz@sysmic.org</email>
</author>
<published>2016-12-20T13:46:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/buildroot/commit/?id=76838f63412a30a358210e457dda4b79f7730624'/>
<id>urn:sha1:76838f63412a30a358210e457dda4b79f7730624</id>
<content type='text'>
The use of the __DATE__ and __TIME__ macros are one of the most common
sources of non-reproducible binaries. In order to fix that, gcc 7 supports
the SOURCE_DATE_EPOCH variable:

https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=e3e8c48c4a494d9da741c1c8ea6c4c0b7c4ff934

This patch take advantage of toolchain-wrapper to provide support of
SOURCE_DATE_EPOCH to older gcc versions.

Function get_source_date_epoch() come directly from gcc git.

This work was sponsored by `BA Robotic Systems'.

[Peter: use sizeof for character array sizes, make function static,
	extend commit message, add upstream gcc commit]
Signed-off-by: Jérôme Pouiller &lt;jezz@sysmic.org&gt;
Reviewed-by: Samuel Martin &lt;s.martin49@gmail.com&gt;
Signed-off-by: Peter Korsgaard &lt;peter@korsgaard.com&gt;
</content>
</entry>
<entry>
<title>toolchain/wrapper: use the {str, len} tuples for the unsafe paths</title>
<updated>2016-12-11T14:45:06+00:00</updated>
<author>
<name>Yann E. MORIN</name>
<email>yann.morin.1998@free.fr</email>
</author>
<published>2016-12-04T09:21:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/buildroot/commit/?id=3eccf762016d2e75911a20bf319e7f15776ae159'/>
<id>urn:sha1:3eccf762016d2e75911a20bf319e7f15776ae159</id>
<content type='text'>
In 61cb120 (toolchain/wrapper: extend paranoid check to -isystem), we
introduced a {str,len} tuple to check the various arguments pased to
gcc, to avoid hard-coding an ever-growing, long list of those args
directly in the condition check.

Now, we're left with a long list of unsafe paths, somehow hidden within
the code, which can use the same mechanism we use for arguments.

Signed-off-by: "Yann E. MORIN" &lt;yann.morin.1998@free.fr&gt;
Cc: Thomas Petazzoni &lt;thomas.petazzoni@free-electrons.com&gt;
Signed-off-by: Thomas Petazzoni &lt;thomas.petazzoni@free-electrons.com&gt;
</content>
</entry>
<entry>
<title>toolchain/wrapper: make the {str, len} tuple more generic, add comments</title>
<updated>2016-12-11T14:44:44+00:00</updated>
<author>
<name>Yann E. MORIN</name>
<email>yann.morin.1998@free.fr</email>
</author>
<published>2016-12-04T09:21:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/buildroot/commit/?id=31c093e6d094194ca61ed476016ed1649c972382'/>
<id>urn:sha1:31c093e6d094194ca61ed476016ed1649c972382</id>
<content type='text'>
In 61cb120 (toolchain/wrapper: extend paranoid check to -isystem), we
introduced a {str,len} tuple to check the various arguments passed to
gcc, to avoid hard-coding an ever-growing, long list of those args
directly in the condition check.

It was made specific to the arguments (the structure member is named
'arg'), but can also be used to store the unsafe paths as well.

Also, that piece is almost un-documented.

Rename the structure member so that it is more generic, and add a bit of
comments to explain the whole of it.

Signed-off-by: "Yann E. MORIN" &lt;yann.morin.1998@free.fr&gt;
Cc: Thomas Petazzoni &lt;thomas.petazzoni@free-electrons.com&gt;
Signed-off-by: Thomas Petazzoni &lt;thomas.petazzoni@free-electrons.com&gt;
</content>
</entry>
</feed>
