Update embedded libproc version #37

Closed
ghedo opened this Issue Jul 3, 2012 · 8 comments

Comments

Projects
None yet
4 participants
Contributor

ghedo commented Jul 3, 2012

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?

@gajdusek gajdusek added a commit to gajdusek/ulatencyd that referenced this issue Aug 27, 2012

@gajdusek gajdusek Remove embedded libproc and coreutils, use system libprocps (issue #37)
WARNING: Current libprops does not export enough symbols. See this patch:
https://gitorious.org/~gajdusek/procps/ulatencyd-procps/commit/9d710916bc0bd0f8b91aa7bc5cc541c51ab6846e
I hope for soon merge :)

Removed features (though not used anywhere):
- temporary disable U_PROC.groups : needs adapt to new libprocps
- proc_t.nsupgid unavailable now

Other changes:
- remove src/proc/*, src/corutils/*
- update make system
- update core.c: free u_task/u_proc simply by calling freeproc()

Signed-off-by: Petr Gajdůšek <gajdusek.petr@centrum.cz>
b30c5ef

iavael commented Mar 24, 2013

Commit gajdusek/ulatencyd@b30c5ef broke ulatency build on fedora 17

pkg_check_modules(LIBPROC libprocps REQUIRED)

This piece of code doesn't work.

Collaborator

gajdusek commented Mar 24, 2013

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: 6947c5d. 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 gajdusek#1

iavael commented Mar 24, 2013

You will need libprocps.a

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

Collaborator

gajdusek commented Mar 24, 2013

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.

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

Collaborator

gajdusek commented Feb 17, 2014

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.

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 added the libprocps label Feb 17, 2014

gajdusek self-assigned this Feb 17, 2014

Collaborator

gajdusek commented Feb 17, 2014

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.

gajdusek closed this Feb 17, 2014

gajdusek added this to the 0.6.0 milestone Mar 2, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment