Log of #mupdf at irc.freenode.net.

 <<<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. and12: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 gcc13: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 changes13:58.10 
malc_ avih__: no i mean purely compilation wise... like adding -m32 to the flags13: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 dark14:00.42 
  LLP that is14: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 it14:04.04 
avih__ malc_: mujs doesn't build with this gcc and -m32. afaik for mingw gcc is either strictly 64 or strictly 3214: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__: gotcha14:24.50 
avih__ malc_: but can you expand a bit on this issue you suspected? i don't think i'm familiar with it14: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 DLLs14: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 along14: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 here14: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 there14: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 later14:34.06 
  (do suggest more things to try, if you have such. i'll read them when i get back)14:34.29 
avih testing15: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)>>> 
ghostscript.com #ghostscript