|
reviving this thread because i'm an inheritor of a yocto-based image and SDK and i have no loving idea what I'm doing long story short: our image is made from yocto 4.0.4, which has go 1.17.something in poky/meta/recipes-devtools/go. we need go 1.19.3 instead. how do i accomplish this? i've run `devtool upgrade --no-patch -V 1.19.3 go`, and that seems to pull down the right go into workspace/source/go & makes the .bb & .inc files in workspace/recipe; but then `devtool build go` and actually generating the image & SDK at the end seem to just include the old go version, whether or not i run `devtool finish go <our_top_layer>` (which seems to just make an empty `go` folder in said layer's recipes-devtools folder anyway, no .bb or .bbappend or .inc or anything) I also know there's GOVERSION and PREFERRED_VERSION_go* variables being set, but i have no idea where - or if - to change them help pls 
|
#
?
Nov 12, 2022 02:54
|
|
|
|
| # ? May 13, 2024 02:28 |
|
|
uhh if it made the new version in a new recipe you’d need to set preferred version yeah. I think the place you want to do it is your distro.conf which is in a conf/ dir of one of your layers, somewhere when doing yocto poo poo it is critically important to figure out and distinguish between: - the base dir. this is what has the build/ dir. it might be called poky - layer dir. typically a lot of layers live in here - the layer thAt owns stuff like distros. this is probably called meta-yourcompany or if you’re lazy meta-yoursocorsomorsbcvendor. i hope you own one of the layers otherwise you have to do very annoying bullshit (see below) - if you own a layer, that layer probably has a conf/distro dir that includes yourcompanyname.conf. this is the “distro config” which is for a set of working software that you might want to install on one or more machines. a combination of distro and machine is an image. if you don’t have this, go to your image recipe and find out what distro you’re using, and then go make a distro conf that inherits from that - in here, you probably want to set your preferred version. if you decide that the distros version is fine in most cases but this device should really have a different one, put it in a machine conf - if none of the above works because for some reason you’re using a vendors entire tree, you can also put this in build/local.conf. please don’t. that poo poo shouldn’t exist. at most it should have some paths uh ask followups in here or pm me if you need more information I’m like harshly mediocre at this but I’ll try
|
|
#
?
Nov 12, 2022 03:21
|
|
|
yocto. not even once.
|
|
#
?
Nov 12, 2022 03:23
|
|
|
if you just want to force it to work set those in your local.conf. see here: https://lists.yoctoproject.org/g/yo...453482707577325 to make the change for "real" set it in the layer.conf for your actual layer
|
|
#
?
Nov 12, 2022 03:24
|
|
|
it's all home-rolled so i can gently caress around quite a bit - yeah i start in /workdir/poky when i run the docker container, has the oe-init-build-env file in it - if by "own a layer" you mean my predecessor wrote it, then yeah, got that. meta-blah-gen5, here (there's another layer below that with a DO NOT TOUCH warning in the README, seems to have initramfs stuff? don't think it's relevant here) - said layer has conf/layer.conf, image/blah-gen5-image.bb, and a bunch of recipe-* folders - said blah-gen5-image.bb has IMAGE_INSTALL:append = with a bunch of stuff in it; i initially added go to this then did the bitbake build, saw it was building go 1.17, ctrl-c'd and started looking into the upgrade - /workdir/poky/build/conf/local.conf has DISTRO ?= "poky" in it, and as far as i can tell there's no others in the repo - i don't see a distro.conf anywhere - the target machines are ultimately just core-i7 PCs in a custom box with a CAN interface added, so idk why the gently caress we're using yocto??? but here we are Ciaphas fucked around with this message at 03:40 on Nov 12, 2022 |
|
#
?
Nov 12, 2022 03:37
|
|
|
hobbesmaster posted:if you just want to force it to work set those in your local.conf. see here: https://lists.yoctoproject.org/g/yo...453482707577325 yeah I saw that one, thought I'd followed it verbatim, but soon as I went to bitbake the image and sdk it said it was doing go 1.17 again. do i need to do something to "commit" workspace local.conf changes maybe???? i'll try putting them in the layer's layer.conf
|
|
#
?
Nov 12, 2022 03:42
|
|
|
Ciaphas posted:- /workdir/poky/build/conf/local.conf has DISTRO ?= "poky" in it, and as far as i can tell there's no others in the repo yes, build/conf/local.conf overrides everything else quote:- the target machines are ultimately just core-i7 PCs in a custom box with a CAN interface added, so idk why the gently caress we're using yocto??? but here we are let’s put it this way: how close are you to finding out what the original author’s consulting rates are?
|
|
#
?
Nov 12, 2022 03:43
|
|
|
hobbesmaster posted:yes, build/conf/local.conf overrides everything else lol @ the idea of the company having $ to hire consultants or even domain-experts
|
|
#
?
Nov 12, 2022 03:52
|
|
|
Ciaphas posted:yeah I saw that one, thought I'd followed it verbatim, but soon as I went to bitbake the image and sdk it said it was doing go 1.17 again. do i need to do something to "commit" workspace local.conf changes maybe???? being hosed by the sstate cache is a rite of passage bitbake -c clean <recipe name>
|
|
#
?
Nov 12, 2022 03:53
|
|
|
i swear to god if that's all i had to do i'ma riot (e) wait i can't just clean go, right, i gotta get go-cross etc too?
|
|
#
?
Nov 12, 2022 03:53
|
|
|
if you’re on a nice machine you can just blow away the entire sstate cache
|
|
#
?
Nov 12, 2022 03:57
|
|
|
Phobeste posted:if you’re on a nice machine you can just blow away the entire sstate cache not a great machine but i'm officially into let-it-run-overnight mode so rm -rf build/sstate-cache/* it is~ thanks for the help folks, here's hoping
|
|
#
?
Nov 12, 2022 04:03
|
|
|
truth be told this'd be kind of interesting stuff for me to mess with if i hadn't got thrown into the deep end on a (loose, but still) work deadline
|
|
#
?
Nov 12, 2022 04:45
|
|
|
it interesting but it’s also true that you get to pick between 1) being able to do any of Shakespeare plays but only Shakespeares plays (buildroot) and being able to write whatever you want but only by picking letters from an Olympic sized pool of alphabet soup with tweezers (yocto)
|
|
#
?
Nov 12, 2022 06:10
|
|
|
what about turning the computer off and disappearing into the woods, to live like a mountain man for the rest of my days befriend the local wildlife? what about that smart fella? did you ever think about which build system would help me become achmed of the opossums, friend to raccoons, brother to the owl? no seriously, which one
|
|
#
?
Nov 12, 2022 06:27
|
|
|
emerge world
|
|
#
?
Nov 12, 2022 06:32
|
|
|
hobbesmaster posted:emerge world help im being attacked
|
|
#
?
Nov 12, 2022 07:36
|
|
|
Phobeste posted:it interesting but it’s also true that you get to pick between 1) being able to do any of Shakespeare plays but only Shakespeares plays (buildroot) and being able to write whatever you want but only by picking letters from an Olympic sized pool of alphabet soup with tweezers (yocto) I choose option 3: Shove more Shakespeare plays into the book (Buildroot Dev)
|
|
#
?
Nov 12, 2022 07:54
|
|
|
small consolation maybe: Yocto is really good once you get over the learning curve. It's a brutal, steep-rear end fucken learning curve. But it's good on the other side. pro-tip: try running 'bitbake -e whatever-package >dump.bb' and then look around in the results. It's the best way I've found to really track down what the gently caress Yocto is doing and why, if you're ever unsure what's going on when you try to build something or other. Poopernickel fucked around with this message at 08:58 on Nov 12, 2022 |
|
#
?
Nov 12, 2022 08:40
|
|
|
FlapYoJacks posted:I choose option 3: Shove more Shakespeare plays into the book (Buildroot Dev) Nice!
|
|
#
?
Nov 12, 2022 08:40
|
|
|
To your question of "why gently caress around with Yocto or Buildroot", there are a few pretty good reasons. 1. You wind up with an OS image that includes only what you want, and nothing that you don't want. 2. You can migrate later to other CPUs pretty drat easily. 3. Dependency management is really important if you're trying to build and ship a product. Yocto and Buildroot both give you the tools you need to track your dependencies, control them, and make sure you're getting the same result if you re-run your build next week or on a different build machine.
|
|
#
?
Nov 12, 2022 08:46
|
|
|
hobbesmaster posted:being hosed by the sstate cache is a rite of passage this, except "bitbake -c cleansstate <recipe name>" is actually what you want 99% of the time
|
|
#
?
Nov 12, 2022 08:50
|
|
|
update: the built SDK after yesterday's suggestions had no golang installed at all; and when i went into a fresh container (still with the added PREFERRED_VERSION_go* in the layer.conf), and tried `devtool upgrade go -V 1.19.3` again, it download 1.17.13 instead wat Ciaphas fucked around with this message at 19:18 on Nov 12, 2022 |
|
#
?
Nov 12, 2022 19:08
|
|
|
Ciaphas posted:update: the built SDK after yesterday's suggestions had no golang installed at all; and when i went into a fresh container (still with the added PREFERRED_VERSION_go* in the layer.conf), and tried `devtool upgrade go -V 1.19.3` again, it download 1.17.13 instead this is the case that this is for Poopernickel posted:pro-tip: try running 'bitbake -e whatever-package >dump.bb' and then look around in the results. It's the best way I've found to really track down what the gently caress Yocto is doing and why, if you're ever unsure what's going on when you try to build something or other. https://docs.yoctoproject.org/bitbake/bitbake-user-manual/bitbake-user-manual-metadata.html
|
|
#
?
Nov 12, 2022 19:21
|
|
|
Poopernickel posted:small consolation maybe: Yocto is really good once you get over the learning curve. oh jeez i was looking for something like this all day yesterday, some kinda dry-run or what-the-gently caress-Yocto command, this'll be a huge help
|
|
#
?
Nov 12, 2022 19:25
|
|
|
lmao wasn't even yocto, i Did A Bad with docker and didn't put the actual updated go recipe in for the last build  i'd have noticed sooner if i used REQUIRED_VERSION instead of PREFERRED and it all just outright failed, so I changed it and bitbake now emits this for each statement code:Ciaphas fucked around with this message at 20:33 on Nov 12, 2022 |
|
#
?
Nov 12, 2022 20:18
|
|
|
Ciaphas posted:lmao wasn't even yocto, i Did A Bad with docker and didn't put the actual updated go recipe in for the last build Womp womp
|
|
#
?
Nov 12, 2022 21:07
|
|
|
gotta love the womp womp anyway it worked, go 1.19 was built and added, but I misunderstood something about how all this works. after i installed the sdk and sourced /poky/environment-setup-corei7-64-poky-linux, go still wasn't on my PATH; the environment setup added /poky/sysroots/x86_64-pokysdk-linux/usr/bin (and all the other bins) to the path, but the go installation ended up under /poky/sysroots/corei7-64-poky-linux. once I added that to PATH, the build of the software this was all for worked perfectly. I haven't tried the actual image on target hardware yet, but I'm going to take a guess that the way I added go to the image layer means go is going to show up on the target, right? I don't want it to do that, I only want it in the sdk (and if I said otherwise before, I misspoke - apologies) so instead of adding go to IMAGE_INSTALL:append, I want to do... what? i saw this page telling me to add it to TOOLCHAIN_TARGET_TASK, but it also presumes the image is inheriting populate_sdk somewhere, which it currently isn't, so I'm a little unsure about that one
|
|
#
?
Nov 12, 2022 23:17
|
|
|
this is why i much prefer Buoldroot. Copy/paste the updated .mk files (and any new dependencies) and rebuild. I sympathize that you inherited the project. 
|
|
#
?
Nov 12, 2022 23:25
|
|
|
i'd rather be doing this than doing bugfixes for the stuff we run on Windows CE 6.0 like i have been lmao
|
|
#
?
Nov 12, 2022 23:43
|
|
|
Ciaphas posted:Windows CE 6.0 No NWS tags? 
|
|
#
?
Nov 12, 2022 23:44
|
|
|
Ciaphas posted:gotta love the womp womp x86_64 is everything for the host, it sounds like your target is called corei7-64 so you were using the go installation you created for the target. this is fine in this case. quote:so instead of adding go to IMAGE_INSTALL:append, I want to do... what? i saw this page telling me to add it to TOOLCHAIN_TARGET_TASK, but it also presumes the image is inheriting populate_sdk somewhere, which it currently isn't, so I'm a little unsure about that one add nativesdk-go TOOLCHAIN_HOST_TASK to get the compiler on the host. did you intend to add the full toolchain to the target as well?
|
|
#
?
Nov 12, 2022 23:53
|
|
|
hobbesmaster posted:x86_64 is everything for the host, it sounds like your target is called corei7-64 so you were using the go installation you created for the target. this is fine in this case. no, just the sdk; target shouldn't be getting any toolchains at all. i'll give that a try soon as wsl2 is done unfucking itself and my cpu/ram usage 
|
|
#
?
Nov 13, 2022 00:03
|
|
|
ok while that runs I'm not really getting what TOOLCHAIN_TARGET_TASK is for, if that's just getting (in this case) the go compiler on the host. How's that different from adding go to IMAGE_INSTALL?
|
|
#
?
Nov 13, 2022 00:12
|
|
|
it sets up what goes in the target’s sysroot in the SDK. the sdk is to develop software for the system, not to recreate it so there’s a lot of stuff you don’t need to include like say bsp startup things
|
|
#
?
Nov 13, 2022 00:26
|
|
|
that part about not including unneeded image stuff in the sdk makes sense but i'm still not really getting the point of having separate host and target sysroots in the sdk. isn't the whole point of the sdk to develop & build applications for the hardware running the sdk's corresponding image? why would i want to build anything for the host, with the host's libraries, and/or whatever else? i'm missing or forgetting something seriously basic & stupid, here, i just know it. about how build toolchains work, or i'm thinking about this all wrong, or not understanding dynamic linking, or something; and it's cheesing me off. i don't want this to just work without understanding why or what i'm doing come on, brain 
Ciaphas fucked around with this message at 00:57 on Nov 13, 2022 |
|
#
?
Nov 13, 2022 00:51
|
|
|
Buildroot is a 2007 Kia Sentra, and Yocto is that car that Homer Simpson designed
|
|
#
?
Nov 13, 2022 00:58
|
|
|
the host and target usually are different architectures. the host sysroot then contains the crosscompiler tools
|
|
#
?
Nov 13, 2022 00:58
|
|
|
hobbesmaster posted:the host and target usually are different architectures. the host sysroot then contains the crosscompiler tools but then why's there a target sysroot in the sdk at all if all the stuff in it's for a wholly different arch? what's it for?
|
|
#
?
Nov 13, 2022 01:01
|
|
|
|
| # ? May 13, 2024 02:28 |
|
|
to link against
|
|
#
?
Nov 13, 2022 01:02
|
|