On Tue, Apr 17, 2012 at 08:20:49AM -0400, Michael Alan Dorman wrote: > Joachim Breitner <nomeata@debian.org> writes: > >> And, of course, there are all the other reasons that usually > >> recommend shared libraries---getting security fixes without requiring > >> recompiles, etc. > > > > Unfortunately, the benefit of „no recompiles“ does not apply to > > Haskell. > > In fact, I must say I was a little surprised at the and confused when I > first started installing Haskell -dev packages because it seemed like > things were set up to be installed in lockstep to a greater degree than > I've ever seen before---and I've been a Debian user since 1995, pre-ELF > shlibs, etc., and don't remember ever encountering anything like it. > > In that situation my natural inclination is to question whther that is > truly a necessity imposed upon us by upstream, or one we've accidentally > imposed on ourselves---it seems contrary to the way the vast majority of > language handles these issues. > > (All of which sounds like I'm being critical of you who've done all this > work, but please be assured, I'm just damned ignorant, and fairly > stubborn, and need to convince myself that this is how it needs to be; > hopefully I will not wear out my welcome in the process ;) For the record, I quite like the "static" binary approach. Yes, it has a higher cost (disk/memory), but it makes it very easy to deploy binaries. Of course, this doesn't help for proper Debian, just for private installations. If you care about disk space and binary size, maybe we should look into split_objs rather than dynamic linking; it would at least permit the binary to use only what is needed (sometimes this can be much less than the entire library). > > The package id includes the version, so every version bump requires a > > recompilation, unless we leave the version at what it is, e.g. when > > adding a Debian patch. But even then it is likely the the patch will > > somehow affect the ABI, which includes the _definitions_ of > > _potentially_ inlined functions and force a recompilation. > > Well, but, the package id is an artifact of how things are being > packaged for Debian, no? (Again, if you want to just throw up your hands > and say "read the source", I will totally understand) > > I mean, I realize that upstream Haskell authors are perhaps not > sensitized to soname issues and such in the way that many C library > authors are, and that the compiler probably does a lot of mangling of > symbols behind the programmer's back---and that different versions of > GHC will probably produce different symbol mangling and so forth...but I > suspect there might still be a lot of latitude, which brings us to the > next item... As far as I understand, it's not symbol mangling, but the fact that dynamic linking (without recompilation) prevents the optimiser from doing its full work (e.g. inlining across modules, etc.). Given that Haskell does by default lots of inlining and rule rewriting that is important for performance, I'm not sure how helpful a dynamic library would be which doesn't do recompilation - after all, the fixed security issue could be (unlikely, but still) in an inlined function, so that replacing the library is not actually fixing the problem. > >> That said, it does sound like there are a lot of technical issues. I > >> wonder if some of the infrastructure that the C++ developers have used > >> to try to handle ABI changes could be helpful? > > > > I don’t know much about their infrastructure; can you tell us a bit > > more? > > Well I don't pretend to be an expert on it *at all*, but there was a > long discussion on d-d in January regarding C++ shared libraries and > symbol compatibility and maintenance, which I *imagine* have some > similar challenges--- that the compiler does many arbitrary > transformations to the symbols in the library without the author's > participation or knowledge, which dramatically ups the ante in what's > involved in maintaining shared library compatibilty. > > Russ Allbery did a write up of his investigations, which might be a > decent place to start if it's of interest: > > http://www.mail-archive.com/debian-devel@lists.debian.org/msg300222.html As a maintainer of a C++ library, I was watching that thread, but in the end I gave up on (starting to) maintaining the symbols list. Just read the problems list in the email you quote :) It seems to me that plain C is a language where dynamic linking, SONAME bumps, etc. are sane; but more complex languages make this a more complex situation (not a clear "yes"). > > If there is sufficient demand we could add -dyn packages for all > > libraries, this would allow you to build your applications dynamically > > locally. For -dyn packages, the recompilation problem is not a big > > problem, as we have to recompile it anyways for the -dev package. The > > cost ist mainly in mirror space and the extended build time, plus some > > work in configuring hlibrary.mk. > > Well all I wanted for the moment was to know that there wasn't a violent > objection to the idea---and it seems like you at least are open to it. > Now to figure out if we can do it in a way that will reflect Debian's > commitment to doing things "right"---I don't want to see this done just > to make things more complex and harder, but to simplify and streamline. IMHO the simple and streamlined way _is_ static linking. Well, not simple for security issues, but for the build process. But that's just IMHO, and not a strong opinion :) regards, iustin
Attachment:
signature.asc
Description: Digital signature