| | <<<Back 1 day (to 2016/04/26) | 20160427 |
| Christian_ | good moring guys !:) | 06:29.35 |
| | first of all sorry for my bad english, im from germany :-P can somebody help me with gs cross compilation? | 06:30.52 |
| chrisl | Christian_: cross compiling gs is pretty involved just now | 06:32.26 |
| | Christian_: There are some basic guidelines at the bottom of this page: http://ghostscript.com/FAQ.html | 06:34.36 |
| Christian_ | yeah i know :D i can compile gs 9.19 as arm binary but i got an issue while using it with cups | 06:34.51 |
| chrisl | Just with cups? Does it work for other devices? | 06:35.42 |
| Christian_ | thank you, i know the FAQs and followed them, arch.h is modified and ccaux is my host gcc | 06:35.49 |
| | yeah.. the strange thing is that i used pre-compiled binarys from debian repo and everything worked, even with gs.. | 06:36.43 |
| | but now with self compiled cups and gs, gs gives no output if the device is cups | 06:37.22 |
| | I get this error from GS: "Unrecoverable error: VMerror in setdevice" any hints?? | 06:37.52 |
| chrisl | Sounds like it's running out of memory...... or thinks it is, anyway | 06:38.16 |
| | As I said, do other devices work? | 06:38.45 |
| Christian_ | which can i test? | 06:39.02 |
| chrisl | I'd try ppmraw - it's a fairly basic device | 06:39.27 |
| Christian_ | ok, i give it a try, mom :) | 06:39.54 |
| | my commandline is: /usr/bin/gs -dDEBUG -dPARANOIDSAFER -dNOPAUSE -dBATCH -dNOINTERPOLATE -sDEVICE=cups -sstdout=%stderr -sOutputFile=%stdout -sMediaType=Plain -sOutputType=0 -r600x600 -dMediaPosition=7 -dDEVICEWIDTHPOINTS=612 -dDEVICEHEIGHTPOINTS=792 -dcupsBitsPerColor=8 -dcupsColorOrder=0 -dcupsColorSpace=17 -dcupsInteger0=2 -scupsPageSizeName=Letter -I/usr/share/cups/fonts -c '<</.HWMargins[9.360000 9.360000 9.359985 9.3599 | 06:42.00 |
| | that doens't work too | 06:42.11 |
| | it gives me debug output and then unreadable output and that doenst stop till i kill gs | 06:42.53 |
| chrisl | Well, you have gs writing the raster output to stdout | 06:43.35 |
| | That's probably your "unreadable output" | 06:43.57 |
| Christian_ | but it doenst stop, if i pipe it to a file that file gets big till my filesystem is full | 06:44.39 |
| | sorry, that was the cmd: | 06:45.16 |
| | damn, that line is too long for my irc client | 06:45.42 |
| chrisl | Use pastebin or similar | 06:45.53 |
| Christian_ | http://pastebin.com/eCCjNuEF | 06:46.32 |
| | test.pdf is a word2013 generated pdf with some text in calibri | 06:51.20 |
| chrisl | Christian_: each page (from cups) is ~122Mb | 06:52.17 |
| Christian_ | that means? | 06:52.36 |
| | ah ok, because of the resolution? | 06:52.49 |
| chrisl | Well, it depends on the size of your filesystem.... | 06:52.50 |
| | Christian_: did you remove our included cups sources? | 06:53.44 |
| Christian_ | no | 06:53.55 |
| | thats my configure params: --disable-dbus --disable-gtk --disable-sse2 --with-system-libtiff --with-drivers=ALL --disable-compile-inits | 06:54.33 |
| chrisl | Of course, that wouldn't affect ppmraw, so..... | 06:54.45 |
| | How about trying the ppmraw device with "-sOutputFile=/dev/null" and see if it runs to completion | 06:55.41 |
| Christian_ | i compiles genconf for my target and run it | 06:55.41 |
| | oh wait | 06:56.04 |
| | ok, the files is 99,6MB big and gs completed | 06:56.19 |
| chrisl | Is that ppmraw? | 06:56.50 |
| Christian_ | yes | 06:56.56 |
| chrisl | Can you view the output? | 06:57.03 |
| Christian_ | sorry but with?? | 06:58.08 |
| chrisl | gimp, imagemagick, ristretto - most image viewers will open ppm | 06:58.41 |
| Christian_ | ah my file extension was wrong | 06:58.45 |
| | sorry about that, unix printing is new for me | 06:59.06 |
| | yes, output is correct | 06:59.32 |
| chrisl | OKay, so that's strong evidence the gs core is okay. | 07:00.39 |
| Christian_ | i try the same with the cups oiutput right now | 07:01.56 |
| | ah ok, the output is 125,7MB | 07:02.14 |
| chrisl | Yes, the cups raster has more stuff over and above the raw raster | 07:02.45 |
| Christian_ | hmm, rasterview shows correct output.. | 07:03.18 |
| | but why it doenst work with gstoraster and cups? | 07:03.39 |
| | i started with gs 9.06, 9.10, 9.16 and now 9.19, everytime the same error :( | 07:04.05 |
| chrisl | I don't think we have gstoraster any more..... | 07:05.04 |
| | Christian_: I would check whether you used the cups source we ship, or linked to libcups - look in your Makefile and search for SHARE_LCUPS and SHARE_LCUPSI | 07:07.13 |
| Christian_ | both is 1 | 07:12.14 |
| chrisl | OKay, so you are using the shared libcups and libcupsimage. Hmmm. I'm at a bit of a loss | 07:13.22 |
| Christian_ | hmm is it a problem that AR=ar ? it should be arm-v5te-linux-gnueabi-ar from my toolchain? | 07:13.31 |
| | maybe anything from my host is used while linking? | 07:14.20 |
| chrisl | We don't use ar in the build. Frankly, if anything from your host was being used I'd be shocked if the link was successful, and if it did, totally stunned if it actually ran on the target | 07:15.45 |
| Christian_ | hmm thats strange now.. | 07:22.05 |
| | i removed gs from my host | 07:22.13 |
| | also cups and every lib related | 07:22.32 |
| | compilation was ok but if i start the command from ealier | 07:23.16 |
| | i get this error: ./base/gsicc_manage.c:1126: gsicc_open_search(): Could not find default_gray.icc | ./base/gsicc_manage.c:1754: gsicc_set_device_profile(): cannot find device profile Unrecoverable error: rangecheck in .putdeviceprops ./base/gsicc_manage.c:1126: gsicc_open_search(): Could not find default_gray.icc | ./base/gsicc_manage.c:1754: gsicc_set_device_profile(): cannot find device profile Unrecoverable error: unkno | 07:23.35 |
| | GPL Ghostscript 9.19: ERROR -1 reclaiming the memory while the interpreter finalization. | 07:23.45 |
| chrisl | You're probably remove the ICC profiles, or removed them from the search path | 07:24.40 |
| | s/You're/You've | 07:24.49 |
| Christian_ | find / -name *.icc /usr/share/color/icc/ghostscript/gray_to_k.icc /usr/share/color/icc/ghostscript/default_gray.icc /usr/share/color/icc/ghostscript/default_cmyk.icc /usr/share/color/icc/ghostscript/ps_cmyk.icc /usr/share/color/icc/ghostscript/ps_gray.icc /usr/share/color/icc/ghostscript/ps_rgb.icc /usr/share/color/icc/ghostscript/lab.icc /usr/share/color/icc/ghostscript/srgb.icc /usr/share/color/icc/ghostscript/sgray.icc /us | 07:25.47 |
| chrisl | Right, so possibly gs isn't looking in that location | 07:26.21 |
| Christian_ | hmm they are present.. i never got this error before.. so make take anything from my host system i think.. | 07:27.01 |
| chrisl | There is a default path where we'll search | 07:27.55 |
| | You can change it with the command line option: -sICCProfilesDir=<path to profiles> | 07:29.26 |
| Christian_ | ok, i'll give it a try! mom | 07:29.45 |
| chrisl | It's possible it might expect a training "/" on the directory: "/usr/share/color/icc/ghostscript/" | 07:30.42 |
| Christian_ | ok, the command is running.. can i set it while compilation? so that cups is working too? | 07:32.37 |
| chrisl | Erm....... I guess it must be possible | 07:33.43 |
| Christian_ | i try to find it myself :) | 07:34.02 |
| | but first i patch gstoraster to test it | 07:34.32 |
| chrisl | Actually, saying that, I'm not so sure: the normal way we do it is that the iccprofiles directory is found relative to the Resource/Init directory...... | 07:35.12 |
| Christian_ | this is my rescource folder: /usr/share/ghostscript/9.19/Resource/Init | 07:35.58 |
| | make install doesn't install it, i install it to the target with my buildsystem (ptxdist) | 07:36.26 |
| chrisl | Right, so on Ubuntu, in /usr/share/ghostscript/9.19 there would be an "iccprofiles" directory | 07:36.47 |
| Christian_ | aha ok | 07:37.11 |
| chrisl | You could probably just "ln" /usr/share/ghostscript/9.19/iccprofiles to "/usr/share/color/icc/ghostscript" | 07:37.38 |
| Christian_ | it seems to work but: "Unrecoverable error: VMerror in setdevice" ... damn.. | 07:40.13 |
| | probably its a gstoraster bug? | 07:40.23 |
| | i use cups-filters 1.0.61 | 07:40.50 |
| chrisl | Well, as I said, I think gstoraster was dropped some time ago - I thought it was now pdftoraster | 07:41.13 |
| Christian_ | you mean in gs? | 07:42.04 |
| chrisl | It was removed from the gs source tree quite a while ago | 07:42.23 |
| Christian_ | yeah, gstoraster comes from cups-filters | 07:42.49 |
| | cups-filters also provide pdftoraster but... pdftoraster crashs if i try to print to a HP printer.. hplip needs gs to render i think.. | 07:44.27 |
| chrisl | Strange, the output from both should be a cups raster.... well, nevermind | 07:44.59 |
| Christian_ | yeah, with samsung or other printers pdftoraster works fine.. i think they got some spezial things in der ppds | 07:45.34 |
| | so, gs works fine on my target but gstoraster/cups got problems with piping to gs? | 07:47.19 |
| | damn .. :( | 07:47.46 |
| chrisl | I doesn't seem to be with pipe to gs, because I don't think we get as far as trying to read the input | 07:48.19 |
| | Possibly piping *from* gs | 07:48.35 |
| Christian_ | yes of course, the way back from gs to cups, right? | 07:50.14 |
| chrisl | Yeh. And I really don't know enough about cups to help debug what's going on there.... | 07:50.51 |
| | Is your gstoraster a binary? | 07:51.16 |
| Christian_ | yes | 07:51.24 |
| chrisl | Hmm, mine too, but the one in the latest cups-filters archive is a perl script | 07:52.31 |
| Christian_ | oh.. my target got no perl so i need a binary | 07:53.08 |
| | i dont unterstand why the procompiled debian binarys worked | 07:53.45 |
| | i think i try some newer cups-filters | 07:54.25 |
| chrisl | I was just wondering if gstoraster called the gs exe, or whether it linked to libgs.so | 07:54.44 |
| Christian_ | you want to see the file? | 07:55.10 |
| | do* | 07:55.18 |
| chrisl | What file? | 07:55.34 |
| Christian_ | gstoraster.c from my cups-filters src | 07:55.46 |
| chrisl | The binary on my system doesn't list libgs, so I guess it must be execing the executable | 07:56.55 |
| Christian_ | yes you're right | 07:57.16 |
| chrisl | So, we've established that you are linking to libcups(image) and that's not working. How about forcing the build to use the cups source we ship? | 07:58.23 |
| Christian_ | hm, the cups driver in gs is working till i output it to a file, only if the output is piped to gstoraster i got the error.. | 08:03.20 |
| | so i think i have to try a newer cups-filters source | 08:04.04 |
| | definitely a big thank to you chrisl and i keep you informed !:) | 08:06.24 |
| chrisl | Christian_: you could try using "-sOutputFile="|cat > out.cups" calling gs directly - that would establish if it's a general problem with piped output | 08:06.50 |
| Christian_ | hmm i tried -sOutputFile=%stdout ..... > test.out | 08:12.52 |
| | that worked | 08:12.55 |
| | i looked into newer cups-filters sources, the gstoraster filter is not modified | 08:13.39 |
| | oh man.. i'm sitting since days at this problem | 08:14.07 |
| chrisl | Christian_: Sorry, I'm at a bit of a loss on how to proceed. Everything that cups is doing seems to work when gs is called normally.... | 08:30.52 |
| Christian_ | me too chrisl :-D thank your for your support!! i tried the whole filters by hand on shell and they worked, i hope its a cups problem and its resolved when i update now.. | 08:43.30 |
| chrisl | Christian_: is it possible cups is doing something to the environment before applying the filters - like limiting memory available (ulimit)? | 08:50.44 |
| Christian_ | chrisl you're right, an env variable causes the problem | 09:25.53 |
| chrisl | Christian_: Aha! What variable? | 09:26.24 |
| Christian_ | i'm not sure, cups sets about 30 variables | 09:27.22 |
| chrisl | Hmm, nice and simple then :-( | 09:28.02 |
| Christian_ | http://pastebin.com/sM0734R0 maybe you can see something?? :) | 09:28.33 |
| | otherwise its try and error | 09:28.45 |
| chrisl | First thing to try would be RIP_MAX_CACHE=128m | 09:30.06 |
| | Then TMPDIR=/var/spool/cups/tmp | 09:30.38 |
| Christian_ | RIP_MAX_CACHE did it | 09:49.03 |
| | but only if i remove it, other values causes same error | 09:50.11 |
| chrisl | Let me do a test here, and see if it causes problems | 09:52.15 |
| | Hmm, it doesn't cause a problem here..... | 09:55.26 |
| | Christian_: what other values did you try? | 09:56.39 |
| Christian_ | i found this old bug: http://bugs.ghostscript.com/show_bug.cgi?id=691170 .. i tried 256m and 512m, now with 0 it worked | 09:57.01 |
| chrisl | Well, to get a better idea of what's going on, you'd have to build a debug gs.... probably not worth the hassle | 09:58.39 |
| Christian_ | oh my god, my hp printer is printing :-D :-) | 10:07.28 |
| | in cups i can configure the rip size | 10:08.05 |
| | can i provide you some debugging output? | 10:08.54 |
| chrisl | At least the first part of the relevant debugging output is only available in a debug build. | 10:09.51 |
| Christian_ | yeah i can do this.. how to enable it? | 10:10.11 |
| chrisl | when you build gs, do "make debug" instead of "make" - the executable will end up in "debugbin" | 10:10.41 |
| | Oh, actually, there might be more... hang on | 10:11.03 |
| Christian_ | hm, can i do this over configure? | 10:11.49 |
| chrisl | You don't need to re-run configure | 10:12.06 |
| | So you want: make XCFLAGS="-DCUPS_DEBUG2" debug | 10:13.02 |
| | And you'll have to copy the debugbin/gs exe manually over your existing exe (there isn't a "debuginstall" target) | 10:14.13 |
| Christian_ | thats no problem | 10:15.23 |
| | wow 41MB exe :-) | 10:24.18 |
| | ok how to proceed? | 10:24.26 |
| chrisl | The easiest thing is to set RIP_MAX_CACHE=128m and try running the gs (cups) command line we tried earlier | 10:25.45 |
| Christian_ | debug output comes to console? | 10:26.04 |
| chrisl | Yeh. | 10:26.13 |
| | You should get a load of extra "DEBUG2" lines | 10:26.56 |
| Christian_ | i'll give it a try after having lunch | 10:27.18 |
| chrisl | The lines you are interested in are the ones with; "DEBUG2: cache_size = " | 10:27.56 |
| | For me they read: "DEBUG2: cache_size = 134217728" | 10:28.30 |
| | (not surprising with RIP_MAX_CACHE=128m of course) | 10:30.01 |
| Christian_ | http://pastebin.com/0NbiDznH | 10:31.19 |
| | my target got 128mb ram | 10:32.00 |
| chrisl | Hmm, so it's probably better to let Ghostscript figure out the raster memory itself, rather than force a value | 10:32.42 |
| | Christian_: so, the way this works is that Ghostscript tries to allocate memory for the output raster. Left to itself, it will try to allocate enough for the full page, and if that fails, it will repeat trying smaller sizes (so the page will be rendered in multiple bands) until it finds one that works *or* the available memory is genuinely too small even for banding to work. | 10:37.23 |
| | *If* on the other hand, the command line, or the device (as in this case), sets a required raster memory size, it will try that, and if it fails, just give up immediately. | 10:38.31 |
| | Christian_: in your case, you may want to (counter intuitively, maybe) try smaller values for RIP_MAX_CACHE, like 32m or 16m | 10:40.43 |
| | Or, as you found, set it to 0, so letting Ghostscript go through its retrying method - it depends what else you expect your target to be doing. | 10:41.56 |
| Christian_ | ok thx chrisl for your help, i stay on RIP_MAX_CACHE 0 because i cannot guarantee that my system has 32m or 16m of free memory | 11:13.32 |
| | i also run a qt application and that can also take much ram at runtime | 11:15.52 |
| | but its funny that the precompiled binarys ran on the target without this issue.. and RIP_MAX_CACHE is 128m in there. but for now its okay for me :) | 11:18.03 |
| squ | hi guys! | 11:32.47 |
| kens | I can't seem to get identify to work, NickServ services unavailable :-( | 14:50.54 |
| | Forward 1 day (to 2016/04/28)>>> | |
IRC Logs