Since the top level takes care of stripping for us, and some file formats
cannot be stripped safely (like FLAT which will error out), simply punt
the manual stripping from the gdb package.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
We've had objective C support in the tree for many years, but somehow
the BR2_GCC_CROSS_OBJC option (similar to the other BR2_GCC_CROSS_*
options) has disappeared.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Default HOST_CFLAGS to -O2, so host tools (like the cross compiler) are
built with optimization by default.
Based on a patch by Will Newton <will.newton@gmail.com>.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Closes#2707
It's not only for kernel headers, and the kernel headers .mk file
isn't included for crosstool-ng toolchain, which broke linux/u-boot/..
builds.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
And all the infrastructure surrounding it. A broken sed implementation
is quite rare nowadays, as seen by the fact that the current host-sed
support has been broken for a while, so just get rid of it.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Using two '=' for string comparison is a bashism.
Revert to using one, as stated in POSIX 1003.1-2008.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The new DL_MODE variable dispatches between the various download
implementations of each method (Git, Subversion, Wget) to deal with the
normal download (default mode, 'DOWNLOAD'), the source-check
('SOURCE_CHECK') and to show the external dependencies for external-deps
('SHOW_EXTERNAL_DEPS').
For the latter, the legacy script wget-show-external-deps.sh is no
longer required as $(WGET) isn't called directly anymore but always
through the DOWNLOAD helper.
Signed-off-by: Maxime Petazzoni <maxime.petazzoni@bulix.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The patch introduced by commit
1ed2e4fffd must also be added to gcc
4.2.2 to let the AVR32 toolchain build properly.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The problem fixed by 60f945e47a is in
fact not limited to the AVR32 architecture, as reported by Will Newton
on the list. The issue is the combination uClibc 0.9.31 with gcc 4.2,
C++ support and locales.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Check in toolchain/dependencies/dependencies.sh if an UTF-8 locale is
properly present on the system before trying to build a locale enabled
toolchain. As this test is only needed when a locale enabled toolchain
is going to be built, we pass the configuration file path to the
dependencies.sh script so that it can grep for the current value of
various options.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
When no UTF-8 locale is available on the host system, uClibc can't
generate some stuff it needs to compile a C library with locale
support. Unfortunately, as gen_wc8bit message is shown on stdout and
the stdout of gen_wc8bit is redirected to a file, the user don't see
anything, as reported at
http://lists.busybox.net/pipermail/buildroot/2010-May/034177.html.
Those two patches fix the problem for uClibc 0.9.31 and 0.9.30.3. It
has been submitted upstream:
http://lists.uclibc.org/pipermail/uclibc/2010-August/044256.html
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The <tuple>/lib* symlinking added by 3c77bab2ee needs to
be moved up to the gcc-intermediate step now the NPTL stuff is merged,
otherwise 64bit builds fails (lib64 already created).
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Since 5575d205c (toolchain: remove multilib) we were no longer passing
--disable-multilib, which broke builds for multilib-capable archs (like
x86-64, ppc, ..).
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
It fails to build with:
ctype_members.cc: In constructor 'std::ctype_byname<_CharT>::ctype_byname(const char*, size_t) [with _CharT = char]':
ctype_members.cc:59: error: invalid use of incomplete type 'struct __uclibc_locale_struct'
/home/test/avr32-br/usr/avr32-unknown-linux-uclibc/sys-include/bits/uClibc_locale.h:85: error: forward declaration of 'struct __uclibc_locale_struct'
ctype_members.cc:60: error: invalid use of incomplete type 'struct __uclibc_locale_struct'
/home/test/avr32-br/usr/avr32-unknown-linux-uclibc/sys-include/bits/uClibc_locale.h:85: error: forward declaration of 'struct __uclibc_locale_struct'
ctype_members.cc:61: error: invalid use of incomplete type 'struct __uclibc_locale_struct'
/home/test/avr32-br/usr/avr32-unknown-linux-uclibc/sys-include/bits/uClibc_locale.h:85: error: forward declaration of 'struct __uclibc_locale_struct'
make[5]: *** [ctype_members.lo] Error 1
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This patch modifies current toolchain build sequence so that
NPTL enabled toolchain can be built. The new sequence works
well with linuxthreads as well.
It introduces a new pass for gcc cross compilation. The new
sequence is binutils->gcc-initial->linux-headers -> uclibc-configured
(some cheats to generate phony shared libc.so and libm.o)
-> gcc-intermediate(with shared lib support) -> uclibc -> gcc-final
I also added a new sample config arm_nptl_toolchain_defconfig which
builds the toolchain and busybox.
I have only tried it on arm. However it should work for other
architectures which support NPTL on uclibc e.g. mips, sh, x86, ppc, x86_64
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The cross-gdb is supposed to be part of the external toolchain, so
Buildroot does not need to build it. Moreover, GDB_HOST build
currently fail with:
ln -snf ../../bin/arm-unknown-linux-gnueabi-gdb \
/home/test/outputs/test-48/staging/usr/arm-unknown-linux-gnueabi/bin/gdb
ln: creating symbolic link `/home/test/outputs/test-48/staging/usr/arm-unknown-linux-gnueabi/bin/gdb': No such file or directory
And even worse: they overwrite the cross-gdb of the external
toolchain!
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Now that two packages (tremor and libsvgtiny) are being downloaded
from svn, svn becomes a mandatory tool to run Buildroot.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Supporting multilib is much more than just passing --enable-multilib
to gcc. You have to actually build the C library several times (once
for each multilib variant you want to support in your toolchain), and
to pass MULTILIB_OPTIONS/MULTILIB_EXCEPTIONS values to gcc to let it
know the set of multilib variants you're interested in.
Since we'll probably never support multilib toolchains in Buildroot,
just get rid of this BR2_ENABLE_MULTILIB option.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This is a very advanced option, and it seems, according to
http://choices.cs.uiuc.edu/exceptions.pdf that SJLJ exceptions aren't
really interesting.
Users really interested by this can always use the
BR2_EXTRA_GCC_CONFIG_OPTIONS is they want.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Handle the internal toolchain backend mechanism the
same way we handle other backends.
Signed-off-by: Yann E. MORIN <yann.morin.1998@anciens.enib.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Including a bunch of Makefiles with wildcard makes it impossible to add
new toolchain backends. Avoid that by namely including needed files.
The external toolchain still needs to include all the toolchain/*/*.mk
sub-makefiles, as they are needed to build a toolchain that runs on the
target. It is to be noted that the cross-toolchain is not built in this
case, as the make-targets to build the cross-toolchain are not present
in the $(BASE_TARGETS) variable, which is later used to create the
dependency rules.
Also, the comment 'Explicit ordering' has been removed, as it is mis-
leading. It is make's responsibility to create the proper ordering based
on the dependency rules it finds in the Makefiles
Signed-off-by: Yann E. MORIN <yann.morin.1998@anciens.enib.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Rename the external toolchain directory.
When new backends are here, it will be easier to sort them out
if they are all prefixed the same way.
Signed-off-by: Yann E. MORIN <yann.morin.1998@anciens.enib.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The helper functions used for external toolchains may also be useful
to alternate toolchain backends (currently, the external toolchain is
the sole user).
Signed-off-by: Yann E. MORIN <yann.morin.1998@anciens.enib.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
This option is already part of the gcc configure options through the
BR2_CONFIGURE_BUILD_TOOLS variable (in toolchain/Makefile.in).
Additionnally, the value that was passed in the AVR32 specific case
was incorrect: it was $(STAGING_DIR)/$(REAL_GNU_TARGET_NAME)/bin
instead of $(STAGING_DIR)/usr/$(REAL_GNU_TARGET_NAME)/bin.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The variable BR2_SYSROOT_STAGING_DESTDIR is no longer used, since now
the prefix for gcc is already set to the correct location.
The variable BR2_SYSROOT_TARGET_DESTDIR was already unused.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The cross binutils and cross gcc are actually going to be executed
from $(STAGING_DIR)/usr, so the correct prefix is $(STAGING_DIR)/usr
and not /usr.
This also fixes what is known as the "AVR32 toolchain build failure",
which was due to the fact that the prefix directory wasn't writable
(since it was /usr).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This commit solves bug #1051. The problem in this bug in that WebKit
compiles a sample C program, which uses WebKit. As WebKit is written
in C++, even though the program it built with CROSS-gcc, it must be
linked with libstdc++. However, CROSS-gcc can't find the libstdc++ has
it's hidden inside <sysroot>/<tuple>/lib.
Therefore, this commit creates a symbolic link <sysroot>/<tuple>/lib
-> <sysroot>/lib before running the CROSS-gcc installation. While this
may look like a hack, this is the solution used by both Crosstool-NG
and OpenWRT.
Moreover, with this symbolic link in place, I think bug #1741 may also
be solved. The problem in this bug is that the linker tries to link
against /lib/libc.so.0. This is due to the fact that the linker finds
a libc.so script file in the original toolchain location and not
inside the copy of the toolchain sysroot in $(STAGING_DIR). As the
script file is found outside of the current toolchain sysroot, ld
considers the script has non-sysrooted, and therefore doesn't prefix
all paths found in the script file (such as /lib/libc.so.0) with the
sysroot path, leading to the failure.
So, in details, this commit :
* Adds a BR2_ARCH_IS_64 invisible config knob that is used to know if
the arch is a 64 bits architecture or not.
* Creates the <sysroot>/<tuple>/lib -> <sysroot>/lib symbolic link,
and the <sysroot>/<tuple>/lib64 -> <sysroot>/lib64 symbolic link if
needed.
* Fixes the external toolchain sysroot detection code so that the
'sed' replacement is done *after* the readlink -f evaluation.
I have tested this by building ARM, x86 and x86_64 toolchains with
Buildroot, and then use these toolchains as external toolchains to
build a full X.org/Gtk/WebKit/Midori stack. I have also done a
complete ARM Buildroot internal toolchain build with the same full
X.org/Gtk/WebKit/Midori stack.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Just as we did to fix target-gcc, pass CXX_FOR_TARGET when building
target g++, and remove useless copies of g++ and c++.
Tested on ARM by compiling a simple C++ program using <iostream> on
the target and running it.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
When doing the "make install" of target, three identical copies of gcc
are installed in $(TARGET_DIR)/usr/bin:
039adcc582c365f12ba6fc5f96098128 arm-unknown-linux-uclibcgnueabi-gcc
039adcc582c365f12ba6fc5f96098128 arm-unknown-linux-uclibcgnueabi-gcc-4.3.5
039adcc582c365f12ba6fc5f96098128 gcc
This patch removes the first two copies and keeps only the common "gcc" one.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Now that $(STAGING_DIR)/usr/bin is no longer in the PATH, we need to
pass the absolute paths to $(TARGET_CC) when building the target gcc
compiler.
This commit fixes the target gcc build problem reported on the list. I
have successfully been able to build a target gcc for ARM, use it to
compile a hello world application on the target and run this
application.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This variable is used only once, so let's just hardcode its value at
its call site.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
We haven't had any updates to the java packages in a long time,
gcj in 4.3.x doesn't build, and 4.4.x is missing ecj1, so it cannot
have many users.
Mark it as broken and remove during the 2010.11 cycle, unless someone
steps up to maintain it.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Commit 7192668 introduced a wrong spelling of BR2_TOOLCHAIN_EXTERNAL_GLIBC
that prevented libnss_files.so and libnss_dns.so from being installed.
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Now that TARGET_CC contains several space-separated words, it must be
used quoted everywhere.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Following the changes to TARGET_CC/TARGET_CXX to include the --sysroot
option, these variables not only contain the path to the compiler, but
also the --sysroot option. For that reason, we cannot anymore just use
"test -x" to test for the compiler presence. Instead, we see if
$(TARGET_CC) -v and $(TARGET_CXX) -v return a zero status.
Moreover, --sysroot now needs to be filtered out of $(TARGET_CC) and
not $(TARGET_CFLAGS) when asking the toolchain for its original
sysroot and arch sysroot.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The external toolchain and internal toolchain cases both need to use
the --sysroot option, and they have almost identical
LDFLAGS/CFLAGS/CXXFLAGS definition, so we can factorize these
definitions.
Moreover, the --isysroot option is implied by --sysroot so there's no
need to specify both.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Closes#2143
Fixes crash on static linking without stdio / x86. Both patches are from
upstream uClibc.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Until now, the function copy_toolchain_lib_root was copying a given
library to the target filesystem by assuming that it should be at the
same place it was in the toolchain sysroot.
However, with Buildroot hiding libstdc++ in
/usr/<target-name>/lib(64), this isn't correct, and it is probably
safer not to rely on the toolchain organization anyway.
Therefore :
* Instead of having a single EXTERNAL_LIBS variable, we now have
LIB_EXTERNAL_LIBS and USR_LIB_EXTERNAL_LIBS, which respectively
list the libraries that should be copied to /lib and /usr/lib. As
of today, only libstdc++ is part of the second list.
* The copy_toolchain_lib_root takes another argument, which is the
destination directory of the library, relative to $(TARGET_DIR)
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Most toolchains have their libraries either in /lib or /usr/lib
relative to their ARCH_SYSROOT_DIR. Buildroot toolchains, however,
have basic libraries in /lib, and libstdc++/libgcc_s in
/usr/<target-name>/lib(64).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
With uClibc 64 bits toolchain, the dynamic loader is named
ld64-uClibc.so.0 and not ld-uClibc.so.0. So, this commit adjust the
uClibc detection code for external toolchains.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Yann E. MORIN <yann.morin.1998@anciens.enib.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Create lib64 -> lib and usr/lib64 -> usr/lib symbolic links in the
target and staging directories. This is needed for some 64 bits
toolchains such as the Crosstool-NG toolchains, for which the path to
the dynamic loader and other libraries is /lib64, but the libraries
are stored in /lib.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Yann E. MORIN <yann.morin.1998@anciens.enib.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
On 64 bits glibc toolchains, the dynamic loader is named
ld-linux-x86-64.so and not simply ld-linux.so. So, adjust the
detection of the C library accordingly.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Yann E. MORIN <yann.morin.1998@anciens.enib.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Instead of copying all directories in "etc lib sbin usr", check that
each of them exists before doing the copy. This is only to avoid an
harmless error message.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Yann E. MORIN <yann.morin.1998@anciens.enib.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
For the detection of the ARCH_SYSROOT_DIR (which contains the C
library variant specific to the compiler flags), we used to pass only
the -march argument instead of the full TARGET_CFLAGS. This was done
because TARGET_CFLAGS contains --sysroot, and we don't want to tell
here the compiler which sysroot to use, because we're specifically
asking the compiler where the *normal* arch sysroot directory is.
Unfortunately, there are some multilib variants that aren't decided
only based on -march, but also on -msoft-float or other compiler
flags. Therefore, we take the opposite approach: pass the full
TARGET_CFLAGS, from which we have stripped the --sysroot option.
For example, this allows a PowerPC CodeSourcery toolchain, on which
we're using the soft-float multilib variant, to work properly as an
external toolchain.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Yann E. MORIN <yann.morin.1998@anciens.enib.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
External toolchains using Glibc have different names for the dynamic
loader. Some of them name it ld-linux.so.*, while some others (such as
the PowerPC and MIPS CodeSourcery toolchains) name it simply ld.so.*.
Therefore, we fix the glibc detection code to handle this case.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Yann E. MORIN <yann.morin.1998@anciens.enib.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Change the default target optimisation value so
it does not conflict with gcc optimization level
Signed-off-by: Paul Jones <paul@pauljones.id.au>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
gdbserver dlopen(3)s libthread_db.so at runtime, so there is no
dependency on it (does not appear as being (NEEDED)).
Copy libthread_db.so from external toolchain when gdbserver is enbled.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
If threads are disabled, do not try to copy the libpthread.so from the
external library.
It is still expected that the BR configuration matches the external
toolchain setup, and no check is done to enforce that.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Having a BR2_NEEDS_GETTEXT option, as introduced by
54d64798e1 isn't sufficient to express
the different kind of dependencies on gettext.
This commit, based on an idea by Peter Korsgaard, introduces two
different options :
* BR2_NEEDS_GETTEXT, which is true as soon as the toolchain doesn't
provide gettext itself (i.e, when the toolchain is uClibc based, be
it an internal or external toolchain)
* BR2_NEEDS_GETTEXT_IF_LOCALE, which is true when the toolchain
doesn't provide gettext *and* locale support has been enabled in
Buildroot.
A following commit adds some documentation that details how these
configuration variables should be used by packages.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Having . in the PATH makes the toolchain build process fail because it
confuses host tools and target tools.
This fixes bug #75.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Things like LD_LIBRARY_PATH=. or even LD_LIBRARY_PATH=.:/usr/lib were
not detected as incorrect.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Verify that the value of BR2_INSTALL_LIBSTDCPP set by the user in the
Buildroot configuration really matches the external toolchain
capabilities by checking that a C++ cross-compiler is available.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
When using an external toolchain that uses the glibc or eglibc C
libraries, compiling a separate gettext and libintl is not needed and
is even a source of confusion, causing build failures. These build
failures are due to the fact that when libintl is compiled, it
replaces the C library libintl.h by its own, which does #define
gettext libintl_gettext. Then, when packages want to use gettext,
autoconf realize that gettext is available in the C library and
therefore do not add -lintl to the LDFLAGS, causing the build failure
because the program has been compiled to use libintl_gettext but this
function is not available.
Therefore, we should only use gettext if a uClibc internal toolchain
or a uClibc external toolchain. If an external glibc toolchain is
used, gettext shouldn't be used.
In order to implement that, we introduce the BR2_NEEDS_GETTEXT option,
which is hidden to the user, and whose value is computed automatically
from the rest of the configuration.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
When building libxcb, the variable XCBPROTO_XCBPYTHONDIR must point to
the location where the Python modules needed to run the c_client.py
program are installed. The path
$(STAGING_DIR)/usr/lib/python2.6/site-packages was hardcoded. However,
it doesn't work when the version of Python installed on the host is
Python 2.5.
Therefore, add a little bit of magic to compute the host Python
version.
We also verify that Python is available on the host, as we don't build
it in Buildroot.
Fixes bug #1531.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Bash seems to be smart enough to source the file when execve returns
ENOEXEC, but other shells might not be.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
These are ancient (2006) and upstream strongly discourage using them:
ftp://sourceware.org/pub/gdb/old-releases/README
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Since new configuration options have been added in 0.9.31, the value
of these configuration options should be determined, either by the
default configuration file we provide, or by uclibc.mk process.
The locale generation process should probably be improved in order to
allow building other locales than just en_US.
[Peter: fixup locale handling, add PROGRAM__NAME to defconfig]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
UCLIBC_HAS_NFTW is a new knob in 0.9.31, which allows the obsolete and
deprecated ftw() to be compiled-out separatly from nftw(), which is
part of POSIX. nftw() should probably be enabled by default in uClibc,
and a bug has been opened about this on uClibc bug tracker
(https://bugs.busybox.net/show_bug.cgi?id=1597).
nftw() is, for example, used in Gtk+.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Paulius Zaleckas <paulius.zaleckas@gmail.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
When compiling GDB for target (in my case i386) it links
wrong BFD library from host OS. This prevents GDB from compiling
support for ELF and thus GDB is unusable on target.
More about this issue was already posted at:
http://lists.uclibc.org/pipermail/buildroot/2009-March/026585.html
Fix this issue by forcing ELF support.
Signed-off-by: Paulius Zaleckas <paulius.zaleckas@gmail.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Backported a patch from CVS that improves linking times for large
projects (eg 700s to 6s). See
http://old.nabble.com/-PATCH--Reduce-ARM-linking-time-tt27961038.html
for the original.
[Peter: add patch header]
Signed-off-by: Laine Walker-Avina <lwalkera@ieee.org>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Multilib toolchains provide different versions of the base libraries
for different architecture variants. For example, the ARM Codesourcery
toolchain provides base libraries for ARMv5 (default), ARMv4t and
Thumb2.
Depending on the -march= argument passed to gcc, the sysroot used by
the compiler is therefore different. This means that the sysroot
location in CROSS-gcc -v cannot be used. Instead, we must use
CROSS-gcc -print-sysroot when available and fall back to the old way
if unavailable.
Moreover, we cannot simply copy the full sysroot as we used to do,
because the sysroot organization of multilib toolchain is more
complicated. In Codesourcery toolchains, we have :
/
etc -- for ARMv5
lib -- for ARMv5
sbin -- for ARMv5
usr -- for ARMv5 (includes headers)
armv4t
etc -- for ARMv4t
lib -- for ARMv4t
sbin -- for ARMv4t
usr -- for ARMv4t (no headers!)
thumb2
etc -- for Thumb2
lib -- for Thumb2
sbin -- for Thumb2
usr -- for Thumb2 (no headers!)
So we have the default ARMv5 architecture variant that is installed in
the main directory, and we have subdirectories for the ARMv4t and
Thumb2 architecture variants.
Copying the full sysroot to the staging directory doesn't work. All
our packages are based on the fact that they should install libraries
in staging/usr/lib. But if ARMv4t is used, the compiler would only
look in staging/armv4t/usr/lib for libraries (even when overriding the
sysroot with the --sysroot option, the multilib compiler suffixes the
sysroot directory with the architecture variant if it matches a
recognized one).
Therefore, we have to copy only the sysroot that we are interested
in. This is rendered a little bit complicated by the fact that the
armv4t and thumb2 sysroot do not contain the headers since they are
shared with the armv5 sysroot.
So, this patch :
* Modifies how we compute SYSROOT_DIR in order to use -print-sysroot
if it exists. SYSROOT_DIR contains the location of the main sysroot
directory, i.e the sysroot for the default architecture variant.
* Defines ARCH_SUBDIR as the subdirectory in the main sysroot for the
currently selected architecture variant (in our case, it can be
".", "armv4t" or "thumb2"). ARCH_SYSROOT_DIR is defined as the full
path to the sysroot of the currently selected architecture variant.
* Modifies copy_toolchain_lib_root (which copies a library to the
target/ directory) so that libraries are taken from
ARCH_SYSROOT_DIR instead of SYSROOT_DIR. This ensures that
libraries for the correct architecture variant are properly copied
to the target.
* Modifies copy_toolchain_sysroot (which copies the sysroot to the
staging/ directory), so that it copies the contents of
ARCH_SYSROOT_DIR, and if needed, adds the headers from the main
sysroot directory and a symbolic link (armv4t -> . or thumb2 -> .)
to make the compiler believe that its sysroot is really in armv4t/
or thumb2/.
Tested with Codesourcery 2009q1 ARM toolchain, Crosstool-NG ARM glibc
and ARM uClibc toolchains.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The copy_toolchain_lib_root function was making the assumption that
all libraries were stored inside the /lib directory of the sysroot
directory. However, this isn't true for certain toolchains,
particularly for the libstdc++ library.
The function is therefore reworked to find the library and its related
symlink either in /lib or /usr/lib in the sysroot, and copies it at
the same location in the target directory.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Since BR2_RECENT was enabled by default, we do not want entries marked
BR2_RECENT (and thus appearing by default in Buildroot) to disappear.
Therefore, all the entries marked BR2_RECENT are converted as
non-deprecated. We can later decide, on a per-entry basis, to add
BR2_DEPRECATED to some of them. But at least, this commit doesn't
change the default current behaviour of Buildroot.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This variable, together with the FIXME comment, has been added has
part of Eric Andersen's « Major buildroot facelift, step one » commit
that occured in October 2004.
Since then, no real usage has been made of OPTIMIZE_FOR_CPU, and the
initial intention has probably been lost in the memories of the
implementors.
Therefore, get rid of the variable, and just use $(ARCH) at the two
locations the variable was used.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
It seems that there was an intention to add BR2_ENABLE_OPENMP someday,
but it was in June 2007 (commit
c81807a9d7) and since then, nothing
occured. Therefore, get rid of this code, and just pass
--disable-openmp to gettext to keep the current behaviour.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The option is marked broken since october 2009, and even the uClibc
configuration help text says that using pregenerated locales is highly
discouraged.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The cleanup of $(TARGET_DIR)/usr/share/man, $(TARGET_DIR)/usr/man,
$(TARGET_DIR)/usr/share/info, $(TARGET_DIR)/usr/info,
$(TARGET_DIR)/usr/share/doc and $(TARGET_DIR)/usr/doc is already done
globally in the main Makefile. Therefore, there's no need to handle
that on a per-package basis.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This option is barely used, no-one is maintaining it or extending
it. So let's remove it.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* Remove the dependency on BR2_HOST_FAKEROOT, since we don't have
config option for host tools.
* Remove a few useless things.
* Check that cpio is available on the host in
toolchain/dependencies/dependencies.sh.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The toolchains built with buildroot use specially crafted paths for their
sysroot and prefix. Fix that by asking gcc where it finds a file we
know by relative path to the sysroot.
This has the side effect of greatly simplifying the sysroot detection
in every cases tested so far (BR toolchains, CT-NG toolchains, and
CodeSourcery toolchains).
Fixes bug #851.
Thanks Thomas Petazzoni for the hint and some testings.
Thanks Grant Edwards for the report and the comments.
Signed-off-by: Yann E. MORIN <yann.morin.1998@anciens.enib.fr>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Enable susv3/susv4 legacy support for now, as a lot of packages (E.G.
busybox) breaks with the stricter interpretation in 0.9.31.
Also slightly tweak uclibc.mk as the "new" linuxthreads symbol changed.
Test built on x86/x86-64/ppc/arm/mips.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Closes#1219
Signed-off-by: Will Wagner <will_wagner@carallon.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Sysrooted toolchain can be relocated. In this case, the sysroot is no
longer located at the place it was configured at.
Signed-off-by: Yann E. MORIN <yann.morin.1998@anciens.enib.fr>
Acked-By: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Has been marked as broken for more than 1 year, with no indication
that anyone cares, and it needs a bunch of special handling.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
