I usually use slackware on my machines, but I have recently installed gentoo to use 64-bit mode on my new Athlon64. When I run gv to look at the file http://www.cs.cmu.edu/~quake-papers/painless-conjugate-gradient.ps, it gives me an error on page 3 (really the fifth page) and several other pages. This doesn't happen on my slackware install (32 bit, of course). Whe compiling gv on amd64, I get many warnings about converting an int (4 bytes) to a pointer (8 bytes) and vice-versa. I beleive that the problem lies here; data must be lost during the conversion, resulting in invalid pointers. Perhaps gv should be masked for amd64 until someone fixes it?
Do you mean app-text/ggv or app-text/ghostview ?
I meant app-text/gv. However, I also tested ggv and ghostscript; both had problems on the same page(s). This is likely due to the fact that ggv is based on gv which is based on ghostscript.
I meant ghostview rather than ghostscript in the previous post.
phi root # uname -a Linux phi 2.6.7-gentoo-r11 #1 Sun Aug 1 10:23:24 CEST 2004 i686 GNU/Linux phi root # ps2pdf painless-conjugate-gradient.ps Error: /rangecheck in --get-- Operand stack: --nostringval-- --nostringval-- --nostringval-- descender 0 --nostringval-- 1 Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1 3 %oparray_pop 1 3 %oparray_pop 1 3 %oparray_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- --nostringval-- Dictionary stack: --dict:1051/1417(ro)(G)-- --dict:0/20(G)-- --dict:69/200(L)-- --dict:149/250(L)-- --dict:48/200(L)-- --dict:36/50(L)-- --dict:1/17(L)-- --dict:5/17(L)-- --dict:1/3(L)-- --dict:13/14(ro)(G)-- Current allocation mode is local Current file position is 83293 ESP Ghostscript 7.07.1: Unrecoverable error, exit code 1 Looks like slackware has a patch to prevent this error. Reassigning to ghostscript maintainer. Printing-herd: Is this probably only a bogus PS file ?
don't know if it's a bogus ps file, can you point me to the slackware patch please
The Slackware patch doesn't do anything except change some config stuff. In fact, I had to patch the gv source with the gentoo gcc patch for it to compile (even on Slackware). Compiling the same source using the same patches (those patches being the Slackware patch and the Gentoo gcc patch) on Slackware and then on Gentoo (AMD64) resulted in a 32-bit Slackware binary that worked and a 64-bit Gentoo binary that gives the error in question. I'll have placed the (working) Slackware 32-bit binary that I compiled at http://www.rpi.edu/~thambj/gv in case anyone wants to be sure that there is binary that works. Additionally, as I said before, the Slackware patch to gv doesn't really do anything; in fact, the source isn't modified at all. But here's a link to it anyway: ftp://carroll.cac.psu.edu/pub/linux/distributions/slackware/slackware_source/xap/gv/gv-3.5.8.diff.gz As I mentioned before, even on Slackware you will need the gentoo gcc patch for gv to compile the Slackware version (with gcc 3.3.4 anyway). --Jonathan Thambidurai
set correct Hardware architecture. should this really be assigned to the printing team and not to the amd64 team?
nothing we currently can fix -> upstream
