Without this canadion cross builds create invalid symlinks:
When the code in do_cc_core_backend is called there is no
${CT_TARGET}-gcc in the install directory. Therefore ext is empty and
we create a link to ${CT_TARGET}-gcc. The final compiler
step then installs ${CT_TARGET}-gcc.exe and creates a working
${CT_TARGET}-cc.exe symlink but we still keep the invalid link
as well.
Signed-off-by: Johannes Pfau <johannespfau@gmail.com>
Prirotize http downloads before ftp downloads.
By having http download first, those using proxy will work with the
current download mechnism.
This tells me that that mechnism needs to be updated.
(proxy support and/or kconfig toggles)
closes#3
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
glibc versions that don't support --with-pkgversion or --with-bugurl
will cause a harmless:
====================
configure: WARNING: unrecognized options: --with-bugurl...`
====================
If it's set, use it, if it's a recognized option.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
As posted on http://www.eglibc.org/
====================
EGLIBC is no longer developed and such goals are now being addressed
directly in GLIBC.
====================
I'm not interested in maintaining build support for unsupported
software.
Older branches of crosstool-ng continue to have eglibc support.
If you find issues with older branches, I'm always open to pull
requests.
Removing eglibc also frees up glibc cleanup and build optimization.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
We had following problem: We're building a toolchain with an old glibc
version for compatibility with old Linux distributions (glibc 2.9). This
version requires make < 4 to build. However, the configure script of
glibc looks for make in the order "gnumake", "gmake" and "make". So when
"gmake" is available in the system (which is the case on Gentoo Linux
per default, unfortunately), then configure finds the system gmake 4.1
instead of the ct-ng make 3.82.
This patch adds an option to install a symlink so that 'gmake' is also
available in the old version when building toolchains.
Signed-off-by: Bernhard Walle <bernhard@bwalle.de>
Canadian Cross compile for baremetal fails with error;
checking for the value of EOF... configure: error: computing EOF failed
which is due to libstdc++ configure not being able to find stdio.h
Having all modes of the core compiler copyheaders from CT_HEADERS_DIR
(in combination with previous patch for newlib to add a do_libc_start_files
function to copy into the CT_HEADERS_DIR) resolves this.
Signed-off-by: David Holsgrove <david.holsgrove@xilinx.com>
Require access to newlibs headers in gcc.sh, matching other libc components.
Resolves issue with headers not found.
Signed-off-by: David Holsgrove <david.holsgrove@xilinx.com>
Currently, the obsolete RPC headers are only installed for eglibc,
but glibc has the same /deficiency/, so install the obsolete RPC
for both.
Signed-off-by: Jérôme BARDON <bardon.pro@gmail.com>
Signed-off-by: David Holsgrove <david.holsgrove@xilinx.com>
Yes, I missed the backslash which messed up the linaro stuff.
The more I look at this code, I feel it needs to be refactored a bit. So
I'll come back to this in the future and clean it up.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
It's not my day.
linaro_version is a filter. If it is not a linaro toolchain, it will
just be CT_{CC,GDB}_VERSION. If it is a linaro toolchain, CT_{CC,GDB}_VERSION
will be prefixed with 'linaro-' and will not match linaro_version, as
linaro_version will just have the part after 'linaro-'.
This *really* fixes the issue :sigh:
Thanks again to @elsonwei for being right the first time!
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
linaro_version and linaro_series are defined but not set if we are not
configured for linaro builds.
Therefore we need to default them to "" (null string).
As reported by @elsonwei
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
If custom {e}glibc is being used, no need to carry out the
extract or patching phase of scripts/build/libc/glibc-eglibc.sh-common
Signed-off-by: David Holsgrove <david.holsgrove@xilinx.com>
CUSTOM_LOCATION config options only presented in menuconfig if component
CUSTOM version selected.
Signed-off-by: David Holsgrove <david.holsgrove@xilinx.com>
CUSTOM_LOCATION config options only presented in menuconfig if component
CUSTOM version selected.
Signed-off-by: David Holsgrove <david.holsgrove@xilinx.com>
No longer recommended practice to use --enable-add-ons=nptl, so
for 2.20 and later (along with custom glibc), don't add the
CT_THREADS to the addons_list
https://sourceware.org/glibc/wiki/Release/2.20#Packaging_Changes
Signed-off-by: David Holsgrove <david.holsgrove@xilinx.com>
This change updates the download locations to default to the official
download site.
For gcc and gdb, also separate out the linaro download locations so that
if you are downloading the linaro variant, it skips trying to download
from the official gcc mirror.
This commit closes#3
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Without this fix, elf2flt will blow up complaining that it can't resolve
dlopen() and friends. One has to explicitly pass '-ldl' on the final
linking command line, because the system linker is not resolving
indirect dependent shared libraries.
I've needed to this patch for several years on Fedora systems.
Signed-off-by: Solomon Peachy <pizza@shaftnet.org>
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
When try to build the static toolchain, binutils failed.
I have checked the libtool script, and found that the following option
-all-static
-static
-static-libtool-libs
are processed in a strange way. If any one of those three options
appears firstly in the cmdline, all others will be neglected. Our
LDFLAGS is ".... -static -all-static -o", so the -static option
takes the real effect, and the -all-static has no useage actually!
that is the cause of the failure.
Signed-off-by: Brock Zheng <goodmenlinux@gmail.com>
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
This commit adds a configuration knob for enabling extra developer
warnings to be enabled during the musl-libc build.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
This option enables a configuration knob for adding debugging info.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
libsaniotizer requires a few headers that are not in uClibc, for
example. Also, it is only available for native threads (NPTL under
glibc.) Finally, it is only available starting with gcc-4.8.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
This patch adds initial support for musl-libc.
Musl-libc versions currently supported:
* 1.0.3 (Stable)
* 1.1.3 (Previous Mainline)
* 1.1.4 (Mainline)
Futher improvements are needed.
* gcc-4.9.x has issues (Might be fixed in musl-1.1.4).
* Multilib support is needed.
* Checks to make sure paths are correct.
* Move to 2-step gcc build. 3-step build is not necessary.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
[yann.morin.1998@free.fr: removed the gcc musl patch, to be added later;
removed dead code do_get_arch()]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
The previous patch (cset b61a1b1, cc/gcc: avoid passing --enable-multilib)
only fixed the core backend, and missed the final backend.
This patch does the same as b61a1b1, but for the final backend.
Signed-off-by: Cody P Schafer <dev@codyps.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Technically, I don't forbid powerpcle support either, but I'm not sure that
there is any library/compiler support for that at the moment (though the hw
technically makes it possible).
powerpc64le needs glibc 2.19 and gcc 4.9. I haven't looked into the support
tools, but at least gdb 7.5 is too old (7.7.1 definitely has support).
Also make powerpc64 non-experimental. It's practically old at this point.
Signed-off-by: Cody P Schafer <dev@codyps.com>
[yann.morin.1998@free.fr: use ${target_endian_le} and ${target_bits_64}]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Message-Id: <64bfbbced9dd8f62e0d6.1399801945@gun>
Patchwork-Id: 347775
In case we're using a custom (aka local) binutils source, we still
need to extract and patch elf2flt.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
The final bare-metal compiler is built using the core backend.
Currently the core uses the CC_CORE_EXTRA_CONFIG_ARRAY variable.
While this works as supposed to, this can leave the user puzzled
in the menuconfig, since all he can see is the core options, not
the final options.
Only show the core options if any of the core passes are needed,
and use the final options in the core-backend if we're issuing
the bare-metal compiler.
Signed-off-by: Cody P Schafer <dev@codyps.com>
[yann.morin.1998@free.fr: hide core options if no core pass needed;
use final option in core backend if issuing the bare-metal compiler]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Message-Id: <22181e546ba746202489.1399688067@localhost>
Patchwork-Id: 347586
Some versions of gcc have a broken --enable-multilib flag. As multilib is the
default, only pass the --disable-multilib flag
Signed-off-by: Cody P Schafer <dev@codyps.com>
[yann.morin.1998@free.fr: make it an if-block; duplicate commit log as comment]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Message-Id: <5c970c1ceb22528fe28a.1399687923@localhost>
Patchwork-Id: 347585
newlib: fix extract process for custom version
If the user specifies the use of a custom newlib version, the logic in the
extract function was reversed, so this step would fail.
Signed-off-by: Trevor Woerner <trevor.woerner@linaro.org>
[yann.morin.1998@free.fr: keep leading indentation]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Message-Id: <c727adf1b7bd2c1e891d.1393353347@openSUSE-i7>
Patchwork-Id: 324060
We now know exactly what pass to build, so build only what is required.
Reported-by: Trevor Woerner <trevor.woerner@linaro.org>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
so that it is available to available to
the core C compiler build because static
libraries are built and ranlib is used
on them.
Signed-off-by: Ray Donnelly <mingw.android@gmail.com>
Message-Id: <CAOYw7dt=+DdnKAHNShfs6a+=7sS+DLQYkyxnQMAwmw7E7zqvgA@mail.gmail.com>
Patchwork-Id: 316477
Decimal floats need support form the C library, namely support
for fenv, which is missing in uClibc for any architecture but
x86/32.
Add an option (a choice) to enable or disable decimal floats.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Support for fenv.h is a little bit more tricky that enabling it only
for x86-32 is not right.
Add an option for the user to choose whther to install fenv.h or not.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Do to glibc what we did to eglibc in #dff359adf15c.
Only (very) old versions of glibc have other external addons,
and they are no longer meaningful.
But for consistency, do the change nonetheless.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
