[users at i-scream] libstatgrab issues on Solaris 10 x64
Scott Severtson
ssevertson at digitalmeasures.com
Mon May 21 21:53:52 BST 2012
All,
We're just getting started with libstatgrab as part of a CollectD
installation, and have run into a problem with 0.17 on Solaris 10 x64.
The project builds successfully using GCC, and installs cleanly. The
"statgrab" binary appears to function without errors, and returns
appropriate and correct metrics.
However, when attempting to compile a very simple C program against
libstatgrab, we get a large number of undefined symbols. Here's the
simple test program (extracted/simplified from CollectD's configure script):
int sg_init ();
int main ()
{
return sg_init ();
}
And here's the GCC invocation/output:
# gcc -o conftest -O3 -m64 -march=athlon64
-I/apps/collectd-5.1.0/include -L/apps/collectd-5.1.0/lib -lstatgrab
conftest.c -lstatgrab
Undefined first referenced
symbol in file
kstat_data_lookup /apps/collectd-5.1.0/lib/libstatgrab.so
di_devfs_path_free /apps/collectd-5.1.0/lib/libstatgrab.so
kstat_lookup /apps/collectd-5.1.0/lib/libstatgrab.so
di_drv_first_node /apps/collectd-5.1.0/lib/libstatgrab.so
di_drv_next_node /apps/collectd-5.1.0/lib/libstatgrab.so
di_instance /apps/collectd-5.1.0/lib/libstatgrab.so
di_devfs_path /apps/collectd-5.1.0/lib/libstatgrab.so
socket /apps/collectd-5.1.0/lib/libstatgrab.so
kstat_read /apps/collectd-5.1.0/lib/libstatgrab.so
kstat_open /apps/collectd-5.1.0/lib/libstatgrab.so
kstat_close /apps/collectd-5.1.0/lib/libstatgrab.so
di_fini /apps/collectd-5.1.0/lib/libstatgrab.so
di_init /apps/collectd-5.1.0/lib/libstatgrab.so
di_minor_name /apps/collectd-5.1.0/lib/libstatgrab.so
di_minor_next /apps/collectd-5.1.0/lib/libstatgrab.so
ld: fatal: Symbol referencing errors. No output written to conftest
collect2: ld returned 1 exit status
The "ldd" utility shows that libstatgrab.so is only linking against a
couple libraries:
# ldd lib/libstatgrab.so
libc.so.1 => /lib/64/libc.so.1
libgcc_s.so.1 => /usr/sfw/lib/64/libgcc_s.so.1
libm.so.2 => /lib/64/libm.so.2
Including lazy references results in the same list of missing symbols as
GCC/ld specifies:
# ldd -r lib/libstatgrab.so
libc.so.1 => /lib/64/libc.so.1
libgcc_s.so.1 => /usr/sfw/lib/64/libgcc_s.so.1
symbol not found: kstat_open (./libstatgrab.so)
symbol not found: kstat_read (./libstatgrab.so)
symbol not found: kstat_close (./libstatgrab.so)
symbol not found: kstat_lookup (./libstatgrab.so)
symbol not found: kstat_data_lookup (./libstatgrab.so)
symbol not found: socket (./libstatgrab.so)
symbol not found: di_init (./libstatgrab.so)
symbol not found: di_drv_first_node (./libstatgrab.so)
symbol not found: di_minor_next (./libstatgrab.so)
symbol not found: di_instance (./libstatgrab.so)
symbol not found: di_devfs_path (./libstatgrab.so)
symbol not found: di_minor_name (./libstatgrab.so)
symbol not found: di_devfs_path_free (./libstatgrab.so)
symbol not found: di_drv_next_node (./libstatgrab.so)
symbol not found: di_fini (./libstatgrab.so)
libm.so.2 => /lib/64/libm.so.2
However, "ldd" on the statgrab binary shows many more linked libraries:
# ldd bin/statgrab
libstatgrab.so.6 => /apps/collectd-5.1.0/lib/libstatgrab.so.6
libkstat.so.1 => /lib/64/libkstat.so.1
libdevinfo.so.1 => /lib/64/libdevinfo.so.1
libsocket.so.1 => /lib/64/libsocket.so.1
libnsl.so.1 => /lib/64/libnsl.so.1
libc.so.1 => /lib/64/libc.so.1
libgcc_s.so.1 => /usr/sfw/lib/64/libgcc_s.so.1
libnvpair.so.1 => /lib/64/libnvpair.so.1
libsec.so.1 => /lib/64/libsec.so.1
libgen.so.1 => /lib/64/libgen.so.1
libmp.so.2 => /lib/64/libmp.so.2
libmd.so.1 => /lib/64/libmd.so.1
libscf.so.1 => /lib/64/libscf.so.1
libavl.so.1 => /lib/64/libavl.so.1
libdoor.so.1 => /lib/64/libdoor.so.1
libuutil.so.1 => /lib/64/libuutil.so.1
libm.so.2 => /lib/64/libm.so.2
Does anyone understand why the statgrab binary has appropriate linking
in place, but libstatgrab.so does not? Are there any configuration flags
or environment variables I could include to enable/enforce correct linking?
Many thanks,
--Scott
More information about the users
mailing list