IRC channel logs

***Server sets mode: +nt

<damo22>youpi: is this the latest version of libpciaccess0? 0.16-1+hurd.1

<damo22>im pretty sure there is a clash of symbols between libpciaccess and rump and so when you run rumpdisk it calls the wrong function

<damo22>or is it the arbiter server and rump

<damo22>hmm the static binary i compiled for rumpdisk has symbols i wasnt expecting

<damo22>08214360 W pci_conf_read

<damo22>080e6f20 T rumpns_pci_conf_read

<damo22>would that be causing a clash? rump vs libhurduser?

<damo22>in the code, it says pci_conf_read

<damo22>but in the symbol table it has rumpns_ prepended to it

<damo22>how does that work?

<youpi>damo22: I don't know

<damo22>i used to use _pic.a libs but my rump package only generates .a libs now and does not seem to detect any disks

<damo22>could that be the problem?

<damo22>maybe its some wierdness with linkage

<youpi>that's possible, yes, print the function addresses to make sure what sees what

<damo22>i am linking the .a libs to a dynamic .so shared object, is that problematic unless i compile the .a with -fPIC?

<damo22>eg libmachdevrump.so.0.3 is linked with all the necessary rump .a libs

<damo22>i would prefer to use all dynamic linkage but rump does not seem to work that way, you have to link the rump libs you want for each driver into the binary otherwise the symbols are unresolved and the autodetection of device drivers does not work

<damo22>i'll have to recompile rump tomorrow

<janneke>what would be the appropriate list to discuss the "kill -KILL -1" problem? the discussion now lives in bug-guix: https://lists.gnu.org/archive/html/bug-guix/2020-03/msg00149.html

IRC channel logs

2020-03-13.log