On 5/2/2011 11:06 PM, Jonathan M Davis wrote:
I'm afraid that I don't understand what the problem is then. Can the linker
not handle a 4.6 Mb object file? Granted, that's not a small file, but I
wouldn't have thought that that would do in the linker.
It is an unusually large .o file, though. Maybe ld has some exponential behavior
with the size of a .o file.
And, of course, that raises the question as to why the object file is so large
when compiling with unit tests.
(I made a mistake, it's 5Mb compiled with -unittest.) By replacing a few
_assertPred's with assert, compiling and looking at the .o file size, each one
consumes an extra 400 to over 1000 bytes. There are 4000 _assertPred's there, so
that explains where the size comes from. There are 5 args that get pushed on the
stack for each call to _assertPred, and one of those is a delegate (the lazy
parameter).
I appreciate that using _assertPred saves you time and effort in development,
but once it is developed it is a bit expensive to carry it around. I wonder if
there's an easy way to swap it out with assert.
Sigh. Even obj2asm crashes with this .o file, but that's my fault.
Running "strings" on the .o for a non-unittest compile shows a lot of redundant
strings that can be factored out to save space, such as "Standard Time"
appearing 80 times or so.
Part of it likely comes from the fact that the
unit tests actually use the stuff in std.datetime, so all of the templated
types and functions get instantiated, and they wouldn't when just compiling
Phobos, unless something else in Phobos is using them. And maybe there's
something in the unit tests which instantiates a bunch of extra templates. I
don't know. Or did you compile with -release and -O _and_ -unittest? That
would change things considerably, since that would imply a difference betwen
release and non-release instead of a difference with regards to whether unit
tests are compiled in.
Regardless, I don't know why the linker wouldn't like a 4.6 Mb object file.
And while fixing dmd's memory consumption won't fix the problem, it might make
it so that dmd actually finishes compiling and moves on to the linker rather
than forcing you to delete unit tests. And whatever the problem may be,
clearly it has something to do with the differences between your machine and
the auto tester, since the auto tester is fine. So, regardless of dmd,
whatever the linker's problem is, there's something about your machine that
makes it fail while it succeeds on the auto tester.
My FreeBSD box is a 10 year old machine, with not much memory on it.
And if all you want to do is to not have std.datetime fail on your machine,
you can remove or comment out the line
version = testStdDateTime;
(line #145, I believe) on your machine, and none of the std.datetime unit
tests will be compiled in. It's already not defined on Windows specifically
because dmd definitely runs out of memory compiling std.datetime on Windows
when compiling all of Phobos' unit tests:
http://d.puremagic.com/issues/show_bug.cgi?id=5454 (it does fine, if you
compile std.datetime separately though).
For now, I'll disable the unittests for FreeBSD.
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
