|
Welcome to the main channel on the development of MoarVM, a virtual machine for NQP and Rakudo (moarvm.org). This channel is being logged for historical purposes. Set by lizmat on 24 May 2021. |
|||
| ugexe | im gonna try and install a new build of windows 11 arm and see if that somehow fixes it. luckily VMWare fusion now has a single click thing to download and install windows 11 arm | 00:24 | |
| hmm i wonder if i had installed stuff on the x86 toolchain even though it was windows arm | 02:31 | ||
| i know im using the arm toolchain this time and i cant even install 2023.04 due to libatomicops not supporting this architecture (which lends itself to the theory i was using x86 toolchain before) | 02:33 | ||
| it does look like there might be some changes to upstream libatomicop related to windows specific arm stuff | 02:37 | ||
|
02:50
discord-raku-bot left,
discord-raku-bot joined
|
|||
| ugexe | if i just switch to using upstream v7.8.0 (since merging into the MoarVM/atomic_ops has a bunch of conflicts) it at least compiles further | 02:56 | |
| but now dyncall is failing presumably because it think im on x86. which i think might be because strawberry perl is x86 only still (and we get the architecture from perl for some build things) | 02:57 | ||
| hmm, it looks like the latest version of dyncall has additional arm64 options as well | 03:11 | ||
| it looks like it might be worth looking at updating both dyncall and libatomic_ops | 03:12 | ||
| MasterDuke | i don't think libatomic_ops is actually required if you have a new enough compiler? wasn't it made part of the c11 spec? | 03:49 | |
| right. what if you pass the `--c11-atomics` option to Configure.pl? | 03:50 | ||
| we're using dyncall v1.1, looks like v1.4 is the newest | 04:01 | ||
| ugexe | i was just looking at the c11 atomics actually | 04:11 | |
| but it seems like build/Makefile.in still includes the paths to libatomicops | |||
| MasterDuke | huh. if you remove them? | 04:12 | |
| ugexe | pastebin.com/raw/rMwU60Pz that is what my Makefile looks like. I'm not seeing where all the other "atomic" references would be coming from in Makefile.in though | 04:15 | |
| MasterDuke | yeah... | 04:19 | |
| ugexe | if i delete all the atomic ops references in there it then errors at github.com/MoarVM/MoarVM/blob/62c7...moar.h#L75 | ||
| pastebin.com/raw/Kn2LMdn5 | |||
| MasterDuke | but that should only be hit if you didn't do `--c11-atomics`? | 04:20 | |
| ugexe | rakubrew build moar-blead --configure-options="--gen-moar=HEAD --c11-atomics" | 04:21 | |
| that is what i used | |||
| but i think it is supposed to be enabled by default now anyway | |||
| MasterDuke | no, it's not the default | 04:22 | |
| don't you need something like `--moar-options=--c11-atomics`? | |||
| i don't konw rakubrew | |||
| oh, you were explicitly building moarvm | 04:23 | ||
| no, --gen-moar is an nqp/rakudo option... | |||
| ugexe | yeah i think you're right. and looking at HEAD I see indeed it isn't the default anymore | 04:24 | |
| pastebin.com/raw/Ve0BdEXQ | 04:34 | ||
| devblogs.microsoft.com/cppblog/c11...preview-2/ | 04:36 | ||
| the probe doesn't find it. that output (with --c11-atomics) makes it seem like maybe it some unfinished version of c11 atomic support from that blog? | |||
| pastebin.com/raw/qxjmZnXM this is the vcruntime_c11_stdatomic.h file from the error | 04:38 | ||
| MasterDuke | ugh. windows... | 04:45 | |
| well, i gotta get some sleep. later... | 04:46 | ||
| Geth | MoarVM: ugexe++ created pull request #1774: Enable c11 atomics on msvc 17.8+ |
06:57 | |
| ugexe | dunno if that'll break msvc older than 17.8+, but CI should show that | ||
|
07:04
xiaomiao left,
xiaomiao joined
|
|||
| ugexe | i think dyncall will have to be updated before i can progress any further | 07:10 | |
|
08:27
samcv left,
samcv joined
09:39
sena_kun joined
10:59
sena_kun left
13:04
Util left,
Util joined
|
|||
| ugexe | How would we make github.com/MoarVM/MoarVM/blob/62c7...up.pm#L420 use 'armasm64' if using an ARM architecture? | 13:53 | |
| the current entry, ml / ml64, is x86 only | 13:54 | ||
|
14:45
sena_kun joined
|
|||
| ugexe | Is there anything special about MoarVM/dyncall or is it just a direct copy of the dyncall svn? | 16:06 | |
|
16:35
jgaz left
|
|||
| MasterDuke | the last couple commits related to 3rdparty/dyncall say they're just updating to upstream revisions with no local changes | 16:47 | |
| e.g., a1a187f003ca85929d4a1485d89cf372d782dc7d | 16:48 | ||
|
17:22
xiaomiao left
17:26
xiaomiao joined
|
|||
| ugexe | i haven't had any luck trying to update it :( | 17:48 | |
| it'd be nice if MoarVM/dyncall had a github action to automatically mirror the dyncall hg repo, and then have dependabot send updates for the moarvm dyncall submodule | |||
| that wouldnt work if we have custom changes though | 17:50 | ||
|
17:51
xiaomiao left
18:03
xiaomiao joined
|
|||
| patrickb | we don't. It's a 1:1 copy. | 18:33 | |
| MasterDuke | ugexe: you mean updating dyncall doesn't fix building on windows arm? or you haven't been able to actually update dyncall? | 19:02 | |
| ugexe | I haven't been able to update it, but i was trying to merge the changes (resulting in lots of conflicts) instead of just cloning it (which it sounds like i could do) | 19:03 | |
| github.com/ugexe/dyncall I created a GitHub action in this repo that mirrors the dyncall mercurial repo on a schedule. Maybe we should use it for MoarVM/dyncall | 19:04 | ||
| it retains all the release tags and everything | |||
| MasterDuke | i just built with dyncall 1.4 | 19:09 | |
| ugexe | nice, its probably worth pushing | 19:12 | |
| nine | Does libffi work instead of dyncall? | 19:23 | |
| --c11-atomics should have become default years ago. I e.g. have built the openSUSE packages with that enabled for at least 2 years. | 19:24 | ||
| ugexe | it is the default if the probe succeeds | 19:27 | |
| nine | IIRC libffi also would be a better default than dyncall. It has better platform support and AFAIK no downsides | ||
| ugexe | there is nothing built into the build system for building with libffi is there? afaik i would have to figure out how to build and install libffi first | 19:36 | |
| which, on this somewhat rare ARM Windows, almost certainly means more pain | 19:37 | ||
| nine | Yeash, looks like it does support Windows on ARM, but has to be built from source in general | 19:42 | |
| ugexe | after updating dyncall to 1.4 i get a little further but it still doesnt quite work even when i set the asm compiler to armasm64. i guess i'll have to try libffi | 20:32 | |
| i tried, but i dont think i'm going to end up figuring out how to build libffi on windows. i followed their instructions but i dont think they are quite valid for windows | 20:53 | ||
| i was hoping i could just install it with winget or chocolatey, but nope | 21:03 | ||
|
23:32
sena_kun left
|
|||