Re: [Astlinux-users] trunk bash compile minor error

[Kristian K. <kri...@gm...>]

On 3/16/07, ast...@el... <ast...@el...> wrote:
>
> But the concurrent jobs setting was at the default 2...

  The only reason I asked was because the more concurrent jobs, the
harder it is to read errors from make, gcc, etc, as they are printed
on the screen.  It doesn't have anything to do with the actual number
of jobs.  It just makes it easier to read.

> I've reinstalled a fair amount of stuff, and ran with only 1
> concurrent job and that seemed to make it go away, I think.

  That could very well be the case.  Can you find out for sure?

> Using gcc 4.2 20070307, binutils 2.16.91.0.7 , and a hand fix in the
> makefile for syslinux so it doesn't call the windows stuff (changing
> the $(BOBJECTS) to $(BTARGET), I got a compile to finish properly.

  Hmmm...  That hand fix is not required with the standard
configuration.  Do you know why you needed to make this change?

> Too bad I don't have an easy way to test the image itself.

  "make iso" - load astlinux.iso into VmWare.  It will boot and run as
a live cd.

> I'm really tempted to make a proper VMware development environment so
> I can say definitively that my environment isn't at fault. Maybe stick
> that into the SVN repository as well?

  While many people use VMWare, that really defeats the purpose of
buildroot.  trunk now includes a basic dependency check.  I plan on
extending that to check the host system for all of the various
required software components, versions, etc.  That should drastically
cut down on some of the problems people are having.

  I should also point out that a lot of your problems come from using
non-standard options.  Your GCC snapshot and bleeding-edge binutils,
for instance.  Quite frankly, there is no way that we could possibly
support all of the various options and packages in buildroot.  Just
because an option for a given version of binutils (for instance), is
available it doesn't mean that it has been tested with all of the
various packages and other options.  As Darrick pointed out a while
ago, we only have the resources to support the default config.

  Most of the time you can change a few options, packages, etc without
causing too many problems.

  How would we stick a VmWare image into SVN?


-- 
Kristian Kielhofner