Patchwork [0/2] Use alternatives for all of binutils instead of -symlinks

login
register
mail settings
Submitter Peter Seebach
Date Oct. 10, 2013, 8:06 p.m.
Message ID <cover.1381435139.git.peter.seebach@windriver.com>
Download mbox
Permalink /patch/59619/
State New
Headers show

Pull-request

git://git.yoctoproject.org/poky-contrib seebs/binutils-alternatives

Comments

Peter Seebach - Oct. 10, 2013, 8:06 p.m.
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(-)
Saul Wold - Oct. 16, 2013, 4:48 p.m.
During MUT builds, we saw a failure with the toolchain


| Computing transaction...error: Can't install 
binutils-cross-canadian-arm-2.23.2-r4@i686_nativesdk: no package 
provides update-alternatives-cworth
|

Can be seen all architectures.


Sau!



On 10/10/2013 01:06 PM, Peter Seebach wrote:
> 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
>
>
Mark Hatle - Oct. 16, 2013, 7:18 p.m.
On 10/16/13 11:48 AM, Saul Wold wrote:
>
> During MUT builds, we saw a failure with the toolchain
>
>
> | Computing transaction...error: Can't install
> binutils-cross-canadian-arm-2.23.2-r4@i686_nativesdk: no package
> provides update-alternatives-cworth
> |
>
> Can be seen all architectures.

Sounds like the new code needs to be restricted to 'class-target'.

--Mark

>
> Sau!
>
>
>
> On 10/10/2013 01:06 PM, Peter Seebach wrote:
>> 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
>>
>>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>