astlinux-users

[Astlinux-users] trunk bash compile minor error

[<ast...@el...>]

Got a bit of a surprise shock when I decided to go a little bleeding edge
with a trunk compile. Seems bash has a minor issue, though I hadn't seen
it before when I either was able to complete a compile, or at least get
much farther along.

This is trunk 757 with gcc 4.2 snapshot 20070307 , compile with ObjC,
shared libraries, and libtool. This is on an older svn checkout where I
had wiped out toolchain, toolchain_buildi586, and build_i586 and did a svn
update to rebuild those parts cleanly while retaining the dl directory.


make[2]: Leaving directory
`/home/ouroboros/astlinuxbuildenv/astlinux/trunk/build_i586/bash-3.0/po'
make[1]: Leaving directory
`/home/ouroboros/astlinuxbuildenv/astlinux/trunk/build_i586/bash-3.0'
rm -f
/home/ouroboros/astlinuxbuildenv/astlinux/trunk/build_i586/root/bin/bash*
mv
/home/ouroboros/astlinuxbuildenv/astlinux/trunk/build_i586/root/usr/bin/bash*
/home/ouroboros/astlinuxbuildenv/astlinux/trunk/build_i586/root/bin/
(cd /home/ouroboros/astlinuxbuildenv/astlinux/trunk/build_i586/root/bin;
/bin/ln -fs bash sh)
rm -rf
/home/ouroboros/astlinuxbuildenv/astlinux/trunk/build_i586/root/share/locale
/home/ouroboros/astlinuxbuildenv/astlinux/trunk/build_i586/root/usr/info \
        /home/ouroboros/astlinuxbuildenv/astlinux/trunk/build_i586/root/usr/man
/home/ouroboros/astlinuxbuildenv/astlinux/trunk/build_i586/root/usr/share/doc
/home/ouroboros/astlinuxbuildenv/astlinux/trunk/build_i586/staging_dir/bin/i586-linux-uclibc-strip
--remove-section=.comment --remove-section=.note
/home/ouroboros/astlinuxbuildenv/astlinux/trunk/build_i586/root/usr/bin/bash
/home/ouroboros/astlinuxbuildenv/astlinux/trunk/build_i586/staging_dir/bin/i586-linux-uclibc-strip:
'/home/ouroboros/astlinuxbuildenv/astlinux/trunk/build_i586/root/usr/bin/bash':
No such file
make: ***
[/home/ouroboros/astlinuxbuildenv/astlinux/trunk/build_i586/root/bin/bash]
Error 1

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

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

On 3/12/07, ast...@el... <ast...@el...> wrote:
> Got a bit of a surprise shock when I decided to go a little bleeding edge
> with a trunk compile. Seems bash has a minor issue, though I hadn't seen
> it before when I either was able to complete a compile, or at least get
> much farther along.
>
> This is trunk 757 with gcc 4.2 snapshot 20070307 , compile with ObjC,
> shared libraries, and libtool. This is on an older svn checkout where I
> had wiped out toolchain, toolchain_buildi586, and build_i586 and did a svn
> update to rebuild those parts cleanly while retaining the dl directory.
>

asterisk,

  Wow, that is bleeding edge!

  Anyways, I can't really make much sense out of that error.  Can you
turn the number of parallel builds down and run make after script?

-- 
Kristian Kielhofner

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

[<ast...@el...>]

On 3/15/07, Kristian Kielhofner <kri...@gm...> wrote:
> On 3/12/07, ast...@el... <ast...@el...> wrote:
> > Got a bit of a surprise shock when I decided to go a little bleeding edge
> > with a trunk compile. Seems bash has a minor issue, though I hadn't seen
> > it before when I either was able to complete a compile, or at least get
> > much farther along.
> >
> > This is trunk 757 with gcc 4.2 snapshot 20070307 , compile with ObjC,
> > shared libraries, and libtool. This is on an older svn checkout where I
> > had wiped out toolchain, toolchain_buildi586, and build_i586 and did a svn
> > update to rebuild those parts cleanly while retaining the dl directory.
> >
>
> asterisk,
>
>   Wow, that is bleeding edge!
>
>   Anyways, I can't really make much sense out of that error.  Can you
> turn the number of parallel builds down and run make after script?
>
> --
> Kristian Kielhofner

But the concurrent jobs setting was at the default 2...

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.

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.

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

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?

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

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

[Darrick H. <dha...@dj...>]

Kristian Kielhofner wrote:
>> 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.
>   
There are several reasons to use VMWare.  The best reason is to prevent 
accidental mishaps.  This will go away with some of the changes in 
trunk, but currently, the makeimage.sh script must be run as root.  I 
know I've accidentially stayed as root and done some actions which could 
potentially cause problems to the host system.  Again, most of that risk 
will go away with trunk shortly.  Kristian has started using a method of 
making the images that doesn't require the user to be root.  (I believe 
this involves fakeroot).

The other reason for using vmware is to have a consistent build 
environment.  Most, if not all, of the development work has been done on 
CentOS4.  If someone doesn't have a spare PC around, they could setup a 
VMware image with CentOS in it (just for consistency).  However, it 
shouldn't matter which version of Linux you compile this on, as long as 
the basic system requirements are met. 
>   How would we stick a VmWare image into SVN?
>   
That would be absurd.  The host system requirements don't change often 
enough to require revision control.  (let along the size of the 
creature).  I don't think we need to distribute a virtual machine for 
the build environment.  It would be good to have the build system 
requirements documented better. Perhaps we need a wiki other than 
voip-info--the information gets too muddled there.

Darrick

-- 
Darrick Hartman
DJH Solutions, LLC
http://www.djhsolutions.com