rebuilding a project on older commits
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
Quoted 5 lines
[ 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
Dear Carsten Schoenert,
Quoted 2 lines · Carsten Schoenert
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.
Quoted 7 lines
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.
Quoted 8 lines
The current kernel with an actual rootfs ended up with
Quoted 7 lines
[ 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. Trypassing init= option to kernel. See Linux
Documentation/init.txtfor 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
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
Hello Thomas,
Am 27.01.2013 09:30, schrieb Thomas Petazzoni:
Quoted 2 lines
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?
Quoted 3 lines
Does Busybox has the init applet enabled? Is
/sbin/inita 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.
Signature · 15 lines
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>
Dear Carsten Schoenert,
Quoted 4 lines · Carsten Schoenert
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.
Quoted 7 lines
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
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
Am 27.01.2013 11:33, schrieb Thomas Petazzoni:
Quoted 19 lines
Dear Carsten Schoenert,
Quoted 4 lines · Carsten Schoenert
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.
Quoted 7 lines
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?
Quoted 7 lines
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.
Quoted 10 lines
$ 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
Quoted 4 lines
Best regards,
Thomas
Signature · 4 lines
reLinux - Stephan Hoffmann Am Schmidtgrund 124 50765 K?ln Tel. +49.221.95595-19 Fax: -64 www.reLinux.de sho at reLinux.de
Peter Korsgaard
Acked-by Yann E. MORINQuoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Thomas" == Thomas Petazzoni <[email protected]> writes:
Hi,
Quoted 2 lines
Quoted 2 lines
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).
Quoted 7 lines
Quoted 7 lines
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 <[email protected]> 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
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.
Signature · 1 line
Bye, Peter Korsgaard