| | <<<Back 1 day (to 2020/10/22) | Fwd 1 day (to 2020/10/24)>>> | 20201023 |
| user38 | Greetings everyone. | 06:06.42 |
| chrisl | user38: Hey, you asked the other day about why the makefiles force -O0 for the "generated" files - I did reply, not sure you saw it? | 07:48.19 |
| sh4rm4^bnc | i didn't read it, but i suppose it's for the obvious reason-to build throw-away stuff as fast as possible | 09:23.00 |
| chrisl | IIRC, the "generated" stuff is just big arrays of bytes representing cmaps, fonts, (probably icc profiles), so it's pointeless trying to "optimise" files with no executable code in them | 09:27.30 |
| sh4rm4^bnc | oh, i actually assumed you mean CFLAGS used for the generators of those files | 09:29.26 |
| chrisl | Well, -O0 is a CFLAG | 09:31.15 |
| | Anyway, I don't if it's still true, but gcc used still attempt to optimise such files if asked | 09:32.30 |
| sh4rm4^bnc | yes, you build a tool called hexdump which is used to generate files, where it would make sense to build it with -O0 | 09:33.09 |
| | this is the kind of tool that need to be compiled with HOSTCC in a cross-compile scenario as the crosscompiler cant produce binaries running on the build host | 09:35.10 |
| chrisl | Oh, I see. No, it's actually the compiling of, for example, Dingbats.cff.c - so the files generated by hexdump | 09:36.00 |
| sh4rm4^bnc | (the reason for this hack here https://github.com/sabotage-linux/sabotage/blob/master/pkg/mupdf#L35 ) | 09:37.48 |
| user38 | chrisl, no I did not see it. | 09:43.16 |
| chrisl | user38: Well, as I say, it's because there's nothing there to optimise | 09:43.50 |
| user38 | That's why I asked, because it was clear that -O0 was purposely appended to the end, so it looked very intentional. Good thing I left it alone.\ | 09:44.59 |
| | s/\\$// | 09:45.06 |
| chrisl | Well, it would *probably* just make compiling those files take longer... | 09:45.47 |
| user38 | Almost certainly; I could earn a coffee taking that bet. | 09:46.20 |
| chrisl | user38: I wanted to ask: do you have a favoured source for solaris/sparc software? I've been using https://www.opencsw.org/ most of the packages are outdated, and some are *very* outdated! | 09:48.40 |
| user38 | No, I build and package everything myself. I have a pretty big library of my own Solaris 10 SVR4 packages. | 09:51.50 |
| | In my view, none of the public Solaris sources are of high enough quality or 100% specifications conforming. | 09:52.48 |
| chrisl | I would agree - but I also find my ancient SPARC machines too slow for me to compile *everything* I need from source - life's too short! | 09:54.12 |
| user38 | Indeed. | 09:54.59 |
| | For now, I'm getting by compiling on T2000's, and the i86pc intel and AMD systems running Solaris are very fast, so that's not an issue. | 09:55.47 |
| | ebay is rife with cheap T5240's (UltraSPARC T2), or T3000's, even some M10 systems, mostly because few people are now left alive who know what to do with that hardware and how to get the maximum out of it. | 09:57.48 |
| chrisl | So far, it's only really gcc that's a problem - the newest one they have is a gcc 5.x.x - could really do with something newer. So I can do that from source - if I start early enough in the morning | 09:57.49 |
| user38 | I modified and built my own GCC 9.2.0. | 09:58.09 |
| chrisl | Modified? Does it not work out of the box? It certainly used to.... | 09:58.52 |
| | Hmm, I also have the old SunStudio around somewhere... I could install that | 10:00.00 |
| user38 | The maintainers built in extra code to make the build purposely break on Solaris; and I also modified it so that it correctly encodes $ORIGIN into the RPATH ELF slot when linking so that no LD_LIBRARY_PATH's are needed ever again. | 10:00.09 |
| chrisl | Purposefully broke it? Any idea why? | 10:00.57 |
| user38 | "No maintainers." It seems they wanted to force the issue and have a maintainer step forth. I contemplated it for a while, then real life happened. | 10:01.36 |
| chrisl | Well, I suppose that makes sense, we've done the same kind of stuff with Ghostscript before | 10:02.28 |
| | I think I'll struggle on with the opencsw tools until I (hopefully) get my slightly less slow SPARC box up and running again..... | 10:04.09 |
| | I have head out for a bit.... | 10:05.19 |
| user38 | waves | 10:09.18 |
| | A question in the round, how do mupdf-x11 and mupdf-gl remember which page the document was last left on when re-opening that same document? | 10:17.22 |
| sebras | mupdf-gl stores a .mupdf.history in the directory given by $XDG_CACHE_HOME, $HOME or $USERPROFILE, or /tmp. depending on what environment variable is set. | 10:19.39 |
| | user38: the same is not true for mupdf-x11. | 10:20.10 |
| user38 | sebras, does mupdf-x11 store anything at all as far as history? | 10:20.53 |
| sebras | user38: not that I know of. | 10:21.24 |
| user38 | sebras when I package MuPDF, is it a good idea to add a mupdf symbolic link to mupdf-x11? | 10:24.50 |
| sebras | user38: most new features will be implemented in mupdf-gl, so it might be a better target of a symbolic link named "mupdf". | 10:26.15 |
| user38 | sebras the only problem with that is that the 64-bit version of mupdf-gl crashes on sparc as things stand right now. | 10:27.15 |
| sebras | user38: then that must be fixed. | 10:29.18 |
| | user38: I know that Robin_Watts has a commit he wants me to review. I haven't had time to look at it enough yet. | 10:29.43 |
| user38 | I've also noticed that mupdf-x11 supports flipping through the pages with the middle mouse button scroll wheel, while the (Open)GL version does not. Is that intentional? | 10:31.33 |
| sebras | user38: I'm not sure, you have to wait for ator next week to see what he says. | 10:32.49 |
| | <<<Back 1 day (to 2020/10/22) | Forward 1 day (to 2020/10/24)>>> | |
Log of #mupdf at irc.freenode.net.