The original complaint that got me started on this was that someone was using binutils on a target, and didn't have an ld command, so they asked for it. We added binutils-symlinks, and that seemed to work, but eventually we ran into a problem because "ar" and "strings" weren't showing up.
After some asking about as to why ar and strings might be omitted from binutils, we concluded that it was probably because they were using the alternatives mechanism. In a local branch, we experimented for a while with just using that instead of the -symlinks package, and found that it was overall better-behaved; in particular, it produces the desireable result that you don't have to know about or add a "-symlinks" package to use the utilities in the common case where you just install a package and expect its binaries to show up. It also eliminates the odd special case difference between ar/strings (which can be provided by busybox) and the other utilities. This is implemented as two patches. The first switches to using the alternatives mechanism, but leaves the alternatives in the -symlinks package rather than in the base package. The second moves them into the base package, and adds an RPROVIDES for the -symlinks name in case anyone is using it. One caveat: This can produce warnings because the "embedspu" and "ld.gold" binaries don't always exist, but they sometimes exist. I'm not sure whether there's a good way to fix that... The following changes since commit 1149b1fef8912f77d971242dfec151fff5a3aa51: build-appliance: Update SRCREV for release (2013-10-08 16:33:25 +0100) are available in the git repository at: git://git.yoctoproject.org/poky-contrib seebs/binutils-alternatives http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=seebs/binutils-alternatives Peter Seebach (2): Use alternatives for the binutils-symlinks package. Drop binutils-symlinks meta/recipes-devtools/binutils/binutils.inc | 68 ++++++++++++++++----------- 1 files changed, 40 insertions(+), 28 deletions(-) _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
