uClibc declares eventfd() as taking two arguments but doesn't properly
pass the second argument to the kernel.
The problem is discussed at:
http://lists.uclibc.org/pipermail/uclibc/2012-May/046873.html
This patch is taken from uclibc 0.9.33 git, so will presumably
be integrated in any future releases.
Signed-off-by: Andy Leiserson <andy@leiserson.org>
SVN-Revision: 33478
testing uclibc changes is tricky because the final gcc tends to miscompile
uclibc code or barf up internal compiler errors.
install binutils into $(TOOLCHAIN_DIR)/initial (without changing the configure
prefix) and copy it from there to $(TOOLCHAIN_DIR)/ so that the initial gcc
can be put into $(PATH) for the uclibc build, even if the final gcc
is already installed.
SVN-Revision: 32553
insight GDB version 6.8-1 sources have apparently changed.
The original file is no longer available upstream.
Signed-off-by: Daniel Golle <dgolle@allnet.de>
SVN-Revision: 32438
When selecting a specific eglibc version, it comes with a specific SVN
revision that should not be modified as it (more or less) correspond to
a tagged release. This patch disable the possibility to select a specific
SVN revision on known eglib versions.
This patch also disables the possibility to select the trunk branch of
eglibc. There are multiple reasons for that:
* trunk/HEAD may not even compile
* the OpenWrt built system makes using trunk/HEAD a difficult thing, as
OpenWRT fetches the source tree and store it in a compressed tar archive.
Subsequent build get the source from the tar archive - not from SVN,
making the use of trunk/HEAD largelly innefective.
* we cannot know the corresponding version of trunk/HEAD, meaning that
we'll face compiling issues when we'll try to copy the libc files -
unless the build system is fixed with this specific issue in mind.
Signed-off-by: Emmanuel Deloget <logout@free.fr>
SVN-Revision: 31502
eglibc version number depends on the branch and on the maintenance release
(i.e. the SVN revision). Changing the revision may change the maintenance
version. This patch correlate the SVN revision to the correct version
number - without this change eglibc 2.14 provoke build errors when
building the base-files package (example, for 2.14):
$ make package/base-files/compile V=1
make[1] package/base-files/compile
make[2] -C package/opkg host-compile
make[2] -C package/base-files-network compile
make[2] -C package/base-files compile
cp: cannot stat `/home/me/openwrt/trunk/staging_dir/toolchain-arm_v7-a_gcc-4.6-linaro_eglibc-trunk_eabi/lib/ld-2.14.so': No such file or directory
Signed-off-by: Emmanuel Deloget <logout@free.fr>
SVN-Revision: 31501
in particular this solves the issue that eglibc version 2.x produced so-files having the version string 2.(x-1) in its names which confused the toolchain
SVN-Revision: 31300
Felix Fietkau