Hey all,
I'm having a problem with Image.SVG in that when trying to do indices(Image.SVG) then Pike hangs quite badly - the only way to stop it is to kill it. It happens only in the Debian packaged version for both Pike versions, the version compiled from the tarballs works fine. Until recently the Debian package was using the --traditional style of installation, but now it uses a modified --new-style one which in 90% resembles the default style with minor differences:
- all the pike code is installed in /usr/share/pike/X.Y.Z/ - all the binary files (.o, pike, .so) are in /usr/lib/pike/X.Y.Z/ - the files in /usr/share/pike/X.Y.Z/ are symlinked to from the /usr/lib/pike/X.Y.Z/ so that the layout looks like that:
$ pwd /usr/lib/pike/7.5.3/lib/modules ... lrwxrwxrwx 1 root root 59 2003-02-06 23:40 _Image_DWG.pmod -> ../../../../../share/pike/7.5.3/lib/modules/_Image_DWG.pmod -rw-r--r-- 1 root root 6062 2003-02-06 19:40 _Image_DWG.pmod.o -rw-r--r-- 1 root root 10908 2003-02-06 19:42 _Image_FreeType.so -rw-r--r-- 1 root root 39188 2003-02-06 19:42 _Image_GIF.so -rw-r--r-- 1 root root 32844 2003-02-06 19:42 _Image_JPEG.so drwxr-xr-x 2 root root 94 2003-02-06 23:40 _Image.pmod lrwxrwxrwx 1 root root 59 2003-02-06 23:40 _Image_PSD.pmod -> ../../../../../share/pike/7.5.3/lib/modules/_Image_PSD.pmod -rw-r--r-- 1 root root 20777 2003-02-06 19:40 _Image_PSD.pmod.o lrwxrwxrwx 1 root root 58 2003-02-06 23:40 _Image_PS.pmod -> ../../../../../share/pike/7.5.3/lib/modules/_Image_PS.pmod -rw-r--r-- 1 root root 8087 2003-02-06 19:40 _Image_PS.pmod.o -rw-r--r-- 1 root root 768976 2003-02-06 19:42 Image.so -rw-r--r-- 1 root root 8156 2003-02-06 19:42 _Image_SVG.so -rw-r--r-- 1 root root 2964 2003-02-06 19:42 _Image_TIFF.so -rw-r--r-- 1 root root 22540 2003-02-06 19:42 _Image_TTF.so lrwxrwxrwx 1 root root 59 2003-02-06 23:40 _Image_XCF.pmod -> ../../../../../share/pike/7.5.3/lib/modules/_Image_XCF.pmod -rw-r--r-- 1 root root 45024 2003-02-06 19:40 _Image_XCF.pmod.o -rw-r--r-- 1 root root 10756 2003-02-06 19:42 _Image_XFace.so lrwxrwxrwx 1 root root 59 2003-02-06 23:40 _Image_XPM.pmod -> ../../../../../share/pike/7.5.3/lib/modules/_Image_XPM.pmod -rw-r--r-- 1 root root 11477 2003-02-06 19:40 _Image_XPM.pmod.o lrwxrwxrwx 1 root root 53 2003-02-06 23:40 Java.pmod -> ../../../../../share/pike/7.5.3/lib/modules/Java.pmod -rw-r--r-- 1 root root 44761 2003-02-06 19:40 Java.pmod.o
so, as far as pike is concerned, the entire tree is in /usr/lib/pike/X.Y.Z/, the module/include paths are:
$ pike7.5 --show-paths master.pike...: /usr/lib/pike/7.5.3/lib/master.pike Module path...: /usr/local/share/pike7.5/site_pike /usr/local/share/pike/site_pike /usr/local/lib/pike7.5/site_pike /usr/local/lib/pike/site_pike /usr/lib/pike/7.5.3/lib/modules Include path..: /usr/local/include/pike7.5 /usr/local/include/pike /usr/lib/pike/7.5.3/lib/include Program path..:
$ pike7.4 --show-paths master.pike...: /usr/lib/pike/7.4.13/lib/master.pike Module path...: /usr/local/share/pike7.4/site_pike /usr/local/share/pike/site_pike /usr/local/lib/pike7.4/site_pike /usr/local/lib/pike/site_pike /usr/lib/pike/7.4.13/lib/modules Include path..: /usr/local/include/pike7.4 /usr/local/include/pike /usr/lib/pike/7.4.13/lib/include Program path..:
Running pike with -t gives the following result (output comes from pike 7.5):
- master.pike: 688: 8298f90->low_findprog("/usr/lib/pike/7.5.3/lib/modules/_Image_SVG",".so",0,1) - master.pike: 516: 8298e58->lock(2) - Return: module.c:67()->Builtin()->mutex_key() - master.pike: 555: 8298f90->master_file_stat("/usr/lib/pike/7.5.3/lib/modules/_Image_SVG.so") - master.pike: 295: 8298f90->combine_path_with_cwd("/usr/lib/pike/7.5.3/lib/modules/_Image_SVG.so") - Return: "/usr/lib/pike/7.5.3/lib/modules/_Image_SVG.so" - master.pike: 297: 8298f90->dirname("/usr/lib/pike/7.5.3/lib/modules/_Image_SVG.so") - Return: "/usr/lib/pike/7.5.3/lib/modules" - master.pike: 325: 82988b8->create() - Return: Stat(-rw-r--r-- 8156b) - master.pike: 555: 82988b8->[](1) - Return: 8156 - master.pike: 560: 82988b8->[](3) - Return: 1044556949
the above lines are the very last ones in the output - after that pike is hung.
Trying to call Image.SVG() renders the same effect - pike is hung. My next step will be to compile the .deb with full debugging info, but I thought that somebody might have a clue as to what's wrong.
TIA,
marek
What does gcc / strace say? That'd be more interesting in this case I think. Either that or higher trace level.
/ David Hedbor
Previous text:
2003-02-12 19:52: Subject: Weird problem with Image.SVG in Pike 7.4/7.5
Hey all,
I'm having a problem with Image.SVG in that when trying to do indices(Image.SVG) then Pike hangs quite badly - the only way to stop it is to kill it. It happens only in the Debian packaged version for both Pike versions, the version compiled from the tarballs works fine. Until recently the Debian package was using the --traditional style of installation, but now it uses a modified --new-style one which in 90% resembles the default style with minor differences:
- all the pike code is installed in /usr/share/pike/X.Y.Z/
- all the binary files (.o, pike, .so) are in /usr/lib/pike/X.Y.Z/
- the files in /usr/share/pike/X.Y.Z/ are symlinked to from the /usr/lib/pike/X.Y.Z/ so that the layout looks like that:
$ pwd /usr/lib/pike/7.5.3/lib/modules ... lrwxrwxrwx 1 root root 59 2003-02-06 23:40 _Image_DWG.pmod -> ../../../../../share/pike/7.5.3/lib/modules/_Image_DWG.pmod -rw-r--r-- 1 root root 6062 2003-02-06 19:40 _Image_DWG.pmod.o -rw-r--r-- 1 root root 10908 2003-02-06 19:42 _Image_FreeType.so -rw-r--r-- 1 root root 39188 2003-02-06 19:42 _Image_GIF.so -rw-r--r-- 1 root root 32844 2003-02-06 19:42 _Image_JPEG.so drwxr-xr-x 2 root root 94 2003-02-06 23:40 _Image.pmod lrwxrwxrwx 1 root root 59 2003-02-06 23:40 _Image_PSD.pmod -> ../../../../../share/pike/7.5.3/lib/modules/_Image_PSD.pmod -rw-r--r-- 1 root root 20777 2003-02-06 19:40 _Image_PSD.pmod.o lrwxrwxrwx 1 root root 58 2003-02-06 23:40 _Image_PS.pmod -> ../../../../../share/pike/7.5.3/lib/modules/_Image_PS.pmod -rw-r--r-- 1 root root 8087 2003-02-06 19:40 _Image_PS.pmod.o -rw-r--r-- 1 root root 768976 2003-02-06 19:42 Image.so -rw-r--r-- 1 root root 8156 2003-02-06 19:42 _Image_SVG.so -rw-r--r-- 1 root root 2964 2003-02-06 19:42 _Image_TIFF.so -rw-r--r-- 1 root root 22540 2003-02-06 19:42 _Image_TTF.so lrwxrwxrwx 1 root root 59 2003-02-06 23:40 _Image_XCF.pmod -> ../../../../../share/pike/7.5.3/lib/modules/_Image_XCF.pmod -rw-r--r-- 1 root root 45024 2003-02-06 19:40 _Image_XCF.pmod.o -rw-r--r-- 1 root root 10756 2003-02-06 19:42 _Image_XFace.so lrwxrwxrwx 1 root root 59 2003-02-06 23:40 _Image_XPM.pmod -> ../../../../../share/pike/7.5.3/lib/modules/_Image_XPM.pmod -rw-r--r-- 1 root root 11477 2003-02-06 19:40 _Image_XPM.pmod.o lrwxrwxrwx 1 root root 53 2003-02-06 23:40 Java.pmod -> ../../../../../share/pike/7.5.3/lib/modules/Java.pmod -rw-r--r-- 1 root root 44761 2003-02-06 19:40 Java.pmod.o
so, as far as pike is concerned, the entire tree is in /usr/lib/pike/X.Y.Z/, the module/include paths are:
$ pike7.5 --show-paths master.pike...: /usr/lib/pike/7.5.3/lib/master.pike Module path...: /usr/local/share/pike7.5/site_pike /usr/local/share/pike/site_pike /usr/local/lib/pike7.5/site_pike /usr/local/lib/pike/site_pike /usr/lib/pike/7.5.3/lib/modules Include path..: /usr/local/include/pike7.5 /usr/local/include/pike /usr/lib/pike/7.5.3/lib/include Program path..:
$ pike7.4 --show-paths master.pike...: /usr/lib/pike/7.4.13/lib/master.pike Module path...: /usr/local/share/pike7.4/site_pike /usr/local/share/pike/site_pike /usr/local/lib/pike7.4/site_pike /usr/local/lib/pike/site_pike /usr/lib/pike/7.4.13/lib/modules Include path..: /usr/local/include/pike7.4 /usr/local/include/pike /usr/lib/pike/7.4.13/lib/include Program path..:
Running pike with -t gives the following result (output comes from pike 7.5):
- master.pike: 688: 8298f90->low_findprog("/usr/lib/pike/7.5.3/lib/modules/_Image_SVG",".so",0,1)
- master.pike: 516: 8298e58->lock(2)
- Return: module.c:67()->Builtin()->mutex_key()
- master.pike: 555: 8298f90->master_file_stat("/usr/lib/pike/7.5.3/lib/modules/_Image_SVG.so")
- master.pike: 295: 8298f90->combine_path_with_cwd("/usr/lib/pike/7.5.3/lib/modules/_Image_SVG.so")
- Return: "/usr/lib/pike/7.5.3/lib/modules/_Image_SVG.so"
- master.pike: 297: 8298f90->dirname("/usr/lib/pike/7.5.3/lib/modules/_Image_SVG.so")
- Return: "/usr/lib/pike/7.5.3/lib/modules"
- master.pike: 325: 82988b8->create()
- Return: Stat(-rw-r--r-- 8156b)
- master.pike: 555: 82988b8->[](1)
- Return: 8156
- master.pike: 560: 82988b8->[](3)
- Return: 1044556949
the above lines are the very last ones in the output - after that pike is hung.
Trying to call Image.SVG() renders the same effect - pike is hung. My next step will be to compile the .deb with full debugging info, but I thought that somebody might have a clue as to what's wrong.
TIA,
marek
/ Brevbäraren
On Wed, Feb 12, 2003 at 08:55:06PM +0100, David Hedbor @ Pike developers forum scribbled:
What does gcc / strace say? That'd be more interesting in this case I think. Either that or higher trace level.
it was done with -t10 and also see the details I gave in the other posting - I'm waiting for the compilation to finish now.
marek
Sounds like _Image_SVG.so halts when it's loaded. I have no idea what that is. It might be in a corresponding libsvg.so, it might not be a Pike problem at all.
A gdb backtrace would probably be informative...
Quick fix: remove _Image_SVG.so.
/ Mirar
Previous text:
2003-02-12 19:52: Subject: Weird problem with Image.SVG in Pike 7.4/7.5
Hey all,
I'm having a problem with Image.SVG in that when trying to do indices(Image.SVG) then Pike hangs quite badly - the only way to stop it is to kill it. It happens only in the Debian packaged version for both Pike versions, the version compiled from the tarballs works fine. Until recently the Debian package was using the --traditional style of installation, but now it uses a modified --new-style one which in 90% resembles the default style with minor differences:
- all the pike code is installed in /usr/share/pike/X.Y.Z/
- all the binary files (.o, pike, .so) are in /usr/lib/pike/X.Y.Z/
- the files in /usr/share/pike/X.Y.Z/ are symlinked to from the /usr/lib/pike/X.Y.Z/ so that the layout looks like that:
$ pwd /usr/lib/pike/7.5.3/lib/modules ... lrwxrwxrwx 1 root root 59 2003-02-06 23:40 _Image_DWG.pmod -> ../../../../../share/pike/7.5.3/lib/modules/_Image_DWG.pmod -rw-r--r-- 1 root root 6062 2003-02-06 19:40 _Image_DWG.pmod.o -rw-r--r-- 1 root root 10908 2003-02-06 19:42 _Image_FreeType.so -rw-r--r-- 1 root root 39188 2003-02-06 19:42 _Image_GIF.so -rw-r--r-- 1 root root 32844 2003-02-06 19:42 _Image_JPEG.so drwxr-xr-x 2 root root 94 2003-02-06 23:40 _Image.pmod lrwxrwxrwx 1 root root 59 2003-02-06 23:40 _Image_PSD.pmod -> ../../../../../share/pike/7.5.3/lib/modules/_Image_PSD.pmod -rw-r--r-- 1 root root 20777 2003-02-06 19:40 _Image_PSD.pmod.o lrwxrwxrwx 1 root root 58 2003-02-06 23:40 _Image_PS.pmod -> ../../../../../share/pike/7.5.3/lib/modules/_Image_PS.pmod -rw-r--r-- 1 root root 8087 2003-02-06 19:40 _Image_PS.pmod.o -rw-r--r-- 1 root root 768976 2003-02-06 19:42 Image.so -rw-r--r-- 1 root root 8156 2003-02-06 19:42 _Image_SVG.so -rw-r--r-- 1 root root 2964 2003-02-06 19:42 _Image_TIFF.so -rw-r--r-- 1 root root 22540 2003-02-06 19:42 _Image_TTF.so lrwxrwxrwx 1 root root 59 2003-02-06 23:40 _Image_XCF.pmod -> ../../../../../share/pike/7.5.3/lib/modules/_Image_XCF.pmod -rw-r--r-- 1 root root 45024 2003-02-06 19:40 _Image_XCF.pmod.o -rw-r--r-- 1 root root 10756 2003-02-06 19:42 _Image_XFace.so lrwxrwxrwx 1 root root 59 2003-02-06 23:40 _Image_XPM.pmod -> ../../../../../share/pike/7.5.3/lib/modules/_Image_XPM.pmod -rw-r--r-- 1 root root 11477 2003-02-06 19:40 _Image_XPM.pmod.o lrwxrwxrwx 1 root root 53 2003-02-06 23:40 Java.pmod -> ../../../../../share/pike/7.5.3/lib/modules/Java.pmod -rw-r--r-- 1 root root 44761 2003-02-06 19:40 Java.pmod.o
so, as far as pike is concerned, the entire tree is in /usr/lib/pike/X.Y.Z/, the module/include paths are:
$ pike7.5 --show-paths master.pike...: /usr/lib/pike/7.5.3/lib/master.pike Module path...: /usr/local/share/pike7.5/site_pike /usr/local/share/pike/site_pike /usr/local/lib/pike7.5/site_pike /usr/local/lib/pike/site_pike /usr/lib/pike/7.5.3/lib/modules Include path..: /usr/local/include/pike7.5 /usr/local/include/pike /usr/lib/pike/7.5.3/lib/include Program path..:
$ pike7.4 --show-paths master.pike...: /usr/lib/pike/7.4.13/lib/master.pike Module path...: /usr/local/share/pike7.4/site_pike /usr/local/share/pike/site_pike /usr/local/lib/pike7.4/site_pike /usr/local/lib/pike/site_pike /usr/lib/pike/7.4.13/lib/modules Include path..: /usr/local/include/pike7.4 /usr/local/include/pike /usr/lib/pike/7.4.13/lib/include Program path..:
Running pike with -t gives the following result (output comes from pike 7.5):
- master.pike: 688: 8298f90->low_findprog("/usr/lib/pike/7.5.3/lib/modules/_Image_SVG",".so",0,1)
- master.pike: 516: 8298e58->lock(2)
- Return: module.c:67()->Builtin()->mutex_key()
- master.pike: 555: 8298f90->master_file_stat("/usr/lib/pike/7.5.3/lib/modules/_Image_SVG.so")
- master.pike: 295: 8298f90->combine_path_with_cwd("/usr/lib/pike/7.5.3/lib/modules/_Image_SVG.so")
- Return: "/usr/lib/pike/7.5.3/lib/modules/_Image_SVG.so"
- master.pike: 297: 8298f90->dirname("/usr/lib/pike/7.5.3/lib/modules/_Image_SVG.so")
- Return: "/usr/lib/pike/7.5.3/lib/modules"
- master.pike: 325: 82988b8->create()
- Return: Stat(-rw-r--r-- 8156b)
- master.pike: 555: 82988b8->[](1)
- Return: 8156
- master.pike: 560: 82988b8->[](3)
- Return: 1044556949
the above lines are the very last ones in the output - after that pike is hung.
Trying to call Image.SVG() renders the same effect - pike is hung. My next step will be to compile the .deb with full debugging info, but I thought that somebody might have a clue as to what's wrong.
TIA,
marek
/ Brevbäraren
On Wed, Feb 12, 2003 at 09:30:08PM +0100, Mirar @ Pike developers forum scribbled:
Sounds like _Image_SVG.so halts when it's loaded. I have no idea what that is. It might be in a corresponding libsvg.so, it might not be a Pike problem at all.
Actually, it probably is. The pike is compiled with gcc 3.2 and I have just compiled pike 7.4 (for debian) without optimizations, with -g3 -ggdb3 and, lo and behold, the problem is gone. Makes me think the compiler overoptimizes something - I'm going to compile pike from tarball with full optimization now to see whether it breaks then. If it does, I will compile it with gcc 2.95 to see whether it happens then as well. I will report back when I have the results.
A gdb backtrace would probably be informative...
Quick fix: remove _Image_SVG.so.
No can do :)
marek
If you're going to use the 3.2.x series, you should at least use 3.2.2 which contains many bugfixes. 3.0.4 is probably more stable, although it depends on which backend you are using.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2003-02-12 21:50: Subject: Re: Weird problem with Image.SVG in Pike 7.4/7.5
On Wed, Feb 12, 2003 at 09:30:08PM +0100, Mirar @ Pike developers forum scribbled:
Sounds like _Image_SVG.so halts when it's loaded. I have no idea what that is. It might be in a corresponding libsvg.so, it might not be a Pike problem at all.
Actually, it probably is. The pike is compiled with gcc 3.2 and I have just compiled pike 7.4 (for debian) without optimizations, with -g3 -ggdb3 and, lo and behold, the problem is gone. Makes me think the compiler overoptimizes something - I'm going to compile pike from tarball with full optimization now to see whether it breaks then. If it does, I will compile it with gcc 2.95 to see whether it happens then as well. I will report back when I have the results.
A gdb backtrace would probably be informative...
Quick fix: remove _Image_SVG.so.
No can do :)
marek
/ Brevbäraren
On Wed, Feb 12, 2003 at 10:45:12PM +0100, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum scribbled:
If you're going to use the 3.2.x series, you should at least use 3.2.2
That's what I have. It's the default compiler in Debian/Sid. Gdb seems to be broken on my development machine with the kernel 2.5 - it cannot set breakpoints. I will try to trace the process with gdb on some other machine with Sid... Frankly, I don't see what might be overoptimized in svg.c - there isn't even the create() function which is what hangs. That makes me think the problem might be somewhere else and Image.SVG is only triggerring it.
marek
Gdb seems to be >broken on my development machine with the kernel 2.5 - it cannot set >breakpoints.
Seems to happen if you use the -ac patch set in 2.4 kernels as well. Quite annoying and the lack breakpoints is only part of the problem. Seems like ptrace() calls fails incorrectly. I don't know if this is a gdb bug but it rather seems like a kernel bug. Took me forever to figure out why my gdb didn't work.
/ David Hedbor
Previous text:
2003-02-12 22:55: Subject: Re: Weird problem with Image.SVG in Pike 7.4/7.5
On Wed, Feb 12, 2003 at 10:45:12PM +0100, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum scribbled:
If you're going to use the 3.2.x series, you should at least use 3.2.2
That's what I have. It's the default compiler in Debian/Sid. Gdb seems to be broken on my development machine with the kernel 2.5 - it cannot set breakpoints. I will try to trace the process with gdb on some other machine with Sid... Frankly, I don't see what might be overoptimized in svg.c - there isn't even the create() function which is what hangs. That makes me think the problem might be somewhere else and Image.SVG is only triggerring it.
marek
/ Brevbäraren
On Wed, Feb 12, 2003 at 11:00:07PM +0100, David Hedbor @ Pike developers forum scribbled:
Gdb seems to be >broken on my development machine with the kernel 2.5 - it cannot set >breakpoints.
Seems to happen if you use the -ac patch set in 2.4 kernels as well. Quite annoying and the lack breakpoints is only part of the problem. Seems like ptrace() calls fails incorrectly. I don't know if this is a gdb bug but it rather seems like a kernel bug. Took me forever to figure out why my gdb didn't work.
It's a gdb bug, AFAIK. And in the 2.5 kernel there is new threading code which breaks gdb even more. It used to work before I last upgraded gdb - so it's not the kernel. Right now pressing 'r' makes gdb halt the process on SIGSTOP and then after 'c' report failure to set breakpoints.
marek
It's possible it's another issue. The issue I saw was not dependent on gdb version however - tried a number of new/old versions and they all failed and it was entirely due to the kernel (strace of the gdb processes showed that 'ptrace' calls failed incorrectly). The 2.5 kernel might very well add additional requirements on the debugger...
/ David Hedbor
Previous text:
2003-02-12 23:21: Subject: Re: Weird problem with Image.SVG in Pike 7.4/7.5
On Wed, Feb 12, 2003 at 11:00:07PM +0100, David Hedbor @ Pike developers forum scribbled:
Gdb seems to be >broken on my development machine with the kernel 2.5 - it cannot set >breakpoints.
Seems to happen if you use the -ac patch set in 2.4 kernels as well. Quite annoying and the lack breakpoints is only part of the problem. Seems like ptrace() calls fails incorrectly. I don't know if this is a gdb bug but it rather seems like a kernel bug. Took me forever to figure out why my gdb didn't work.
It's a gdb bug, AFAIK. And in the 2.5 kernel there is new threading code which breaks gdb even more. It used to work before I last upgraded gdb - so it's not the kernel. Right now pressing 'r' makes gdb halt the process on SIGSTOP and then after 'c' report failure to set breakpoints.
marek
/ Brevbäraren
Ok, I though you said you had 3.2. I wasn't expecting 3.2.2 to be default anywhere yet as it's only been out for 1 week... :-)
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2003-02-12 22:55: Subject: Re: Weird problem with Image.SVG in Pike 7.4/7.5
On Wed, Feb 12, 2003 at 10:45:12PM +0100, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum scribbled:
If you're going to use the 3.2.x series, you should at least use 3.2.2
That's what I have. It's the default compiler in Debian/Sid. Gdb seems to be broken on my development machine with the kernel 2.5 - it cannot set breakpoints. I will try to trace the process with gdb on some other machine with Sid... Frankly, I don't see what might be overoptimized in svg.c - there isn't even the create() function which is what hangs. That makes me think the problem might be somewhere else and Image.SVG is only triggerring it.
marek
/ Brevbäraren
On Wed, Feb 12, 2003 at 11:05:07PM +0100, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum scribbled:
Ok, I though you said you had 3.2. I wasn't expecting 3.2.2 to be default anywhere yet as it's only been out for 1 week... :-)
:-) Debian/Sid has had it for quite some time - it was using the CVS version. Anyhow, now I'm at loss about where to look next... It doesn't seem that Image.SVG is the problem...
marek
It could possibly be a compiler mismatch perhaps - are you sure the svg library is also compiled with gcc 3.2[.2]?
/ David Hedbor
Previous text:
2003-02-12 23:22: Subject: Re: Weird problem with Image.SVG in Pike 7.4/7.5
On Wed, Feb 12, 2003 at 11:05:07PM +0100, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum scribbled:
Ok, I though you said you had 3.2. I wasn't expecting 3.2.2 to be default anywhere yet as it's only been out for 1 week... :-)
:-) Debian/Sid has had it for quite some time - it was using the CVS version. Anyhow, now I'm at loss about where to look next... It doesn't seem that Image.SVG is the problem...
marek
/ Brevbäraren
pike-devel@lists.lysator.liu.se
-
David Hedbor ＠ Pike developers forum -
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum
-
Marek Habersack -
Mirar ＠ Pike developers forum