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. :-( Matthew. On Tue, Dec 14, 2010 at 02:58:47PM +0100, Sandor Geller wrote:
Hello,
I don't think this is related to glib at all, sounds like a linker issue due to missing RPATHs.
`libnet-config --libs` doesn't give library paths, just outputs '-lnet'. Similarly 'libnet-config --defines' doesn't contain header location so CFLAGS and LDFLAGS should get adjusted by the build environment.
I added "-I<libnet_prefix>/include" to CFLAGS and "-L<libnet_prefix>/lib -Wl,-rpath,<libnet_prefix>/lib" to LDFLAGS.
Without the -rpath linker option the app could get built but won't run.
Don't know about DBI as I'm not using it. In theory its pkgconfig should contain all needed paths. AFAIK upstream libdbi still doesn't have pkgconfig support so probably a cvs snapshot should get used.
hth,
Sandor
On Tue, Dec 14, 2010 at 6:17 AM, Martin Holste <mcholste@gmail.com> wrote:
Hm, I know I ran into something similar to this a long time ago, but I'm having a hard time remembering exactly how I fixed it. I do believe that it had something to do with needing to install some dev RPM's, but I don't want to go on record as saying that will definitely fix this. Obviously, though, it might be good to triple-check that you've got -devel on everything.
Also, since your libs are in a non-standard place, it could also be a bug in that values that work during the configure step are not getting passed as macros everywhere they need to be in the make step. You may want to try editing your ld.so.conf to include your custom lib location if you haven't already and running ldconfig -v to make sure it's being linked.
Finally, if you're building the dependency libs from source as well, making sure that there aren't any other "make" steps that need to be done is another one to check off. I believe some libs need "make shared" (libpcap, for one).
I don't know if any of these will fix the problem, but they can't hurt to verify.
On Mon, Dec 13, 2010 at 8:12 PM, Matthew Hall <mhall@mhcomputing.net> wrote:
I am getting the following on load:
Error opening plugin module; module='afsocket', error='/home/y/lib64/syslog-ng/libafsocket.so: undefined symbol: libnet_build_ipv4' Error opening plugin module; module='afsql', error='/home/y/lib64/syslog-ng/libafsql.so: undefined symbol: dbi_result_free' Error opening plugin module; module='afsocket', error='/home/y/lib64/syslog-ng/libafsocket.so: undefined symbol: libnet_build_ipv4'
The rpath looks OK:
megahall@logproxy2:~$ readelf -a /home/y/lib64/syslog-ng/libafsocket.so | fgrep -i rpath 0x000000000000000f (RPATH) Library rpath: [/home/y/lib64] megahall@logproxy2:~$ readelf -a /home/y/lib64/syslog-ng/libafsql.so | fgrep -i rpath 0x000000000000000f (RPATH) Library rpath: [/home/y/lib64] megahall@logproxy2:~$
megahall@logproxy2:~$ ldd /home/y/lib64/syslog-ng/libafs* | fgrep -i '(dbi|net)' megahall@logproxy2:~$
The libraries are in a reasonable location:
/home/y/lib64/libdbi.so.1.0.0 /home/y/lib64/libnet.so.1.5.0 /home/y/lib64/dbd/libdbdsqlite3.so /home/y/lib64/dbd/libdbdmysql.so /home/y/lib64/libnet.so.1 /home/y/lib64/libdbi.so.1 /home/y/lib64/libdbi.so
Reading through the glib docs for glib modules, it seems like the .la files are maybe not containing the right library dependencies, or something like this. However adding the library directories using LD_LIBRARY_PATH as a temporary test does not help.
Because this step fails, it's not possible to use tcp, udp, or any of the other important drivers you need to collect logs.
I could really use some advice on this one!
Matthew. ______________________________________________________________________________ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.campin.net/syslog-ng/faq.html
______________________________________________________________________________ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.campin.net/syslog-ng/faq.html
______________________________________________________________________________ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.campin.net/syslog-ng/faq.html