#370 closed defect (wontfix)
libpng conflicts PHP version of libpng causes php/mapscript to crash
Reported by: | Owned by: | dmorissette | |
---|---|---|---|
Priority: | high | Milestone: | 5.2 release |
Component: | MapScript-PHP | Version: | 4.0 |
Severity: | major | Keywords: | |
Cc: | ed@… |
Description (last modified by )
I think is really a php mapscript build problem. Anyway here is the scenerio: We built mapserver, php/mapscript (3.7 may 2nd and 4.0b2) with php 4.3.1 and 4.3.2 and were using gd-2.0.12 and gd-2.0.15 built with gif support on RH8.0 with latest rpm updates also had gdal-1.1.8 and gdal-1.1.9. Everything works fine when we use mapserv cgi for both gif and png image generation. The problem came when we switched our mapfiles to generate PNG and all the mapscript apps broke on the call to $oImg->SaveImage(...) in mapscript. After rebuilding most of the combinations above, I rebuilt PHP without --with-pdflib as just adding --without-png didnot clear the problem. So the following worked: ./configure \ --enable-force-cgi-redirect \ --enable-discard-path \ --with-config-file-path=/etc/httpd/ \ --without-png \ --with-gd=/usr/local \ --with-jpeg-dir \ --with-zlib-dir \ --with-freetype-dir \ --without-ttf \ --with-mysql \ --with-regex=system \ --with-ming \ --enable-dbase \ --enable-dbx while this did NOT work: rm -f config.cache ./configure \ --enable-force-cgi-redirect \ --enable-discard-path \ --with-config-file-path=/etc/httpd/ \ --with-png \ --with-gd=/usr/local \ --with-jpeg-dir \ --with-zlib-dir \ --with-freetype-dir \ --without-ttf \ --with-mysql \ --with-regex=system \ --with-pdflib \ --with-ming \ --enable-dbase \ --enable-dbx Recommended action: 1) someone needs to see if they can reproduct this problem 2) because it is subtle and very difficult to debug, and appropriate fix needs to be added to ./configure AND/OR better yet the code needs to be changed to allow this to work in either case. Commentary: I'm not sure that this has anything to do with the problem, but reading up on the libpng it seems that there are two (2) versions of the API that are not compatible, but apparently have the same entry points. I surmise that libpdf is causing the new api to be loaded and that the php_mapscript.so is expecting the old api, so when we call the png entry point from mapscript is crashes, but when we call the same entry point from CGI mapserv we have loaded the old version of the libpng since both version are installed on the system.
Change History (9)
comment:2 by , 21 years ago
My copy of pdflib-4.0.2 comes with libpng 1.0.8 and according to the PDF configure script this internal copy of PNG would be used by default. So you're right, by default you end up with two versions of libpng and this is bad. Can you try rebuilding pdflib using '--with-pnglib=/usr --with-zlib=/usr' and see if that fixes your problem.
comment:3 by , 21 years ago
Daniel, Thank you for looking at this. We have been using the RH8 RPM version of pdflib. I guess I will have to ditch that and build it from source. I am kind of surprised that RH doesn't build all their RPMs pointing at common system libs, instead of package internal libs! Here are ldd lists from a system that I think is built with this problem. I think the last listing confirms the libpdf is statically linked with internal libpng as it does not show it as an external reference. Is this how you read this? [root@strabo03 root]# ldd /usr/lib/libpng.so libz.so.1 => /usr/lib/libz.so.1 (0x4002c000) libm.so.6 => /lib/i686/libm.so.6 (0x4003b000) libc.so.6 => /lib/i686/libc.so.6 (0x42000000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000) [root@strabo03 root]# ldd /usr/lib/libpng12.so libz.so.1 => /usr/lib/libz.so.1 (0x4002c000) libm.so.6 => /lib/i686/libm.so.6 (0x4003b000) libc.so.6 => /lib/i686/libc.so.6 (0x42000000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000) [root@strabo03 root]# ls -l /usr/lib/libpng* -rw-r--r-- 1 root root 169444 Jan 8 2003 /usr/lib/libpng12.a lrwxrwxrwx 1 root root 13 Jun 20 17:31 /usr/lib/libpng12.so -> libpng12.so.0 lrwxrwxrwx 1 root root 19 Jan 29 10:10 /usr/lib/libpng12.so.0 -> libpng12.so.0.1.2.2 -rwxr-xr-x 1 root root 160715 Jan 8 2003 /usr/lib/libpng12.so.0.1.2.2 lrwxrwxrwx 1 root root 10 Jun 20 17:31 /usr/lib/libpng.a -> libpng12.a lrwxrwxrwx 1 root root 19 Jun 20 17:31 /usr/lib/libpng.so -> libpng12.so.0.1.2.2 lrwxrwxrwx 1 root root 18 Jan 29 10:10 /usr/lib/libpng.so.2 -> libpng.so.2.1.0.13 -rwxr-xr-x 1 root root 155775 Dec 19 2002 /usr/lib/libpng.so.2.1.0.13 lrwxrwxrwx 1 root root 19 Jan 29 10:10 /usr/lib/libpng.so.3 -> libpng12.so.0.1.2.2 lrwxrwxrwx 1 root root 19 Jan 29 10:10 /usr/lib/libpng.so.3.1.2.2 -> libpng12.so.0.1.2.2 [root@strabo03 root]# ldd /var/www/cgi-bin/php libpdf.so.1 => /usr/lib/libpdf.so.1 (0x4001d000) libz.so.1 => /usr/lib/libz.so.1 (0x400ad000) libpng12.so.0 => /usr/lib/libpng12.so.0 (0x400bb000) libming.so => /usr/lib/libming.so (0x400de000) libm.so.6 => /lib/i686/libm.so.6 (0x4011b000) libgd.so.2 => /usr/local/lib/libgd.so.2 (0x4013d000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x4018d000) libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x401d7000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x401f5000) libresolv.so.2 => /lib/libresolv.so.2 (0x40222000) libdl.so.2 => /lib/libdl.so.2 (0x40234000) libnsl.so.1 => /lib/libnsl.so.1 (0x40237000) libc.so.6 => /lib/i686/libc.so.6 (0x42000000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) [root@strabo03 root]# ldd /etc/httpd/php_mods/php_mapscript.so libcurl.so.2 => /usr/lib/libcurl.so.2 (0x400b5000) libz.so.1 => /usr/lib/libz.so.1 (0x400da000) libssl.so.2 => /lib/libssl.so.2 (0x400e8000) libcrypto.so.2 => /lib/libcrypto.so.2 (0x40118000) libdl.so.2 => /lib/libdl.so.2 (0x401ec000) libming.so => /usr/lib/libming.so (0x401ef000) libgdal.1.1.so => /usr/local/lib/libgdal.1.1.so (0x4022c000) libpthread.so.0 => /lib/i686/libpthread.so.0 (0x40488000) libproj.so.0 => /usr/local/lib/libproj.so.0 (0x404d8000) libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x40506000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x40524000) libpng12.so.0 => /usr/lib/libpng12.so.0 (0x4056d000) libpdf.so.1 => /usr/lib/libpdf.so.1 (0x40590000) libgd.so.2 => /usr/local/lib/libgd.so.2 (0x40620000) libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x40670000) libm.so.6 => /lib/i686/libm.so.6 (0x40722000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40744000) libc.so.6 => /lib/i686/libc.so.6 (0x42000000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000) [root@strabo03 root]# [root@strabo03 root]# ls -l /usr/local/lib/libgd.* -rw-r--r-- 1 root root 802780 Jun 23 12:55 /usr/local/lib/libgd.a -rwxr-xr-x 1 root root 750 Jun 23 12:55 /usr/local/lib/libgd.la lrwxrwxrwx 1 root root 14 Jun 23 12:55 /usr/local/lib/libgd.so -> libgd.so.2.0.0 lrwxrwxrwx 1 root root 14 Jun 23 12:55 /usr/local/lib/libgd.so.2 -> libgd.so.2.0.0 -rwxr-xr-x 1 root root 545347 Jun 23 12:55 /usr/local/lib/libgd.so.2.0.0 [root@strabo03 root]# ldd /usr/local/lib/libgd.so.2.0.0 libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x40059000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x40078000) libpng12.so.0 => /usr/lib/libpng12.so.0 (0x400c1000) libz.so.1 => /usr/lib/libz.so.1 (0x400e4000) libm.so.6 => /lib/i686/libm.so.6 (0x400f2000) libc.so.6 => /lib/i686/libc.so.6 (0x42000000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000) [root@strabo03 root]# [root@strabo03 root]# ls -l /usr/lib/libpdf.* -rw-r--r-- 1 root root 773970 Jun 7 2001 /usr/lib/libpdf.a -rw-r--r-- 1 root root 641 Jun 7 2001 /usr/lib/libpdf.la lrwxrwxrwx 1 root root 15 Jun 20 16:15 /usr/lib/libpdf.so -> libpdf.so.1.1.1 lrwxrwxrwx 1 root root 15 Jun 20 16:15 /usr/lib/libpdf.so.1 -> libpdf.so.1.1.1 -rwxr-xr-x 1 root root 663046 Jun 7 2001 /usr/lib/libpdf.so.1.1.1[root@strabo03 root]# ldd /usr/lib/libpdf.so.1.1.1 libc.so.6 => /lib/i686/libc.so.6 (0x42000000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000) [root@strabo03 root]#
comment:4 by , 21 years ago
> I think the last listing confirms the libpdf is statically linked with internal > libpng as it does not show it as an external reference. Is this how you read > this? Yes, that's also the way I read this too. What surprises me is that we never had problems using pdflib inside the mapserv CGI. We've probably just been lucky with the order in which symbols are loaded in this case I guess.
comment:6 by , 17 years ago
I don't use this configuration any more, so I will leave this up to Daniel. This is pretty well documented, so Daniel might want to see if anyone on his team can reproduce it. There have been a lot of Linux changes since this was filed and I don't even have access to a RH Linux any more. Other than that it is probably safe to close as "over come by events"
comment:7 by , 17 years ago
Milestone: | → 5.2 release |
---|
comment:8 by , 16 years ago
Resolution: | → wontfix |
---|---|
Status: | assigned → closed |
Closing WONTFIX since there have been no other reports of the issue, so while it may still exist this is a very low priority. For anyone encountering this, a simple workaround is to build pdflib without the builtin copy of libpng.
comment:9 by , 16 years ago
Thank you Daniel, this seems to be well documented in the bug so I'm ok with this resolution.