Bug 2675 - do_compile for x32 build fails on 1.2.1
Summary: do_compile for x32 build fails on 1.2.1
Status: CLOSED FIXED
Alias: None
Product: Other YP Layers
Classification: Build System, Metadata & Runtime
Component: layers (show other bugs)
Version: 1.2.1
Hardware: x86 Multiple
: High normal
Target Milestone: 1.3 M3
Assignee: Radu Moisan
QA Contact:
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2012-07-02 12:43 UTC by Laurentiu Serban
Modified: 2012-08-29 10:40 UTC (History)
8 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: ---


Attachments
do_patch log (2.24 KB, application/octet-stream)
2012-07-02 12:43 UTC, Laurentiu Serban
no flags Details
log (524 bytes, application/octet-stream)
2012-07-02 12:48 UTC, Laurentiu Serban
no flags Details
log do compile (536.97 KB, application/octet-stream)
2012-08-17 15:26 UTC, Laurentiu Serban
no flags Details
config log (46.47 KB, text/x-log)
2012-08-17 15:27 UTC, Laurentiu Serban
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Laurentiu Serban 2012-07-02 12:43:08 UTC
Created attachment 612 [details]
do_patch log

Building x86-64 with x32 layer fails.
The instruction from the link below were followed:
http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html#using-x32-right-now

The log is attached
Comment 1 Laurentiu Serban 2012-07-02 12:48:05 UTC
Created attachment 613 [details]
log

The correct log
Comment 2 Laurentiu Serban 2012-07-02 12:48:38 UTC
The issues is on sgw/denzil branch
Comment 3 Bruce Ashfield 2012-07-03 03:38:17 UTC
What layer contains the linux-korg that this is using ?

One thing to fix is this:

WARNING. /home/lserban/work/poky-contrib/build/tmp/work/qemux86_64-poky-linux-gnux32/linux-korg-3.1+x32-r0/git is not a bare clone.

but without seeing the actual recipe that is being used, I can't say more.
linux-korg comes out of poky-extras .. since it is just that .. extra, and
can periodically change. If there's a BSP depending on it, we should have
made copy into the BSP layer.

If a copy was made, it also needs to stay up to date with any tools changes.

In denzil: YOCTO_KERNEL_META_DATA must be cleared if you don't have a meta
branch (which you don't in this case), otherwise, you get the error that
was attached to this bug.
Comment 4 Laurentiu Serban 2012-07-04 14:49:33 UTC
Hello Bruce,
I reproduced this issue earlier on http://autobuilder.yoctoproject.org/pub/nightly/20120629-1/yocto.tar.bz2
plus adding http://git.yoctoproject.org/cgit/cgit.cgi/experimental/meta-x32/
 
and adding in local.conf
MACHINE = "qemux86-64"
DEFAULTTUNE = "x86-64-x32"

If there are any other changes needed, please tell me.

Thank you,
Laurentiu
Comment 5 Bruce Ashfield 2012-07-04 14:57:51 UTC
You need to talk to nitin about what he did in meta-x32 and the recipe there, looking at that layer, it isn't branched to match our releases and has
it's own copies of the recipes.

So again, is this master ? denzel .. something else ?

The recipe in the layer is out of sync with the tools, and need an
update. 

This isn't a recipe that I support directly, all I can say is that the error message
is saying exactly what is wrong .. the recipe needs to indicate that a meta
data branch should not be checked .. and it hasn't done that.
Comment 6 Saul Wold 2012-07-05 18:21:18 UTC
I think this is with the meta-x32 layer with Denzil 1.2.1 RC, which means the issue is in the the x32 layer. I am going to re-assign this to Bogan who is the new x32, and CC Nitin.
Comment 7 Bruce Ashfield 2012-07-05 18:32:42 UTC
sounds good. If there IS a bug in the tools (after the 
configuration changes I suggested), I'll can take the bug back.
Comment 8 Bogdan Marinescu 2012-07-16 15:36:02 UTC
Can you please let me know the exact branch that I need to use to reproduce this problem? I've tried with denzil and I'm unable to compile anything with x32. Saul mentioned Denzil 1.2.1 RC, but I don't know where I can find it.
Comment 9 Laurentiu Serban 2012-07-16 18:02:44 UTC
hello Bogdan, 
the branch is denzil (1.2.1 is it was created)
Comment 10 Bogdan Marinescu 2012-07-17 09:07:44 UTC
(In reply to comment #9)
> hello Bogdan, 
> the branch is denzil (1.2.1 is it was created)

For me, x32 on denzil fails with a very different error (the compiler complains that it knows nothing about "-mx32" when compiling gcc-cross-initial). This is why I was wondering if I'm using the right branch. Maybe I'm doing something wrong somewhere.
Comment 11 Bogdan Marinescu 2012-07-17 15:09:31 UTC
I understood why this happened. experimental/meta-x32 continued to evolve independent of the denzil branch, introducing changes that are incompatible with the denzil branch (such as switching to gcc 4.7 or using kernel 3.4). The denzil branch still compiles with this commit from experimenta/meta-x32:

http://git.yoctoproject.org/cgit/cgit.cgi/experimental/meta-x32/commit/?id=d7088df5d4a64f071ec01748b1ca528cf2e85e88

(which is 4 commits before HEAD). I'm guessing we don't want to modify denzil to work with gcc 4.7, so what I'd like to do is create a git tag named "denzil" in the experimental/meta-x32 repo which points to the above commit (d7088df5d4a64f071ec01748b1ca528cf2e85e88). In the future, when using denzil with x32, you'd simply need to use the "denzil" tag. Please let me know if this is OK. If it is, please also let me know if this should be documented somewhere.
Comment 12 Nitin Kamble 2012-07-18 03:33:41 UTC
Bogdan,
  you analysis is right. I noticed Beth created denzil branch and denzil-7.0.1_rc2 tag in the meta-x32 repository. But these point to the latest master, which will break with denzil branch of poky. 
  I replaced these denzil branch & tag from meta-x32 layer to the correct commit. 
which makes meta-x32 commit history non-progressive, but that is the best we can do now.
  There is no need for extra documentation for this. If there are any instructions for x32 build in denzil release, that would need mentioning the denzil branch.

Nitin
Comment 13 Bogdan Marinescu 2012-07-18 07:17:53 UTC
Thanks, Nitin. This clears the issue, so I'll mark this bug as "resolved".
Comment 14 Laurentiu Serban 2012-08-17 15:26:19 UTC
do compile fails for x32 tune on 1.2.1
Logs attached.
Changed the bug name
Comment 15 Laurentiu Serban 2012-08-17 15:26:44 UTC
Created attachment 697 [details]
log do compile
Comment 16 Laurentiu Serban 2012-08-17 15:27:09 UTC
Created attachment 698 [details]
config log
Comment 17 Laurentiu Serban 2012-08-17 15:28:33 UTC
local.conf was modified and these lines were added
MACHINE = "qemux86-64"
DEFAULTTUNE = "x86-64-x32"
baselib = "${@d.getVar('BASE_LIB_tune-' + (d.getVar('DEFAULTTUNE', True) \
         or 'INVALID'), True) or 'lib'}"
Comment 18 Saul Wold 2012-08-27 23:28:57 UTC
I can't reproduce this, I setup a denzil branch from both poky/denzil-7.0.1 and from the meta-x32/denzil-7.0.1 repo/branch, then setup my bblayers and local.conf according to the x32 right now web page, it build core-image-minimal with no issues.

Please double check what branches you have maybe:

BB_VERSION        = "1.15.2"
TARGET_ARCH       = "x86_64"
TARGET_OS         = "linux-gnux32"
MACHINE           = "qemux86-64"
DISTRO            = "poky"
DISTRO_VERSION    = "1.2.1"
TUNE_FEATURES     = "mx32"
TARGET_FPU        = ""
meta              
meta-yocto        = "denzil:73cdebf60df225ee10f2eb215935be3b61e1b831"
meta-x32          = "1.2.1:d7088df5d4a64f071ec01748b1ca528cf2e85e88"
Comment 19 Alexandru Palalau 2012-08-28 15:17:25 UTC
Verified with the branches/commit-IDs that Saul mentioned.
Comment 20 Radu Moisan 2012-08-29 10:24:34 UTC
same here, build completed successfully

OE Build Configuration:
BB_VERSION        = "1.15.2"
TARGET_ARCH       = "x86_64"
TARGET_OS         = "linux-gnux32"
MACHINE           = "qemux86-64"
DISTRO            = "poky"
DISTRO_VERSION    = "1.2.1"
TUNE_FEATURES     = "mx32"
TARGET_FPU        = ""
meta              
meta-yocto        = "branch-denzil-7.0.1:73cdebf60df225ee10f2eb215935be3b61e1b831"
meta-x32          = "branch-denzil-7.0.1:d7088df5d4a64f071ec01748b1ca528cf2e85e88"
Comment 21 Laurentiu Serban 2012-08-29 10:40:07 UTC
setting to resolved fixed
Comment 22 Laurentiu Serban 2012-08-29 10:40:22 UTC
verified