| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
SVN-Revision: 31740
|
|
|
|
| |
SVN-Revision: 31739
|
|
|
|
|
|
| |
fixes exposure of a kernel-only data type (umode_t) to application layer which causes compile errors in ext2_fs.h using programs.
SVN-Revision: 31697
|
|
|
|
| |
SVN-Revision: 31546
|
|
|
|
|
|
| |
for reference: http://www.mail-archive.com/openwrt-devel@lists.openwrt.org/msg13425.html
SVN-Revision: 31503
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
SVN-Revision: 31500
|
|
|
|
| |
SVN-Revision: 31489
|
|
|
|
| |
SVN-Revision: 31393
|
|
|
|
| |
SVN-Revision: 31392
|
|
|
|
|
|
| |
environment variable is unset
SVN-Revision: 31390
|
|
|
|
| |
SVN-Revision: 31342
|
|
|
|
|
|
| |
Mentioned patch got obsoleted by commit 31300, since it went upstream meanwhile
SVN-Revision: 31341
|
|
|
|
|
|
| |
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
|
|
|
|
| |
SVN-Revision: 31255
|
|
|
|
|
|
| |
without failing avr32 builds
SVN-Revision: 31249
|
|
|
|
| |
SVN-Revision: 31230
|
|
|
|
| |
SVN-Revision: 31216
|
|
|
|
| |
SVN-Revision: 31073
|
|
|
|
| |
SVN-Revision: 30970
|
|
|
|
| |
SVN-Revision: 30969
|
|
|
|
|
|
| |
-Os/-O2 workaround that dealt with it earlier
SVN-Revision: 30815
|
|
|
|
|
|
| |
are tricky to deal with wrt. libgcc. they cannot be linked dynamically
SVN-Revision: 30814
|
|
|
|
|
|
| |
about 400 bytes on every executable or shared library
SVN-Revision: 30614
|
|
|
|
| |
SVN-Revision: 30613
|
|
|
|
|
|
| |
libgcc crap from leaking into every single binary
SVN-Revision: 30486
|
|
|
|
|
|
| |
a patch and testing by WillieNL)
SVN-Revision: 30478
|
|
|
|
| |
SVN-Revision: 30471
|
|
|
|
| |
SVN-Revision: 30470
|
|
|
|
| |
SVN-Revision: 30469
|
|
|
|
| |
SVN-Revision: 30468
|
|
|
|
| |
SVN-Revision: 30467
|
|
|
|
| |
SVN-Revision: 30466
|
|
|
|
|
|
| |
in 0.9.33
SVN-Revision: 30398
|
|
|
|
| |
SVN-Revision: 30394
|
|
|
|
| |
SVN-Revision: 30375
|
|
|
|
| |
SVN-Revision: 30374
|
|
|
|
| |
SVN-Revision: 30372
|
|
|
|
| |
SVN-Revision: 29842
|
|
|
|
| |
SVN-Revision: 29836
|
|
|
|
|
|
| |
cross toolchains to always search headers and libraries in $STAGING_DIR, this should solve most issues with missing headers, indirect linking and not found libraries. At a later stage, all -I and -L flags will be purged from TARGET_LDFLAGS and TARGET_CPPFLAGS.
SVN-Revision: 29768
|
|
|
|
|
|
| |
to wrap external toolchain commands, abort build if certain features such as CONFIG_SOFT_FLOAT or CONFIG_IPV6 are enabled but not supported by the toolchain.
SVN-Revision: 29766
|
|
|
|
| |
SVN-Revision: 29748
|
|
|
|
|
|
| |
hosts that refuse to link it in implicitly (should fix #10587)
SVN-Revision: 29721
|
|
|
|
|
|
| |
EXTERNAL_TOOLCHAIN || NATIVE_TOOLCHAIN Currently we always assume uClibc if an external toolchain is used, this breaks for non-uClibc toolchains or even vanilla uClibc ones since they do not share the external librpc semantics as OpenWrt. Solve the problem by defining an abstract "EXTERNAL_LIBC" which packages might or might not depend on.
SVN-Revision: 29689
|
|
|
|
|
|
| |
is on (#10735)
SVN-Revision: 29646
|
|
|
|
| |
SVN-Revision: 29633
|
|
|
|
|
|
| |
for systems that prefer this as library path (e.g. current SuSE), fixes mpfr and gcc build
SVN-Revision: 29352
|
|
|
|
| |
SVN-Revision: 28087
|