tag:blogger.com,1999:blog-5169926515402298799.post1888157450749135696..comments2023-08-05T08:25:22.224-07:00Comments on Cooperative Computing Lab News: Dynamic Linking and Distributed Computing Don't MixDouglas Thainhttp://www.blogger.com/profile/10046446527813216338noreply@blogger.comBlogger8125tag:blogger.com,1999:blog-5169926515402298799.post-7178091432114075072009-06-01T13:30:57.622-07:002009-06-01T13:30:57.622-07:00And, another thing (continuing the above post). on...And, another thing (continuing the above post). on linux "static" linking means the resolver libraries are still dynamically loaded, so if you use LDAP and the administrator chose to use LDAP, so it loads ssl, then your statically linked ssl in your executable fights with it, and bam, segfault again.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5169926515402298799.post-57721513795638366092009-06-01T13:28:26.375-07:002009-06-01T13:28:26.375-07:00Also, if you complain that readdir() and opendir()...Also, if you complain that readdir() and opendir() do not have this behaviour so it is a non-issue, I present openssl as an example. I've seen cases where an executable has a static version compiled into it, loads a library which wants a different revision, and then load a different library which wants yet a different revision. The global variables between all of the revisions of ssl are the same (the default link behaviour) so they each trash each other's spaces and handles and end up segfaulting. This is an example which is quite simple to see and has various permutations of it.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5169926515402298799.post-59801288786684969982009-06-01T12:46:05.658-07:002009-06-01T12:46:05.658-07:00The symbol versioning topic has a good explanation...The symbol versioning topic has a good explanation here:<br>http://lists.debian.org/lsb-spec/1999/12/msg00017.html<br><br>As for changing the names of the symbol, you misunderstand--from the point of view of the user, the two functions act identically, but the libc (or whatever) implements them differently with different internal state. The trouble comes in when you do something like opendir() against an old glibc version, then pass the handle to a differenlt compiled shared library which then uses a newer revision of readdir() on it. The readdir() will expect the handle to be a specific thing, and it may not be that at all.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5169926515402298799.post-86254133356855519242009-06-01T07:50:15.762-07:002009-06-01T07:50:15.762-07:00Note that my advice is simply that dynamic linking...<i>Note that my advice is simply that dynamic linking should only be used with standard system libraries that can be found on any machine</i>This is too simplistic, because it means you need to know what the least common denominator of even your glibc runtimes is, and code to that. For example, if you use the regexec function from glibc, and dynamically link on RHEL 5, your code won't load on RHEL 4, even though RHEL 4's glibc has the regexec function! Static linking fixes that problem. And, good lucking finding this mentioned in the man pages.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5169926515402298799.post-17065858380831402752009-05-30T13:32:30.475-07:002009-05-30T13:32:30.475-07:00On linux, shared libraries have an oddball scoping...On linux, shared libraries have an oddball scoping mechanism like foo@@GLIBC_2.0 which is the function foo that has a semantic signature matching the definition of it in GLIBC 2.0. Suppose GLIBC 2.1 defines a *different* foo with the same function signature but different internal behavior. Old programs use the old API, new programs use the new API, and you think things work. Now, how many revision of the old things are kept around, the answer apparenty is "until someone notices and removes it". Also, what happens when you take data from an old style function and pass it to a new style function, which can happen when one shared library invokes calls froma different and later compiled shared library? I'll leave the answer as an excersize to the reader...Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5169926515402298799.post-30053253759145765102009-05-30T13:22:15.583-07:002009-05-30T13:22:15.583-07:00Suppose you have two styles of processor that your...Suppose you have two styles of processor that your program may run upon. One of them has a hardware math error in it that the libm.so for that specific revision of the OS patches so the application never sees the error. Now, if you package up all of the libraries for your application and move them to the other processor, you'll get wrong answers. Think this'll never happen? It happened with the IRIX OS on the R Series of processors. That one took a while to track down....Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5169926515402298799.post-20017681799458371382009-05-30T13:05:14.908-07:002009-05-30T13:05:14.908-07:00Hey Doug, psilord here, I had written a similar po...Hey Doug, psilord here, I had written a similar post about dynamic libraries and how they aren't that great of an idea when you want to move binaries around.<br><br>http://pages.cs.wisc.edu/~psilord/blog/2.html<br><br>Other than a real benefit in the sharing of text segments between processes, the rest of the ideals of dynamic linking seems to be superstitiously believed.<br><br> Of course, on non-linux OSes, backwards compatibility between dynamic library APIs most often works, but a lot of those OSes are dying off, and Linux absolutely doesn't care about backwards compatibility.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5169926515402298799.post-19873898916618027692009-05-29T20:37:55.577-07:002009-05-29T20:37:55.577-07:00Isn't it interesting how the faster computers ...Isn't it interesting how the faster computers get, the <b>more</b> interested in efficiency we are? The PDP-11s that Unix was originally developed on were unthinkably slow by today's standards (KIPS!). Yet the graybeards wrote lots of shell scripts, used interpreted languages like awk, implemented fork without COW, and didn't have shared libraries.Anonymousnoreply@blogger.com