| <<<Back 1 day (to 2018/02/06) | 20180207 |
Cesarr | hello, i'm trying to reduce size of files with gs, it's working great mostly, but sometime i get errors (/rangecheck) using /ebook setting | 08:20.17 |
| i'd guess it's because of some bogus file, but is there a workaround? | 08:20.43 |
kens | If you think you've found a bug, best thing is to report it. Note that Ghostscript doesn't reduce the size of PDF files, it creates new ones, they might be smaller, but they might not. | 08:20.56 |
| The only 'work around' I can suggest without seeing the input file and command line is to not use the PDFSETTINGS switch, which sets *lots* of controls simultaneously, but instead to set each control individually. | 08:21.43 |
Cesarr | I don't think it is a bug, rather a non compliant source file | 08:22.04 |
kens | That will probably give better (certainly more controllable) results, and if you identify which control is causing your problem then you can simply avoid it | 08:22.10 |
| In general, if Acrobat will open a file, even if its broken, we try to as well. SO we'd consider a fileure to open a file that Acrobat opens to be at least plausibly a bug | 08:22.53 |
| You can also try rendering the file to the display, or creating a new PDF with the default settings. If either of those works, then its not the file. | 08:23.24 |
| But realistically, we can't tell you anything without seeing the source file and the command line | 08:23.47 |
Cesarr | yeah default works | 08:24.45 |
kens | Then its not the file | 08:24.52 |
Cesarr | i can upload the source pdf somewhere if you want | 08:26.09 |
kens | Better to open a bug report, I'm busy with other stuff right now and it may be some time before I can look at it. If you open a bug I won't forget | 08:26.54 |
| Oh, you should also make sure you're using an up to date version of Ghostscript | 08:27.08 |
Cesarr | let me check | 08:27.26 |
| I'm not. | 08:27.55 |
kens | Well, there are always bug fixes, so it possible your problem has been fixed. What version are you using ? | 08:28.18 |
Cesarr | 9.05 | 08:29.01 |
kens | That's really very old | 08:29.11 |
Cesarr | thought debian would have updated it | 08:29.12 |
kens | Current is 9.22 you should probably try that, there have been *lots* of bug fixes in that time. | 08:29.35 |
| I was going to search the Git history to see if anything looked likely, but that's really going to return too many results over that time period | 08:29.57 |
Cesarr | I will try on an updated version | 08:31.27 |
kens | Its certainly worth a go | 08:31.38 |
Cesarr | GS is amazing btw, as far as I'm capable of using it | 08:32.19 |
kens | Its been around for a long time :-) | 08:32.33 |
Cesarr | 2k1. I was already on IRC, but not concerned about pdfs though | 08:34.19 |
kens | Ghostscript is older than that, been arond since the 1980's | 08:34.43 |
| I don't recall offhand when the initial version was released | 08:34.59 |
Cesarr | definitively not concerned about pdfs! | 08:35.14 |
| Ok, my laptop is 8.79 | 08:35.21 |
kens | Well not back then, no, Ghostscript is really a PostScript interpreter | 08:35.29 |
| O.O that *is* old.... | 08:35.40 |
| Actually.... | 08:35.52 |
| there never was an 8.79 | 08:35.55 |
| We went from 8.71 to 9.00 | 08:36.04 |
Cesarr | 8.71 | 08:36.05 |
kens | :-) | 08:36.09 |
Cesarr | you're right. | 08:36.10 |
kens | So 8.71 is 7 years old, and 9.05 is 6 years old | 08:36.31 |
Cesarr | I remind when we had to "print" to Postscript to print elsewhere because nothing was compatible together | 08:37.34 |
kens | Seems like Debian is, as usual, rather behind the times | 08:37.39 |
| Jessie apparently packages 9.06..... | 08:38.11 |
| Ah stretch is up to 9.20 | 08:38.33 |
| Of course, you could just build it yourself, assuming you have autotools and gcc installed | 08:38.58 |
| Debian sid has tyhe current version, 9.22 | 08:39.15 |
| Packages are available here: | 08:40.39 |
| https://packages.debian.org/sid/ghostscript | 08:40.39 |
Cesarr | the laptop I was referring to, is a mac. | 08:41.53 |
| I'm trying to updated this one | 08:41.59 |
kens | Oh.... | 08:42.05 |
| I think there a MacPort somewhere | 08:42.15 |
| https://www.macports.org/ports.php?by=library&substr=ghostscript | 08:42.52 |
| Hmm that seems to suggest that GS is BSD, which it isn't | 08:43.22 |
| It does say AGPL3, which is correct, but also says BSD | 08:43.34 |
chrisl | There's BSD code in the package | 08:43.52 |
kens | Oh and that seems to be a source link :-( | 08:43.53 |
| Hmm, fair enough | 08:44.05 |
chrisl | I'd prefer it changed, but I suspect that's the reasoning - plus "Maintained by: nomaintainer" - good luck getting it changed ;-) | 08:44.56 |
kens | :-( | 08:45.32 |
chrisl | They have a bug tracker, IRC channel, mailing lists etc - we could possibly start a dialogue | 08:46.22 |
kens | Well its pretty minor. | 08:46.41 |
| Though it reminds me I should go check on the Windows thingy, if I can remember teh name. I never heard back from Kate on that one | 08:47.06 |
chrisl | There's also a homebrew port for MacOS which is kept pretty up to date | 08:48.32 |
kens | Ah that's what I was thinking of, homebrew | 08:49.00 |
Cesarr | Well. I messed it up. I've not gs9.05 anymore | 09:06.39 |
kens | Umm, oops ? | 09:06.53 |
Cesarr | Ok, so running 9.22. Processing the pdf without error, so it was an old bug i guess | 11:12.55 |
| Thank you | 11:13.00 |
| Sorry for wasting your time, I should have tested the latest first | 11:13.19 |
chrisl | Cesarr: Glad it worked | 11:26.07 |
deekej | hello chrisl :) just a small question - how big (approximately) is your regression testsuite in number of tests? hundreds? thousands? :) | 13:12.05 |
| I'm writing a request to be able to update to latest version of Ghostscript more often in RHEL, and this info could help it :) | 13:12.55 |
kens | deekej we have thousands of files I think, and we run them with several different devioces and combinations of settings. | 13:16.42 |
| According to my last run, we execute 98,605 tests | 13:17.23 |
| I think we use about 10 different configurations, so that's 'about' 9800 files tested 10 different ways | 13:17.57 |
| The number of files in the suite grows over time. We do include teh PostScript 3 CET and FTS, the PCL CET and FTS and the PDF fts (all from Quality Logic) as well as a number of files which have provoked bug reports in the past. | 13:18.51 |
| NB that's the 'on every commit' testing. We also run an 'all devices' test on every commit, but that just runs a very small number of files with every device supported by Ghostscript. Its really just a smoke test | 13:20.04 |
| Then there are some nightly and weekly runs which test different devices and combinations of serttings. | 13:20.35 |
| Unfortunately the range of options available in Ghostscript (and GhostPCL and GhostXPS) mean that its not feasible to test every option in every possible combination. We do try to test the configurations we think are most used, and exercise as much of the code base as possible. | 13:21.50 |
| By conincidence we were dicsussinf adding some more tests last night. | 13:22.19 |
deekej | kens: Holy crap, that's a huge number! :-O Anyway, thanks! :) | 13:26.29 |
kens | Well, we do try not introduce regressions. | 13:26.49 |
deekej | kens: you run much much more tests than we do, and that's significant for me :) | 13:26.55 |
kens | Fair enough, we have a network of 21 machines, it takes it about 20 minutes to run all the tests, collate the results and send an email. That's doen for every commit, and we use it extensively in development as well, we can submit code for testing at any time, and we generally do, frequently. We find it an exceedingly useful tool. | 13:28.19 |
chrisl | There are also regualr, but less frequent tests for less common configurations | 14:13.41 |
kens | Other than the nightly and weekly tests ? | 14:14.06 |
chrisl | Oh, I missed that you'd mentioned those | 14:14.41 |
kens | I didn't say much about them | 14:14.50 |
chrisl | Some of them aren't relevant to deekej | 14:15.09 |
kens | Yeah I assumed that, also I was thinking 'too much information' | 14:15.22 |
chrisl | Sorry, it's what happens when I come to a conversation 45 minutes late! | 14:16.38 |
kens | Not a problem :-) | 14:16.49 |
deekej | ^_^ | 14:17.37 |
| chrisl: we have found out that during our build some of the linker flags get eaten | 15:51.45 |
| we try to link the Ghostscript with -z now -z relro -z -pic -z now options | 15:52.21 |
| but at some point some of these options get lost (we are producing binaries without PIE) | 15:52.58 |
| any idea where should I start looking in the build process? | 15:53.13 |
chrisl | What hell is PIE? | 15:55.03 |
deekej | it's similar to position independent code | 15:55.28 |
chrisl | What was wrong with PIC, one wonders :-( | 15:55.50 |
| deekej: if you add your extra flags to XLDFLAGS on the make command line, that should work | 15:56.21 |
deekej | the -fPIE (for gcc) is similar to -fPIC, "but generated position independent code can be only linked into executables" | 15:56.38 |
chrisl | So would -fPIE work? | 15:57.46 |
deekej | it works for us with other applications | 15:58.09 |
| we have to define the -fPIE for CFLAGS, and the options I mentioned above for LDFLAGS | 15:58.39 |
| the CFLAGS "injection" works OK, the LDFLAGS injection is failing for us somehow | 15:59.01 |
chrisl | so, configure CFLAGS=-fPIE LDFLAGS="-z now -z relro -z -pic -z now" ? | 16:00.45 |
| deekej: Well, it seems to work for me: Makefile has: "LDFLAGS=-z now -z relro -z -pic -z now $(AC_LDFLAGS) $(XLDFLAGS)" | 16:02.23 |
deekej | we use this: | 16:04.38 |
| https://pastebin.com/7fPDHwr2 | 16:04.39 |
| the problem is (it seems) those linker flags are not passed correctly for 'gs' and 'gsx' binary | 16:06.25 |
chrisl | I must be missing something.... I thought PIC code was for shared libraries | 16:08.11 |
deekej | yes, AFAIK the PIC is for shared libraries, and the PIE is "extension" of it for executables | 16:09.04 |
| here's the excerpt from linker's man page: | 16:10.25 |
| -pie | 16:10.25 |
| --pic-executable | 16:10.25 |
| Create a position independent executable. This is currently only | 16:10.25 |
| supported on ELF platforms. Position independent executables are | 16:10.25 |
| similar to shared libraries in that they are relocated by the | 16:10.26 |
| dynamic linker to the virtual address the OS chooses for them | 16:10.28 |
| (which can vary between invocations). Like normal dynamically | 16:10.30 |
| linked executables they can be executed and symbols defined in the | 16:10.32 |
| executable cannot be overridden by shared libraries. | 16:10.34 |
chrisl | I'll need to look at this: we just build gsx and co with a simple gcc invocation | 16:11.26 |
deekej | right now, we're passing -fPIE to gcc via CFLAGS in Fedora, and we need to pass the '-pie' to the linker for gs and gsx binary as well | 16:12.00 |
| that last part is currently failing for us :) | 16:12.10 |
| we have lot of other software with the same issue, it was recently discovered | 16:12.49 |
chrisl | Sounds like a gcc bug, tbh | 16:13.04 |
| For example, for gsx we just do: $(GLCC) -g -o $(GSSOC_XE) $(PSSRC)dxmainc.c -L$(BINDIR) -l$(GS_SO_BASE) | 16:14.05 |
| So there isn't a separate call to the linker | 16:14.16 |
| So surely if gcc gets -fPIE it ought to pass the appropriate option when it calls the linker? | 16:14.43 |
deekej | hmm, fair point | 16:15.08 |
chrisl | I think there is an option to pass options thought gcc to the linker, but I can't remember it off hand | 16:15.48 |
| deekej: Ah, "-Xlinker -pie" maybe? | 16:17.15 |
deekej | I'll try to check | 16:17.24 |
| give me minute, please :) | 16:17.38 |
chrisl | Hmmm, "/usr/bin/ld: warning: -z -pic ignored" | 16:21.47 |
deekej | ok, so looking at the way the flags injection is done in the build system in Fedora | 16:22.12 |
| it should be okay to just add $(LDFLAGS) to the command line when building the gs / gsx | 16:22.46 |
| the gcc option is -Wl | 16:22.53 |
| since it is for a linker, comma is used for options separation with -Wl option | 16:23.49 |
| in Fedora, the LDFLAGS are set to something like this: LDFLAG='-Wl,-z,relro,-pie,-z,-now' | 16:25.09 |
| then it should be okay to just pass this to gcc, same as we do with CFLAGS | 16:25.38 |
| I'll try to look at the unixlink.mak and other unix-* Makefiles | 16:27.59 |
| to see if this could be safely added there :) | 16:28.14 |
chrisl | deekej: we may need to look at how the gsc and gsx exes get built - they really aren't intended as "production" executables | 16:33.54 |
deekej | chrisl: no problem :) if you need any help, just let me know | 16:35.25 |
chrisl | deekej: Well, I'll only tackle it if it becomes necessary...... | 16:36.01 |
| BTW, how can I tell if an executable is PIE? | 16:36.24 |
deekej | on Linux I'm using readelf -h <executable> | 16:36.53 |
| the Type field there will show DYN if the executable is PIE-enabled | 16:37.10 |
| otherwise it will show EXEC | 16:37.20 |
chrisl | deekej: Okay, so if I use CFLAGS="-fPIE -fPIC" and LDFLAGS="-z now -z relro -z -pic -z now" - that seems to work | 16:38.05 |
deekej | nice :) | 16:39.45 |
chrisl | note "seems"! | 16:40.19 |
Cesarr | Finaly I compiled gs on mac os, without any issue sofar. | 18:25.40 |
| Forward 1 day (to 2018/02/08)>>> | |