Bugzilla – Bug 3771
linux spell sets up symlinks where it shouldn't
Last modified: 2007-04-01 01:53:46 UTC
The following from kernels/linux/PRE_BUILD: mkdir -p ../include if [[ ! -L ../include/asm-generic ]]; then ln ../src/linux/include/asm-generic ..//include/ -s fi if [[ ! -L ../include/asm ]]; then ln ../src/linux/include/asm ..//include/ -s fi if [[ ! -L ../include/linux ]]; then ln ../src/linux/include/linux ..//include/ -s fi These lines should not be there... the /usr/include/asm and /usr/include/linux both should be generated from the glibc install, and should represent the state of the kernel headers at compile time, not to be replaced by a simple cast -r - c linux. And the reason they should not be there, is when you are compiling multiple kernels, with different patches, and if the patches conflict (which is valid if you are compiling in different directories), it will not build at all. Any questions, ask away.
does glibc actually do that? If so, I guess those can be tugged out. Is this the only thing blocking the ska3 patch bug too? Is there some reason I haven't run into too many build issues with multiple kernels despite this bug? I recompile with different patch sets all the time -- is it only the uml, etc patches that cause this bug to show?
The reason that you haven't run into this problem, is that the patch for the host kernel (skas3) conflicts with the patch for the uml kernel, because of the includes that each of them need... I have deleted those symlinks, and am trying to rebuild glibc, which fails because it wants the headers there already... so we'll see if gcc deals with the copying over... (well, it's the only road block that I can see that is blocking skas3... )
Hmm... seems as though we may need to manually copy the linux and asm... rather than symlink... will update if then after a glibc build that it works...
ok - i should really fix this now. but i am not sure what exactely i shall do. i start to belive the linux spell shouldn't handle the includes at all, but glibc spell should. any advice?
Sorry, I have been very busy at work, and have had no time to test this. I also had to change my machine back to "test", so I may not be much help :( Damien
http://www.linuxgazette.com/issue62/tag/4.html Sorry for such a long delay in getting around to this... From the read of the above URL, it seems as though there should be a "kernel-headers" package, which is what glibc should rely on, so the symlink /usr/src/linux should point to the "kernel-headers" package which glibc was built against. Sooo... moving forward... :) 1) kernel-headers package needs to exist 2) glibc needs to depend on kernel-headers, and needs a trigger to be build when a new kernel-headers in installed 3) /usr/src/linux symlink needs to be created by the kernel-headers package, which then should then setup the appropriate /usr/include/asm etc symlinks 4) perhaps the kernel build shouldn't use the /usr/src directory? Perhaps /usr/src/sorcery/* would be a better build directory? [In case users want to actually use /usr/src to store virgin source that doesn't get purged?] 5) buy worf a beer ? Damien
these links are needed if their is already no headers in /usr/include{asm,asm-generic,linux} make *config will fail without headers in this location. So I changed the spell to only make the symlinks if actual directories aren't already there. glibc current copies the headers from uname -r after a successful build, but this will soon be split into a seperate kernel-headers spell, with optional choice of 2.4 or 2.6 headers and probably arch support for ppc and sparc too This should be fixed now, if there are any unaddressed issues left over then post back here, if you check the linux spell and it now works properly then come back and verify this bug as closed please and thankyou
closing fixed bugs
reassign to sm-grimoire-bugs