Hi, This is a rather long message, not only from a single person. But I'll try to answer inline and give a summary at the end, to start sorting things out. On Tue, 2010-12-14 at 16:34 -0600, Martin Holste wrote:
I do recall that spoof-source would not work on SLES 10--I had to upgrade to SLES 11.2 in order to get the non-broken libnet.
I think that was an unrelated problem. In that case syslog-ng could be built, but the checksum of packets were not correctly calculated.
On Tue, Dec 14, 2010 at 4:18 PM, Matthew Hall <mhall@mhcomputing.net> wrote:
megahall@logproxy2:~$ readelf -d /home/y/lib64/syslog-ng/libafsocket.so
Dynamic section at offset 0x19978 contains 29 entries: Tag Type Name/Value 0x0000000000000001 (NEEDED) Shared library: [libsyslog-ng.so.0] 0x0000000000000001 (NEEDED) Shared library: [libssl.so.108] 0x0000000000000001 (NEEDED) Shared library: [libcrypto.so.108] 0x0000000000000001 (NEEDED) Shared library: [libdl.so.2] 0x0000000000000001 (NEEDED) Shared library: [libz.so.1] 0x0000000000000001 (NEEDED) Shared library: [libwrap.so.0] 0x0000000000000001 (NEEDED) Shared library: [libpthread.so.0] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] 0x000000000000000e (SONAME) Library soname: [libafsocket-tls.so] 0x000000000000000f (RPATH) Library rpath: [/home/y/lib64:/usr/lib64] ...
It looks to me like libafsocket itself is built broken because it does not declare its libnet dependency that it picks up when spoof source is enabled.
Hmm.. this is strange. In my build of syslog-ng, libafsocket.so is linked against libnet (and I also build into a private prefix): 0x0000000000000001 (NEEDED) Shared library: [libsyslog-ng.so.0] 0x0000000000000001 (NEEDED) Shared library: [libssl.so.0.9.8] 0x0000000000000001 (NEEDED) Shared library: [libcrypto.so.0.9.8] 0x0000000000000001 (NEEDED) Shared library: [libdl.so.2] 0x0000000000000001 (NEEDED) Shared library: [libnet.so.1] <--- 0x0000000000000001 (NEEDED) Shared library: [libwrap.so.0] 0x0000000000000001 (NEEDED) Shared library: [libpthread.so.0] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] the thing that determines whether afsocket is linked against libnet or not is LIBNET_LIBS variable as detected by the configure script. You can check your config.status script to see your value, mine has this: $ grep LIBNET_LIBS config.status S["LIBNET_LIBS"]="-lnet" This is pasted into the libafsocket.so linker command line, in modules/afsocket/Makefile.am
Matthew.
According to the glib API:
First of all g_module_open() tries to open file_name as a module. If that fails and file_name has the ".la"-suffix (and is a libtool archive) it tries to open the corresponding module. If that fails and it doesn't have the proper module suffix for the platform (G_MODULE_SUFFIX), this suffix will be appended and the corresponding module will be opended. If that fails and file_name doesn't have the ".la"-suffix, this suffix is appended and g_module_open() tries to open the corresponding module. If eventually that fails as well, NULL is returned.
So in order for 210 to get executed to write the message, g_module_open must have had NULL retval.
As above, this could happen when:
opening as a module fails opening as a module.la fails opening as a module.platform_suffix fails opening as a module.platform_suffix.la fails
The error returned from g_module_error gets output as:
/home/y/lib64/syslog-ng/libafsocket.so: undefined symbol: libnet_build_ipv4 /home/y/lib64/syslog-ng/libafsql.so: undefined symbol: dbi_result_free
Wondering what to try now to debug it further.
The glib .la parser peek out 3 values from the .la file: installed dlname libdir these are used to locate the .so file and the dependency loading is not affected. (those are performed by the dynamic linker).
Matthew.
On Tue, Dec 14, 2010 at 11:18:37AM -0800, Matthew Hall wrote:
Hello,
I'm aware of rpath overall but not an expert at its usage as I have not needed it for previous environments I've used. I have been using:
export CFLAGS="-I /home/y/include" export LDFLAGS="-Wl,-rpath,/home/y/lib64"
and my libs are:
/home/y/lib64/libnet.so.1.5.0: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), stripped /home/y/lib64/libdbi.so.1.0.0: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped /home/y/lib64/dbd/libdbdmysql.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped /home/y/lib64/dbd/libdbdsqlite3.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped
with all the usual symlinks.
The readelf shows the rpath is as follows on each:
Library rpath: [/home/y/lib64]
Strace seems to show that the libnet and libdbi don't get opened (whether I follow parent or child syslog-ng).
What could I try next? My thought was perhaps GDB but that will get very messy very quickly. :-(
The root cause seems to be that your afsocket.so is not linked against libnet.so It'd be wise to check out the link command line and the LIBNET_LIBS value suggested above. -- Bazsi