http://www.libpng.org/pub/png/libpng.html
"libpng is available as ANSI C source code and requires zlib 1.0.4 or later (1.1.4 recommended due to a potential security vulnerability in earlier versions). The current public release, libpng 1.2.3, has a new API (since 1.0.x) for dynamically enabling and disabling certain optimizations (currently limited to MMX code--which is compiled into GNU C versions only if PNG_THREAD_UNSAFE_OK is defined, due to the gcc code's use of static global variables to work around addressing limitations). As a consequence of this and some other changes, its DLL and shared-library (.so) numbers were bumped from 2 to 3." Basically, it seems that there are two versions of libpng, 1.0.x and 1.2.x. And there are library incompatibilities. Instead of 1.2.x supporting the old calls they trap them and die with the message we've all seen. Nowhere on ur-tigger (the UML machine I do the rpms on) do I have libpng.so.3 (the link I listed was on tigger where I do my development). ur-tigger is a normal RedHat machine with normal RedHat rpms installed. (Tigger is another story, but irrelevant and Pooh is worse): [ntop@ur-tigger ntop]$ locate libpng.so /usr/lib/libpng.so.2.1.0.12 /usr/lib/libpng.so.2 [ntop@ur-tigger ntop]$ ls -l /usr/lib/libpng* lrwxrwxrwx 1 root root 18 Apr 28 11:01 /usr/lib/libpng.so.2 -> libpng.so.2.1.0.12 -rwxr-xr-x 1 root root 131560 Jul 16 2001 /usr/lib/libpng.so.2.1.0.12 I guess the question is whether you've installed the 1.2.2 version from rawhide (http://www.rpmfind.net//linux/RPM/rawhide/1.0/i386/RedHat/RPMS/libpng-1.2.2 -5.i386.html)? That would create the .3 (incompatible) library. At snapshot, I documented a procedure for updating a RedHat system to 1.2.x from source. But that's more manual than I'd like (and irrelevant now that 1.2.x rpms have been released on RawHide). It appears that RedHat have stayed with 1.0.x - probably because it would require co-req updates of a number of packages. Which means I need to update the ntop.spec file to specify the version, vs. just requiring libpng. I'm puzzled - I had expected, however, that following the procedure in BUILD-NTOP.txt, to create the rpms would make a static linked ntop, and that would make the rpm version irrelevant - I guess I need to look over the Makefile too... -----Burton Install date: Sun Apr 28 21:39:23 2002 Build Host: stripples.devel.redhat.com Group : System Environment/Libraries Source RPM: libpng-1.0.12-2.src.rpm Size : 354504 License: distributable Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla> URL : http://www.libpng.org/pub/png/ Summary : A library of functions for manipulating PNG image format files. Description : The libpng package contains a library of functions for creating and manipulating PNG (Portable Network Graphics) image format files. PNG is a bit-mapped graphics format similar to the GIF format. PNG was created to replace the GIF format, since GIF uses a patented data compression algorithm. Libpng should be installed if you need to manipulate PNG format image files. /usr/lib/libpng.so.2 /usr/lib/libpng.so.2.1.0.12 /usr/share/doc/libpng-1.0.12 /usr/share/doc/libpng-1.0.12/CHANGES /usr/share/doc/libpng-1.0.12/README /usr/share/doc/libpng-1.0.12/TODO /usr/share/doc/libpng-1.0.12/example.c /usr/share/doc/libpng-1.0.12/libpng.txt /usr/share/man/man5/png.5.gz -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Fred Grayson Sent: Saturday, June 15, 2002 10:47 AM To: [EMAIL PROTECTED] Subject: Re: [Ntop] libpng Hi, I'm seeing something similar here on RH 7.3. I've been building rpms from the daily snapshots for quite some time with no problems at all. However, the very day when libpng went to 1.2.1 in the ntop source, a problem did come up. The rpms build fine, but when I try to install them I get a failure due to a dependency not being met for libpng.so.3. I just force install them with a --nodeps switch and they work fine, so I haven't looked into this any further. I do have the same link as you do: /usr/lib/libpng.so.3 -> libpng12.so.0.1.2.2. Looks like a packaging quirk here. >You are right, you're rambling <grin />... read on... > >On my Linux box, libpng.so.3 is a link to the real library: > >[bstrauss@tigger ntop-current]$ ls -l /usr/lib/libpng.so.3 >lrwxrwxrwx 1 root root 19 Apr 18 10:19 >/usr/lib/libpng.so.3 -> libpng12.so.0.1.2.2 > >Doing a cp will create a copy, not another link. If you then update libpng, >you have a version mismatch... > >The message - as described in the FAQ entry - occurs because RedHat (and >probably other distros although I decline to claim knowledge about them) >have already installed shared versions (.so) of the libpng libraries of >particular (peculiar) versions. > >That's why the standard ntop instructions tell you to build a STATIC version >(.a) of the libraries and links against that. You build STATIC against a >version, you run STATIC against the same version ... no mismatch errors. > >Somehow you didn't do that - get it all static - or the .so wouldn't have >mattered. > >Now I did notice that the file in the cvs still has the old version numbers >for zlib and libpng, so I'll update that. But the right versions were the >only ones present in the .tgz. (I just checked). > >Perhaps you commingled two downloads (one with the old versions) and then >did build 1.0.8 and 1.2.1? The Makefile does use 1.2.1 for the .h files... >that might cause the problem, but I'm still clueless about the .so issue, it >shouldn't have happened. > >Sorry, but in the absence of more info, if I haven't guessed correctly >above, I'm going to tag this as user error, given that 10s or 100s of people >have followed those instructions on a huge variety of distros w/o problem... > _______________________________________________ Ntop mailing list [EMAIL PROTECTED] http://lists.ntop.org/mailman/listinfo/ntop _______________________________________________ Ntop mailing list [EMAIL PROTECTED] http://lists.ntop.org/mailman/listinfo/ntop
