| <<<Back 1 day (to 2021/05/01) | Fwd 1 day (to 2021/05/03)>>> | 20210502 |
avih__ | ator: good news, i can reproduce the unexpected abort with the mujs REPL (on windows). I follows the instructions to setup the ingw env and stopped after building gcc, then built only mujs, and then at the REPL, i enter some unknown symbol, like foo, then press enter - an the REPL aborts without messages. in contrast, with my owm mujs win32 binary it just prints a reference error message. so now i can start playing with the flags, optimizations, etc. and | 12:55.09 |
| i'm glad it's not a bug in mpv ;) | 12:55.09 |
| for reference, that's the build repo https://github.com/shinchiro/mpv-winbuild-cmake/ | 12:55.39 |
| disabling optimizations doesn't help (make clean && CC=... make HAVE_READLINE=no XCFLAGS=-O0) | 13:21.51 |
| i even tried going back to mujs 1.0.8 (2020-08) and i still get the same issue. i have a feeling this gcc is broken in some way, or mujs has some issue which only manifests with this gcc | 13:22.48 |
| ator: however, all other packages built with the same gcc seem to be fine, including lua which also makes use of longjmp (see the vast list of packages built at the link i posted). | 13:31.28 |
| i'm a bit lost on how to make progress... | 13:31.38 |
| for reference, gcc --version prints "x86_64-w64-mingw32-gcc (GCC) 10.2.1 20210403", and mingw seem to be master: "7faa2f34 (HEAD) crt: Generate libfeclient.a for x86. 2021-04-03" | 13:41.11 |
| (the mingw toolchain is built from source) | 13:41.52 |
malc_ | avih__: have you tried eliminating LLP64 (win64) as a source of the problem? | 13:57.00 |
avih__ | malc_: didn't try touching the source yet. if you have a patch i could try it out, otherwise i don't know hot to translate this suggestion into concrete code changes | 13:58.10 |
malc_ | avih__: no i mean purely compilation wise... like adding -m32 to the flags | 13:58.45 |
avih__ | wouldn't that built a 32bit binary? (sorry, not well versed with gcc build options) | 13:59.23 |
malc_ | avih__: yes. it would, that's the point. win64 is unique in using LLP ABI and that might be the source of the problem, just a shot in the dark | 14:00.42 |
| LLP that is | 14:01.18 |
avih__ | so you think the x86-64 gcc will be able to generate a 32 bit build? in my experience it wouldn't be the case. do you know otehrwise? | 14:01.37 |
malc_ | i can't tell for win64 but on all my 64bit machines (arm, ppc and amd) it was always able to do it | 14:04.04 |
avih__ | malc_: mujs doesn't build with this gcc and -m32. afaik for mingw gcc is either strictly 64 or strictly 32 | 14:21.34 |
malc_ | avih__: okay, out of curiosity what's the failure? | 14:22.25 |
avih__ | (and there's an option at the build scripts to build a 32 bit mingw gcc, but it takes about 20 minutes to build it, so for now i'm not attempting it) | 14:22.27 |
| malc_: seemingly missing libc symbols on linkage, like: x86_64-w64-mingw32/bin/ld: build/release main.o:main.c:(.text+0x76b): undefined reference to `_free' | 14:23.59 |
| (long list of similarly missing symbols) | 14:24.45 |
malc_ | avih__: gotcha | 14:24.50 |
avih__ | malc_: but can you expand a bit on this issue you suspected? i don't think i'm familiar with it | 14:26.50 |
| (but i do have access to 32 bit build of mpv from the same origin, i could test it out, but so far for my experiments i've only build mingw gcc and mujs. building mpv requires building a lot more deps) | 14:28.13 |
malc_ | avih__: win64 adopted llp64 abi, to ease porting subtly broken win32 applications presumably, not many other systems opted to use this model (long = 32bit, pointer's and long longs = 64) | 14:29.36 |
avih__ | malc_: isn't this needed for compatibility with windows DLLs? | 14:30.27 |
malc_ | avih__: personally i found mpv builds to be relatively painless (once you have built ffmpeg that is) | 14:30.48 |
avih__ | i.e. i don't think it had any other real choice unless you're never going to use windows DLLs | 14:30.59 |
malc_ | avih__: you don't have a choice it's a system abi... you can use 32bit one though which is there all along | 14:31.40 |
avih__ | yeah, i maintain a repo for ease building mpv. i'm fairly aware of what it takes. but in this case the issue is already apparent at mujs alone regardless of mpv, so there's no need for mpv here | 14:31.55 |
| but i could try a pre-built 32 bit mpv from the same source, which i assume if it's indeed the issue you suspect then the mujs issue would not exist there | 14:32.44 |
| (i maintain js/mujs in mpv, so it's basically on me to figure it out) | 14:33.33 |
| anyway, be back a bit later | 14:34.06 |
| (do suggest more things to try, if you have such. i'll read them when i get back) | 14:34.29 |
avih | testing | 15:26.23 |
avih__ | good (sorry, had connection issues...) | 15:26.46 |
| <<<Back 1 day (to 2021/05/01) | Forward 1 day (to 2021/05/03)>>> | |