dynamic linking against procps is broken

[Szpadel]

used symbols are no longer exported in liblary lua_binding.c:(.text+0x1f51): undefined reference to vminfo' lua_binding.c:(.text+0x1f6a): undefined reference tovm_nr_dirty' lua_binding.c:(.text+0x1f98): undefined reference to vm_nr_writeback' lua_binding.c:(.text+0x1fc6): undefined reference tovm_nr_pagecache' etc.

[gajdusek]

Hi,

used symbols are no longer exported in liblary

This is known issue in procps that probably will not be fixed soon, if ever. Dynamic linking almost anything against procps is currently broken and unsupported. Procps is being rewritten and in the meantime things may become even worse (more symbols removed). I also doubt the rewritten library would export all symbols ulatencyd needs. See e.g. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=685962

You should simple static link with libprocps.a file that SHOULD be provided by your distribution, probably in procps dev package and be placed along the libprocps.so file (in directory defined in pkgconfig libprocps.pc). Ulatencyd cmake system will detect this and use for static linking.

Run "ccmake ." and check that static linking is enabled (should be by default) and the libprocps.a file was found: STATIC_LINK_LIBPROCPS ON
STATIC_LINK_LIBPROCPS_PATH /usr/lib/x86_64-linux-gnu/libprocps.a

If libprocps.a is missing, bug your distributor and compile procps yourself. Then change STATIC_LINK_LIBPROCPS_PATH to generated libprocps.a.

If you really want to link against shared libprocps.so you must patch it to export more symbols, but be aware they will probably break ABI without bumping SO version so you should take care about this.

Let me know, Petr

[Szpadel]

I using Gentoo distro, and I trying write ebuild using your version of ulatencyd. did you think we can grab this variables from /proc/vmstat? We can write something like simple library for this. What you thinking about this?

[gajdusek]

did you think we can grab this variables from /proc/vmstat? We can write something like simple library for this.

That's an option but we depend on other things procps provides, mainly /proc parsing and then there are other issues with procps being dynamic linked with.

procps issue 1: procps does not export even the essential freeproc(). You seem not suffer with this, maybe it is already fixed, I should check.

procps issue 2: being rewritten, ABI is not stable at all and SO versions seems not being updated. Two of declared goals are to remove global variables and unneeded exports, so it may become unusable for ulatencyd. I would wait for the surprise ;-)

Outlined several options: 1) Include procps source in ulatencyd source tree the same way it is done in original ulatencyd. Drawbacks: a) outdated library, b) multiple sources of same library of different versions in distribution - security issue - bugs must be fixed everywhere. This is the reason I have decided to remove embedded libproc copy. In ulatencyd the embedded library was patched to fix some bugs and to suite better ulatencyd needs but this is not needed anymore. If you want I can create branch to reintroduce embedded library.

2) Just static link with system library. In Debian it is tracked what libprocps version ulatency was built with and auto rebuild if needed. This should fix above issues. I know nothing about Gentoo, but IMHO you will have similar mechanism just because Gentoo is source based. So if a bug gets fixed in liprocps, the ulatencyd will be (auto) rebuild - much better then point 2. And I think you should have an option to leave libprocps.a after procps was built, as currently the only safe way to use libprocps is static linking with it.

3) Dynamic link to libprocps and use it only for /proc parsing and get other info in other ways. But before this procps issues 1 and 2 must get fixed.

4) Stop using procps at all, as it parse /proc for information we don't need or we need only on demand.

Currently the 2) works pretty good. I would wait until procps gets rewritten and then take decision what do next.

Cheers, and sorry for my bad English, Petr