Environment for tc kernel build

[wdef]

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

[Juanito]

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/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

[curaga]

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.

[wdef]

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? 

[Rich]

Hi wdef
gcc -v  is reporting version 4.4.3 under TC3.4.

[curaga]

Yes, TC 3, not gcc 3

[Rich]

Hi wdef
Looking at the first line of  dmesg  will also tell you the compiler version used to build the kernel.

[wdef]

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.   

[gerald_clark]

Common bootstrapping is to recompile the kernel with the shipping toolchain before release.

[wdef]

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.

[curaga]

Common bootstrapping is to recompile the kernel with the shipping toolchain before release.

And thus invalidate testing results / force redoing tests?

[wdef]

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?

[gerald_clark]

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.

[Juanito]

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.

[gerald_clark]

As long as there are no problems, OK.