[syslog-ng] load failures in afsocket and afsql

[Matthew Hall]

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 at 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 at 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 at logproxy2:~$ readelf -a /home/y/lib64/syslog-ng/libafsocket.so | fgrep -i rpath
> >>  0x000000000000000f (RPATH)              Library rpath: [/home/y/lib64]
> >> megahall at logproxy2:~$ readelf -a /home/y/lib64/syslog-ng/libafsql.so | fgrep -i rpath
> >>  0x000000000000000f (RPATH)              Library rpath: [/home/y/lib64]
> >> megahall at logproxy2:~$
> >>
> >> megahall at logproxy2:~$ ldd /home/y/lib64/syslog-ng/libafs* | fgrep -i '(dbi|net)'
> >> megahall at 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
>