[Buildroot] Kernel panic - not syncing: Attempted to kill init!
H Hartley Sweeten
hartleys at visionengravers.com
Wed Aug 26 16:45:05 UTC 2009
On Tuesday, August 25, 2009 12:02 PM, Bernhard Reutner-Fischer wrote:
> On Tue, Aug 25, 2009 at 01:48:21PM -0400, H Hartley Sweeten wrote:
>> I found this FAQ on the CodeSourcery website.
>> Installing CodeSourcery Run-time Libraries
>> Would this simplify copying the external toolchain libraries
>> to the target rootfs?
>> What was the original problem with using the external toolchain
>> from it's installed location? Why do the files need to be
>> copied to $(STAGING_DIR) and the flag "--sysroot $(STAGING_DIR)"
>> added to the TARGET_*FLAGS.
>> If the external toolchain is used from the install location I
>> think the -march= option will correctly setup the library paths
>> and allow the multilib toolchain to work correctly. I believe
>> this is how the kernel build works.
> except that the kernel won't link against those helper-libs as opposed
> to userspace which will need some of those libs on the rootfs.
I agree that the kernel does not link against the helper-libs in the
I also agree that those libs need to be copied to the rootfs.
What I don't understand is why they need to be copied to $(STAGING_DIR)
and then needing to re-direct the --sysroot to them. The only comment
about this in ext-tool.mk says:
# 3. Copy the libraries and headers to the staging directory. This
# will allow all further calls to gcc to be made using --sysroot
# $(STAGING_DIR), which greatly simplifies the compilation of the
# packages when using external toolchains. So in the end, only the
# cross-compiler binaries remains external, all libraries and headers
# are imported into the Buildroot tree.
The question is "how" does this actually simplify the compilation?
More information about the buildroot