| | <<<Back 1 day (to 2020/10/20) | Fwd 1 day (to 2020/10/22)>>> | 20201021 |
| kofm | Hello, is it normal that clipboard function does not work with mupdf-gl 1.18 on MacOSX? | 08:02.21 |
| | Tried both the Homebew formula and building from source | 08:05.45 |
| user38 | Greetings! | 08:10.30 |
| | Good news everyone!, changing CMS_PTR_ALIGNMENT to 8 in thirdparty/lcms2/src/lcms2_internal.h makes 32-bit mupdf-x11 and mupdf-gl work on the sparc platform. | 08:12.06 |
| kens | user38 good morning, thanks for the update, I expect Robin will make some changes to integrate that | 08:14.01 |
| | Its a little early for either Robin or Tor to be about | 08:14.45 |
| user38 | I'll have to clean up my Solaris patches some more, and send them those in a separate bug. | 08:18.12 |
| | s/them/him/ | 08:18.25 |
| kens | I'm sure they'll be happy to have anything you can give them. | 08:21.55 |
| user38 | I'm all too happy toi provide. | 08:43.18 |
| | s/toi/to/ | 08:43.23 |
| chrisl | user38: That's a relief - as promised, I fired up my SPARC box this morning, and found I needed to update to a newer GNU make. Part way through that, it *looks* like the hdd has died :-( | 09:22.21 |
| chrisl | wonders if an ssd is a possibility...... | 09:23.53 |
| Robin_Watts_ | user38: Thanks. | 09:38.29 |
| | chrisl: Crap. | 09:38.34 |
| | chrisl: Is the sparc hd PATA or SATA? | 09:38.47 |
| chrisl | Hah! Fibre Channel | 09:38.59 |
| Robin_Watts_ | reckons an SSD is a stretch then :) | 09:39.35 |
| chrisl | Probably. I shall do some research. ISTR that HP or IBM did FC SSDs for some of their big iron hardware.... | 09:40.50 |
| Robin_Watts_ | https://www.techbuyer.com/005-049184-fc-emc-100gb-fibre-channel-solid-state-drive-ssd-17887 | 09:41.23 |
| chrisl | "Refurbished"?? :-) | 09:42.01 |
| Robin_Watts_ | https://scsishop.co.uk/product-category/data-storage/fibre-channel-40-pin-disks/ | 09:43.28 |
| | What size do you need? | 09:43.49 |
| chrisl | I guess 100Gb or more would be plenty | 09:44.18 |
| | There's a few on ebay - I'll grab one of those, and experiment | 09:45.54 |
| | And I still have my Ultra60, but it has an old Debian version on it, rather than Solaris | 09:46.39 |
| kofm | Hi everybody :) Is there a way to get help on mupdf for a complete noob? I mean, is this channel for users help or developers only? | 09:47.03 |
| chrisl | kofm: it won't do any harm to ask... | 09:49.20 |
| kofm | I don't want to keep bothering you here if this is not the right place. If instead it is just a matter of waiting for someone to have time and willingness to help | 09:49.39 |
| | Okay :) Thanks | 09:49.49 |
| | I can't get to work the clipboard on MacOS | 09:50.01 |
| | tried both with the Homebrew formula and compiling myself | 09:50.16 |
| Robin_Watts_ | kofm: You are using mupdf-gl or mupdf-x11 ? | 09:50.38 |
| kofm | everything is fine except when i run mupdf-gl i get This version of MuPDF has been built WITHOUT clipboard or unicode input support! | 09:50.51 |
| | mupdf-gl | 09:50.56 |
| Robin_Watts_ | right. | 09:51.00 |
| kofm | I also tried to install freeglut | 09:51.24 |
| Robin_Watts_ | kofm: Our codebase doesn't contain the words "without clipboard" | 09:52.07 |
| | wait... look in the right source tree... | 09:52.30 |
| kofm | I'm using git://git.ghostscript.com/mupdf.git | 09:52.56 |
| Robin_Watts_ | #if defined(FREEGLUT) && (GLUT_API_VERSION >= 6) | 09:53.02 |
| | glutKeyboardExtFunc(on_keyboard); | 09:53.02 |
| | #else | 09:53.02 |
| | fz_warn(ctx, "This version of MuPDF has been built WITHOUT clipboard or unicode input support!"); | 09:53.02 |
| | So you need to have freeglut with GLUT_API_VERSION >=6 | 09:53.28 |
| | kofm: Did you clone that with --recursive ? | 09:53.48 |
| kofm | I'm afraid not | 09:54.18 |
| Robin_Watts_ | kofm: OK, so do: | 09:54.24 |
| | git submodule update --init | 09:54.30 |
| kofm | Yep i did that | 09:54.47 |
| Robin_Watts_ | That'll make you local copies of all the libraries we need, including freeglut. | 09:54.50 |
| kofm | after cloning | 09:54.52 |
| Robin_Watts_ | right. | 09:54.56 |
| | So you should have thirdparty/freeglut ? | 09:55.05 |
| kofm | Yes, I have | 09:55.21 |
| Robin_Watts_ | And what make command are you using? | 09:55.50 |
| kofm | sudo make prefix=/usr/local install | 09:56.09 |
| Robin_Watts_ | OK. make clean, then: | 09:57.59 |
| | make verbose=yes >& log | 09:58.21 |
| | Then email me the log. robin.watts@artifex.com | 09:58.35 |
| kofm | Okay, I'll do it now. I do not know how to thank you! | 09:59.04 |
| | Can I make without install to not override the actual installation? | 09:59.59 |
| | Sorry, stupid question :D | 10:05.16 |
| chrisl | Robin_Watts_: Does mupdf allow C99 stuff (like inline variable declarations)? | 10:05.40 |
| Robin_Watts_ | chrisl: no. | 10:08.27 |
| | kofm: Yes. | 10:08.36 |
| kofm | Robin_Watts_: I sent you the logs | 10:08.50 |
| Robin_Watts_ | kofm: When the make completes, you should be left with the binaries in build/release/ | 10:08.59 |
| chrisl | Robin_Watts_: "source/fitz/xmltext-device.c:296: error: ‘for’ loop initial declarations are only allowed in C99 mode" | 10:09.43 |
| Robin_Watts_ | kofm: They've not arrived yet. | 10:09.43 |
| | chrisl: crap. I thought cgdae had fixed all those. | 10:10.06 |
| chrisl | That seems to be the only remaining one | 10:10.29 |
| Robin_Watts_ | Ta. I'll get a fix for that in in a bit. | 10:10.54 |
| kofm | Robin_Watts_: yes i've binaries in build/release folder. mupdf-gl still returns the error | 10:11.13 |
| Robin_Watts_ | kofm: Ah, ok, so on macos, the makefile forces it to use the system version of freeglut. | 10:12.36 |
| | rather than the version we supply. | 10:12.57 |
| | I'm not a mac user, so I can't easily test why. I assume there was a reason. | 10:13.28 |
| kofm | Do you think there's any workaround? Like e.g. updating my system version of freeglut? | 10:14.41 |
| | Or try to force the use of the supplied version? | 10:15.03 |
| Robin_Watts_ | kofm: Well, in Makerules... search for SYS_GLUT_CFLAGS | 10:15.55 |
| | and the line after it, SYS_GLUT_LIBS | 10:16.19 |
| | Those should be in an else ifeq ($(OS),MACOS) section. | 10:16.39 |
| | comment those 2 lines out (start the lines with #) | 10:16.52 |
| kofm | yep i've found them | 10:16.56 |
| Robin_Watts_ | Then in Makethird near the top there is another MACOS section that sets USE_SYSTEM_GLUT := yes | 10:17.27 |
| | comment that line out. | 10:17.32 |
| | Then make clean && make verbose=yes and let's see what happens. | 10:17.46 |
| kofm | returns this error: | 10:21.25 |
| | thirdparty/freeglut/src/x11/fg_internal_x11.h:36:10: fatal error: 'GL/glx.h' file not found | 10:21.34 |
| | #include <GL/glx.h> | 10:21.35 |
| | ^~~~~~~~~~ | 10:21.35 |
| | 1 error generated. | 10:21.35 |
| | make: *** [build/release/thirdparty/freeglut/src/fg_callbacks.o] Error 1 | 10:21.35 |
| | Robin_Watts_: also some warnings like this one -> platform/gl/gl-main.c:2202:13: warning: 'glutGet' is deprecated: first deprecated in macOS 10.9 - OpenGL API deprecated. | 10:23.12 |
| | (Define GL_SILENCE_DEPRECATION to silence these warnings) [-Wdeprecated-declarations] | 10:23.12 |
| | screen_w = glutGet(GLUT_SCREEN_WIDTH) - SCREEN_FURNITURE_W; | 10:23.12 |
| Robin_Watts_ | kofm: Ok, so the guy you really need to talk to this is ator, but he's away today. | 10:39.07 |
| | That sounds like it's looking for some opengl headers. | 10:39.37 |
| | according to google, replacing #include <GL/...> with #include <OpenGL/...> might get you further. | 10:40.14 |
| user38 | Robin_Watts, now that mupdf-gl is working, it emits the following: | 10:49.44 |
| | GLUT warning: fgInitGL2: fghGenBuffers is NULL | 10:49.54 |
| | warning: OpenGL implementation does not support non-power of two texture sizes | 10:50.06 |
| | ...is that anything that needs to be addressed? | 10:50.29 |
| Robin_Watts_ | user38: Not by me :) | 10:53.57 |
| user38 | Robin_Watts: presumably those messages are harmless, since the software appears to work, although to be thorough, I will recompile 64-bit and also 32- and 64-bit on the i86pc platform to perform regression testing. | 10:55.24 |
| Robin_Watts_ | D'Oh. user38. Sorry, was getting you confused with kofm, cos of the GL stuff :) | 10:56.35 |
| | user38: Great to know that that solved stuff for you. | 10:57.12 |
| user38 | Robin_Watts that's a different issue, unrelated :) | 10:57.14 |
| kofm | Robin_Watts_: still not working for me :) (changing GL to OpenGL) | 10:57.32 |
| Robin_Watts_ | user38: The GL problems are one for ator, not for me though. | 10:57.49 |
| chrisl | user38: It *probably* just means you're not getting all/any of the hardware acceleration - which isn't surprising on SPARC hardware! | 10:58.02 |
| Robin_Watts_ | I am slightly unhappy with the current fix that I have for the sparc issues. | 10:59.21 |
| user38 | chrisl: well, it would depend on the sparc hardware, for some of those workstations have (for that time) very high-end Nvidia and Raptor graphics accelerators. The sparc platform was one of the earliest platforms to get 3D acceleration, right after SGI and before the PC-bucket. | 10:59.50 |
| Robin_Watts_ | The actual fix (of aligning stuff) is fine, but I'm looking for some way to know whether I should align or not. | 10:59.59 |
| | Currently I'm aligning stuff on amd64 too, when I don't need to. | 11:00.30 |
| user38 | chrisl: in my case though, there is no graphics hardware at all in my T2000 development system. It's a headless server in a rack. | 11:00.37 |
| Robin_Watts_ | I'm slightly reluctant to make amd64 pad just to fix sparc. | 11:00.56 |
| | I am more likely to use a #ifdef SPARC thing (or similar). | 11:01.14 |
| chrisl | user38: Yes, but expecting modern software to integrate with 20 year old hardware... I wouldn't expect that to (fully) work.... | 11:01.17 |
| user38 | Robin_Watts, I already took that into account! | 11:01.22 |
| | chrisl: seems to work though! :D | 11:01.40 |
| | Robin_Watts, my patch looks like this: | 11:02.05 |
| | +# if defined (sun) && defined (__SVR4) | 11:03.01 |
| | +# define CMS_PTR_ALIGNMENT 8 | 11:03.14 |
| | +# else | 11:03.28 |
| | +# define CMS_PTR_ALIGNMENT sizeof(void *) | 11:03.38 |
| Robin_Watts_ | user38: right. | 11:03.46 |
| user38 | +# endif | 11:03.50 |
| chrisl | Robin_Watts_: mupdf uses memory pools for some stuff, doesn't it? | 11:03.51 |
| Robin_Watts_ | chrisl: For epub stuff, yes. | 11:04.05 |
| | la la la, I can't hear you. | 11:04.18 |
| chrisl | I would think an overall minimum alignment value would be a sensible addition | 11:05.06 |
| Robin_Watts_ | user38: I think it'd be more correct to check for __sparc__ etc, cos it's an architecture rather than a vendor. | 11:05.23 |
| | i.e. any OS on sparc will have the problem, not just SUN ones. | 11:05.34 |
| | chrisl: Will ponder on that, yes. | 11:05.56 |
| chrisl | Robin_Watts_: FWIW, most platforms, theoretically, will perform better using aligned accesses - although, I think that's probably *only* theoretical on modern hardware | 11:06.50 |
| user38 | Robin_Watts, I thought about that too, in which case +# if defined (sun) && defined (__SVR4) && defined (sparc), or +# if defined (sparc) | 11:06.53 |
| Robin_Watts_ | but right now, I need to review sebras' patches. | 11:07.17 |
| chrisl | user38: Probably just the "sparc" one - you want to catch linux/sparc systems, too | 11:07.55 |
| user38 | Robin_Watts go on then, I'll be busy with cleaning up the patches and regression testing. | 11:07.58 |
| | Is there even Linux on SPARC any more? | 11:08.19 |
| Robin_Watts_ | user38: #if defined(__sparc__) || defined(__sparc) is what I'd use. | 11:08.22 |
| | https://sourceforge.net/p/predef/wiki/Architectures/ | 11:08.29 |
| chrisl | user38: There is, yes | 11:08.37 |
| Robin_Watts_ | user38: Is there even solaris on sparc any more? :) | 11:08.40 |
| user38 | Robin_Watts, there is something called "Solaris 11", although I would vehemently argue against it being Solaris! | 11:09.21 |
| chrisl | user38: Installing Debian10/Sparc64 is on my to-do list..... | 11:10.30 |
| user38 | Robin_Watts: I'm usually reluctant to use macros with underscores in them, as it means that they are private. I believe we should only use __sparc or __sparc__ if there is no sparc macro defined. | 11:11.20 |
| | I will test this of course beforehand. | 11:11.53 |
| | chrisl: I am suprised that Debian still supports the sparc platform in any incarnation. | 11:12.39 |
| | Robin_Watts: my tests reveal the following: | 11:19.18 |
| | > cc -E -xdumpmacros /dev/null |& fgrep '#define sparc' | 11:19.34 |
| | #define sparc 1 | 11:19.43 |
| Robin_Watts_ | OK, so sparc, __sparc__, __sparc then :) | 11:19.58 |
| user38 | > cpp -dM < /dev/null |& fgrep '#define sparc' | 11:20.08 |
| | #define sparc 1 | 11:20.25 |
| | > gcc -dM -E - < /dev/null |& fgrep '#define sparc' | 11:20.54 |
| | #define sparc 1 | 11:21.03 |
| | Can anyone tell me why in the Makefile, the following rule explicitly overrides optimizations with -O0: | 11:27.07 |
| | $(OUT)/generated/%.o : generated/%.c | 11:27.21 |
| | $(CC_CMD) $(LIB_CFLAGS) -O0 | 11:27.30 |
| chrisl | user38: the "generated" files are just large chunks of data, no code - so attempting to optimise is just a waste of time | 11:54.45 |
| sh4rm4^bnc | can libmupdf be built as a shared lib too ? | 12:27.57 |
| user38 | There appears to be a shared=yes|no setting when calling make(1), haven't tried it myself yet. | 12:29.54 |
| | Or maybe it's just shared=yes. | 12:30.35 |
| sh4rm4^bnc | alright, trying. and how i can get headers ? | 12:31.39 |
| user38 | They get automatically installed by the build engine in ${prefix}/include/. | 12:32.49 |
| sh4rm4^bnc | they don't here ^_^ | 12:33.23 |
| user38 | 72 header files get installed. | 12:34.04 |
| | Let me see which target I'm calling to install... | 12:34.14 |
| sh4rm4^bnc | oh oops might be my own fault | 12:34.51 |
| | indeed, sorry for the noise | 12:36.09 |
| user38 | ${MAKE} install prefix=${prefix} libdir=${prefix}/${libdir} DESTDIR="${DESTDIR}" HAVE_X11=yes HAVE_GLUT=yes ($DESTDIR might be my own modification). | 12:36.24 |
| sh4rm4^bnc | hmm, there's no "shared" occurence anywhere in my mupdf 1.17 sources' Makefile | 12:52.46 |
| user38 | Makerules then. I just saw it this morning. | 13:00.11 |
| sh4rm4^bnc | 1.18.0 has it | 13:01.40 |
| | but 1.18.0 build fails due to #include <gumbo.h> | 13:01.55 |
| user38 | It does??? I just finished building the 32- and 64-bit versions of 1.18.0. | 13:03.13 |
| sh4rm4^bnc | source/fitz/xml.c:7:19: fatal error: gumbo.h: No such file or directory | 13:04.54 |
| | it seems to want google's gumbo parser | 13:07.29 |
| | it's shipped in thirdparty sources dir... trying to figure why it isnt picked up | 13:09.18 |
| user38 | I don't have this error while building. Didn't even know about "gumbo" until just now. | 13:19.28 |
| | Maybe it doesn't even get built on my operating system. | 13:19.52 |
| sh4rm4^bnc | your OS is linux ? | 13:26.31 |
| | my first expectation skimming Makefiles is that the proper -I include directives aren't added for in-tree build | 13:27.11 |
| | s/expectation/suspicion/ | 13:27.35 |
| user38 | My OS is Solaris 10. | 13:32.14 |
| sh4rm4^bnc | so it seems mupdf uses this fork https://github.com/GerHobbelt/gumbo-parser/commit/91075ac371c4e736b91295890cb8c38bce4c1baf | 13:42.28 |
| | however this one https://github.com/chozekun/gumbo-parser seems more advanced | 13:43.07 |
| user38 | Robin_Watts_: it would seem that setting #define CMS_PTR_ALIGNMENT 8 now breaks the 64-bit build: | 13:43.56 |
| sh4rm4^bnc | it sports the work done by craig barnes https://gitlab.com/craigbarnes/lua-gumbo/tree/master/lib | 13:43.57 |
| | which looks quite skilled to my trained eye | 13:44.17 |
| user38 | Robin_Watts_: Thread 2 received signal SIGSEGV, Segmentation fault. | 13:44.27 |
| | Robin_Watts_: [Switching to Thread 1 (LWP 1)] | 13:44.52 |
| | Robin_Watts_: 0x0000000100107f20 in fz_pack_path (ctx=0x1025eda80, pack_=0x102806adc "", max=56, path=0x10281a0c0) at source/fitz/path.c:196 | 13:45.11 |
| Robin_Watts_ | user38: Do you still have my patch in from the other day? | 13:48.09 |
| user38 | Robin_Watts_: I thought I did: "Date: Mon, 19 Oct 2020 18:35:05 +0100" | 13:49.09 |
| | Robin_Watts_: yes, I do, I do indeed. | 13:49.38 |
| Robin_Watts_ | user38: And that's one that you applied yourself, not the one that was (briefly) on master? | 13:50.50 |
| user38 | I downloaded it from the bug report link. | 13:51.22 |
| | Robin_Watts_, this is the patch I downloaded and applied: https://git.ghostscript.com/?p=user/robin/mupdf.git;a=patch;h=d0c52a75dee4f6b3677003de05f11ad9608bce64 | 13:52.17 |
| Robin_Watts_ | right. | 13:52.30 |
| | dunno why that's not working then. | 13:52.39 |
| user38 | I am at a loss myself; the only change made was the #ifdef (sparc) as we discussed. | 13:53.22 |
| Robin_Watts_ | user38: I'll be doing a revised patch shortly. | 13:53.55 |
| user38 | Robin_Watts_ I will be logging off for the day in a few minutes, but I will check the bug entry tomorrow, so if you leave a link to the patch as usual, it will be picked up from there. | 13:55.16 |
| Robin_Watts_ | user38: Ta. | 13:59.19 |
| sh4rm4^bnc | i hope we can convince somebody to make a proper gumbo fork https://gitlab.com/craigbarnes/lua-gumbo/-/issues/8 | 14:25.50 |
| malc_ | sebras: e785a6e02d98a052cd4a1a2054c6f463a9657cd9 - LOC +7-3 comment 65 lines - bravo! and i'm not even kidding | 15:33.09 |
| sebras | malc_: yeah, robin was happy with that essay too. | 15:37.59 |
| | but man, that was difficult to find and understand for me. | 15:38.13 |
| | and then I need to convince other's that this change is not only necessary but also correct. | 15:38.28 |
| malc_ | sebras: in general: life sucks and then you die :( | 15:42.14 |
| sebras | malc_: luckily it doesn't suck _all_ the time. :) | 15:45.58 |
| malc_ | sebras: :) closest i ever got to the greatness you've just demonstrated was probably https://git.qemu.org/?p=qemu.git;a=commit;h=c878da3b27ceeed953c9f9a1eb002d59e9dcb4c6 | 15:49.23 |
| sebras | malc_: that is a nice patch too. though I have a hard time understanding the commit message because I don't (yet) speak qemu. :) | 15:53.59 |
| malc_ | sebras: :) | 15:56.31 |
| sh4rm4^bnc | hurr Error loading shared library build/shared-release/libmupdf.so: No such file or directory (needed by /bin/mupdf-x11) | 19:27.48 |
| | Dynamic section at offset 0xd738 contains 31 entries: | 19:28.49 |
| | Tag Type Name/Value | 19:28.49 |
| | 0x0000000000000001 (NEEDED) Shared library: [build/shared-release/libmupdf.so] | 19:28.49 |
| | this is when building mupdf with shared=yes | 19:29.12 |
| | apparently some rpath fail here | 19:29.24 |
| malc_ | sh4rm4^bnc: (idle curiosity question) does it work with LD_PRELOADED mupdf .so? | 19:30.53 |
| sh4rm4^bnc | nope | 19:36.07 |
| | trying whether this fixes it: LINK_CMD = $(QUIET_LINK) $(MKTGTDIR) ; $(CC) $(LDFLAGS) -o $@ $(subst $(MUPDF_LIB),-Lbuild/shared-release -lmupdf,$^) $(LIBS) | 19:47.21 |
| | yup: 0x0000000000000001 (NEEDED) Shared library: [libmupdf.so] | 19:49.36 |
| | patch http://ix.io/2BxE | 19:50.02 |
| | this might need some tweaking for the non-shared case in the -L path | 19:50.46 |
| | there you go http://ix.io/2BxG | 19:53.04 |
| | should work with shared and static build | 19:53.11 |
| sebras | sh4rm4^bnc: do you mind sticking this in a bug? | 20:07.32 |
| sh4rm4^bnc | hmm how? | 20:12.22 |
| | do you have a github repo for that? i'm reluctant to register at yet another bugtracker | 20:14.15 |
| sebras | sh4rm4^bnc: bugs.ghostscript.com is our official bug tracker. | 20:18.23 |
| sh4rm4^bnc | https://github.com/sabotage-linux/sabotage/commit/374ff53b41b2154066b0b29cf773e86f9f80cde8 | 20:18.46 |
| sebras | sh4rm4^bnc: I'll try to remember it for next week when ator is back. | 20:19.30 |
| sh4rm4^bnc | you could also just apply my patch, i don't think it can get any more elegant =) | 20:24.45 |
| | <<<Back 1 day (to 2020/10/20) | Forward 1 day (to 2020/10/22)>>> | |
Log of #mupdf at irc.freenode.net.