=== bigon` is now known as bigon
=== _bigon is now known as bigon`
=== bigon` is now known as bigon
=== bigon is now known as bigon`
=== bigon` is now known as bigon
=== bigon is now known as bigon`
james_wHi, do you use a second channel when a session is running for people asking questions etc?18:48
db-keenthis channel is empty when sessions are not running18:49
Kirrusjames_w, sometimes, depending on the session18:50
james_wKirrus: is there one existing, or is it just set up when needed?18:58
=== bigon` is now known as bigon
* slangasek scribbles on the chalkboard19:19
=== bigon is now known as bigon`
=== bigon` is now known as bigon
mok0slangasek: I brought an apple for you19:44
slangasekplease tell me you aren't talking about an airbook19:44
=== bigon is now known as bigon`
=== bigon` is now known as bigon
sistpotyhi everyone20:02
sistpotyhehe, finished the text in the last minute :)20:02
* slangasek sits at attention20:03
mok0Am I the only student?20:03
sistpotyanyone else here for the library packaging session?20:03
james_wI am20:03
* warp10 raises an hand :)20:04
mok0Ah, more students than teachers...20:04
* db-keen lurks in a seat at the back of the room20:04
sistpotymaybe we'll wait five more minutes before we start?20:04
warp10okay for me20:04
sistpotyor just start right away?20:04
slangasekI think it would be more respectful of the time of those who are here to go ahead and start, and if there are latecomers we can recap for them at the end?20:05
slangasek(or point them at a log and invite questions)20:05
mok0Is there some text we need to look at?20:06
james_wI agree.20:06
sistpotyok, that's fine, so let's get started :)20:06
sistpotyso a big welcome to everyone for joining the motu school session about library packaging20:06
sistpotythe session will be split in two parts:20:06
sistpotyin the first part, we'll dive deeply into the background of shared objects, and how to find out information about theses20:07
sistpotyand in the second part, we'll go through creating a library package by example20:07
sistpotyso let's start with part 120:07
sistpotyFirst off, shared objects are useful for two different purposes20:07
sistpoty1) as a plugin mechanism in conjunction with dlopen20:08
sistpoty2) for dynamic libraries, to share code between different projects20:08
sistpotyas this is about library packaging, we'll be only looking at 2) in this session20:08
sistpotyFirst off, (ELF) shared objects are a collection of symbols in different sections together with some meta-information20:09
sistpotya symbol denotes a named entity in C (e.g. a function or a variable)20:09
sistpotythe section will give us some detail about the symbol20:09
sistpotybtw.: if you have questions, just ask ;)20:10
sistpotylet's take a look at an example: http://www.potyra.de/library_packaging/example.c20:10
sistpotyso please everyone download the file20:10
sistpotyeveryone got it?20:11
sistpotygreat, so let's compile the file:20:11
sistpotygcc -c example.c -o example.o20:11
sistpotyso far, the .o is just a normal object, not a shared object yet... however we can do some stuff with it already20:12
sistpotynow run20:12
sistpotynm example.o20:12
sistpotythe output are the different symbols defined in example.c20:12
mok0what are the letters U, T, t...20:14
sistpotyfor example in line 3, the variable "static_global" is results as symbol "0000000000000000 d static_global"20:14
sistpotymok0: will talk about that in a second ;)20:14
sistpotywhen you compare the output of nm, together with the variables of example.c, does anyone see anything odd?20:14
sistpotyI'll give you a hint: look at the beginning of the function local_function20:15
sistpotynow, anyone?20:16
warp10why local_var isn't listed?20:16
sistpotywarp10: excellent20:16
mok0it's allocated on the call stack20:16
geserwhy does static_local_var has a number in the nm output (here: static_local_var.2268)?20:17
sistpotyexcactly... some symbols in C (like local_var) don't need to be stored anywhere, because these are located in the stack20:17
sistpotyok, and some variables (like static_local_var) won't result in the same symbols as they are named. This is because the variable is not visible anywhere but in the function, and you can name a variable like this anywhere else20:18
slangasekgeser: that's a very good question whose answer I don't remember :)20:18
sistpotyand you cannot have two symbols with the same name of course20:18
mok0geser: could that number be the offset?20:18
sistpotyany more questions or shall we go to the funny letters?20:19
slangasekmok0: it's not the offset20:19
warp10What's the order with which symbols are listed by nm?20:19
sistpotywarp10: good question: slangasek?20:19
slangasekplain alphabetical20:20
siretartslangasek: in order to avoid name clashes between different static local variables with the same name in different functions?20:20
sistpotymok0: I guess it's just a counted number gcc will assign, but I may err on this side20:20
mok0sistpoty: my number is != gesers20:20
gesermok0: it could be the line number after including all headers. after changeing the line with the previous one the number is now 226720:20
slangaseksiretart: probably, yes20:21
sistpotymok0: he, ah20:21
mok0 static_local_var.178120:21
slangaseksiretart, geser: suffice to say, it goes away once you've linked the object into a shared library, so it ends up not being very relevant20:21
sistpotyok, then now let's take a look at the letters.20:22
sistpotyFirst off, some are lower case and some are upper case.20:22
slangasekgeser: it isn't the line number; if I run the source through gcc -E, I get line 75720:22
sistpotyThe lower case letters denominate local symbols. Noone except this very object file can see these kind of symbols20:22
mok0lower case == local, Upper case == global20:23
sistpotywhereas the upper case letters mean that the symbol is global, and other object files are global... exactly.20:23
sistpotythe letter denote the type of the symbol:20:23
sistpotyt -> text section (may be mapped readonly), executable20:23
sistpotyd -> initialized data (statics, initialized globals)20:23
sistpoty(as in variables)20:23
sistpotyc -> uninitialized data (uninitialized global variables)20:24
sistpotyr -> read only data (const variables), not necessarily read only though.20:24
slangasek(btw, if you later don't remember what these letters map to, they're listed in man nm)20:24
sistpotyand then there's an interesting one: u20:24
sistpotythis means that the symbol is not defined in the object, but somewhere else20:24
slangasekto clarify, that means the object *refers* to the symbol but does not define it20:25
sistpotyso "stderr" is listed there, as it comes somewhere from the c library, as well as fprintf20:25
sistpotyok, now let's make a shared object from this file:20:26
sistpotygcc -Wl,-z,defs -Wl,-soname,libexample.so.1 -fPIC -shared example.c -o libexample.so20:26
sistpotyeveryone got it?20:27
sistpotyok, now let's look again at it with nm20:27
sistpoty(you can ignore anything with an underscore, that's internal stuff)20:29
bddebiannm is like objdump?20:29
slangasekI might suggest at this point also running 'nm -D libexample.so', for comparison20:29
sistpotyerm... sorry, we need to do another thing I forgot... let's first strip off the debugging symbols20:29
sistpotystrip libexample.so20:30
slangasek... or that :)20:30
gesernm: libexample.so: no symbols20:30
mok0that's easy :-)20:31
sistpotyok, to look at the dynamic symbols, you'll now want nm -D as slangasek suggested20:31
slangasekright - since we strip binaries by default, 'nm foo.so' in the wild is going to give you empty output20:32
geserthe local symbols aren't listed anymore?20:32
sistpotywhat you'll see is that there are now (apart from some internals) only global symbols left. i.e. everything not defined as "static"20:32
sistpoty(side note: the static modifier in c means that the resulting symbol will be a local symbol)20:33
sistpotyany questions so far? then let's try some other tools on the shared object20:34
mok0sistpoty: well, global to the functions in that file20:34
sistpotymok0: yes, a local global *g*20:34
slangasekgeser: since they're local, they're by definition not accessible to other things linking to this code; so aside from debugging symbols, which we've used 'strip' to wipe out, there's no reason to take up space by keeping around names for these variables20:34
sistpotyok, now let's take a look at the meta-information:20:35
sistpotyobjdump -x libexample.so20:35
sistpotythis will give lots of info. The most interesting stuff can be found with objdump -p libexample.so as well20:36
bddebianWho uses anything more than |grep SONAME? ;-)20:37
sistpotyone thing that's in there is the SONAME, we'll take a look at it later20:37
* slangasek raises his hand20:37
sistpotythe other thing in there is the NEEDED entry (or entries)20:37
sistpotythe SONAME denotes the ABI-Verison of the shared object...20:38
sistpotyeverything with the same SONAME can be considered to be compatible20:38
geserif upstream doesn't make a mistake20:39
sistpotythe NEEDED entries denote what libraries this shared object needs. These refer to the SONAME of other libraries20:39
bddebiangeser: Never happens ;)20:39
slangasekeverything with the same SONAME *will be* considered compatible by ld.so, so it darn well better *be* compatible :)20:39
sistpotygeser: we'll just see what happens then ;)20:39
sistpotyI guess everyone knows ldd, let's try that one20:40
sistpotyldd libexample.so20:40
* bddebian doesn't know anything20:40
nxvl_worki'm late again :(20:41
sistpotyldd will resolve any shared libraries a binary or a shared object needs20:41
geseris linux-vdso.so.1 provided by the kernel?20:42
sistpotyso, what's the difference between the NEEDED entries and the output of ldd apart from the pathname?20:42
slangasekgeser: yes, linux-vdso is a bit of Magic20:42
warp10ldd output shows three entries, not just one20:43
geserldd resolves them recursively20:43
* bddebian thinks geser is too smart for this class :)20:43
sistpotyexactly what geser said :)20:43
geserbddebian: :P20:43
sistpotyso you should keep these in mind when dealing with shared objects, as you might want to look at the *direct* dependencies as well20:43
james_wldd resolves recursively?20:44
sistpotyjames_w: yes20:44
slangasekyes; for a real world-example, have a look at ldd /usr/lib/libgnome-2.so.0, vs. objdump -p /usr/lib/libgnome-2.so.0 | grep NEEDED20:44
slangasekso we've looked at the output of nm -D on this object, but nm -D has one weakness as a tool which is not at all obvious if you don't already know what's missing20:45
slangasekhave a look at the output of nm -D libexample.so again20:46
slangaseknow, compare it to the output of readelf -s libexample.so20:46
slangasekwho can spot the difference in the names?20:46
bddebianThe stuff from @@glibc?20:47
geseryou mean the versioned symbols?20:47
slangasekyep - nm -D doesn't show symbol versions20:47
slangasekso if you want to get at those, you'll want to use objdump -T or readelf -s20:48
geserwhat does the "(2)" in "6: 0000000000000000   144 FUNC    GLOBAL DEFAULT  UND fprintf@GLIBC_2.2.5 (2)" mean?20:48
slangaseksymbol versions are sometimes important, so you'll want to keep these tools in mind -- sometimes, an app/lib will not know the symbol version it's supposed to use, and that indicates a bug!20:48
slangasekgeser: I'm not sure, sorry20:49
slangasekI'd probably have to look at the readelf source to figure that out, the fields aren't all well-explained in the documentation20:50
mok0we can write a dependency resolver from these tools20:50
slangasekmok0: indeed, dpkg-shlibdeps uses these tools20:50
sistpotyok, any more questions so far?20:51
sistpotyWhen writing a program, that uses a library, we want to make sure that the API of that library is stable.20:51
sistpotyIf we want to distribute this program, we also want a stable ABI.20:52
sistpotystable API means that my program compiles against the library and a newer version of it.20:52
sistpotystable ABI means that the symbols stay the same20:52
mok0what if there are new symbols?20:53
sistpotymok0: of course... I just wanted to correct myself20:53
sistpotystable ABI means that there won't get any symbols removed, and their meaning is still the same20:53
james_wsistpoty: if you have a stable API it means if you compiled against it you will be able to link against it?20:54
sistpotyjames_w: no, that would be stable ABI20:54
sistpotyjames_w: it means you can compile against it again20:54
geserjames_w: you can also link against an unstable API/ABI but you need to rebuild everytime the API/ABI changes20:54
sistpoty(w.o. changing your code)20:54
james_wsistpoty: sorry, that's what I meant.20:54
mok0If you write code that corrects a bug, but the interface remains the same?20:55
sistpotymok0: then the ABI and API is stable20:55
sistpoty(most likely)20:56
mok0... but I would still want that programs exclusively use the fixed version20:56
sistpotybut let's first have some fun... as some newby upstream started to produce a library...20:56
gesermok0: if I'm correct you can change the implementation as long as function name, arguments and return type stay the same20:56
sistpotymok0: you can do this (as upstream) only, if the library have some version string or date encoded20:57
sistpotymok0: or by advetising it on your homepage *g*20:57
mok0you can bump the minor version number20:57
sistpotyfor the library: yes (I'll come to this part yet)20:58
chiptoxichow do you tell if a library has a stable API or ABI is it just by watching the version numbers of that library?20:58
sistpotychiptoxic: I'd like to postpone this question, as I first want to show you an example20:58
sistpotyso please everyone get <http://www.potyra.de/library_packaging/libmyhello-1.0.1.tar.gz>20:59
sistpotyif you've got it, extract it and compile it with20:59
sistpotythen install the result (as root) with21:00
sistpotymake install21:00
sistpoty(no worries, it will only copy files to the /usr/local/ namespace, and make uninstall removes it again)21:00
sistpotyeveryone got so far? (then me types the commands as well)21:01
mok0 make PREFIX=. install21:02
mok0does it locally21:02
sistpotythen you might have trouble upgrading the library21:03
sistpoty(or building an application against it, which we'll do as soon as everyone is finished)21:04
* warp10 is done21:04
sistpotyok, next step: of course we want s.th. that uses the library, so get <http://www.potyra.de/library_packaging/hello_prog-1.0.tar.gz>21:04
sistpotyextract that somewhere else and also build the binary with "make"21:05
sistpotyif you've done that, you should have a cool binary hello_prog, which will print hello. you can even tell it how often it should print hello with the first argument21:06
sistpoty./hello_prog 1021:06
sistpotyeveryone got so far yet?21:07
mok0error while loading shared libraries: libmyhello.so.1: cannot open shared object file: No such file or directory21:07
frigautsame here21:07
gesermok0: sudo ldconfig21:07
warp10and here too :)21:07
slangasekheh, did any of the people having this problem install to /usr/local?21:07
mok0geser: just doing what the teachers tell me .-)21:08
slangasekor did you all install to a different prefix?21:08
frigautworks now after ldconfig21:08
sistpotyof course I forgot to mention ldconfig21:08
chiptoxicmine works and i just did what you said and ran ldconfig21:08
james_wslangasek: /usr/local for me21:08
slangasekah, ok21:08
sistpoty(still got it installed from testing *g*)21:08
mok0Yay, it says hello to me 10 times21:09
kdubyou have to have /usr/local in your /etc/ld.so.conf of course21:09
gesersistpoty: "eventually run ldconfig now."21:09
slangasekkdub: in /etc/ld.so.conf.d/libc.conf actually... :)21:09
sistpotygeser: hehe, what a nice upstream *g*21:09
sistpotynow if it prints hello for everyone, let's remove the *library* again with21:10
sistpotymake uninstall (run as root)21:10
sistpotynow try again to run the hello_prog.21:11
sistpotyany results yet?21:12
geser./hello_prog: error while loading shared libraries: libmyhello.so.1: cannot open shared object file: No such file or directory21:12
sistpotygreat, so (I guess what you expected) it won't work w.o. the library21:13
sistpotynow upstream has released a new version of the library... I guess you all want hot new stuff?21:13
sistpotythen get it at http://www.potyra.de/library_packaging/libmyhello-1.0.2.tar.gz21:13
sistpotywe'll be compiling it again:21:13
sistpotyand install it again (run as root)21:14
sistpotymake install21:14
mok0If you install the library again, it works once more :-)21:14
warp10I don't think so :)21:14
geser./hello_prog: symbol lookup error: ./hello_prog: undefined symbol: print_hello21:15
sistpoty(oh, if you haven't removed installed the new library, you could also try ldd ./hello_prog)21:15
sistpotyso what happened?21:16
sistpotynow let's try to make use of the knowledge we gathered so far21:16
mok0the application attempts to use the new library21:16
sistpotymok0: exactly21:17
sistpotylet's take a look at the symbols of both shared objects (old library vs. new library)21:17
mok0=> ABI has changed21:17
sistpotyin the old library, we had the function: T print_hello21:18
sistpotywhich upstream obviously renamed to just: T hello21:18
sistpotywhen you start the program, one of the first steps is that undefined symbols will get resolved21:19
* bddebian curses upstream21:19
slangasekyeah, I would think twice about packaging any libraries from this upstream ;)21:20
sistpotywhich is done recursively for each shared object that is used21:20
* sistpoty removes copyright notices *g*21:20
mok0This is why it is wrong to use the program version number for library versions21:20
mok0which a lot of upstream programmers don't understand21:20
sistpotywhen the symbol lookup can't resolve one symbol.. well you just saw what happens.21:21
sistpotyok, what we've seen now is an incompatibility on symbol level.21:21
sistpotyI hope with the tools you've learned so far, you can easily track those down21:22
sistpoty-> any removed symbol in a shared library is a problem, *if* the SONAME stays the same21:22
mok0so let's change it21:23
sistpotymok0: feel free to change it, I guess you can figure this in the Makefile21:24
mok0I set major to 221:24
albert23Wouldn't this be an API change, since print_hello is not defined anymore in hello.h?21:25
albert23I wouldn't expect this to compile anymore?21:25
sistpotyalbert23: exactly: this is an API change as well21:25
sistpotyok, but let's get back to the ABI...21:26
sistpotysymbols however cannot represent the signature of functions (i.e. number of parameters, type of parameters)21:27
sistpotythis is part of the ABI as well21:27
sistpotyif we want to look if this changed, we'll need to dig a little bit deeper21:27
mok0Now the program works again, because it finds the first version of the library21:27
mok0(I changed MAJOR to 2)21:27
sistpotymok0: hehe, so you didn't unstall the old library?21:28
chiptoxicim not a programmer but is there a way you could put an alias in the code say print_hello is really hello so you dont break the api? or would that just be messy21:28
mok0sistpoty: I still have 1.0.1 but I removed 1.0.221:28
mok0The new one is 2.0.121:28
sistpotychiptoxic: you could for example abuse the preprocessor: "define print_hello hello"21:29
mok0My experiment shows you can have several versions of the library present21:29
sistpotyer... #define print_hello hello21:29
chiptoxicah cool, thanks21:29
sistpotyok, back to the topic...21:29
sistpotyyou can look at the debug information with gdb, so let's run21:30
sistpotygdb libmyhello.so21:30
slangasekmok0: exactly, and this is a key reason why we always use the full soname for the names of our library packages21:30
gesermok0: and now try the same on windows :)21:30
sistpotyinside gdb, you can look at the signatures of functions with21:30
sistpotyinfo functions21:30
mok0slangasek: you mean the major soname ?21:31
slangasekmok0: the "soname" is the value returned by objdump -p $lib | grep SONAME21:31
mok0slangasek: ok21:31
slangasekand set (hopefully) using the -Wl,-soname option at build time21:31
sistpotymok0: the Makefile just puts $(MAJOR) and a name in the soname, but the real soname is in SONAME21:32
slangaseklintian knows the standard way to map sonames to package names, and warns you if your package is named differently.  but of course, we have to take care that upstream is handling their ABI right in the first place!21:32
sistpotyinside gdb, you can also display the types of variables with21:32
sistpotyinfo variables21:32
=== \sh is now known as \sh_away
sistpoty(which is uninteresting for libmyhello.so though, since it doesn't define a global variable by itself)21:33
sistpotyeveryone looked at the output of "info functions"?21:33
mok0just one: hello(void)21:34
sistpotyyou should see s.th. like "void hello(void);" or "void print_hello(void);" there (depending which version you chose)21:34
sistpotyyes, so upstream is lazy as well *g*21:34
* bddebian files upstream bug21:35
sistpotynow let's strip the shared object (which wasn't done during the build process):21:35
sistpotystrip libmyhello.so21:35
sistpoty(outside gdb again)21:35
sistpotyand then call gdb libmyhello.so again and look at the functions again21:36
sistpotyas you can see, these are all gone.21:36
gesermok0: install the -dbgsym package of it :)21:36
sistpotythat's because these were part of the debug symbols, which have been stripped away21:37
sistpotyok, so if we want to find out about the ABI-part of the signatures, it's a little bit tougher, but still doable21:37
sistpotyif a signature is changed (number of arguments and type of a function), it can lead to different results. Most probably it will segfault, since the library and the application no longer agree on what data they exchange)21:39
sistpotyan exception to this rule is C++21:39
sistpotyin C++ the signature is encoded in the name of a symbol21:40
sistpotyso if you change an argument, add an argument or remove one, you get a different symbol name21:40
sistpoty(side note: you can use nm -C to demangle these names back to a human readable signature)21:41
slangasekor c++filt21:41
sistpotyany questions so far?21:41
sistpotychiptoxic: did that answer your question from some time ago?21:42
slangasekother side note, checking for ABI changes of this kind by hand is hard and tedious; there is a tool in universe that tries to automate this checking, called icheck21:42
chiptoxicyea, thanks21:42
mok0slangasek: icheck, what package?21:42
sistpotyslangasek: ah, nice :)21:43
sistpotymok0: icheck21:43
slangasekif you're maintaining a library and want to be careful because your upstream isn't, icheck will let you generate a "manifest" from the old and new -dev packages, and compare them to see if the signatures have changed21:43
* chiptoxic cant believe how much im learning :)21:43
james_wslangasek: how does that compare to check-symbols from the ubuntu-dev-tools package?21:43
* mok0 install icheck21:43
slangasekjames_w: icheck examines headers, not symbols21:43
slangasekjames_w: so it's specifically for the case where you're trying to detect the kinds of ABI changes that /don't/ show up in the symbol table21:44
* bddebian can't keep up being at work :'-(21:44
slangasek(doh, check-symbols uses nm -D?  Baaad, what did we learn was the weakness of nm -D? :-)21:45
sistpotyslangasek: since you mentioned ABI changes not showing up in the symbol table, want to say a few words to these?21:45
slangasekprobably, let me see where I put those words21:46
slangasekright - does everyone here understand why changing the arguments or return type of a function is an ABI change?21:47
slangasek(if everyone knows, there's no sense in me spending time explaining it - but if you don't know, please speak up :)21:47
mok0Well renaming a global variable would show up21:48
slangasektwo people know who care, everyone else is asleep or doesn't want to talk to me ;)21:49
slangaseksistpoty: back to you21:49
mok0I just tried icheck on the 2 library versions,21:49
mok0but I couldn't get it to work21:50
mok0... "Failed to parse libmyhello.so21:50
sistpotymok0: haven't used it myself yet21:50
mok0sistpoty: :-)21:51
sistpotywhat we should have learned so far is that if the ABI breaks, you'll need to bump the SONAME21:51
slangasekmok0: you point it at the headers, not at the library21:51
sistpotyhowever there is yet another case, we didn't consider21:51
slangasekthat's the whole point - the library doesn't have the info you need about the function sigs :)21:51
sistpotyupstream might put additional functionality in the library21:52
sistpotyand keep the ABI downwards compatible21:52
sistpotyin that case, the SONAME would (and should) stay the same, because no program ceases to work with the newer library21:53
sistpotyhowever this has one caveat: people who use this library might make use of the new features21:53
mok0... but new programs that use the new functionality?21:53
sistpotyright, so these programs wouldn't work with the old library but only with the new one (even though the SONAME is the same)21:54
sistpotyfor this, there the SONAME is not sufficient alone.21:54
sistpotyslangasek: told me that historically the minor version was incremented for this21:55
* mok0 also read that21:55
sistpotybut that won't work if you copy binaries from one system to another (as you don't know about the libraries there)21:55
sistpotyok, this pretty much was part 1 -- shared objects21:56
sistpotyany questions so far?21:56
mok0Well, what is the answer to the last problem?21:57
sistpotymok0: we'll see that in part 2 :)21:57
mok0It stops at the most exiting part21:57
mok0typical of these mini-series :-)21:58
sistpotyactually I wanted to continue with part 2 now, unless there are questions of course21:58
* warp10 has no questions 21:59
sistpotyok, now for part 2 the plan was to let you package libmyhello on a walkthrough basis21:59
sistpotyhowever the session went much longer than I expected21:59
mok02 hours22:00
sistpotywould you prefer the walkthrough or shall we just look at (one possible) result?22:00
mok0I'm ok with the latter22:00
james_wsistpoty: would you like to move that part to another session?22:00
warp10any choice is fine for me22:00
* albert23 would like the walkthrough22:00
sistpotythat would be an option as well22:00
sistpotywhat does everyone else think?22:01
james_wsistpoty: I think a walkthrough would be really valuable, but I'm sure you are tired.22:01
warp10maybe moving to another session could give the opportunity to go in deeper details than going on now.22:02
sistpotyjames_w: heh, a little bit, but tomorrow is friday so I don't mind going to work tired *that* much *g*22:02
sistpotyok, then let's move this to another session... maybe tomorrow?22:03
mok0Works for me22:03
sistpotywarp10: what about you?22:03
albert23that's fine for me22:03
slangasekmok0: btw, a follow-up comment regarding icheck: there are ways that the necessary information can be retained in the library in the form of debugging symbols, but in the common case we've already discarded these symbols from the old version of the lib at build time, long before we ever want to start running icheck22:03
warp10tomorrow... what time?22:03
sistpotyI'd say same time, 20.00 UTC?22:04
warp10should be fine. +122:04
mok0slangasek: I didn't assume icheck had a parser for C code, parsing the symbol tables seems simpler, but if the info ain't there....22:05
sistpotyjames_w: alright for you as well?22:05
james_wsistpoty: that's fine with me.22:05
mok0slangasek: but it did discover the API/ABI change22:05
sistpotyok, then let's meet here again tomorrow at 20.00 UTC22:06
warp10cool :)22:06
chiptoxiccool ill be back tomorrow this was great think ill go read some of the past classrooms listed at https://wiki.ubuntu.com/ClassroomTranscripts22:06
albert23great, thanks sistpoty!22:06
sistpotyyou're welcome albert2322:06
mok0great class, thanks!22:07
* warp10 has learned a *lot* of things tonight22:07
james_wsistpoty, slangasek: thanks a lot.22:07
geserthanks sistpoty and slangasek22:07
sistpotythanks for coming :)22:07
bddebianYeah, w00t sistpoty and slangasek22:07
bddebianAnd geser the teachers pet.. ;-P22:07
mok0We shall spread the knowledge22:07
slangasekcheers, all :)22:08
sistpoty<- out for a smoke now, finally *g*22:08
* slangasek having lunch, finally ;)22:08
sistpotyok, gn8 everyone22:24

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!