Update embedded libproc version

[ghedo]

The embedded libproc version is quite outdated, and, among other things, doesn't recognize two-component kernel versions, which are perfectly normal. It would be nice if it could be updated.

It would be even nicer if ulatencyd could use a system-provided libproc instead of embedding it, is there any progress on that front?

[iavael]

Commit https://github.com/gajdusek/ulatencyd/commit/b30c5ef10c63b978e16a2f8addd5ed4a02761944 broke ulatency build on fedora 17

pkg_check_modules(LIBPROC libprocps REQUIRED)

This piece of code doesn't work.

[gajdusek]

You need patched libproc to export more symbols or use static linking. The later is better option and support for it is implemented in next commit: 6947c5dc28cb9037d5ba88278d5f1d079cf47f94. You will need libprocps.a that should be in libprocps-dev package or similar - I am not Fedora user. So you probably just need to add libprocps-dev (libprocps0-dev on Debian) to build dependencies.

See https://github.com/gajdusek/ulatencyd/issues/1

[iavael]

You will need libprocps.a

There is no such file in procps-devel package in fedora. Was your patch for procps accepted in upstream?

[gajdusek]

It wasn't, and I removed the pull request later. AFAIK the procps is being heavily rewritten and the finalized interface will be a lot different, they won't to export more symbols in current state, even those most obvious and complementing those already exported.

Currently dynamic linking to libprocps is mostly useless for most use cases, the only way is static linking. I think you should request Fedora procps maintainers to include static library to the -dev package. Then in the ulatencyd source package you should track what procps version it was built with, so e.g. security team can rebuild ulatency if a security bug gets fixed in procps. I don't how the "built-with" is tracked in Fedora but this is obvious better than have arbitrary version of procps code duplicated in ulatencyd.

[Hubbitus]

Hello.

Currently dynamic linking to libprocps is mostly useless for most use cases Why?

In most cases static libs inclusion is forbidden in Fedora by guidelines: http://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Static_Libraries_2

[gajdusek]

Hi, sorry for late answer.

Currently dynamic linking to libprocps is mostly useless for most use cases Why?

Short answer: missing symbols and unstable API. see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=685962

From Debian README for libproc-dev

It is generally a bad idea to dynamically link to libproc. The API changes a fair bit and I cannot guarantee that it will stay the same between minor versions (though it will stay the same between Debian versions). I've now re-included the libproc.a file so use that.

libprocps 3.3.9 still missing symbols (not sure if the list is complete):

group_from_gid

kb_inact_laundry, kb_inact_dirty, kb_inact_clean, kb_inact_target, kb_swap_cached, kb_writeback, kb_slabkb_committed_as, kb_dirty, kb_mapped, kb_pagetables

vminfo, vm_nr_dirty, vm_nr_writeback, vm_nr_pagecache, vm_nr_page_table_pages, vm_nr_reverse_maps, vm_nr_mapped, vm_nr_slab, vm_pgpgin, vm_pgpgout, vm_pswpin, vm_pswpout, vm_pgalloc, vm_pgfree, vm_pgactivate, vm_pgdeactivate, vm_pgfault, vm_pgmajfault, vm_pgscan, vm_pgrefill, vm_pgsteal, vm_kswapd_steal, vm_pageoutrun vm_allocstall

Therefore I think procps should have Fedora -static package.

Petr.

[Hubbitus]

What about procps-ng? And there no -static package in Fedora:

$ repoquery 'procps' procps-ng-0:3.3.8-15.fc20.i686 procps-ng-0:3.3.8-15.fc20.x86_64 procps-ng-devel-0:3.3.8-15.fc20.i686 procps-ng-devel-0:3.3.8-15.fc20.x86_64

[gajdusek]

Hi, I am closing this issue because it was fixed by removing embedded libproc from ulatencyd source tree nearly a year ago.

I created new issue #48 to track the ulatency inability to dynamically link with procps (alias procps-ng). Hubbitus, can we move there? I will post reply to your last post there.

Petr.