Chaser has quit [Quit: My Unrecognized Mac has gone to sleep. ZZZzzz…]
Chaser has joined #yocto
CrazyGecko has joined #yocto
jmd has joined #yocto
Chaser has quit [Quit: My Unrecognized Mac has gone to sleep. ZZZzzz…]
Chaser has joined #yocto
CrazyGecko has quit [Remote host closed the connection]
Chaser has quit [Quit: My Unrecognized Mac has gone to sleep. ZZZzzz…]
sotaoverride has quit [Ping timeout: 244 seconds]
sotaoverride has joined #yocto
Kubu_work has joined #yocto
amitk_ has joined #yocto
CrazyGecko has joined #yocto
amitk has quit [Ping timeout: 265 seconds]
jmiehe has joined #yocto
jmiehe has quit [Client Quit]
ablu has quit [Ping timeout: 276 seconds]
ablu has joined #yocto
leon-anavi has joined #yocto
ehussain has joined #yocto
florian has joined #yocto
Chaser has joined #yocto
<JaMa>
mathieudb: I've passed that e-mail about AB warnings in webosose builds to internal people when you sent it, still waiting for reply about the plan for next webosose release (which will probably include switch from kirkstone to scarthgap), but doesn't resolve the warnings yet
ederibaucourt has quit [Quit: ZNC 1.8.2 - https://znc.in]
ederibaucourt has joined #yocto
prabhakalad has quit [Quit: Konversation terminated!]
prabhakalad has joined #yocto
florian__ has joined #yocto
<RP>
JaMa: thanks, I think mathieudb is away this week
sotaoverride has quit [Ping timeout: 244 seconds]
sotaoverride has joined #yocto
ptsneves has quit [Ping timeout: 264 seconds]
<bjdooks>
vmeson: yeah, been trying to get something going but no-one has done riscv big endian before so needs a few things updating
<RP>
bjdooks: it sounds like the kind of thing khem might be interested in
<bjdooks>
if i can't get anything going soon I might put out a request for help
goliath has joined #yocto
<RP>
bjdooks: it is definitely possible but not been done before as far as I know
<bjdooks>
yeah, i've got to the point it is trying to build the kerne
sotaoverride has quit [Ping timeout: 276 seconds]
sotaoverride has joined #yocto
psv has joined #yocto
reatmon_ has quit [Remote host closed the connection]
<RP>
mcfrisk_: I'm a bit lost off with who I should be talking to about beagleplay issues :/
sotaoverride has quit [Ping timeout: 252 seconds]
sotaoverride has joined #yocto
cyxae has joined #yocto
sanbeam has joined #yocto
sanbeam9 has joined #yocto
sanbeam has quit [Ping timeout: 260 seconds]
sanbeam18 has joined #yocto
sanbeam9 has quit [Ping timeout: 260 seconds]
sanbeam9 has joined #yocto
sanbeam has joined #yocto
sanbeam18 has quit [Ping timeout: 276 seconds]
sanbeam9 has quit [Ping timeout: 276 seconds]
sanbeam9 has joined #yocto
<Slimey>
so how do i find this recipe for u-boot and what can i glean from it
miau_miau has joined #yocto
sanbeam has quit [Ping timeout: 248 seconds]
sanbeam18 has joined #yocto
miau_miau has quit [Client Quit]
sanbeam9 has quit [Ping timeout: 260 seconds]
risca has quit [Ping timeout: 272 seconds]
risca has joined #yocto
sanbeam18 has quit [Ping timeout: 248 seconds]
Chaser has quit [Ping timeout: 252 seconds]
Chaser_ has joined #yocto
Knogle has joined #yocto
sotaoverride has quit [Ping timeout: 260 seconds]
sotaoverride has joined #yocto
sanbeam18 has joined #yocto
sanbeam18 has quit [Changing host]
sanbeam18 has joined #yocto
Guest59 has joined #yocto
marka has quit [Read error: Connection reset by peer]
Chaser_ has quit [Quit: My Unrecognized Mac has gone to sleep. ZZZzzz…]
paulg has quit [Ping timeout: 244 seconds]
<Guest59>
Hello! Can someone tell me, how can i bbappend a native recipe? I'm seeing error `configure: error: __cxa_demangle not found in libstdc++, use --disable-demangler to disable demangler support.` for elfutils 0.191 on Ubuntu 22.04 so i wanted to add an bbappend:
<Guest59>
`elfutils_0.191.bbappend` with contents `PACKAGECONFIG += " --disable-demangler "`.
<Guest59>
However:
<Guest59>
a) when i check `bitbake-layers show-appends` it's path is visible there, but in `bitbake -e elfutils-native | less` one cant find `--disable-demangler`
<Guest59>
b) when i tried `devtool modify elfutils-native` -> run configure myself -> `devtool build elfutils-native` it seems to fail to configure again
<Guest59>
c) when i tried to rename the recipe to `elfutils-native_0.191.bbappend` yocto says `No recipes in default available for: path to my bbapend`
<Guest59>
I'd be happy if someone could explain me, how could i fix such items myself, in the future.
marka has joined #yocto
sanbeam9 has joined #yocto
sanbeam18 has quit [Ping timeout: 276 seconds]
<RP>
Guest59: Firstly, PACKAGECONFIG probably isn't the right variable, you probably want EXTRA_OECONF for a specific config option
<Guest59>
right, i'll experiment with it. But that's a second issue, isn't it? guess it should "do" something first?
<RP>
Guest59: secondly you only want to apply this for the native recipe, so something like EXTRA_OECONF:append:class-native = " --disable-demangler" might be more what you're looking for
<Guest59>
hmm, let me quickly try and report back
sanbeam9 has quit [Ping timeout: 276 seconds]
<Guest59>
worked! Thanks. Btw, i've seen in irc chat logs from about 6m ago, you had similar issue. Maybe this is some sort of regression?
<RP>
Guest59: me specifically?
<Guest59>
well, you - were helping - someone else had the ssue ;)
<Guest59>
12:17 <Guest59> NOTE: Tasks Summary: Attempted 806 tasks of which 696 didn't need to be rerun and 1 failed.
<Guest59>
12:18 <Guest59> platform is Ubuntu 18.04, should I upgrade to 22.04?
<Guest59>
12:19 <Xogium> might be worth at least trying
<Guest59>
12:19 <Xogium> using a container or similar at least, to see if it solves the problem
<Guest59>
12:19 <Xogium> but iirc 18.04 is quite long in the tooth by now and might be dropped in the next lts for all I know
<Guest59>
12:19 <Xogium> I'm a total newbie at yocto but
<Guest59>
12:20 <Guest59> container will use the same kernel nbut at least an updated versionn of trhe libraries, t'is true
<Guest59>
12:20 <Xogium> yeah I doubt kernel has got anything to do with this
<Guest59>
12:20 <Guest59> indeed
<Guest59>
12:21 <Guest59> ok will create a 22.04 based container and map the directory, see what happens
<Guest59>
12:21 <Xogium> if it's not solved then there's a real problem indeed
<Guest59>
12:36 <RP> Guest59: have a look in config.log and see what the error really is. It sounds like the demangler test failed but seeing exactly how the test failed may be revealing
<RP>
that is different to the log you linked to!
<Guest59>
sorry, IRC in a browser is slightly confusing
<RP>
I'd try and avoid pasting larger numbers of lines into IRC, links are better, just the right ones :)
<Guest59>
but anyways, he was building in 18.04, version 0.189 so probably not scarthgap
<RP>
the issue does look similar. My question stands - I'd be curious why the demangler test failed
<RP>
if you have that config.log from a failed build it might be revealing
<Guest59>
right, anything longer than this i'll post to pastebin
<Guest59>
after removing bbappend and building from scratch just `bitbake elfutils-native`
<RP>
Guest59: as it says at the end: NOTE: The following config.log files may provide further information. NOTE: /yoc/test/build/tmp-glibc/work/x86_64-linux/elfutils-native/0.191/build/config.log
<Guest59>
`/yoc/test/build/tmp-glibc/hosttools/ld: /tmp/cc70VOyR.o: in function `main':
<Guest59>
conftest.c:(.text.startup+0x9): undefined reference to `gzdirect'` :hmm:
prabhakalad has quit [Ping timeout: 265 seconds]
prabhakalad has joined #yocto
<Guest59>
but then even earlier, cannot link stdcpp, line 770
<RP>
Guest59: /yoc/test/build/tmp-glibc/hosttools/ld: cannot find -lstdc++: No such file or directory
<RP>
Guest59: makes me wonder if you have c++ devel packages installed
* RP
made the mistake of trying to use a go recipe. There are so many problems :(
<RP>
network in compile for example :(
<Guest59>
dpkg -l | grep std
<Guest59>
ii lib32stdc++6 12.3.0-1ubuntu1~22.04 amd64 GNU Standard C++ Library v3 (32 bit Version)
<Guest59>
ii libstdc++-11-dev:amd64 11.4.0-1ubuntu1~22.04 amd64 GNU Standard C++ Library v3 (development files)
<Guest59>
ii libstdc++6:amd64 12.3.0-1ubuntu1~22.04 amd64 GNU Standard C++ Library v3
<Guest59>
ii libstdc++6-arm64-cross 12.3.0-1ubuntu1~22.04cross1 all GNU Standard C++ Library v3 (arm64)
<rfs613>
RP: all the cool kids compile in the cloud on serverless lambda fruitloops ;-)
<rfs613>
(or so I am told... i'm neither cool nor a kid ;-)
<fray>
RP but it's great to download random untraceable things that you can't review for security issues prior to compiling... it just makes it easier
<RP>
Guest59: libstdc++-12-dev missing maybe ?
<rfs613>
the AI will save us from harm, fear not
<zeddii>
RP: my go recipes are unique .. but they don't commit that crime! :)
<RP>
zeddii: I was trying to look into one bug and I'm just hitting failure after failure as the whole thing is just so fragile and broken
<RP>
rfs613: I suspect I'm also in the camp now :)
<rfs613>
RP welcome to the club ;-)
<RP>
zeddii, fray: there is an interesting proposal to rework the fetchers including gomod on the bitbake-devel list. I'm torn on it
druppy has joined #yocto
Knogle has quit [Quit: WeeChat 4.5.1]
<RP>
Gah. It fails, task errors, you rerun the task and it passes
<zeddii>
I read it. didn't actually understand it. I still just like the git ferches.
<Guest59>
RP - right, that fixes it. Apparently it wouldn't it find older even if present.
<RP>
zeddii: I tried to explain it a bit more in my reply in case it helped others. It took me a while to "get" it
<zeddii>
I saw a random lob possibly towards meta-virt in those bitbake series. Something like "hopefully other layers will convert their custom .. .blah.."
* zeddii
answers 'no'
<RP>
Guest59: it is nice to understand why it breaks. I wonder how we detect that...
<RP>
zeddii: having one good fetcher everyone can use would be nice
<zeddii>
they are just too opague.
<zeddii>
opaque. not interested when there's the simple git fetches.
<Guest59>
we could strace linker and see which files it looks for when -lsomelib is passed :thinking:
<RP>
zeddii: that is my worry with the proposal. It is quite clever in that it does translate it all into standard git fetches in the background
<zeddii>
it's the "in the background" I object to, but you already knew that :)
<RP>
Guest59: I guess we should probably add a sanity test that linking with -lstdc++ works
<Guest59>
so Go fetches stuff during compile, how about rust? I guess they also have similar cargo based dynamic package download?
<RP>
zeddii: my feedback on the list earlier today uses the word opaque so I have raised that concern. I probably can't fight this alone though
<RP>
Guest59: our fetcher is supposed to stop it
florian__ has quit [Ping timeout: 264 seconds]
<Guest59>
i see, one blog post writes, its either pinning specific versions or `do_compile[network] = "1"` (well, according to the blog, haven't tested)
<RP>
Guest59: both. I knew compile was trying to fetch as it blew up with failed network access :/
<Guest59>
I though one could have some bb class which would just download dependencies and build them once, but apparently such thing was not foreseen by rust :)
<Guest59>
i meant this, as in do_prepare__something_with_network_for_rust so they could also benefit from rebuilding the app without rebuilding deps
<fray>
I'm waiting for one malicious actor to sabatage something in the cargo downloads like what has happened in python, javascript, etc..
<Guest59>
right, like this node "isodd" ;)
<RP>
fray: these things are kind of inevitable
jmd has left #yocto [ERC 5.4 (IRC client for GNU Emacs 28.2)]
sotaoverride has quit [Ping timeout: 252 seconds]
bigguiness has joined #yocto
sotaoverride has joined #yocto
<bigguiness>
how do I replace the busybox /etc/udhcp/50defaults file? This file is created by busybox.inc from files/simple.script in the busybox recipe. I need to add a leasefail action to the script.
ehussain has quit [Remote host closed the connection]
merit has quit [Remote host closed the connection]
merit has joined #yocto
<rfs613>
bigguiness: looks like 50default is a renamed copy of simple.script, so could you just create your own version of that file in another layer?
<fray>
those are all the baremetal riscv configurations we do
<khem>
fray:for baremetal its managable and I am not too worried, its when we want to establish a Linux Userspace ABI for such combinations and fix tonne of packages to comply
<fray>
I'm already getting questions about this.. people are asking me for configuration combinations similar to what the microblaze allows.. basically a complex TUNE features that produce a severely optimized Linux
<fray>
My suggestion, a base minimal configuration(s) are defined. Then _COMPATIBLE_ options be allowed.. problem comes, I've no idea how to do that
<khem>
looking at what you have infact is fine, you are using it only on rv32 which is not an issue
<fray>
that baremetal stuff includes both 32-bit and 64-bit configs..
<khem>
my reference was more for running a rv64 in ilp32 mode
<fray>
I leave that to whomever is implementing the runtime.. :)
<khem>
yeah you seem to use lp64 and its variants for rv64 and ilp32 and its variants for rv32 so you are good to go
<fray>
well I wouldn't call it "good", but it's acceptable
<fray>
biggest problem I've seen with it, people set the final '--' which is the 'compatible' flag, and then when they run things they manually pass in mcpu arguments to force their own configuration against a specific configuration...
<khem>
only one which is iffy is ilp32e
<fray>
and then ask my why something doesn't work
<khem>
since IIRC thats not ratified fully yet
sotaoverride has quit [Ping timeout: 276 seconds]
<fray>
what needs to be done (for Linux) is the core set be defined, with compatible ones also defined -- but the complexity of this makes it impossible for someone who doesn't intrinscly know the architecture
sotaoverride has joined #yocto
<khem>
yeah hopefully linker is smart enough to send a good diagnostic on such incompatible ABIs being used in final link
<fray>
and I've asked our 'experts' and they basically don't know how to tell me to configure GCC.. since they only know the hardware side.. it's madenning
<khem>
well, you can build gcc once with --enable-multilib and for baremetal it should generate gcc C startup files correctly for all possible ABIs
<khem>
but the way we build toolchains in yocto this might need some thought because we do not allow multiple ABIs
<fray>
the problem is what constitutes an ABI.. i.e. if you have one rv32i and one rv32imf (both ilp32) is the imf one a new ABI, a new multilib, is it compatible, etc? This whole concept is horrible foreign to the hardware engineers I work with
<khem>
although for baremetal this can be relaxed a bit, since it will allow us to use single compiler for all possible ABI combinations
<khem>
first part is cpu capabilities, second part is abi and second part is what you care for when it comes to compiling s/w
<fray>
From a _LINUX_ perspective, it's reasonable to define 'these are the ABIs, you can deviate in this way'. but so far I've not really seen those suggestions.. just some "expectations" from various distribution providers, but nothing points back to a specific risc-v best practice.. more of a "this is how we've done it before, so we're going to keep doing it"
<fray>
anyway, if I can help with anything let me know. At this point I'm focused on baremetal, but I know Linux needs are coming "soon(tm)"
<khem>
MCU performance varies radically when using improper ABIs e.g. if you have a chip supporting floating point, technically you can run ilp32 abi compiled code on it but it will be vastly slower than ilp32f e.g.
<khem>
on fully hosted systems like Linux the performance difference it not much
<fray>
exactly
<khem>
so options are good in this case, provided you know which one is for you :)
<fray>
and circling back, this is why people are asking me for a 'microblaze-like' tunefile solution, and my answer so far is "no, I'm not doing it myself or specific to out parts. Work with the community."
<khem>
I think gcc and clang for that matter as well, are able to support all ABIs in one toolchain
<khem>
I am not including libgloss or other semihosted ABI stuff
<fray>
that's the kind of stuff I'm being asked for, but replace that with the riscv variations
<mischief>
RP: speaking of go, i had a weird bug where i couldn't make a non-CGO binary unless i unset GOROOT even with CGO_ENABLED=0 for some reason.
<khem>
I think this will be neat way to encompass ABIs using tune-features although I can see it will be a complex state machine
<fray>
again happy to help with this. 5 years ago I had to wrangle the diverse microblaze set into something that actually worked and was managable.. I'm happy to help do something like that for risc-v, but I need someone who actually knows the architecture or there is no way it'll be done even halfways correct
<fray>
as you said, need to define ABIs first.. (which may imply word length)... endian (if appropriate) and THEN variations and how they enhance or conflict..
<fray>
i.e. ilp32f should require a floating point unit.. ;)
<mischief>
i ordered a risc-v board but they didn't mail it yet. :-(
<fray>
all the stuff I have to deal with is either a riscv "built" into a SoC as a secondary CPU, or implemented in the FPGA itself. Nothing (so far) has been primarily a risc-v arch part..
<khem>
fray nudge me on that
<khem>
mischief:which one ?
<mischief>
milk-v megrez.
<khem>
mischief: milkv-duo does support yocto but others dont yet
<khem>
I have access to pioneer box
<mischief>
i know, i built the layer for mine :-) but the duo had some problems
<fray>
khem the other thing I would like is a way to take (whatever) the YP tune features become and covert it to the GCC RISCV configuration. So you can specify things in a tune feature and configure GCC to just 'work'
<mischief>
i think some interrupt bug i did not have time to investigate. it was very neat that the layer works with almost vanilla upstream kernel, though
<khem>
fray: I think if multilibs are enabled then all we need is to add the needed options via TOOLCHAIN_OPTIONS or something like that
<khem>
mischief:yeah at this moment we have more h/w issues than s/w :)
<fray>
the problem with the current GCC riscv options, they're completely opaque to someone who doesn't know what 'm' means.. but if 'm' is defined in the YP 'verbose' feature way, then suddenly it might ACTUALLY make sense to me on how to generate teh GCC multilib configs
<mischief>
duo was anemic with (in the original version) 64M memory, so i was hoping the megrez with 32G ddr would be a bit more roomy. but.. they didn't mail it yet and i ordered it when it was announced in late november
<fray>
rv32imafc-ilp32f-- w/o a corresponding verbose version is absolutely useful to anyone but an expert..
<fray>
(but I think i tcan also be used as a reference to how we need to define thing sin the YP context.. i.e. rv32 as an option, ilp32f as the ABI option.. the ilp32f needs to require the 'f'.. but what about imac? Any of those required, optional, what do they mean, etc..
<fray>
absolutely useless not useful.. ;P
sotaover1ide has joined #yocto
<SlimeyX>
mischief i figured out the recipe it was running, how do i see what commands where used to compile the recipe
<mischief>
build/tmp/work/.../temp/log*
<mischief>
(probably, if your yocto is old maybe things changed)
<nerdboy>
so i have a virtualenv for kas and the doc says "machine: key... Can be overwritten by the KAS_MACHINE environment variable"
<nerdboy>
except this doesn't seems to change anything: kas shell layers/meta-user-aa1/kas/sysvinit.yaml -c 'KAS_MACHINE=qemuarm bitbake core-image-minimal'
<nerdboy>
doh! i should probably export that first...