CentOS problem with libpcap and tcpdump
 

Hi there!
In order to install tcpdump-4.1.1 I had to install libpcap-1.1.1. They said on the tcpdump's site, "for CentOS install it from a source", so I did it.

First bell started ringing when I noticed that built library was still in the directory where I extracted .tar.gz, and not in the /usr/lib64/
When I installed tcpdump from source, and tried to start it, instead of tcpdump4.1.1 it was still 3.9.4 with 0.9.4 libpcap.

I noticed no errors. I even tried to grep errors. This is all I got.
Of course - I installed both with sequence ./configure -> make -> make install, all after extracting it from .tar.gz., like I said installation went smooth, so it must be that I forgot to do something else in between. But, what?
Any help?!
PLEASE

Hi,

Try :
If there is now such file search with

hombre, you're truly good! :) Told me just what I need to hear! Now I need some more help :)

For those who might be experiencing same problem, and hopefully for some developer who is about to see this. I located libpcap, and haven't done the same with tcpdump. So, when I did what you said goodhombre, I found that:
1. installing newer version haven't removed older one(I know I'm stupid :) I thought it would detect older version and upgrade it), so I had two versions of tcpdump(/usr/sbin and /usr/local/sbin), and each time I issued the command older version had been invoked. So that was inital problem...
2. I had to remove both versions and than reinstall the new version. I must notice I had problem uninstalling tcpdump because "make uninstall" didn't delete all tcpdump files, so I had to do it manually :(
3. Installing tcpdump to /usr/sbin and libpcap to /usr/lib64 caused error I can't quote, but is something like: (!no path!)tcpdump: Couldn't open object file (!no path!)`libpcap.so.1': no such file. Recipe with linking mentioned by @nx5000 in topic "problem with libpcap" didn't work for me either.

REMEDY: I finally uninstalled both tcpdump and libpcap, cleaned system of tcpdump files(best I could) and reinstalled it to predefined locations. One more notice is that installing tcpdump to the predefined location without cleaning the system of rests of earlier installation caused the fail as well.

PROBLEM: I can only start tcpdump by entering absolute path /usr/local/sbin/tcpdump. If I type just tcpdump, error message appears that says it can't find tcpdump in /usr/sbin
Problem is that both "/usr/local/sbin" and "/usr/sbin/" are in the $PATH, so I'm wondering why does system insist on /usr/sbin path, and how can I change that, except by creating link placed in the /usr/sbin.
Thanks in advance :)

Nothing as easy as that. If you truly want to contribute something you must email their user or development mailing list or file a bug report, not post here. In the end it's PEBCAK and not a problem with the OS or any userland packages.

Now confining alien package versions to a different subtree like /usr/local and then exporting the required LD_LIBRARY_PATH (or use ldconfig) so new tcpdump could pick up new libraries should work, but you could have avoided all of this if you would just have created the required packages then upgrade them instead of installing from source and destabilizing and polluting your system in the process.


If you didn't clear the system using package management then there may be dangling symlinks (unlikely), user-configured shell aliases (unlikely) or scripted location replacements (highly unlikely) pointing to the previous binary location. More likely, if in your user account `echo $PATH` shows to have /usr/sbin before /usr/local/sbin (which makes sense efficiency-wise), then the shell will try to exec the binary in /usr/sbin as long as it's hashed in your current shell session. Logging out and back in should fix hashing but exporting your PATH statement, placing /usr/local/sbin before /usr/sbin, should fix execution problems.

You were right, all I needed to do is to logout, so hash could be emptied. Everything works just fine now.

I searched the web for how to make rpm from source and easily found a lot of materials about it. Thank you very much for the hint :)
I didn't think it was OS, I thought it was person in tcpdump team responsible for "make". All right, maybe I am P that EBCAK :), but shouldn't "./configure && make && make uninstall" clean the system of ALL the files "make install" injected during installation?!? What did I miss, or did wrong, so it is my fault, that it wasn't uninstaled properly???