For certain situations, users may want to install shared FLAT
libraries to the target filesystem even if FDPIC is used as the
primary binary format, or symmetrically users may want to install FDPIC
libraries to the target filesystem even if shared FLAT is used as the
primary binary format.
This commit allows that by:
* Offering additional Kconfig options to install shared FLAT or FDPIC
libraries even when those libraries are not selected as the primary
binary format.
* Preserving all Blackfin toolchain folders under the
TOOLCHAIN_EXTERNAL_DIR, instead of keeping only the one related to
the selected binary format.
* Adding some additional install targets that do the installation of
either the shared FLAT or FDPIC libraries when requested.
[Thomas: refactored code, adjusted commit log]
Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
If ext-toolchain-wrapper was built with a gcc that uses hash-style 'gnu' by
default, the resulting binary might be unusable on other systems. The error
in this case is "Floating point exception".
Using hash-style 'both' solves this issue.
Signed-off-by: Patrick Ziegler <patrick.ziegler@fh-kl.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Instead of a long list of the ARMv7-A Cortex-A, use a conditional
based on BR2_GCC_TARGET_ARCH to hide/show toolchains that are only
usable on ARMv7-A.
However, in the comment related to Linaro toolchains, we keep
mentioning Cortex-A{5,8,9,15} because that's what users see when they
select their architecture variant.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
We add support for Linaro 2013.04 and Linaro 2013.05 and remove
support for Linaro 2013.01 and Linaro 2013.02.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Remove old 2011.09 release. Allow MIPS64 cores on
2013.05 release since they are supported by the toolchain.
Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
And mark 3.8.x series as deprecated to match upstream.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
If ext-toolchain-wrapper or any symbolic link to it was resolved by PATH,
the wrapper takes the working directory to calculate the relative paths.
Now '/proc/self/exe' is used to resolve the absolute path to the toolchain
directory if the wrapper was called neither with a relative nor an absolute
path.
[Peter: fix off-by-one, swap value == var checks around]
Signed-off-by: Patrick Ziegler <patrick.ziegler@fh-kl.de>
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
ADI officially supports the buildroot and related GNU toolchain for
Blackfin since ADI's 2012R1 release only. In order to avoid confusion,
it is better to remove the 2011R1 GNU toolchain for Blackfin. In
addition, the 2011R1 GNU toolchain for Blackfin doesn't support the
BF60x processors.
Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
When thread support is disabled, the libitm and libatomic libraries
from gcc should be disabled, otherwise, the build of gcc fails.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
For a reason that's fairly unclear to me, Peter added a '-lz' link
flag to the elf2flt.mk build in d5664ee99 ("elf2flt: fix link").
However, the zlib library may not necessarily be installed on the host
machine, so we should depend on host-zlib, and pass the appropriate
LDFLAGS. This is what this patch does.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
For some reason (probably because the ARC changes modify some lex/yacc
files without updating their pre-generated variants, or because the
date/time of the pre-generated files is not correct), building the ARC
gcc requires host-flex and host-bison.
We have tested 4.2 for AVR, 4.3 and 4.4 for ARM, and none of those
need host-flex or host-bison to be installed, so only the 4.4 for ARC
seems to be affected.
Fixes the build failure visible at
http://autobuild.buildroot.org/results/673c6262e3dde8ee8dd28204d814097e6ba8f8e9/build-end.log.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Since gcc doesn't use the package infrastructure, it doesn't get all
the good generic environment variables, and forgets to get
$(HOST_DIR)/usr/bin in its PATH. This prevents gcc from finding and
using host tools built by Buildroot.
This patch therefore ensures that $(HOST_MAKE_ENV) or
$(TARGET_MAKE_ENV) are passed at the appropriate locations. It will be
useful for a later patch that makes gcc depend on host-flex/host-bison
in some situations.
Original patch by Thomas Petazzoni.
Signed-off-by: Mischa Jonker <mjonker@synopsys.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Prefer xz compressed tarball so some bandwidth is saved for kernel headers
and kernel itself downloads.
Signed-off-by: Raúl Sánchez Siles <rasasi78@gmail.com>
Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The external toolchain logic checks (and finds) the proper ARCH_LIB_DIR
and forcibly copies it to */lib even if it's in */lib64
This is all well until the check is done for create_lib64_symlinks which
only verifies if ARCH_SYSROOT_DIR/lib64 is a symlink, which in some
toolchain it's a real directory (like sourcery x86_64 2012.09) and thus
doesn't make the symlink in the target.
Fix this by also checking for a real directory.
Easily reproducible by running "make qemu_x86_64_defconfig", switching
to an external toolchain before build, building and then trying to run
the resulting image.
Closes bug #5054
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
For the following reasons:
- it used to be broken without anyone noticing for a long time,
- it is still not fully integrated within the Buildroot set of options,
- it has not gained much traction (not even I use it),
- I've always argued that sustained development should use an external
toolchain, and not rely on building one with Buildroot,
- I did not submit any of the enhancements requested during the last
developpers' day in Brussels,
- I have neither the incentive nor the time to maintain and enhance it,
it is time to deprecate the crosstool-NG backend for the 2013.05 release.
Then, it will be entirely removed early in the 2013.08 cycle, to let some
time for those that rely on it to voice their opinions. ;-)
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Peter Korsgaard <jacmet@uclibc.org>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Commit 8d929f4b ("toolchain/gcc: Only enable --with-float when it makes
sense") restricted the --with-float use to only MIPS, ARM and SPARC,
while it seems that powerpc needs it as well.
Fixes the qemu_ppc_virtex_ml507_defconfig build.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Adds the possibility to have a free-form CPU revision string and append it
to the target CPU. Only Blackfin actually uses this option.
Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Just introduce the symbol and options in arch generic Config.in.
Append FLAT format link flags to external toolchain wrapper.
Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Also make sure that older kernels are not selected for ARC.
Signed-off-by: Mischa Jonker <mjonker@synopsys.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
According to gcc/config.gcc, only ARM, MIPS and SPARC have the
"--with-float" option when configuring gcc.
[Peter: sort list]
Signed-off-by: Mischa Jonker <mjonker@synopsys.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
For ARC, libgcc is always included, even when -nostdlib is given. This is
related to some small pieces of code that are not always generated by the
compiler; a call to libgcc is used in those cases instead.
During the initial stages of building the toolchain, this is a problem, as
libgcc does not exist yet. The ARC compiler supports -really-nostdlib to
override the default behavior.
Signed-off-by: Mischa Jonker <mjonker@synopsys.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
ARC needs a specific GCC for now, while we wait for ARC support to get
upstreamed.
Signed-off-by: Mischa Jonker <mjonker@synopsys.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
When a FOO_SITE variable ends in a slash and gets joined with a
FOO_SOURCE variable like $(FOO_SITE)/$(FOO_SOURCE), the resulting URI
has a double slash. While double-slashes are fine in unix paths, they
are reserved in URIs - the part following '//' must be an authority.
Signed-off-by: Shawn J. Goff <shawn7400@gmail.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Commit 79828fc01d (toolchain-external:
update ARM Linaro toolchains) accidently broke the URL for the Linaro
2013.01 toolchain by replacing a .bz2 extension by .bz. This patch
fixes this problem.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The x86/x86-64 CodeSourcery toolchains use some weird locations for
the gdbserver binary:
$ find . -name 'gdbserver'
./i686-pc-linux-gnu/libc/atom/usr/bin/gdbserver
./i686-pc-linux-gnu/libc/atom/usr/lib/bin/gdbserver
./i686-pc-linux-gnu/libc/core2/usr/bin/gdbserver
./i686-pc-linux-gnu/libc/core2/usr/lib64/bin/gdbserver
./i686-pc-linux-gnu/libc/usr/lib/bin/gdbserver
./i686-pc-linux-gnu/libc/usr/lib64/bin/gdbserver
Notice that it's sometimes hidden in a usr/{lib,lib64}/bin
directory. This patch changes the gdbserver logic to also try in this
location.
Originally based on work done by Daniel Nilsson, visible at
http://patchwork.ozlabs.org/patch/155767/.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
This commit converts gdb to the package infrastructure, and therefore
moves it from toolchain/gdb to package/gdb.
The target package is now visible in "Package selection for the
target" => "Debugging, profiling and benchmark". The main option,
"gdb", forcefully selects the "gdbserver" sub-option by
default. Another sub-option, "full debugger" allows to install the
complete gdb on the target. When this option is enabled, then
"gdbserver" is no longer forcefully selected. This ensures that at
least gdbserver or the full debugger gets built/installed, so that the
package is not a no-op.
The host debugger is still enabled through a configuration option in
"Toolchain". It is now visible regardless of the toolchain type (it
used to be hidden for External Toolchains). The configuration options
relative to the host debugger are now in package/gdb/Config.in.host,
similar to how we have package/binutils/Config.in.host.
Since gdb is now a proper package, it is no longer allowed to 'select
BR2_PTHREADS_DEBUG' to ensure thread debugging is available when
needed. Instead, it now 'depends on
BR2_TOOLCHAIN_HAS_THREADS_DEBUG'. This option, in turn, is selected by
the different toolchain backends when appropriate. The
'BR2_TOOLCHAIN_HAS_THREADS_DEBUG_IF_NEEDED' option is removed, since
we no longer need to know when it is allowed to 'select
BR2_PTHREADS_DEBUG'. Also, the 'BR2_PTHREADS_DEBUG' option is moved to
appear right below the thread implementation selection (in the case of
the Buildroot toolchain backend).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* Add Faraday FA526/626 as suggested on bug #1291
Note however that these cores are v4 and NOT v4t.
* Make the sa110 & sa1110 cores -> strongarm since they're the same.
* Drop all of the ARM variants lower than v4 including generic, there's
no point in supporting obsolete targets.
* Fix uClibc USE_BX logic, it was always on, this would break the new
FA526/626 support and broke StrongARM since it's a v4 core.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
git.xilinx.com is no longer available (moved to github), and github
doesn't allow downloading the tarball blobs directly, so use a local
mirror on sources.buildroot.net instead.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Add the AArch64 Linaro toolchains 2013.02 and 2013.03, remove 2012.11
and 2012.12.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Add the ARM Linaro toolchains 2013.02 and 2013.03, remove 2012.11 and
2012.12.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The 3.7.x series is EOLed upstream so match that marking it as
deprecated.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
With 4.8.x released, it makes sense to update our default gcc version
before 4.6.x becomes unmaintained.
At the same time simplify the kconfig logic a bit.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Newer versions of texinfo (>=5) break the gcc makeinfo routine, so just
disable it.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Tested-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Add a missing $(Q) in front of a MESSAGE call, which leads to the
message being displayed but also the command that shows the message.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Add a missing $(Q) in front of a MESSAGE call, which leads to the
message being displayed but also the command that shows the message.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Add a missing $(Q) in front of a MESSAGE call, which leads to the
message being displayed but also the command that shows the message.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
For each version of gcc, we need to check whether it requires mpc as a
dependency. Since this is true for 4.5, 4.6, 4.7, snapshots and now
4.8, let's factorize this code a bit by using a Kconfig symbol that
tells us whether we are using a gcc version that requires mpc.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
This commit adds support for the recently released gcc 4.8. We re-add
the same patch series as the one used for 4.7.x, after refreshing the
patches.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The gcc snapshots are now located at
ftp://gcc.gnu.org/pub/gcc/snapshots/. This has been tested with a
recent 4.8.0-RC snapshot.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Previously, the crosstool-NG backend did depend on the top-level
Buildroot's .config to detect changes in the toolchain options,
using a tentatively-clever heuristic, which also included the full
Buildroot's version string to push down to set the components' versions
strings.
In doing so, any commit in the Buildroot tree would imply a complete
rebuild of the toolchain, even in the case the toolchain options did
not change, thus being a large annoyance (to say the least).
As Buildroot never guaranteed that toolchain options would be detected,
even less handled, and that the internal backend does neither detect nor
act on toolchain options changes, and delegate that to the user, there
is no point in individualising the crosstool-NG backend's behaviour.
This reasoning also applies to the depdency on the crosstool-NG's bundled
.config file, too.
So, just drop the not-so-clever heuristic, and just build the toolchain
once, leaving to the user the responsibility to explictly ask Buildroot
to rebuild the toolchain.
Reported-by: "Przemyslaw Wrzos" <przemyslaw.wrzos@calyptech.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: "Przemyslaw Wrzos" <przemyslaw.wrzos@calyptech.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Also mark 3.6.x as deprecated to match upstream EOL.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The BR2_KERNEL_HEADERS_2_6_35 symbol no longer exists since some time,
so get rid of code that was specific to this kernel version.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The existing Microblaze toolchains that we have have the annoying
property of being based on a very old glibc version: 2.3.6. Xilinx
provides newer toolchains with glibc 2.14, generated by Crosstool-NG,
but they are only available as part of a huge Git repository that
contains the gcc, Linux, binutils, glibc sources unpacked (4.4 GB
total), which makes is very unpractical.
I contacted the Xilinx person who did those toolchains, but they
apparently didn't intend to change that anytime soon.
So, we have created a tarball for those toolchains, adding a
README.txt file in the tarball that points back to the original
location that contains the source code for them. Those tarballs are
hosted on sources.buildroot.net.
This commit then adds support for those two new external toolchains,
one for little endian Microblaze, another one for big endian
Microblaze.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
This reverts commit 1d8c3e6caf
The forward port breaks compilation at least for SPARC NPTL toolchains:
LD libuClibc-0.9.33.2.so
libc/libc_so.a(pipe.os): In function `__GI_pipe':
(.text+0x38): undefined reference to `__GI___errno_location'
collect2: ld returned 1 exit status
Easily triggered by a "make qemu_sparc_ss10_defconfig && make".
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Without this patch programs using libglib2 (libsoup, etc.. ) and pthread
may be broken.
Signed-off-by: Sagaert Johan <sagaert.johan@skynet.be>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The manual linux headers option may specify versions other than the 2.6
series, so drop the "2.6"
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The external toolchain wrapper sets sysroot etc. to an absolute path.
By changing this to a relative path, it is possible to move the host
directory to a different location and still have a working build
system.
This only works for a downloaded external toolchain. For a pre-installed
external toolchain, it is possible to move the host directory to a
different location, but not the external toolchain directory (it does work
if the external toolchain directory lies within the host directory). For
an internal or crosstool-ng toolchain, there is no wrapper so updating the
sysroot path should be done in a different way.
See http://lists.busybox.net/pipermail/buildroot/2012-February/050371.html
for information about others things to do to make the host directory
relocatable.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Acked-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
This commit fixes the exact same problem than
21a0c11a90, but for the gdbserver
build. The problem is that when you use the Crosstool-NG toolchain
backend, gawk gets built as a dependency of Crosstool-NG. So the gdb
configure scripts detects it, and assumes it is in the PATH (because
the gdb configure step gets run with TARGET_MAKE_ENV).
But then, the build fails, because it tries to run gawk, but gawk
isn't in the PATH, because we forget to use this TARGET_MAKE_ENV
variable when building gdbserver.
Fixes http://autobuild.buildroot.org/results/d0173de533b5e2fffed2eff7327a502ed2d787cd/build-end.log
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Add a uClibc patch from OpenWRT, and tweak an existing patch to cope with
the lack of a dup3 Linux syscall on avr32. This allow uClibc 0.9.33.2 to be
built for avr32.
[Peter: add upstream url for openwrt patch]
Signed-off-by: Simon Dawson <spdawson@gmail.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Remove the old 2010RC1 toolchain and add the new 2012R2-RC2 toolchain.
On related good news the new toolchain fixes:
http://autobuild.buildroot.net/results/eac5bd4f4766d98431e72a3c81492a962c85fa98/
since it's got unshare() support now.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Thus, the failing step can be easily extracted by autobuilders,
to ease with post-mortem analysis.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Reviewed-by: Markos Chandras <markos.chandras@imgtec.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Thus, the failing step can be easily extracted by autobuilders,
to ease with post-mortem analysis.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: Markos Chandras <markos.chandras@imgtec.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Thus, the failing step can be easily extracted by autobuilders,
to ease with post-mortem analysis.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: Markos Chandras <markos.chandras@imgtec.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Thus, the failing step can be easily extracted by autobuilders,
to ease with post-mortem analysis.
At the same time, remove two debug echoes (Arnout).
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Thus, the failing step can be easily extracted by autobuilders,
to ease with post-mortem analysis.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The Eclipse plugin at
https://github.com/mbats/eclipse-buildroot-toolchain-plugin allows
users of Eclipse to easily use the toolchain available in
Buildroot. To do so, this plugin reads
~/.buildroot-eclipse.toolchains, which contains the list of Buildroot
toolchains available on the system, and then offer those toolchains to
compile Eclipse projects.
In order to interface with this plugin, this commit adds an option
that allows the user to tell whether (s)he wants the Buildroot project
toolchain to be visible under this Eclipse plugin. It simply adds a
line in this ~/.buildroot-eclipse.toolchains file.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
No need to recreate a path we already have.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Some users seem to interpret:
make ctng-menuconfig
as being a value that can be fit for the ct-ng config file.
Clarify that it is a command to run, not a possible value.
Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
All supported pre-built external toolchains are built for x86 Linux,
so we add the BR2_HOSTARCH_NEEDS_IA32_LIBS select.
[Peter: microblaze toolchains are 64bit]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The pre-build external toolchains are all built for x86, so they are
only available if the build machine is a x86 or x86-64 machine.
[Peter: microblaze toolchains are 64bit]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
When using the crosstool-ng toolchain option, the libc libraries were not
installed to target. Buildroot calls the show-tuple function to determine
the directory to copy from, and it seems that outputs the result to stderr
instead of stdout
Signed-off-by: Floris Bos <bos@je-eigen-domein.nl>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Update the version of glibc to be used, since older versions are
broken with the currently-used binutils versions.
Fixes build issues ending with:
tmpfs/ccvkz3ro.s:33: Error: CFI instruction used without
previous .cfi_startproc
This new version does not have RPC support, so update the Config.in.
CC: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
We have updated our Crosstool-NG configuration to gcc 4.6.x, but the
PPL and CLoog versions were not updated accordingly. With gcc 4.6.x,
at least PPL 0.11 is needed, and only CLoog > 0.15.9 can work with PLL
0.11.
Fixes:
http://autobuild.buildroot.org/results/c22758a30c3b8abb582150cefd7099605c527e14/build-end.log
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Update the arm processor types: add the cortex A5 & A15 variants.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Update the powerpc processor types.
Remove the 801, it's the original IBM experimental implementation.
Add the 464, 464fp, 476 and 476fp cores.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
This bumps the GCC version from 4.4.6 to 4.6.3 to for
*.config-eglibc
*.config-glibc
*.config-uClibc
be equal to the default GCC setting in buildroot as well in addition to
commit b855154ee8.
Signed-off-by: Carsten Schoenert <c.schoenert@t-online.de>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Whatever the gdbserver source, as long as it's installed on the target,
assume it requires libthread_db.
Signed-off-by: Richard Braun <rbraun@sceen.net>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
When building gdb for the host, we properly pass the PATH (through
HOST_CONFIGURE_OPTS) during the configure step, but we forget to do so
for the compilation step.
The result of this is that when the Crosstool-NG backend is used, gawk
is built and installed in $(HOST_DIR), as a dependency of the
crosstool-ng package.
Then, the host gdb configure script detects this gawk binary
($(HOST_DIR) is in the PATH), and assumes gawk is
available. Unfortunately, during the compilation step, it fails to
find the expected gawk binary, because $(HOST_DIR) is no longer in the
PATH. This causes the following build failure:
http://autobuild.buildroot.org/results/067d0c2ea01673ba98ec11de2426f1ab92dac800/build-end.log
In order to fix this, we simply call the compilation step of gdb for
the host with $(HOST_MAKE_ENV), as it should have been done from the
beginning.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
On ARM, Linaro external toolchains are only visible if the user
selects Cortex-A8 or Cortex-A9. Therefore, we add a comment that tells
the user that the Linaro toolchains are only available under those
conditions.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Fix build breakage, use the version of the ptrace header file in asm
instead of sys. Also, fix GDB running on 64 bit hosts. GDB was using
unsigned long for 32-bit registers, but unsigned long is 64 bit on
64-bit hosts.
Signed-off-by: Chris Zankel <chris@zankel.net>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Except for architecture and processor names, buildroot uses capitalized
configuration names, so change the macro names for xtensa to follow that
standard.
Change the overlay file to have a subdirectory for each component
(gdb, binutils, gcc, etc.) to make it more future-prove.
Signed-off-by: Chris Zankel <chris@zankel.net>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
As discussed during the ELCE 2012 Buildroot Developers Meeting, we no
longer want to support the possibility of building a toolchain for the
target. None of the core developers have any use for this, it has been
known to be broken or cause problems for a long time without anyone
providing fixes for it.
In addition to this, Buildroot is inherently a cross-compilation tool,
so the usage of a native toolchain on the target is not really
useful. Many newcomers are tempted to use this possibility even though
it is clearly not the intended usage of Buildroot.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Xtensa is a configurable processor architecture, which allows to define
additional instructions and registers. The required variant specific
information for the toolchain is delivered in an 'overlay' file, which
needs to be 'untarred' to the corresponding directories after the
source is installed and patched.
This patch provides support for binutils, gcc, and gdb with a very
limited changes to the build scripts. These additions are only executed
for the Xtensa architecture and have no effect on other architectures.
[Thomas: rebased on top of the 'arch: improve definition of gcc mtune,
mcpu, etc.' patch, and changed 'Target ABI' to 'Target Architecture
Variant'].
Signed-off-by: Chris Zankel <chris@zankel.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The Xtensa architecture had been removed because it required special
handling and depended on additional directories and files that became
obsolete over time. This change is more aligned to other architectures.
[Thomas: rebased on top of the "arch: improve definition of gcc mtune,
mcpu, etc." patch].
Signed-off-by: Chris Zankel <chris@zankel.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
This patch has since a long time been merged upstream in uClibc, so it
cannot apply on any of the recent uClibc snapshots.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Basically, the BR2_TOOLCHAIN_EXTERNAL_GLIBC option no longer
unconditionally selects BR2_TOOLCHAIN_HAS_NATIVE_RPC since there are
glibc toolchains that don't have RPC support. All the predefined
toolchain profiles are updated to take into account this change: for
the moment, all glibc toolchains that have pre-defined toolchains have
RPC support, but further patches in the series add pre-defined glibc
toolchains that don't have RPC support. In the case of custom glibc
toolchains, a question is asked to the user so that he can say whether
the external glibc toolchain has RPC support or not. The validity of
this configuration option is checked by the new
check_glibc_rpc_feature function in helpers.mk.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The BR2_INET_RPC has for a long time been a not very descriptive
configuration option name, and with the advent of non-RPC glibc
toolchains and the apparition of libtirpc, we really need to rename it
to something more sensible, BR2_TOOLCHAIN_HAS_NATIVE_RPC.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Since we are some day going to finally rename the badly named common
toolchain options (BR2_USE_WCHAR, BR2_ENABLE_LOCALE, BR2_INET_RPC,
etc.) into something more logical, let's start using the Crosstool-NG
toolchain options in the Crosstool-NG code.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Since we are some day going to finally rename the badly named common
toolchain options (BR2_USE_WCHAR, BR2_ENABLE_LOCALE, BR2_INET_RPC,
etc.) into something more logical, let's start using the Buildroot
toolchain options in the uClibc code.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
When an external toolchain without thread debug is used, the gdb
package can be selected, but no version can be choosen, since none
match any of the requirements. This leads Buildroot to try to build
gdb for the target without a version being defined, as in the
following build log:
http://autobuild.buildroot.org/results/84e8fd2df0cc22448052a572c2e9a6e03dd137eb/build-end.log
To fix this, we adjust the dependencies of the BR2_PACKAGE_GDB option
so that the package as a whole is not selectable when the required
conditions are not met. Basically, we have the choice of:
* Having a toolchain that supports thread debugging, which is needed
for gdb >= 7.x
* Having BR2_DEPRECATED enabled, which allows gdb 6.8 to be selected,
which doesn't require thread debugging
* Using bfin, since this architectures has a special old gdb version
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Our internal toolchain backend does not yet have support for AArch64,
and Crosstool-NG also does not have support for AArch64 at the moment
(though it should be coming quickly since the Linaro AArch64 toolchain
is generated with a modified Crosstool-NG version).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
ld-linux*.so may not be present in lib/ directory, it could be
in lib32 and/or lib64 only. But check_glibc reports
"Incorrect selection of the C library" in this case, which is
not true.
Fixed by extending the search to SYSROOT/*/*.
Signed-off-by: Jean-Mickael Guerin <jean-mickael.guerin@6wind.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Since 11017f081f, the Crosstool-ng
backend generates toolchains that have a prefix inconsistent with what
Buildroot expects. Buildroot expects a "buildroot" vendor name, while
Crosstool-NG builds toolchain with the "unknown" vendor name.
This is causing build failure such as:
http://autobuild.buildroot.org/results/15b2c0e50a81b86dd13af684c9254df2bc0df8de/build-end.log
Fix this by changing the vendor part of the tuple used by Crosstool-NG
to "buildroot".
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Yann E. MORIN says:
"Although eglibc can be configured to include/exclude parts of the
features, it seems to not be in wide use, if at all."
Acked-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
As stated in commit 555c2585bf, the
Xtensa architecture has been introduced in 2009 and never changed
since its initial introduction. It requires some special handling that
is a bit annoying, and despite our call to the initial developers, and
the announcement of the deprecation of the architecture during the
2012.05, nothing has happened. Therefore, drop support for this
architecture.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: me
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
BR2_SPARC_TYPE is a hidden configuration option that is only used for
the configuration of uClibc, therefore, we move it from
target/Config.arch.in to toolchain/uClibc/Config.in.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
BR2_ARM_TYPE is a hidden configuration option that is only used for
the configuration of uClibc, therefore, we move it from
target/Config.arch.in to toolchain/uClibc/Config.in.
We also add a comment that explains that this stuff is only useful for
uClibc <= 0.9.32. Starting from 0.9.33, uClibc build process simply
uses the compiler flags to find the ARM processor that should be
used. So, someday, we'll be able to remove this.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Practically speaking, MIPS has three useful ABIs:
* o32 is for 32-bits CPUs, or 64-bit CPUs running only a 32-bit subset
of the instruction set.
* n32 is for 64-bits CPUs only. It has 32-bits pointers and long
integers.
* n64 is for 64-bits CPUs only. It has 64-bits pointers and long
integers.
See http://www.linux-mips.org/wiki/MIPS_ABI_History and
http://www.linux-mips.org/wiki/WhatsWrongWithO32N32N64 for more
details.
So, this commit reworks the Buildroot MIPS support by:
* Add separate mips64/mips64el top-level architectures.
* Renaming the n32 ABI option to BR2_MIPS_NABI32, for consistency
with BR2_MIPS_OABI32.
* Renaming the n64 ABI option to BR2_MIPS_NABI64, for consistency
with BR2_MIPS_OABI32.
* Make the n32 and n64 ABI selections select the BR2_ARCH_IS_64,
since those ABIs are valid on 64-bits CPUs only.
* Removing the o64 ABI, which is practicaly never used.
* Removing the "none" ABI, which really doesn't make sense.
* Introduce the mips64 and mips64el architecture names when a 64-bits
MIPS ABI is choosen. This will fix build issue like
http://autobuild.buildroot.org/results/9b8c5ea86c953a89e85e7b67e9221de41773f652/build-end.log
where gmp was confused by the fact of having a 32 bits architecture
(detected by the mips- architecture part of the tuple) but 64 bits
integer size when compiling.
* Adjust the uclibc.mk logic to support the new mips64/mips64el
architecture names, and take into account the renaming of the ABI
options.
This has been build tested by generating Buildroot toolchains and
compiling a few packages for MIPS o32, MIPS n32 and MIPS n64.
This work is originally based on prior work done by Gustavo Zacarias.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Introduced by 68973cca2 (adjust logic to support Linaro 2012.05)
Reported-by: R Zhong <rzhong@hotmail.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Commit ba92d6ef68 made hard float the
default when Cortex-A8 and Cortex-A9. The problem it was trying to fix
is that the newer Linaro toolchains (2012.05 and 2012.06) are
hard-float, so the default selection of soft-float enabled on ARM
doesn't work for those toolchains.
Unfortunately, not selecting soft-float causes problems with
the Crosstool-NG backend at the moment.
As an intermediate solution, make the soft float option disappear when
using external toolchain: the toolchain will decide by itself whether
to generate hard float or soft float code.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Instead of having two separate list of choices for select the target
architecture variant for i386 and x86_64, with many CPU choices
duplicated (because all modern x86 CPUs can be both used as i386 or
x86_64), merge them into a single list. In the x86_64 case, all the
x86 CPUs that do not support the 64 bits instruction set are hidden.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
All the defconfig files used by the autobuilders that use
pre-installed external toolchains are making the assumption that the
default for a custom external toolchain is "pre-installed". We keep
this default for now, since changing it breaks the autobuilders.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cortex-A8 and Cortex-A9 ARM cores are guaranteed to provide a hardware
floating point unit, so there's no reason to default to software
floating point for them.
More importantly, the newest Linaro toolchains are hard float
toolchains, so basically an user choosing those toolchains and leaving
the default option of software float would run in compilation issues.
So let's make hard float the default for Cortex-A8 and Cortex-A9.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The check_glibc function verifies that the C library of the external
toolchain is glibc. To do so, it verified that a file matching
ld-linux*.so.* or ld.so.* was found in the lib/ directory of the
toolchain's sysroot. However, with the Linaro 2012.05 toolchain, the
lib/ directory contains two links named ld-linux-armhf.so.3 and
ld-linux.so.3, which means that the first ld-linux*.so.* wildcard
expression expands to two files, which generates a syntax error for
the "test" program. We replace that with a more elaborate find+wc
combination to determine whether at least one matching file is
present.
The check_arm_abi function verifies the ABI of an ARM toolchain. For
EABI, it tested that the target name ends with eabi. However, with
Linaro 2012.05, the tuple is now arm-linux-gnueabihf (for hard float),
so we have to adjust the logic to accept this additional "hf"
specification in the tuple.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Line-up with changes from commit 3367d5ce77
"external-toolchain: run checks even on extracted toolchains"
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This patch adds the possibility to download a custom external
toolchain, in addition to the existing support of preinstalled custom
external toolchains.
With the modified configuration, the user is presented with the
following options:
- Toolchain type: Buildroot toolchain | External toolchain | Ct-ng toolchain
In case of External toolchain:
- Toolchain: the CodeSourcery toolchains | Custom toolchain
- Toolchain origin: Toolchain to be downloaded and installed | Pre-installed toolchain
In case of Toolchain to be downloaded, the user is presented with:
- Toolchain URL
In case of Pre-installed toolchain, the users sees:
- Toolchain Path
For CodeSourcery toolchains, the toolchain URL field is not used (the
URLs are directly coded in ext-tool.mk).
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Fix the indentation of the external toolchain Config file, where tabs
and spaces are mixed as indentation even within the same block.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
MIPS EABI is a bare-metal ABI so remove it.
Also fix uClibc to really work with N32 ABI, which used the EABI knob
previously.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Instead of providing two variables, make GNU_TARGET_NAME give the real
target name, and remove REAL_GNU_TARGET_NAME altogether.
Signed-off-by: Richard Braun <rbraun@sceen.net>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Block unsupported processors according to gcc version.
Also remove the comments since we now hide them according to this.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Bump default snapshot gcc version to 4.8-20120429 so that it is newer
than our latest supported version (4.7.0 release).
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Decimal floats were introduced circa gcc-4.2 or -4.3, and requires
the floating-point environement fenv.h in the C library.
The uClibc .config file used by crosstool-NG to build uClibc is the
same as used by the internal buildroot mechanism, and explcitly
disables fenv support.
The quick workaround is to simply disable decimal floats in all
crosstool-NG config files.
In the long run, it might be better to check this situation, and/or
add code and/or options in crosstool-NG to handle this (but it is
much more involved, and this workaround is sane).
Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
CC: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
SUPPORT_LIB_DIR would get resolved to the main buildroot directory for
external toolchains without C++ support, as:
- gcc -print-file-name=<nonexisting-file> returns <nonexisting-file>
- readlink -f <nonexisting-file> returns $PWD/<nonexisting-file>
So fix it by ensuring output of gcc -print-file-name actually exists
before using it.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
