 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sat, 14 Feb 2009 22:07:01 +0000, Orchid XP v8 wrote:
>>> Yah, that's right. First you install a binary version of the compiler.
>>> Then you use that to compile a minimal version of the compiler from
>>> source. Then you use *that* to compile a full version from source.
>>
>> That used to be common with GCC - not sure if that's the one you're
>> using, but I remember the first time I saw it built was on a SunOS
>> platform, used the Sun CC compiler to build the first time and then it
>> built itself in order to fully optimise itself.
>>
>> On hardware of the time, it generally took about 12 hours IIRC.
>
> Actually, I'm recompiling the Haskell compiler. Which is written in
> Haskell. (And a small amount of C.)
>
> It's still compiling. o_O
Interesting....how long has it been running?
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 <voi### [at] dev null> wrote:
> >> Yah, that's right. First you install a binary version of the compiler.
> >> Then you use that to compile a minimal version of the compiler from
> >> source. Then you use *that* to compile a full version from source.
> >
> > That used to be common with GCC - not sure if that's the one you're
> > using, but I remember the first time I saw it built was on a SunOS
> > platform, used the Sun CC compiler to build the first time and then it
> > built itself in order to fully optimise itself.
> >
> > On hardware of the time, it generally took about 12 hours IIRC.
>
> Actually, I'm recompiling the Haskell compiler. Which is written in
> Haskell. (And a small amount of C.)
I knew it! ;)
BTW, In my early Debian years I too thought package management sucked. So, I
began to do my own compilations in a ~/root directory of new packages (gtk and
most of its dependencies) and use those instead with LD_LIBRARY_PATH.
Eventually, I wanted to compile a new version of GCC instead of waiting for the
new version to be packaged to Debian. All was good, I was learning my way the
hard way. Then, someday I compiled libc itself and, tired of LD_LIBRARY_PATH,
I decided to replace the current with it. I don't remember quite exactly what
I did, but I think I *moved* the current libc to /lib/bkup-libc.so or something
and would then move my compiled libc to /lib. Unfortunately, I couldn't. The
system began breaking apart, beginning by mv itself and bash and then the whole
system. Kernel panic ensued eventually. oh, my...
Nowadays, having learned the hard way in the past, I think package managers are
a blessing. Not even several /Next/ clicks in a row, just choose what you want
installed and let it go. :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Actually, I'm recompiling the Haskell compiler. Which is written in
>> Haskell. (And a small amount of C.)
>>
>> It's still compiling. o_O
>
> Interesting....how long has it been running?
In the end, at around about 11:45 PM, I gave up waiting so I could go to
bed instead. It then took an additional hour or so this morning.
So, in total... hmm... maybe 4 hours? Something of that order.
Remember this is running on a *laptop* that's some 6 years old now. It's
powered by an AMD Mobile Athlon XP 1400+ CPU. It's not even 64-bit.
(Mercifully, it *does* have a decent amount of RAM though. I upgraded it
a while back.)
Anyway, I just made the mistake of running the compiler validation
script. The first thing this does is... clean the build tree. That is,
it deletes everything and recompiles from scratch. I guess the idea is
if you're been working on the compiler all day and you think it should
work now, it does a full rebuild from scratch to check it really *does*
work and it's not just that you're using an old result.
Rebuild started at 10:30 AM. We'll see how long it takes to rebuild. :-/
(Of course, as well as compiling the compiler twice, it also compiles
all sorts of other build tools, the standard libraries twice, builds
HTML documentation, and sweeps your bedroom floor...)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> Anyway, I just made the mistake of running the compiler validation
> script. The first thing this does is... clean the build tree. That is,
> it deletes everything and recompiles from scratch. I guess the idea is
> if you're been working on the compiler all day and you think it should
> work now, it does a full rebuild from scratch to check it really *does*
> work and it's not just that you're using an old result.
>
> Rebuild started at 10:30 AM. We'll see how long it takes to rebuild. :-/
10:30 Started the validate process.
Delete everything except the source code.
Compile the stage-1 compiler using the stage-0 compiler.
11:00 Stage-1 compiler is ready.
Compile all the Haskell standard libraries using stage-1 compiler.
11:30 Standard libraries are ready.
Compile the stage-2 compiler using the stage-1 compiler.
12:00 Stage-2 compiler is ready.
Compile the doc-gen program.
Generate the HTML documentation.
12:15 Start running compiler test suite.
12:50 All tests completed successfully.
NB:
* The stage-0 compiler is the binary package that the Linux package
manager installed. (GHC 6.8.2, as it happens.) The version I'm compiling
is 6.11.20080214.
* The stage-1 compiler is linked against the stage-0 Haskell standard
libraries. Then we recompile all the libraries using the new stage-1
compiler. Last we recompile the compiler itself, linking against the new
libraries we just built (i.e., we make stage-2).
* When I did a "normal" build yesterday, it made 2 copies of every
Haskell library - a normal copy, and a copy with profiling enabled.
(Enabling profiling makes the compiled stuff 2x bigger and 12x slower.)
The validation build didn't bother with the profiling step, making the
process about twice as fast.
* Curiosly, the normal build seemed to build a version of the compiler
with profiling enabled - I'm not sure why the hell it would do that, but
still. The validation build didn't seem to bother.
* The normal build also generated the HTML documentation for the
compiler itself. This validation build has built the library
documentation and the GHC API documentation, but not the user guide.
(The user guide is quite fast though; just translate DocBook to HTML.)
I love the way that every now and then, you see a command line that
starts with "ld" or "ar" and goes on for 3 pages. o_O Pretty crazy! Well
anyway, after half an hour of compiling the compiler itself, the
resulting binary is about 30 MB. (The stage-1 compiler is smaller, but
then it does have several features disabled.)
Now, do I dare run the benchmark?
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sun, 15 Feb 2009 11:16:59 +0000, Orchid XP v8 wrote:
> (Of course, as well as compiling the compiler twice, it also compiles
> all sorts of other build tools, the standard libraries twice, builds
> HTML documentation, and sweeps your bedroom floor...)
Maybe I should run this as well, the cat tumbleweeds are quite prominent
on the floor here by the computers. ;-)
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 <voi### [at] devnull> wrote:
> I love the way that every now and then, you see a command line that
> starts with "ld" or "ar" and goes on for 3 pages. o_O Pretty crazy! Well
> anyway, after half an hour of compiling the compiler itself, the
> resulting binary is about 30 MB. (The stage-1 compiler is smaller, but
> then it does have several features disabled.)
You could try:
strip -g binary -o new-binary
strip -g strips a binary off of any debugging info it might have. Or -s to
strip even more possibly useless info on a production binary. Don't forget the
-o new-binary or it'll strip away and write the stripped binary to the same
file. You can backup yourself if you're unsure.
stripping generally yields severelly smaller binaries. That's supposing the
whole build process already didn't perform such step (I think it's standard to
leave the debugging info if you don't provide a -g flag).
> Now, do I dare run the benchmark?
heh, why not? ;)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
