Fred - can you grab MY rpm from SourceForge and install that without doing
the rebuild? Even if you have to install mySQL client
I'm suspicious of your rpm given the line I found in the makefile. I
haven't been able to make my rpm fail, even with gd and libpng et al
installed. And ur-tigger is a vanilla RedHat 7.2...
What happens may be this:
First ntop's ./configure looks for libgdchart.a in the directory specified
by --with-gdchart-root=. If it's not found, then it looks in gdchart0.94c.
Same thing for libgd.a and libpng...
If it finds them, it sets
MORELIBS="${MORELIBS} -L$GDCHART_ROOT -lgdchart -L$GDCHART_ROOT/gd-1.8.3 -lg
d -L$GDCHART_ROOT/gd-1.8.3/libpng-1.2.1 -lpng -L$GDCHART_ROOT/zlib-1.1.4 -lz
"
But, comes link time, if ld finds a .so in there, it prefers the .so to the
.a, regardless of the test it used!
You might try adding this patch to your ntop.spec:
--- RC2/gdchart0.94c/Makefile.in.orig Tue Jun 18 18:10:14 2002
+++ RC2/gdchart0.94c/Makefile.in Tue Jun 18 18:10:27 2002
@@ -26,5 +26,5 @@
$(GD_LIB)/libgd.a:
cd $(GD_LIB) ; $(MAKE) -f Makefile libgd.a
- /bin/rm -f $(GD_LIB)/libpng-1.0.8/*.so*
+ /bin/rm -f $(GD_LIB)/libpng-1.2.1/*.so*
libgdchart.a: gdc.o gdc_pie.o gdchart.o price_conv.o
That should delete the .so, so that ld uses the .a
Other things to do...
run ldd on your installed ntop. You should see something like this:
[ntop@ur-tigger ntop]$ ldd /usr/sbin/ntop
libntopreport-2.0.so.99 => /usr/lib/libntopreport-2.0.so.99
(0x4001b000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x400d4000)
libm.so.6 => /lib/libm.so.6 (0x40101000)
libssl.so.2 => /lib/libssl.so.2 (0x40123000)
libcrypto.so.2 => /lib/libcrypto.so.2 (0x40150000)
libpthread.so.0 => /lib/libpthread.so.0 (0x40213000)
libresolv.so.2 => /lib/libresolv.so.2 (0x4022b000)
libnsl.so.1 => /lib/libnsl.so.1 (0x4023d000)
libdl.so.2 => /lib/libdl.so.2 (0x40254000)
libntop-2.0.so.99 => /usr/lib/libntop-2.0.so.99 (0x40258000)
libpcap.so.0.6.2 => /usr/lib/libpcap.so.0.6.2 (0x404a0000)
libgdbm.so.2 => /usr/lib/libgdbm.so.2 (0x404bb000)
libc.so.6 => /lib/libc.so.6 (0x404c2000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
(Note no refs to libpng or libgd), not like this:
[bstrauss@tigger ntop]$ ldd /usr/bin/ntop
libntopreport-2.0.so.99 => /usr/lib/libntopreport-2.0.so.99
(0x40027000)
libmysqlclient.so.10 => /usr/lib/mysql/libmysqlclient.so.10
(0x40096000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x400cb000)
libm.so.6 => /lib/i686/libm.so.6 (0x400f8000)
>> libz.so.1 => /usr/lib/libz.so.1 (0x4011b000)
>> libgd.so => /usr/lib/libgd.so (0x40129000)
>> libpng12.so.0 => /usr/lib/libpng12.so.0 (0x4015a000)
libssl.so.2 => /lib/libssl.so.2 (0x40186000)
libcrypto.so.2 => /lib/libcrypto.so.2 (0x401b3000)
libntop-2.0.so.99 => /usr/lib/libntop-2.0.so.99 (0x40276000)
libpcap.so.0.6.2 => /usr/lib/libpcap.so.0.6.2 (0x404c1000)
libgdbm.so.2 => /usr/lib/libgdbm.so.2 (0x404dc000)
libpthread.so.0 => /lib/i686/libpthread.so.0 (0x404e4000)
libresolv.so.2 => /lib/libresolv.so.2 (0x404f9000)
libnsl.so.1 => /lib/libnsl.so.1 (0x4050b000)
libdl.so.2 => /lib/libdl.so.2 (0x40521000)
libc.so.6 => /lib/i686/libc.so.6 (0x40525000)
libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x40661000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
I'm building a new rpm to test the patch (if this is the problem, then
fixing the makefile would mean gdchart would use the static gd built as part
of ntop, regardless of whether you have a gd installed). That build is now
telling me:
Requires: glibc openssl gdbm ncurses libpcap ld-linux.so.2 libc.so.6
libcrypt.so.1 libcrypto.so.2 libdl.so.2 libgdbm.so.2 libm.so.6
libncurses.so.5 libnsl.so.1 libntop-2.0.so.99 libntopreport-2.0.so.99
libpcap.so.0.6.2 libpthread.so.0 libresolv.so.2 libssl.so.2 /bin/sh
libc.so.6(GLIBC_2.0) libc.so.6(GLIBC_2.1) libc.so.6(GLIBC_2.1.3)
libcrypt.so.1(GLIBC_2.0) libdl.so.2(GLIBC_2.0) libdl.so.2(GLIBC_2.1)
libm.so.6(GLIBC_2.0) libpthread.so.0(GLIBC_2.0) libpthread.so.0(GLIBC_2.1)
Again, note no libgd!
Let me know!
-----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
