[Aboriginal] lsi_scsi: error

[Rob Landley]

On 10/11/2011 11:43 PM, John Spencer wrote:
> On 10/10/2011 07:35 PM, Rob Landley wrote:
>> On 10/10/2011 01:14 AM, John Spencer wrote:
>>> On 10/10/2011 03:08 AM, John Spencer wrote:
>>>> btw, do you happen to know by chance why the kernel make disrespects
>>>> my CC/HOSTCC settings and uses gcc instead of distcc ?
>>> nevermind, it seems the only way is to mess with the makefile, if you
>>> dont happen to use the usual prefixed crosstoolchain.
>> Make is horrible, here's how bits of the horror work:
>>
>> Environment variables become the default values of make variables when
>> make starts, but there are two forms of assignment in make: ?= leaves a
>> variable alone if it already has a value, = overwrites unconditionally.
>>   Make developers tend to use the = without thinking about it.
>>
>> To overcome this, variables assigned on the make command line become
>> read-only and cannot be overridden by make assignments.  (The
>> assignments are ignored.)  Thus you specify your architecture and cross
>> compiler on the command line, not in environment variables.
> 
> thanks for the explanation. using make dep; make -j4 CC=distcc i could
> finally get the kernel to use distcc...
> however it compiles since more than 26 hours. the distcc threads on the
> host are rarely doing some work.

Huh, it really shouldn't take that long.  (Although the distcc host
threads usually complete quickly enough that it doesn't look like
they're doing much.)

That said, I'm having some performance problems on my laptop where
native builds under qemu aren't working as fast as they used to.  Trying
to figure out why.

It's not the root filesystem, I downloaded slackware and it took a day
to install and then running the aboriginal build under it (to reproduce
the uClibc++ issue) has been running since yesterday and just made it
base the simple-cross-compiler gcc build and into the kernel headers
install...

It reeeeally shouldn't be this slow.  When I upgraded qemu to 0.15.0
something went "boing", need to figure out what and why...  (Or is it
something to do with emulating the 3.0 kernel?  Hmmm...)

> it seems the bottleneck is the cpp work done on the qemu vm.
> google has targeted this weakness in their "pump mode" addition to
> distcc, but that is unfortunately written in *python*.

Except that preprocessing the headers inside the VM means you're working
in a context where there ARE only one set of headers and falling back to
/usr/include if you can't find something _won't_ accidentally stumble
across bad information you shouldn't be using.

> it seems nobody, and especially not big corporations, cares about
> portability any more.

Big corporations never cared, it's up to us to care.  They trail along
once everybody else is already doing whatever it is.

> apart from its syntax which is even harder to learn than perl, make is
> not that bad imo... at least it is available on nearly all systems and
> compiles without patches, and is relatively powerful.
> once you copy/pasted together your first working makefile, you can reuse
> that relatively well....
> of course i could imagine a better solution, but hey, most of the rest
> is much worse ;)

There's _always_ something worse, that's no excuse to put up with an
existing bad thing...

Rob

 1318465136.0