Re: Moving to shared libraries?
Iustin Pop <firstname.lastname@example.org> 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
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.