Tiny Core Linux
Tiny Core Base => TCB Q&A Forum => Topic started by: wdef on October 09, 2011, 09:24:51 AM
-
Hi,
My apologies if this info is somewhere, I couldn't see it offhand on the wiki.
Are the shipped tinycore kernels built on tinycore?
Is the kernel in tc-4.0.1 built with compile.tcz?
If so, what else is installed - presumably perl.
When building modules I want to be sure these match the running tc kernel. Are the "prepared" kernel sources (kernel sources intact after building and installing a kernel) for tc-4.0.1 available to download anywhere?
Thanks
-
When building modules I want to be sure these match the running tc kernel. Are the "prepared" kernel sources (kernel sources intact after building and installing a kernel) for tc-4.0.1 available to download anywhere?
Thanks
The patched kernel source and config are here:
http://distro.ibiblio.org/tinycorelinux/4.x/x86/release/src/kernel/linux-3.0.3-patched.tar.xz (http://distro.ibiblio.org/tinycorelinux/4.x/x86/release/src/kernel/linux-3.0.3-patched.tar.xz)
http://distro.ibiblio.org/tinycorelinux/4.x/x86/release/src/kernel/config-3.0.3-tinycore (http://distro.ibiblio.org/tinycorelinux/4.x/x86/release/src/kernel/config-3.0.3-tinycore)
You can either prepare the kernel source the long way using compiletc, perl5, bash and ncurses-dev or you can use compiletc and linux-headers-3.0.3-tinycore without the kernel source
-
Note that the kernel is usually one of the earliest pieces built, so it was done with the previous toolchain - in this case on the 3.x gcc.
-
Thanks. I need the full tree. Bummer about the older gcc, just built the kernel with newer gcc.
Do you know which gcc 3.x version the kernel was built with?
-
Hi wdef
gcc -v is reporting version 4.4.3 under TC3.4.
-
Yes, TC 3, not gcc 3 ;)
-
Hi wdef
Looking at the first line of dmesg will also tell you the compiler version used to build the kernel.
-
Hi wdef
Looking at the first line of dmesg will also tell you the compiler version used to build the kernel.
So it does. Thanks I'd completely forgotten that. It's not a good idea to build modules with a different version of gcc to that which the kernel was compiled with.
-
Common bootstrapping is to recompile the kernel with the shipping toolchain before release.
-
Are you saying that is what happens with TC releases or that is what ought to happen?
ie TC's kernel as released should always have been compiled with the same gcc and tools as in compiletc extension in the repo provided for that release.
If that is the intent, there appears to be a mismatch.
On multicore (plus) 4.0.1:
$ dmesg | grep "Linux version"
Linux version 3.0.3-tinycore (root@box) (gcc version 4.4.3 (GCC) ) #90210 SMP Thu Aug 18 11:28:07 EEST 2011
but compiletc.tcz:
$ gcc -v 2>&1 | grep version
gcc version 4.6.1 (GCC)
If modules have been submitted to the repo compiled with a different version of gcc to the one that built the running kernel, that's a problem.
-
Common bootstrapping is to recompile the kernel with the shipping toolchain before release.
And thus invalidate testing results / force redoing tests?
-
Or the other way around: could the exact matching versions of gcc and tools used to build the released kernel be put in the repo, perhaps named appropriately?
-
And thus invalidate testing results / force redoing tests?
If you build the toolchain first, that should not be a problem.
Currently we have source and tools that don't build the current release.
-
Currently we have source and tools that don't build the current release.
The current toolchain built eglibc in the current release. The previous toolchain built the kernel, but it's been that way for three releases now without problems.
-
As long as there are no problems, OK.
-
I agree it would be better to have matching sets, but it's so far happened that the kernel's been one of the first items in a new release - it's one of the most important components in the core.
I should mention that the 64-bit toolchain in 4.x has not changed from 3.x, it can be used to build the 64-bit modules.
-
Building the whole thing with toolchains made available in the current repo is probably what is expected.
If I want to build a matching (32-bit) kernel to that in TC4.x, I'll need to do it booted from TC3.x with its tools installed. Ok now I know, thanks.
-
If I want to build a matching (32-bit) kernel to that in TC4.x, I'll need to do it booted from TC3.x with its tools installed. Ok now I know, thanks.
You can build Kernel practically on any other 2.6.x/3.0 LINUX system of course within certain limits, like CentOS, OpenSuSe, Fedora, ...
-
Yes but the goal is to get a matching kernel and prepared source tree, not just the same kernel version. For that I'll need to use the same gcc and tools as was used to build TC4.x's if I want to insert modules built for TC4.x (which should have all been built with the TC3.x toolchain) without issues. Of course I could get those on another system.
If built otherwise (with a different toolchain), modules will still insert and will most of the time still work without issues - but a gremlin may appear one day unexpectedly.
-
What is matching kernel?
-
For example, if I compile a kernel module using the compiletc.tcz tools found in the 4.2.1 repository
( which has gcc ver. 4.6.1 , etc. ) and the kernel source available for linux-3.0.3-tinycore,
I cannot load the module, because it does not match the kernel.
So, while the module compiled successfully, when attempting to " insmod somedriver.ko "
it results in "invalid module format" and does not load.
I will try using a TC. 3.6 installation, which has GCC 4.4.3,
but will the remainder of the tools in the compiletc.tcz extension, found in the TC 3.6 repository
work with the 3.0.3 kernel source?
-
This will be fixed in the coming 4.4. Yes, current 4.x kernel was built in 3.x.