|
rebuild finished, went into a container, installed the sdk, sourced the environment-setup, and now `make` isn't there anymore  e: hobbesmaster posted:to link against 
Ciaphas fucked around with this message at 01:13 on Nov 13, 2022 |
#
?
Nov 13, 2022 01:05
|
|
|
|
| # ? Apr 26, 2024 04:47 |
|
|
Poopernickel posted:Buildroot is a 2007 Kia Sentra, and Yocto is that car that Homer Simpson designed Buildroot is a 2022 Kia Sentra. 
|
|
#
?
Nov 13, 2022 01:08
|
|
|
When you build the SDK, it spits out a self-extracting installer. You can give it to other devs who want to write code for your system, but don't want to gently caress around with Yocto. The SDK gets the compiler, headers/static/dynamic libs that match what goes into your target image, and also anything else you add to TOOLCHAIN_TARGET_TASK.
|
|
#
?
Nov 13, 2022 01:09
|
|
|
hobbesmaster posted:to link against or to qemu with
|
|
#
?
Nov 13, 2022 01:09
|
|
|
Poopernickel posted:When you build the SDK, it spits out a self-extracting installer. You can give it to other devs who want to write code for your system, but don't want to gently caress around with Yocto. yeah i wasn't getting - somehow - that the toolchains build apps using the target's set of libraries, but those libraries are not* the same set of libraries that lets the toolchains actually run in the first goddamn place * necessarily Ciaphas fucked around with this message at 01:20 on Nov 13, 2022 |
|
#
?
Nov 13, 2022 01:17
|
|
|
go commands work in the sdk now, but when i try and actually build the app this is all for, it can't get & install any of the deps like gomockcode:
|
|
#
?
Nov 13, 2022 01:40
|
|
|
this is all a massive loving waste of time and sanity, isn't it? can't I just not put go in the sdk, and instead install it as part of the dockerfile that builds the container the sdk is installed in?
|
|
#
?
Nov 13, 2022 01:54
|
|
|
what exactly are you trying to do? do you think you can “just” use a recipe like this and not bother with the SDK? https://blog.gopheracademy.com/advent-2015/go-in-a-yocto-project/ or do you need this go environment to be installable? the bitbake class that article is referring to is built in. (look in meta/class) I remember helping a couple customers set up go for the armv5 routers at my last job but all my language specific yocto memories right now are taken up by the butcher job they did on python
|
|
#
?
Nov 13, 2022 02:02
|
|
|
nudgenudgetilt posted:yocto. not even once.
|
|
#
?
Nov 13, 2022 02:08
|
|
|
let me go over the problem this all started with that we're actually trying to solve, in case someone sees i reached a really stupid conclusion for fixing it: - we have an app written in Go, with a smattering of C built by CGo, that runs on the target device - said target device runs some kinda intel processor, at least at this time; no idea if it'll stay that way in the future but i'm guessing it will - originally we were building our target image & SDK from Yocto 3.something. it didn't include golang, that came from `FROM golang-1.19` at the top of the sdk container's dockerfile. this was apparently working fine - recently, before i got involved, we started trying to build from Yocto 4.0.4 instead, to get a whole bunch of dependencies updated all at once - our Go app could still build, but testing no longer worked - generating mocks started breaking down with errors about GLIBC_2.32. i don't have the exact message in front of me rn, but it specifically only happened on those mocks - specifically the ones needing CGo, a coworker thinks - we tried dicking around in the sdk container with ldconfig, symlinks from /poky, etc. etc - results ranged from "didn't help" to "not even ls runs anymore" - i thought, maybe trying to use go from a stock docker image to build for our targets only worked by library versions coincidentally lining up before the yocto upgrade, and we couldn't just use the go distribution from the stock docker go-1.19 base image anymore - and so i started this misadventure with trying to add go to the image recipe's IMAGE_INSTALL. which did install go, but yocto 4.0.4's go is at 1.17, and the team needs 1.19 - finally, figuring out upgrading that is where I came into the thread yesterday fast forward to today where i'm just plain mad at everything but especially despairing at myself Ciaphas fucked around with this message at 02:18 on Nov 13, 2022 |
|
#
?
Nov 13, 2022 02:14
|
|
|
yes we get it thank you
|
|
#
?
Nov 13, 2022 02:14
|
|
|
i'm confused, what's the output artifact of the yocto build? a container image? half a container image? a disk image that gets slapped in a container and loopback mounted?
|
|
#
?
Nov 13, 2022 03:26
|
|
|
a squashfs for the target machines*, and a sdk .sh for the devs * there's some Magic i don't understand going on, to do with some kind of initramfs thing, but the end result is the squashfs is essentially mounted to / on the target machine at boot. don't think it's strictly relevant to my problem Ciaphas fucked around with this message at 03:36 on Nov 13, 2022 |
|
#
?
Nov 13, 2022 03:32
|
|
|
idk if this'll help even a little but here's the original error from the failing software build that set me off on this whole stupid misadventurecode:
|
|
#
?
Nov 13, 2022 03:49
|
|
|
quote:/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32 it’s looking for the host libc, not the target’s I’m not familiar enough with typical go builds but you’re calling make so I’m guessing there was a configure script run that picked up go in the sysroot but not the cross CC
|
|
#
?
Nov 13, 2022 04:04
|
|
|
Ciaphas posted:idk if this'll help even a little but here's the original error from the failing software build that set me off on this whole stupid misadventure glibc errors always suck, regardless of build system this might help? https://utcc.utoronto.ca/~cks/space/blog/programming/GoAndGlibcVersioning
|
|
#
?
Nov 13, 2022 04:10
|
|
|
Good lord. Everytime I see someone seek help for Yocto I am glad I chose Buildroot as my embedded Linux BSP of choice. Want an SDK? “make sdk” want to rebuild a package? “make $pkg_name-reconfigure” Yeah, it’s not as powerful as Yocto and doesn’t build a distribution (Buildroot is a firmware generator not a distribution builder) but it works quite well and I will never willingly choose Yocto over Buildroot. 
|
|
#
?
Nov 13, 2022 04:52
|
|
|
i think the final answer is that the docker image i'm installing the sdk in has to be changed to use a glibc version >= the target image's glibc, without regard for the glibc installed in the SDK's host or target sysroots this is because - and maybe this was obvious, but it's only now becoming clear to my addled-rear end mind - our go project builds things that run as part of the build; stuff like mockgen, but also the stuff compiled by `go test` because of us needing CGo support. so end result is our build container, on glibc 2.31, builds these intermediaries targeting glibc 2.35 to match the target hardware, then tries to run these programs made for a newer glibc while running off the older glibc - with the results you'd expect what I'd been misunderstanding is, I thought sourcing the poky environment setup also swapped out the host (the build container)'s active glibc with the one in the poky sysroot - which is evidently not actually the case. idk if that's expected behavior or if we've got something misconfigured somewhere; but frankly now that i understand the real problem, I don't actually care anymore now i just gotta find a container in docker.io with glibc 2.35 and go 1.19, use that instead of golang:1.19, and the problem's solved. (put that way, the whole problem seems so goddamn obvious in retrospect...  )(e) can i shoot the devs for using a mock generator or is that just normal nowadays Ciaphas fucked around with this message at 10:08 on Nov 15, 2022 |
|
#
?
Nov 15, 2022 10:03
|
|
|
can this be thread you bump every time you’re hosed by the sstate-cache? because… yeah
|
|
#
?
Mar 23, 2023 03:19
|
|
|
hobbesmaster posted:can this be thread you bump every time you’re hosed by the sstate-cache? because… yeah Absolutely.
|
|
#
?
Mar 23, 2023 04:37
|
|
|
Embedded with a display is surprisingly an incredibly underserved market considering the number of tiny screens out there. I hate all the options. I want Electron in an embedded image with easy updates. Somehow after many years of existence this still isn’t a thing. At the Yocto level there is embedded WebKit, which by name is gimped and missing the NodeJS stack. At higher levels, Ubuntu Core doesn’t seem to have any packages that can use the GPU and is all a proprietary soup of Snap packages. Fedora IoT doesn’t seem to have any X11 support, hopefully is better in the upcoming 38 release. Fedora Silverblue has all gimped packages with no GPU support too. Flatpak on Ubuntu Core can use the GPU, but obviously Ubuntu want to completely fix that by removing support for Flatpak. Apparently third party packages Firefox on Silverblue supports the GPU though. Embedded platform + immutability + GPU = 💩 It is even worse than normal because you cannot really run in a VM because all the VM vendor GPUs are blacklisted due to a plethora of bugs and bad support. MrMoo fucked around with this message at 00:08 on Mar 27, 2023 |
|
#
?
Mar 27, 2023 00:03
|
|
|
what general type of hardware?
|
|
#
?
Mar 27, 2023 00:27
|
|
|
MrMoo posted:Embedded with a display is surprisingly an incredibly underserved market considering the number of tiny screens out there. I hate all the options. the last thing anything embedded needs is javascript
|
|
#
?
Mar 27, 2023 00:29
|
|
|
Shaggar posted:the last thing anything embedded needs is javascript lol if JavaScript is the worst thing you can think of to ship in 2023
|
|
#
?
Mar 27, 2023 00:35
|
|
|
it litterrally is
|
|
#
?
Mar 27, 2023 00:37
|
|
|
unless you're separating javascript from its underlying tooling/runtimes in which case yes those are worse
|
|
#
?
Mar 27, 2023 00:38
|
|
|
I got electron running ok on a yocto build. the key is kind of bypassing yocto for the electron build part (although someone with more time and brains than me could do it). Run electron builder in your recipe for the linux-arm64 arch and it'll pick up the right prebuilds, and it's version controlled up to hash locking via language package control files like yarn.lock or whatever. The pain was getting it to play nicely with appropriate mesa stuff but you can now get it to run on wayland and so on with appropriate flags
|
|
#
?
Mar 27, 2023 00:40
|
|
|
Shaggar posted:it litterrally is use more imagination
|
|
#
?
Mar 27, 2023 00:43
|
|
|
IMO there's in general tension between modern language setups that do their own dependency management and system builders like yocto or buildroot. i think i might have talked about it before in here. like whatever your opinions on the js ecosystem or the python ecosystem, there are language-native tools that your application developers expect to use that do things like separated "what version will i allow automated updates for and expect a minimal level of oversight to tolerate" (roughly the same as whether you'd be comfortable pulling upstream buildroot or some yocto layer) and "in a given build, use exactly these package versions by hash" (what you get in a given buildroot or yocto build). the only solution is for yocto or buildroot to ingest those tools' specification files but I think nobody wants to deal with that because it's still not _that_ common
|
|
#
?
Mar 27, 2023 00:43
|
|
|
this page doesnt even load, but whatever it is its not worse than javascript
|
|
#
?
Mar 27, 2023 00:44
|
|
|
ye it is
|
|
#
?
Mar 27, 2023 00:44
|
|
|
I choose to believe the page did load and shaggar’s mind is unable to process it
|
|
#
?
Mar 27, 2023 00:46
|
|
|
adobe air is litterrally javascript
|
|
#
?
Mar 27, 2023 00:48
|
|
|
Like adobe air is probably better than electron because its out of date and hasnt caught up to all the latest web "developer" abominations
|
|
#
?
Mar 27, 2023 00:51
|
|
|
Yeah, the generally accepted best practice for UI is QT QML
|
|
#
?
Mar 27, 2023 00:52
|
|
|
emuelec seems to be some kind of custom debian
|
|
#
?
Mar 27, 2023 00:53
|
|
|
Shaggar posted:adobe air is litterrally javascript as well as..
|
|
#
?
Mar 27, 2023 00:54
|
|
|
Also, Buildroot LTS 2023.02 is out with QT6!
|
|
#
?
Mar 27, 2023 00:55
|
|
|
Shaggar posted:this page doesnt even load, but whatever it is its not worse than javascript lol it does load it's flash. in 2023 quote:HARMAN also provide enterprise support for the Adobe Flash Player. Following the 'end of life' of the Adobe deployment at the end of 2020, and the removal of the Flash Player deployments in Windows by Microsoft, HARMAN are still able to provide updated versions of the Flash Player, version 50.0, to enterprse customers under special license terms. cheerpx vm 
|
|
#
?
Mar 27, 2023 00:57
|
|
|
|
| # ? Apr 26, 2024 04:47 |
|
|
why did harman kardon take over flash development lol
|
|
#
?
Mar 27, 2023 00:59
|
|