| Surely the executable itself is only linked with the
| functions that are actually used by the program?
AFAIUI the GNU linker is not clever enough to remove junk
on a per-function basis, only on a per-object basis. This is
why we do object-splitting -- by breaking libraries up into
I notice that the method for detecting the configuration of ghc (for
building 'hmake') no longer works with 5.02. This must be the most
unstable part of ghc - I've had to change it at 4.06, 4.08, 5.00,
and now 5.02 as well!
ghc-pkg-5.00 --show-package std --field import_dirs
I notice that the method for detecting the configuration of ghc (for
building 'hmake') no longer works with 5.02. This must be the most
unstable part of ghc - I've had to change it at 4.06, 4.08, 5.00,
and now 5.02 as well!
ghc-pkg-5.00 --show-package std --field import_dirs
Mon, 1 Oct 2001 09:55:11 +0100, Simon Marlow [EMAIL PROTECTED] pisze:
We don't have support for shared libraries under Unix at the moment. It
has been investigated at various times in the past, and I believe the
story is that we couldn't do it without at least losing some performance
(more
Simon Marlow wrote:
Perhaps it would be easier to have hmake just invoke 'ghc --make' under
the hood?
I don't think ghc --make is mature enough to replace other make tools
yet. For example, when trying to compile Fudgets with ghc-5.02 --make
-O2, with GHCRTS=-M100M, I got
GHC's heap
Simon Marlow [EMAIL PROTECTED] wrote,
| Surely the executable itself is only linked with the
| functions that are actually used by the program?
AFAIUI the GNU linker is not clever enough to remove junk
on a per-function basis, only on a per-object basis. This is
why we do
On 2001-10-03T10:37:24+1000, Manuel M. T. Chakravarty wrote:
Simon Marlow [EMAIL PROTECTED] wrote,
| Surely the executable itself is only linked with the
| functions that are actually used by the program?
AFAIUI the GNU linker is not clever enough to remove junk
on a per-function
