Yeah, it doesn't build - I have patches, but I'm actually trying to finish the thing instead of another band aid - anyone willing to test, let me know off list.
As I said last time (http://listgateway.unipi.it/pipermail/ntop-dev/2004-June/004677.html), those are just pass-throughs from the dlsym() calls. You'll have to figure out what is causing the OS to whine about that... From the 4.9 man page: The dlsym() function returns the address binding of the symbol described in the null-terminated character string symbol, as it occurs in the shared object identified by handle. The symbols exported by objects added to the address space by dlopen() can be accessed only through calls to dlsym(). Such symbols do not supersede any definition of those sym- bols already present in the address space when the object is loaded, nor are they available to satisfy normal dynamic linking references. If dlsym() is called with the special handle NULL, it is interpreted as a reference to the executable or shared object from which the call is being made. Thus a shared object can reference its own symbols. If dlsym() is called with the special handle RTLD_DEFAULT, the search for the symbol follows the algorithm used for resolving undefined symbols when objects are loaded. The objects searched are as follows, in the given order: 1. The referencing object itself (or the object from which the call to dlsym() is made), if that object was linked using the -Wsymbolic option to ld(1). 2. All objects loaded at program start-up. 3. All objects loaded via dlopen() which are in needed-object DAGs that also contain the referencing object. 4. All objects loaded via dlopen() with the RTLD_GLOBAL flag set in the mode argument. If dlsym() is called with the special handle RTLD_NEXT, then the search for the symbol is limited to the shared objects which were loaded after the one issuing the call to dlsym(). Thus, if the function is called from the main program, all the shared libraries are searched. If it is called from a shared library, all subsequent shared libraries are searched. RTLD_NEXT is useful for implementing wrappers around library functions. For example, a wrapper function getpid() could access the ``real'' getpid() with dlsym(RTLD_NEXT, "getpid"). If dlsym() is called with the special handle RTLD_SELF, then the search for the symbol is limited to the shared object issuing the call to dlsym() and those shared objects which were loaded after it. The dlsym() function returns a null pointer if the symbol cannot be found, and sets an error condition which may be queried with dlerror(). It's got to relate to your creation of the symbolic links, since that's the only thing you are doing that seems outside the norm. Permissions or some such... I note that on my box, those files are NOT symlinks: $ ls -l /usr/lib/ntop/plugins total 1564 -rwxr-xr-x 1 ntop ntop 166375 Feb 28 12:31 icmpPlugin.so -rwxr-xr-x 1 ntop ntop 159189 Feb 28 12:32 lastSeenPlugin.so -rwxr-xr-x 1 ntop ntop 226551 Feb 28 12:32 netflowPlugin.so -rwxr-xr-x 1 ntop ntop 156803 Feb 28 12:33 pdaPlugin.so -rwxr-xr-x 1 ntop ntop 230969 Feb 28 12:33 rrdPlugin.so -rwxr-xr-x 1 ntop ntop 281010 Feb 28 12:34 sflowPlugin.so -rwxr-xr-x 1 ntop ntop 147144 Feb 28 12:33 snmpPlugin.so -rwxr-xr-x 1 ntop ntop 148602 Feb 28 12:34 xmldumpPlugin.so The code that does it is loadPlugin() in plugin.c ... There's an old thread http://www.mail-archive.com/[email protected]/msg18291.html re the rtld program... The rtld code is here: http://www.freebsd.org/cgi/cvsweb.cgi/src/libexec/rtld-elf/rtld.c If you look there, dlcheck() is what's issuing the message, based on zero ref counts. dlinfo() calls dlcheck(), and dlsym() is what calls dlinfo(). Since you're not getting "unable to load", the call to dlopen() is working, but the subsequent call to dlsym() is failing. So it seems as though it's calling dlsym(). You could try instrumenting the code, but I doubt it will show much since you're already getting the reflected error. -----Burton -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Cole Sent: Monday, February 28, 2005 3:43 PM To: [email protected] Subject: [Ntop-dev] Ntop 3.1.1 and Freebsd 4.x Plugin Problem Hey. I have a Freebsd server running freebsd-4.9-stable. I cvsupped the ntop src last week for 3.1.1. I then had no problems what so ever building ntop, except for the xml plugin saying it was not built, cause it cannot find xmlversion.h, even though I have libxml installed, and specified the right paths to the .h. But that is not the problem. Ntop runs and works fine on this box, not a single problem that I can see. The problem is that, I have a few other servers, that I want to copy ntop too, but dont want to build it on all those boxes. I created a tar with all the ntop binaries, as well as all the libraries that its linked too, as well as all the plugins that ntop uses from both the /usr/local/lib directory as well as the plugins from the /usr/local/lib/ntop/plugins directory. I rebuilt all the symbolic links for all the libraries and plugins and all the files that ntop was linked too. I have also checked all the permissions on all the files and they are all the same. One other thing, the boxes that I am copying ntop to, are almost exact duplicates of the first box that I built ntop on, and where it works fine. The problem is, when running ntop on the boxes that I copied it to, after checking all the permissions and links and everything, I get these errors with regards to the plugins. Tue Mar 1 05:37:16 2005 **WARNING** Unable to locate plugin '/usr/local/lib/ntop/plugins/icmpPlugin.so' entry function [Invalid shared object handle 0x29a14000] Tue Mar 1 05:37:16 2005 **WARNING** Unable to locate plugin '/usr/local/lib/ntop/plugins/snmpPlugin.so' entry function [Invalid shared object handle 0x29a16400] Tue Mar 1 05:37:16 2005 **WARNING** Unable to locate plugin '/usr/local/lib/ntop/plugins/sflowPlugin.so' entry function [Invalid shared object handle 0x29a19800] Tue Mar 1 05:37:16 2005 **WARNING** Unable to locate plugin '/usr/local/lib/ntop/plugins/rrdPlugin.so' entry function [Invalid shared object handle 0x29a1bc00] Tue Mar 1 05:37:16 2005 **WARNING** Unable to locate plugin '/usr/local/lib/ntop/plugins/pdaPlugin.so' entry function [Invalid shared object handle 0x2bcae400] Tue Mar 1 05:37:16 2005 **WARNING** Unable to locate plugin '/usr/local/lib/ntop/plugins/netflowPlugin.so' entry function [Invalid shared object handle 0x2d862800] Tue Mar 1 05:37:16 2005 **WARNING** Unable to locate plugin '/usr/local/lib/ntop/plugins/lastSeenPlugin.so' entry function [Invalid shared object handle 0x2d866c00] Tue Mar 1 05:37:16 2005 **WARNING** Unable to locate plugin '/usr/local/lib/ntop/plugins/xmldumpPlugin.so' entry function [Invalid shared object handle 0x2f697000] I have absolutely no idea how this has happened, and I have had this problem before, and not a single other person was able to help me in any regards what so ever. I was hoping maybe someone would at least know what this error even means, so that I have some idea of what I am meant to be doing to fix this. If anyone has any idea, I would gladly apprecaite any suggestions. Thanks /Cole _______________________________________________ Ntop-dev mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop-dev _______________________________________________ Ntop-dev mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop-dev
