Bug 12718 - builtools-tarball fails with x86_64-mingw32 sdkmachine
Summary: builtools-tarball fails with x86_64-mingw32 sdkmachine
Status: RESOLVED INVALID
Alias: None
Product: Other YP Layers
Classification: Build System, Metadata & Runtime
Component: layers (show other bugs)
Version: unspecified
Hardware: x86 x86_64
: Undecided normal
Target Milestone: ---
Assignee: Stephano Cetola
QA Contact:
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2018-04-26 22:51 UTC by sai pavan
Modified: 2018-04-27 08:33 UTC (History)
4 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: Don't know


Attachments
x86_64-mingw32-builtools-tarball-fail (84.36 KB, text/plain)
2018-04-26 22:51 UTC, sai pavan
no flags Details
sdk manifest for working build (715 bytes, application/octet-stream)
2018-04-26 22:54 UTC, sai pavan
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description sai pavan 2018-04-26 22:51:09 UTC
Created attachment 4289 [details]
x86_64-mingw32-builtools-tarball-fail

After the "bug 12662" has been fixed. I tested it too late, also I don't see the previous issue related to diffutils so creating a new one now.

With OE-CORE & meta-mingw master branches buildtools-tarball recipe fails for x86_64-mingw32 SDKMACHINE.

Seems like we there are more libs added by default and mingw is not able to compile it. It would be nice either we start supporting default recipes or restrict them.

Following recipes fail
 
nativesdk-qtbase
nativesdk-gdbm
nativesdk-db
nativesdk-openssl
nativesdk-ncurses

Working commits: (I dont see above libs beeing compiled with below version of OE-CORE)
    OE-CORE: ba2eb6237497494e3ec0296485ded61b024c5ba7
    Meta-Mingw: a07fe304228b7f41b5558de7d8f39fd5e8a430d2
    meta-xilinx: master

Noworking:
    OE-CORE: master
    Meta-Mingw: master
    meta-xilinx: master

Steps to reproduce:
1) update local.conf
   TOOLCHAIN_HOST_TASK = "nativesdk-qemu-xilinx"
2) run bitbake
   SDKMACHINE="x86_64-mingw32" bitbake buildtools-tarball
Comment 1 sai pavan 2018-04-26 22:54:55 UTC
Created attachment 4290 [details]
sdk manifest for working build

sdk manifest for working build
Comment 2 Ross Burton 2018-04-27 02:53:55 UTC
Surely buildtools-tarball is only failing because you're installing qemu?

Specifically qtbase isn't even part of oe-core so that is out of scope here.
Comment 3 Ross Burton 2018-04-27 05:13:41 UTC
Why are you setting TOOLCHAIN_HOST_TASK to just qemu?  That's not buildtools.  buildtools is what is in buildtools-tarball.  I don't believe we ever claims that you can build a mingw buildtools-tarball.
Comment 4 Ross Burton 2018-04-27 05:25:47 UTC
I'm closing this as resolved invalid.

You're not building buildtools-tarball, you're building nativesdk-qemu-xilinx.  Presumably this is what has changed.

If you can demonstrate that a pure buildtools-tarball for mingw worked in a previous release and we've regressed then please file a new bug, but with the 'working' commits you mentioned a proper buildtools-tarball fails in exactly the same way for me.
Comment 5 sai pavan 2018-04-27 06:26:58 UTC
(In reply to comment #3)
> Why are you setting TOOLCHAIN_HOST_TASK to just qemu?  That's not
> buildtools.  buildtools is what is in buildtools-tarball.  I don't believe
> we ever claims that you can build a mingw buildtools-tarball.

My usecase was to have just qemu and related dependencies in the installer. So i just mentioned qemu in TOOLCHAIN_HOST_TASK. Is it not used suchway ?
Comment 6 sai pavan 2018-04-27 06:35:55 UTC
Sorry, this is a false bug.

I had done a mistake during build, instead of "master" I was using rocko for OE-CORE and meta-mingw. Now fixing that, every thing works.

BTW, as you said you could reproduce the issue. There should be something similarly wrong with your setup.

And yes, bare bulidtools-tarball fails with mingw. Which explains what you said.

Thanks for looking into this.

Regards,
Sai Pavan
Comment 7 Juro Bystricky 2018-04-27 07:54:25 UTC
(In reply to comment #6)
> Sorry, this is a false bug.
> 
> I had done a mistake during build, instead of "master" I was using rocko for
> OE-CORE and meta-mingw. Now fixing that, every thing works.
> 
> BTW, as you said you could reproduce the issue. There should be something
> similarly wrong with your setup.
> 
> And yes, bare bulidtools-tarball fails with mingw. Which explains what you
> said.
> 
> Thanks for looking into this.
> 
> Regards,
> Sai Pavan

I regularly build buildtools-tarball with meta-mingw without any problems (with master (sumo) commits as of April 15, 2018):

SDKMACHINE="x86_64-mingw32"
BASECANADIANEXTRAOS=""
SDKTAROPTS_append=" -h --hard-dereference"
MACHINE="qemux86-64"
TOOLCHAIN_HOST_TASK+="nativesdk-qemu"
bitbake buildtools-tarball

which will create something like this::
tmp/deploy/sdk/x86_64-buildtools-nativesdk-standalone-2.4+snapshot-20180415.tar.xz

So if this fails for you, you should perhaps file a new bug with more details.
Comment 8 sai pavan 2018-04-27 08:33:48 UTC
(In reply to comment #7)
> (In reply to comment #6)
> > Sorry, this is a false bug.
> > 
> > I had done a mistake during build, instead of "master" I was using rocko for
> > OE-CORE and meta-mingw. Now fixing that, every thing works.
> > 
> > BTW, as you said you could reproduce the issue. There should be something
> > similarly wrong with your setup.
> > 
> > And yes, bare bulidtools-tarball fails with mingw. Which explains what you
> > said.
> > 
> > Thanks for looking into this.
> > 
> > Regards,
> > Sai Pavan
> 
> I regularly build buildtools-tarball with meta-mingw without any problems
> (with master (sumo) commits as of April 15, 2018):
> 
> SDKMACHINE="x86_64-mingw32"
> BASECANADIANEXTRAOS=""
> SDKTAROPTS_append=" -h --hard-dereference"
> MACHINE="qemux86-64"
> TOOLCHAIN_HOST_TASK+="nativesdk-qemu"
> bitbake buildtools-tarball
> 
> which will create something like this::
> tmp/deploy/sdk/x86_64-buildtools-nativesdk-standalone-2.4+snapshot-20180415.
> tar.xz
> 
> So if this fails for you, you should perhaps file a new bug with more
> details.

Thanks Juro, for taking time looking through issue. It was a false alarm. Every thing is fine after I fixed my branches.

Thanks