As discussed on the list. I suspect the ARM abi thing isn't needed anymore
now we use the correct abi in the first place, but I'll leave it in until
after the release.
I know that changing something as fundamental as mpfr this close to the
release isn't really ideal, but it's listed as the minimum version
for gcc 4.3.x:
http://gcc.gnu.org/install/prerequisites.html
Bernhard's tree has been using 2.3.2 since October, so the risk is probably
not that big though.
The GNU_TARGET_NAME symlink and target_utils location were not correctly
adjusted to match the move of the toolchain to $(STAGING_DIR)/usr,
creating dangling symlinks.
Make sure the developer is informed why a package is not
visable and that they need to have a NPTL enabled
toolchain.
Signed-off-by: Daniel Laird <daniel.j.laird@nxp.com>
Buildroot is adopting depends on for toolchain features and
select for packages. Make this change in this file.
Signed-off-by: Daniel Laird <daniel.j.laird@nxp.com>
Have been having various issues with multiple jobs (-jX) and building
autoconf. Turns out that v2.63 has fixed this. So bounce version
to a working version.
Signed-off-by: Daniel Laird <daniel.j.laird@nxp.com>
The avahi-autoipd target install step adds /var/lib/avahi-autoipd as a
symlink to /tmp/avahi-autoipd, which is fine, except if your /var/lib is
already a symlink to /tmp (E.G. like the default target_skeleton is).
If that's the case, then you end up adding a /tmp/avahi-autoipd symlink
pointing to itself, causing subsequent builds to fail
(Too many levels of symbolic links in the ln -sf call). Fix it by simply
first removing the symlink if it's there.
This seems to be required to compile some of the inline asm.
This solves the following compiler errors:
h264.c: In function 'decode_cabac_residual':
h264.c:6158: warning: passing argument 4 of 'decode_significance_8x8_x86' discards qualifiers from pointer target type
cabac.h: In function 'get_cabac_noinline':
cabac.h:513: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm'
cabac.h:513: error: 'asm' operand has impossible constraints
While searching several weeks ago, I hit the following URL, which
unfortunately currently doesn't seem to work anymore and I can't
remember what the bug was about.
Also see http://bugs.uclibc.org/view.php?id=4604
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
