Fred: Try this change to Makefile.in in gdchart0.94c
[bstrauss@tigger gdchart0.94c]$ cvs diff Makefile.in Index: Makefile.in =================================================================== RCS file: /export/home/ntop/gdchart0.94c/Makefile.in,v retrieving revision 1.3 diff -r1.3 Makefile.in 28c28 < /bin/rm -f $(GD_LIB)/libpng-1.0.8/*.so* --- > /bin/rm -f $(GD_LIB)/libpng-1.2.1/*.so* Maybe, just maybe, ld is favoring the .so it finds in that directory, instead of the .a??? That could also be why some people have to run make install. Otherwise, do you have gd installed? Perhaps that has a shared call to libpng?? -----Burton -----Original Message----- From: Fred Grayson [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 18, 2002 10:21 AM To: Burton M. Strauss III Subject: RE: [Ntop] libpng Hi, I did have that 1.2.2 package from rawhide installed, but I have since removed it and that didn't help. I have also tried on other RH 7.3 machines where that package wasn't installed and I get the same result. I also did some other experimentation, with the same result: I downloaded your RC2 SRPM and did a rpm --rebuild on it. This failed immediatly because I don't have a requirement, MySQL-Add (I think). So I edited that, and only that out of the spec file. Then I did rpm - bb against the edited spec. This produced the rpm. But when I went to install it, it still failed with the libpng.so.3 dependency problem! I tried this on the other two RH 7.3 machines with identical results. So, like I said, it appears to be a packaging quirk. I can install the rpm with --nodeps and it runs fine. I'm not having any other apparent problems with it at all. And the rpms I make with my old spec file from snapshot that also have this dependency problem work fine too; I just force them on with --nodeps. As to RH rawhide and the 1.2.2, when I tried to upgrade to that the first time it said a whole ton of things were going to be broken by dependencies, so I balked. When I looked into this further on an install vs an upgrade, only the man page would have been overwrittten, so instead of upgrading libpng, I just installed the new 1.2.2 alongside and let it overwrite the man page. That left both the old and new versions installed with no other conflicts that I'm aware of. But, as I said, I removed 1.2.2 to try and solve this. Hope this provides some more clues, but I think you have it nailed, it's somewhere in the make files. On Tue, 18 Jun 2002 09:53:25 -0500, Burton M. Strauss III wrote: >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-dev mailing list [EMAIL PROTECTED] http://lists.ntop.org/mailman/listinfo/ntop-dev
