[Buildroot] rebuilding a project on older commits

[Buildroot] rebuilding a project on older commits

[Carsten Schoenert]

Hello,

is there a simple way to rebuild a project without the whole
crosscompiler part?

I have to search in my project why now the current output of Buildroot
isn't startable via nfs. So I want to go back and try out which commit
breaks the build, like I can do similar with git bisect in other Git
repos. Probably the busybox here is miss configured in the between time
because the current kernel config, which has also some little changes
works with an older rootfs.tar.

The current kernel with an actual rootfs ended up with
> [   10.890000] Looking up port of RPC 100003/3 on 192.168.136.4
> [   10.910000] Looking up port of RPC 100005/3 on 192.168.136.4
> [   10.920000] VFS: Mounted root (nfs filesystem) on device 0:12.
> [   10.930000] Freeing init memory: 104K
> [   10.940000] Kernel panic - not syncing: No init found.  Try passing init= option to kernel. See Linux Documentation/init.txt for guidance.

But after make <myproject>defconfig the complete crosscompiler is
rebuilded which I don't want to do because I don't have change something
on it. How to handle that?

Thanks and regards
Carsten

[Buildroot] rebuilding a project on older commits

[Thomas Petazzoni]

Dear Carsten Schoenert,

On Sat, 26 Jan 2013 18:57:28 +0100, Carsten Schoenert wrote:

> is there a simple way to rebuild a project without the whole
> crosscompiler part?

The easiest way is to use an external toolchain. This way, your
toolchain is never rebuilt, but directly used pre-compiled.

> I have to search in my project why now the current output of Buildroot
> isn't startable via nfs. So I want to go back and try out which commit
> breaks the build, like I can do similar with git bisect in other Git
> repos. Probably the busybox here is miss configured in the between
> time because the current kernel config, which has also some little
> changes works with an older rootfs.tar.
> 
> The current kernel with an actual rootfs ended up with
> > [   10.890000] Looking up port of RPC 100003/3 on 192.168.136.4
> > [   10.910000] Looking up port of RPC 100005/3 on 192.168.136.4
> > [   10.920000] VFS: Mounted root (nfs filesystem) on device 0:12.
> > [   10.930000] Freeing init memory: 104K
> > [   10.940000] Kernel panic - not syncing: No init found.  Try
> > passing init= option to kernel. See Linux Documentation/init.txt
> > for guidance.

Does Busybox has the init applet enabled? Is /sbin/init a symbolic link
to /bin/busybox? Are the shared library loader and the C library both
available in /lib in your root filesystem?

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] rebuilding a project on older commits

[Carsten Schoenert]

Hello Thomas,

Am 27.01.2013 09:30, schrieb Thomas Petazzoni:
> The easiest way is to use an external toolchain. This way, your
> toolchain is never rebuilt, but directly used pre-compiled.

Yes, this is the solution. Right now I build the toolchain with ct-ng
inside buildroot.
Is it possible to move this existing toolchain outside buildroot or
should I rebuild from scratch?

> Does Busybox has the init applet enabled? Is /sbin/init a symbolic link
> to /bin/busybox? Are the shared library loader and the C library both
> available in /lib in your root filesystem?

For the first two points I can answer with yes, but your tip with the
/lib folder is the right one. This folder is empty, and this also in the
output/target directory so it must be empty in the rootfs.tar too.

So the libraries in the /lib folder are missing there must be something
wrong with the config of the ct-ng? Any suggestions where I have to look to?


PS: I'm on a business trip shortly so I can't answer quickly.

-- 
Regards
Carsten

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cst_hdx_2.6.34.13_defconfig
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130127/bd1eeef1/attachment-0003.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: busybox-1.20.2.config
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130127/bd1eeef1/attachment-0004.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ct_ng_config
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130127/bd1eeef1/attachment-0005.ksh>

[Buildroot] rebuilding a project on older commits

[Thomas Petazzoni]

Dear Carsten Schoenert,

On Sun, 27 Jan 2013 10:11:46 +0100, Carsten Schoenert wrote:

> Yes, this is the solution. Right now I build the toolchain with ct-ng
> inside buildroot.
> Is it possible to move this existing toolchain outside buildroot or
> should I rebuild from scratch?

You should build it once with Crosstool-NG outside of Buildroot,
install it somewhere, and tell Buildroot to use it as an external
toolchain.

> For the first two points I can answer with yes, but your tip with the
> /lib folder is the right one. This folder is empty, and this also in
> the output/target directory so it must be empty in the rootfs.tar too.
> 
> So the libraries in the /lib folder are missing there must be
> something wrong with the config of the ct-ng? Any suggestions where I
> have to look to?

That sounds really odd. Maybe we have a bug in the ct-ng backend, and
it doesn't copy the libraries? I would have to do a test build, but I'm
on the battery in the train for now, so I can't do heavy builds for now.

If someone could do a quick test build of a minimal system that uses
the ct-ng backend, and verify that $(O)/target/lib contains the right
libraries, that would be nice.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] rebuilding a project on older commits

[Stephan Hoffmann]

Am 27.01.2013 11:33, schrieb Thomas Petazzoni:
> Dear Carsten Schoenert,
>
> On Sun, 27 Jan 2013 10:11:46 +0100, Carsten Schoenert wrote:
>
>> Yes, this is the solution. Right now I build the toolchain with ct-ng
>> inside buildroot.
>> Is it possible to move this existing toolchain outside buildroot or
>> should I rebuild from scratch?
> You should build it once with Crosstool-NG outside of Buildroot,
> install it somewhere, and tell Buildroot to use it as an external
> toolchain.
>
>> For the first two points I can answer with yes, but your tip with the
>> /lib folder is the right one. This folder is empty, and this also in
>> the output/target directory so it must be empty in the rootfs.tar too.
>>
>> So the libraries in the /lib folder are missing there must be
>> something wrong with the config of the ct-ng? Any suggestions where I
>> have to look to?
> That sounds really odd. Maybe we have a bug in the ct-ng backend, and
> it doesn't copy the libraries? I would have to do a test build, but I'm
> on the battery in the train for now, so I can't do heavy builds for now.
>
> If someone could do a quick test build of a minimal system that uses
> the ct-ng backend, and verify that $(O)/target/lib contains the right
> libraries, that would be nice.
I just tried (took beaglebone-defconfig and only changed toolchain to
ct-ng) and output/target/lib/ seems o.k.
> $ ls output/target/lib/
> ld-uClibc-0.9.33.2.so  libcrypt.so.0      libdl.so.0       
> libm.so.0           libpthread-0.9.33.2.so  libresolv.so.0    
> libuClibc-0.9.33.2.so
> ld-uClibc.so.0         libc.so.0          libgcc_s.so.1    
> libnsl-0.9.33.2.so  libpthread.so.0         librt-0.9.33.2.so 
> libutil-0.9.33.2.so
> libcrypt-0.9.33.2.so   libdl-0.9.33.2.so  libm-0.9.33.2.so 
> libnsl.so.0         libresolv-0.9.33.2.so   librt.so.0        
> libutil.so.0
Kind regards

Stephan
>
> Best regards,
>
> Thomas


-- 
reLinux     -    Stephan Hoffmann
Am Schmidtgrund 124    50765 K?ln
Tel. +49.221.95595-19    Fax: -64
www.reLinux.de     sho at reLinux.de

[Buildroot] rebuilding a project on older commits

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

Hi,

 >> Is it possible to move this existing toolchain outside buildroot or
 >> should I rebuild from scratch?

 Thomas> You should build it once with Crosstool-NG outside of Buildroot,
 Thomas> install it somewhere, and tell Buildroot to use it as an external
 Thomas> toolchain.

Building it inside Buildroot should also work (E.G. just set
BR2_HOST_DIR to some/place/elsewhere and use that directory as your
external toolchain dir).

 >> For the first two points I can answer with yes, but your tip with the
 >> /lib folder is the right one. This folder is empty, and this also in
 >> the output/target directory so it must be empty in the rootfs.tar too.
 >> 
 >> So the libraries in the /lib folder are missing there must be
 >> something wrong with the config of the ct-ng? Any suggestions where I
 >> have to look to?

 Thomas> That sounds really odd. Maybe we have a bug in the ct-ng
 Thomas> backend, and it doesn't copy the libraries? I would have to do
 Thomas> a test build, but I'm on the battery in the train for now, so I
 Thomas> can't do heavy builds for now.

It sounds like this:

commit de1eb105a45f88d8c6bf0e00f9b878a36114a5c1
Author: Floris Bos <bos@je-eigen-domein.nl>
Date:   Sat Jan 5 19:11:45 2013 +0000

    Fix installation of crosstool-ng libraries to target
    
    When using the crosstool-ng toolchain option, the libc libraries were not
    installed to target.  Buildroot calls the show-tuple function to determine
    the directory to copy from, and it seems that outputs the result to stderr
    instead of stdout
    
    Signed-off-by: Floris Bos <bos@je-eigen-domein.nl>
    Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
    Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>

I don't quite recall when the problem was introduced, but if it's
present in 2012.11, this would certainly be a candidate for 2012.11.2.

-- 
Bye, Peter Korsgaard