Open source is great! You can just modify the thing yourself if it 
doesn't work right.



...er, yeah. Nice in theory. Not so great in practice. ;-) Between 
trying to get Linux to work properly, fiddling with CLI tools, and 
trying to get revision control to play nicely, not to mention the fun 
and games of communicating with other humans, it's... quite tricky.

Still, if I ever manage to get this to work, I guess it'll look nice on 
my CV. :-}

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On Sat, 14 Feb 2009 15:20:33 +0000, Orchid XP v8 wrote:

> ...er, yeah. Nice in theory. Not so great in practice. ;-) Between
> trying to get Linux to work properly, fiddling with CLI tools, and
> trying to get revision control to play nicely, not to mention the fun
> and games of communicating with other humans, it's... quite tricky.

So what problems are you having, which distro, and where are you asking?

Using openSUSE, there's nothing I had to do to "get Linux to work 
properly", 11.0 basically just worked for me.

Jim

Post a reply to this message

>> ...er, yeah. Nice in theory. Not so great in practice. ;-) Between
>> trying to get Linux to work properly, fiddling with CLI tools, and
>> trying to get revision control to play nicely, not to mention the fun
>> and games of communicating with other humans, it's... quite tricky.
> 
> So what problems are you having, which distro, and where are you asking?
> 
> Using openSUSE, there's nothing I had to do to "get Linux to work 
> properly", 11.0 basically just worked for me.

I've got it all straightened out *now*. ;-)

My problem wasn't actually "getting Linux to work", but rather "getting 
Linux to do what I want". But in my experience, Linux package managers 
are often very awkward to use. You know - the whole "I want to install 
this one package, and no I don't want to also upgrade 3,657 other 
packages to a different version".

Weirdly, this kind of thing never seems to happen on Windows. I guess 
because "Windows" is one monolithic block of software, whereas "Linux" 
is several billion tiny pieces, all of which are in a sense optional.

After that, I had all the fun of trying to work out how to operate 
makefiles, where the stuff I want to alter actually is, how to operate 
the version control system, and so forth. Plus getting hold of a human 
over IRC seems to be like getting blood out of a stone. I guess 
everybody is in a different timezone to me?

It's sorted now, it just took rather a lot of effort considering the 
triviallity of what I actually set out to do. ;-)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 wrote:
> Weirdly, this kind of thing never seems to happen on Windows. I guess 
> because "Windows" is one monolithic block of software, whereas "Linux" 
> is several billion tiny pieces, all of which are in a sense optional.

It's more like people actively avoid using what doesn't come with Windows, 
or they buy libraries for support that allow redistribution. When's the last 
time you bought a Windows program that had documentation in PDFs but didn't 
have adobe reader on the CD, or a game that didn't have a DirectX install 
directory on it, or etc?

When there are big enough packages that people *do* want to rely on them 
(say, .NET runtimes), you wind up installing prerequisites.

> over IRC seems to be like getting blood out of a stone. I guess 
> everybody is in a different timezone to me?

Or, maybe, you're not paying them so they don't care? :-)

-- 
   Darren New, San Diego CA, USA (PST)
   "Ouch ouch ouch!"
   "What's wrong? Noodles too hot?"
   "No, I have Chopstick Tunnel Syndrome."

Post a reply to this message

On Sat, 14 Feb 2009 19:23:59 +0000, Orchid XP v8 wrote:

>>> ...er, yeah. Nice in theory. Not so great in practice. ;-) Between
>>> trying to get Linux to work properly, fiddling with CLI tools, and
>>> trying to get revision control to play nicely, not to mention the fun
>>> and games of communicating with other humans, it's... quite tricky.
>> 
>> So what problems are you having, which distro, and where are you
>> asking?
>> 
>> Using openSUSE, there's nothing I had to do to "get Linux to work
>> properly", 11.0 basically just worked for me.
> 
> I've got it all straightened out *now*. ;-)
> 
> My problem wasn't actually "getting Linux to work", but rather "getting
> Linux to do what I want". But in my experience, Linux package managers
> are often very awkward to use. You know - the whole "I want to install
> this one package, and no I don't want to also upgrade 3,657 other
> packages to a different version".

openSUSE's package management seems to do pretty well with this.  If I 
want to install Virtualbox OSE, I just run "yast2 -i" (for a graphical 
way to do this) or "zypper in virtualbox-ose" in a terminal window.

The package manager figures out what's needed, resolves all dependencies, 
and installs the necessary packages.

> Weirdly, this kind of thing never seems to happen on Windows. I guess
> because "Windows" is one monolithic block of software, whereas "Linux"
> is several billion tiny pieces, all of which are in a sense optional.

While not as common as it used to be, dll hell still (to what I hear, not 
being a Windows user) happens.  But much of the time packages include the 
version of the DLLs they need and use them rather than the installed 
system libraries.

> After that, I had all the fun of trying to work out how to operate
> makefiles, where the stuff I want to alter actually is, how to operate
> the version control system, and so forth. Plus getting hold of a human
> over IRC seems to be like getting blood out of a stone. I guess
> everybody is in a different timezone to me?

Try online forums instead - you're already familiar with them.  Ubuntu 
and openSUSE have very vibrant online communities.

I never use IRC to ask for help - just never needed that sort of 
immediacy.

> It's sorted now, it just took rather a lot of effort considering the
> triviallity of what I actually set out to do. ;-)

Which was what, out of curiosity?

Jim

Post a reply to this message

>> I've got it all straightened out *now*. ;-)
>>
>> My problem wasn't actually "getting Linux to work", but rather "getting
>> Linux to do what I want". But in my experience, Linux package managers
>> are often very awkward to use. You know - the whole "I want to install
>> this one package, and no I don't want to also upgrade 3,657 other
>> packages to a different version".
> 
> openSUSE's package management seems to do pretty well with this.  If I 
> want to install Virtualbox OSE, I just run "yast2 -i" (for a graphical 
> way to do this) or "zypper in virtualbox-ose" in a terminal window.
> 
> The package manager figures out what's needed, resolves all dependencies, 
> and installs the necessary packages.

Yeah. It's great when it works like that. But sometimes it decides that 
it wants to install version X of the thing you asked for, which depends 
on a completely different version of something critical - GCC, the Linux 
kernel, libc, whatever. Obviously, replace that and you have to replace 
half the software on your HD. :-}

> While not as common as it used to be, dll hell still (to what I hear, not 
> being a Windows user) happens.  But much of the time packages include the 
> version of the DLLs they need and use them rather than the installed 
> system libraries.

This, of course, completely defies the entire purpose of shared 
libraries! :-D

>> Plus getting hold of a human
>> over IRC seems to be like getting blood out of a stone. I guess
>> everybody is in a different timezone to me?
> 
> Try online forums instead - you're already familiar with them.  Ubuntu 
> and openSUSE have very vibrant online communities.
> 
> I never use IRC to ask for help - just never needed that sort of 
> immediacy.

No - this was for help with the open-source project I'm trying to 
contribute to, not for Linux. ;-)

>> It's sorted now, it just took rather a lot of effort considering the
>> triviallity of what I actually set out to do. ;-)
> 
> Which was what, out of curiosity?

I added a section to the user manual. (Which is written in something 
called "docbook", by the way.)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On Sat, 14 Feb 2009 20:03:53 +0000, Orchid XP v8 wrote:

>>> I've got it all straightened out *now*. ;-)
>>>
>>> My problem wasn't actually "getting Linux to work", but rather
>>> "getting Linux to do what I want". But in my experience, Linux package
>>> managers are often very awkward to use. You know - the whole "I want
>>> to install this one package, and no I don't want to also upgrade 3,657
>>> other packages to a different version".
>> 
>> openSUSE's package management seems to do pretty well with this.  If I
>> want to install Virtualbox OSE, I just run "yast2 -i" (for a graphical
>> way to do this) or "zypper in virtualbox-ose" in a terminal window.
>> 
>> The package manager figures out what's needed, resolves all
>> dependencies, and installs the necessary packages.
> 
> Yeah. It's great when it works like that. But sometimes it decides that
> it wants to install version X of the thing you asked for, which depends
> on a completely different version of something critical - GCC, the Linux
> kernel, libc, whatever. Obviously, replace that and you have to replace
> half the software on your HD. :-}

Funny, I don't run into that problem - and generally haven't in the 
nearly 15 years I've been running Linux.

You *can* run into this if you use nonstandard repos regularly, but I 
don't.  What's in a repo like the openSUSE repos is tested so that these 
types of conflicts don't occur.

Case in point:

--- snip ---

[jhenderson@krikkit ~]$ sudo zypper in virtualbox-ose
Downloading repository 'Packman Repository' metadata [done]
Building repository 'Packman Repository' cache [done]
Reading installed packages...

The following NEW packages are going to be installed:
  virtualbox-ose virtualbox-ose-kmp-default libXerces-c-28 libXalan-c-110 


Overall download size: 6.2 M. After the operation, additional 26.2 M will 
be used.
Continue? [YES/no]: 
Downloading package virtualbox-ose-kmp-
default-1.5.6_2.6.25.5_1.1-33.1.x86_64 (1/4), 71.0 K (1.7 M unpacked)
Downloading: virtualbox-ose-kmp-
default-1.5.6_2.6.25.5_1.1-33.1.x86_64.rpm [done]
Installing: virtualbox-ose-kmp-default-1.5.6_2.6.25.5_1.1-33.1 [done]
Downloading package libXerces-c-28-2.8.0-10.1.x86_64 (2/4), 1.0 M (4.5 M 
unpacked)
Downloading: libXerces-c-28-2.8.0-10.1.x86_64.rpm [done (200.7 K/s)]
Installing: libXerces-c-28-2.8.0-10.1 [done]
Downloading package libXalan-c-110-1.10-116.1.x86_64 (3/4), 862.0 K (4.4 
M unpacked)
Downloading: libXalan-c-110-1.10-116.1.x86_64.rpm [done (91.6 K/s)]
Installing: libXalan-c-110-1.10-116.1 [done]
Downloading package virtualbox-ose-1.5.6-33.2.x86_64 (4/4), 4.2 M (15.6 M 
unpacked)
Downloading: virtualbox-ose-1.5.6-33.2.x86_64.rpm [done (12.9 K/s)]
Installing: virtualbox-ose-1.5.6-33.2 [done]

--- snip ---

And just to make the point:

--- snip ---

[jhenderson@krikkit ~]$ rpm -ql virtualbox-ose | grep bin
/usr/bin/VBoxAddIF
/usr/bin/VBoxDeleteIF
/usr/bin/VBoxManage
/usr/bin/VBoxSDL
/usr/bin/VBoxSVC
/usr/bin/VBoxTunctl
/usr/bin/VirtualBox
/usr/bin/vditool

--- snip ---

Nope, these are not source files.  These are *binary* files from the 
package I installed.

>> While not as common as it used to be, dll hell still (to what I hear,
>> not being a Windows user) happens.  But much of the time packages
>> include the version of the DLLs they need and use them rather than the
>> installed system libraries.
> 
> This, of course, completely defies the entire purpose of shared
> libraries! :-D

Of course it does.  But you were lamenting that "This never happens in 
Windows" - this is a big part of the reason why.

>>> Plus getting hold of a human
>>> over IRC seems to be like getting blood out of a stone. I guess
>>> everybody is in a different timezone to me?
>> 
>> Try online forums instead - you're already familiar with them.  Ubuntu
>> and openSUSE have very vibrant online communities.
>> 
>> I never use IRC to ask for help - just never needed that sort of
>> immediacy.
> 
> No - this was for help with the open-source project I'm trying to
> contribute to, not for Linux. ;-)

And questions about VirtualBox (for example) are not out of place in an 
appropriate Ubuntu or openSUSE community group.

>>> It's sorted now, it just took rather a lot of effort considering the
>>> triviallity of what I actually set out to do. ;-)
>> 
>> Which was what, out of curiosity?
> 
> I added a section to the user manual. (Which is written in something
> called "docbook", by the way.)

Very cool.  Make sure you note that for your CV as well, things like that 
can be useful.

Jim

Post a reply to this message

>> Yeah. It's great when it works like that. But sometimes it decides that
>> it wants to install version X of the thing you asked for, which depends
>> on a completely different version of something critical - GCC, the Linux
>> kernel, libc, whatever. Obviously, replace that and you have to replace
>> half the software on your HD. :-}
> 
> Funny, I don't run into that problem - and generally haven't in the 
> nearly 15 years I've been running Linux.
> 
> You *can* run into this if you use nonstandard repos regularly, but I 
> don't.  What's in a repo like the openSUSE repos is tested so that these 
> types of conflicts don't occur.

I'm guessing KNOPPIX is configured to look for something silly. When I 
tried to repeat the process with Ubuntu, it was fairly painless. I 
remember Gentoo was always a PITA though... and Debian, for that matter. 
(Debian was years ago tho.)

>> This, of course, completely defies the entire purpose of shared
>> libraries! :-D
> 
> Of course it does.  But you were lamenting that "This never happens in 
> Windows" - this is a big part of the reason why.

I think maybe like Darren said, people on Windows try to minimise 
dependencies. For example, I remember trying to set up an email program 
and discovering that you can't install it unless you have sound enabled 
in the Linux kernel. (WTF?) Because the package manager thinks foomail 
depends on libsound, or something.

>>> I never use IRC to ask for help - just never needed that sort of
>>> immediacy.
>> No - this was for help with the open-source project I'm trying to
>> contribute to, not for Linux. ;-)
> 
> And questions about VirtualBox (for example) are not out of place in an 
> appropriate Ubuntu or openSUSE community group.

Even if you want to know which one would be the best choice to run 
Ubuntu on your Windows box? ;-)

>> I added a section to the user manual. (Which is written in something
>> called "docbook", by the way.)
> 
> Very cool.  Make sure you note that for your CV as well, things like that 
> can be useful.

And you think I embarked on this crazy mission, *why*?? 0;-)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Jim Henderson wrote:
> Of course it does.  But you were lamenting that "This never happens in 
> Windows" - this is a big part of the reason why.

This really hasn't been a problem in about 8 years. DLL hell was caused by 
people replacing working code in the OS directories with broken code. As 
soon as you implemented the policy that you can't overwrite microsoft's code 
with your own, the DLL hell bits went away.

> Very cool.  Make sure you note that for your CV as well, things like that 
> can be useful.

Yep. All that stuff is good.

-- 
   Darren New, San Diego CA, USA (PST)
   "Ouch ouch ouch!"
   "What's wrong? Noodles too hot?"
   "No, I have Chopstick Tunnel Syndrome."

Post a reply to this message

So OK, so it's saturday night... and I'm recompiling my compiler. o_O

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.

Not forgetting that since the compiler is written in the same 
programming language, gotta compile all the standard libraries twice 
too. Oh, and then on the final pass, the libraries get compiled into 
several versions - "normal", "debug", "profiling", etc. And the user 
manual needs to be converted from DocBook to HTML - but you don't need a 
compiler for that, fortunately!

I should probably get out more...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On Sat, 14 Feb 2009 20:26:20 +0000, Orchid XP v8 wrote:

>>> Yeah. It's great when it works like that. But sometimes it decides
>>> that it wants to install version X of the thing you asked for, which
>>> depends on a completely different version of something critical - GCC,
>>> the Linux kernel, libc, whatever. Obviously, replace that and you have
>>> to replace half the software on your HD. :-}
>> 
>> Funny, I don't run into that problem - and generally haven't in the
>> nearly 15 years I've been running Linux.
>> 
>> You *can* run into this if you use nonstandard repos regularly, but I
>> don't.  What's in a repo like the openSUSE repos is tested so that
>> these types of conflicts don't occur.
> 
> I'm guessing KNOPPIX is configured to look for something silly. When I
> tried to repeat the process with Ubuntu, it was fairly painless. I
> remember Gentoo was always a PITA though... and Debian, for that matter.
> (Debian was years ago tho.)

Well, KNOPPIX is primarily designed to run from the disc as I recall, so 
it makes sense that package management wouldn't be as robust as on full-
on distributions.

>>> This, of course, completely defies the entire purpose of shared
>>> libraries! :-D
>> 
>> Of course it does.  But you were lamenting that "This never happens in
>> Windows" - this is a big part of the reason why.
> 
> I think maybe like Darren said, people on Windows try to minimise
> dependencies. For example, I remember trying to set up an email program
> and discovering that you can't install it unless you have sound enabled
> in the Linux kernel. (WTF?) Because the package manager thinks foomail
> depends on libsound, or something.

Well, here again, this isn't something that I have recently run into.  
But you can generally override the dependencies if you want; I converted 
a Debian package to run on openSUSE (a video converter called HandBrake), 
and the library dependencies weren't met because the library is called 
something else on Debian (and yes, I do find that kinda frustrating).  So 
I installed with --nodeps and linked to the library name on openSUSE.  
Works perfectly.

But that was the exception in my experience.


>>>> I never use IRC to ask for help - just never needed that sort of
>>>> immediacy.
>>> No - this was for help with the open-source project I'm trying to
>>> contribute to, not for Linux. ;-)
>> 
>> And questions about VirtualBox (for example) are not out of place in an
>> appropriate Ubuntu or openSUSE community group.
> 
> Even if you want to know which one would be the best choice to run
> Ubuntu on your Windows box? ;-)

Sure, why not?  You think that people in the Ubuntu forums only ever run 
their distro on real hardware?

>>> I added a section to the user manual. (Which is written in something
>>> called "docbook", by the way.)
>> 
>> Very cool.  Make sure you note that for your CV as well, things like
>> that can be useful.
> 
> And you think I embarked on this crazy mission, *why*?? 0;-)

Good lad. ;-)

Jim

Post a reply to this message

On Sat, 14 Feb 2009 12:29:42 -0800, Darren New wrote:

> Jim Henderson wrote:
>> Of course it does.  But you were lamenting that "This never happens in
>> Windows" - this is a big part of the reason why.
> 
> This really hasn't been a problem in about 8 years. DLL hell was caused
> by people replacing working code in the OS directories with broken code.
> As soon as you implemented the policy that you can't overwrite
> microsoft's code with your own, the DLL hell bits went away.

I might go as far as 6 years ago, but I remember the folks doing package 
management for desktop distribution in the company I worked for at the 
time having to jump through all sorts of hoops to get some programs to 
work together because of differences in DLL versions.  We had something 
like 15,000 desktops total and had to test all applications against all 
others generally before rolling them out.  We had a team of 4-6 people 
who worked on the packaging.

Jim

Post a reply to this message

On Sat, 14 Feb 2009 21:29:40 +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.

Jim

Post a reply to this message

Jim Henderson wrote:
> work together because of differences in DLL versions. 

I suppose it's not completely solved anywhere, no. But it's a lot better 
than it was. At least DLL hell only affects third-party DLLs now, and 
installing software that *doesn't* share DLLs won't break your code. :-)

It used to be a lot worse, tho, especially with things like third-party tcp 
stacks (i.e., winsock.dll), where every browser came with a different 
implementation of TCP and such.  Or the MS C runtimes, or the "New" 3D 
button graphics libraries, etc.  People would do things like try to replace 
the GUI libraries with their own in order to put their own "theme" on 
things, thereby breaking everyone else who actually based their code on 
released OS files. :-)

-- 
   Darren New, San Diego CA, USA (PST)
   "Ouch ouch ouch!"
   "What's wrong? Noodles too hot?"
   "No, I have Chopstick Tunnel Syndrome."

Post a reply to this message

Jim Henderson wrote:
> That used to be common with GCC 

I remember seeing the bootstrap code for compiling Hermes, which had its own 
assembly language that looked a lot like SQL for example. :-) It had 
comments in there like "Only Greg, the God of Awesome, is allowed to touch 
this, because the rest of you keep screwing it up."

-- 
   Darren New, San Diego CA, USA (PST)
   "Ouch ouch ouch!"
   "What's wrong? Noodles too hot?"
   "No, I have Chopstick Tunnel Syndrome."

Post a reply to this message

On Sat, 14 Feb 2009 13:46:03 -0800, Darren New wrote:

> Jim Henderson wrote:
>> work together because of differences in DLL versions.
> 
> I suppose it's not completely solved anywhere, no. But it's a lot better
> than it was. At least DLL hell only affects third-party DLLs now, and
> installing software that *doesn't* share DLLs won't break your code. :-)

I'd go with that....

> It used to be a lot worse, tho, especially with things like third-party
> tcp stacks (i.e., winsock.dll), where every browser came with a
> different implementation of TCP and such.  Or the MS C runtimes, or the
> "New" 3D button graphics libraries, etc.  People would do things like
> try to replace the GUI libraries with their own in order to put their
> own "theme" on things, thereby breaking everyone else who actually based
> their code on released OS files. :-)

Yeah, I can remember back in the Win9x days there being 3rd party TCPIP 
stacks that you could create all sorts of havoc with.

Jim

Post a reply to this message

On Sat, 14 Feb 2009 13:47:20 -0800, Darren New wrote:

> Jim Henderson wrote:
>> That used to be common with GCC
> 
> I remember seeing the bootstrap code for compiling Hermes, which had its
> own assembly language that looked a lot like SQL for example. :-) It had
> comments in there like "Only Greg, the God of Awesome, is allowed to
> touch this, because the rest of you keep screwing it up."

LOL, love it.

The oddest system I ever saw was one that used lisp at the system level.  
I can't for the life of me remember the manufacturer of the system.  It 
was used for a prototype of an ATC simulator where the system applied AI 
to the situation to do the control for the operator - used for training 
purposes.

Jim

Post a reply to this message

Orchid XP v8 wrote:
> I should probably get out more...

Oh, and for some reason I picked this backlogged link to read today, for 
anyone who doesn't know the basics of writing their own compiler.

http://msdn.microsoft.com/en-us/magazine/cc136756.aspx

-- 
   Darren New, San Diego CA, USA (PST)
   "Ouch ouch ouch!"
   "What's wrong? Noodles too hot?"
   "No, I have Chopstick Tunnel Syndrome."

Post a reply to this message

>> 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

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 wrote:

> It's still compiling. o_O

...still going...

It has at least now finished compiling all the libraries. It's now 
recompiling the compiler.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

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] devnull> 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