Iustin Pop <[email protected]> writes: > 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.).
Err, now I could be wrong, but I didn't think GHC was doing link-time optimization---and if it's not, ISTM that inlining across modules, whether static or dynamic is infeasible, no? > 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 :) Yeah, I know. I was hoping that the Haskell situation might be more tractable, though in fact it looks like it's even less so. ;) > 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 :) The company I work for has plans to deploy several Haskell-based apps in the next six months to a year. The supporting libraries are more or less the same across all of them---so dynamic libraries have the potential, at least, to reduce the aggregate memory footprint of those apps significantly. We may just end up cheering that we've saved as much memory as we have by moving to Haskell from an interpreted language and not worrying about the static vs. dynamic cost. At least, on further examination that would seem to be the most bang for the buck. Anyway, I appreciate everyone's patience with me on this. Mike. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
