On Thu, Dec 20, 2018 at 7:48 AM Burton, Ross wrote:
>
> On Thu, 20 Dec 2018 at 15:37, Khem Raj wrote:
> > > Well, I built core-image-sato core-image-weston with AR=gcc-ar
> > > RANLIB=gcc-ranlib globally and it worked fine.
> >
> > Please build a lot more. These images cover only handful of recip
On Thu, 20 Dec 2018 at 15:37, Khem Raj wrote:
> > Well, I built core-image-sato core-image-weston with AR=gcc-ar
> > RANLIB=gcc-ranlib globally and it worked fine.
>
> Please build a lot more. These images cover only handful of recipes
> there are problems like
>
> https://gcc.gnu.org/bugzilla/sho
On Thu, 20 Dec 2018 at 15:37, Khem Raj wrote:
> > As we build the cross gcc we know what is in it. Other toolchains be
> > they clang, ICC, or external GCCs, can override AR just like they do
> > the other variables.
>
> Yes they can, but what doe this buy us ? except we make Core toolchain
> gcc
On Thu, Dec 20, 2018 at 4:37 AM Burton, Ross wrote:
>
> On Thu, 20 Dec 2018 at 01:20, Khem Raj wrote:
> > > That however leads to the question of should we just change the
> > > defaults? Does anything break if we use gcc-ar instead of ar?
> >
> > Dont think that is a good idea in general since g
On Thu, 20 Dec 2018 at 01:20, Khem Raj wrote:
> > That however leads to the question of should we just change the
> > defaults? Does anything break if we use gcc-ar instead of ar?
>
> Dont think that is a good idea in general since gcc-ar is a wrapper
> around normal ar
> passing --plugin=/path/to
On Tue, Dec 18, 2018 at 5:07 PM Burton, Ross wrote:
>
> On Wed, 19 Dec 2018 at 00:42, Brad Bishop wrote:
>
> > I wonder if this is something they would be interested in upstream. I’ve
> > copied
> > the oe-core mailing list for possible comment.
>
> Thanks for forwarding this to us. The class
On Tue, Dec 18, 2018 at 4:42 PM Brad Bishop wrote:
>
>
>
> > On Dec 18, 2018, at 1:08 PM, James Feist
> > wrote:
> >
> > If you aren't planning on enabling flto in a repo you can ignore this email.
> >
> >
> > I've created a new class flto-automake
> > https://github.com/openbmc/meta-phosphor/b
On Wed, 2018-12-19 at 10:00 +, Burton, Ross wrote:
> On Wed, 19 Dec 2018 at 01:07, Burton, Ross
> wrote:
>
> > That however leads to the question of should we just change the
> > defaults? Does anything break if we use gcc-ar instead of ar?
>
> Answer: yes.
>
> > x86_64-poky-linux-gcc-ar r
On Wed, 19 Dec 2018 at 01:07, Burton, Ross wrote:
> That however leads to the question of should we just change the
> defaults? Does anything break if we use gcc-ar instead of ar?
Answer: yes.
| x86_64-poky-linux-gcc-ar rc libgcov.a $objects
| x86_64-poky-linux-gcc-ar: Cannot find plugin 'libl
On Wed, 19 Dec 2018 at 00:42, Brad Bishop wrote:
> I wonder if this is something they would be interested in upstream. I’ve
> copied
> the oe-core mailing list for possible comment.
Thanks for forwarding this to us. The class is very simple and just does:
PACKAGECONFIG_CONFARGS += " AR=${TAR
> On Dec 18, 2018, at 1:08 PM, James Feist wrote:
>
> If you aren't planning on enabling flto in a repo you can ignore this email.
>
>
> I've created a new class flto-automake
> https://github.com/openbmc/meta-phosphor/blob/master/classes/flto-automake.bbclass
> if you are enabling -flto in
11 matches
Mail list logo
