make menuconfig Makefile:442: mixed implicit and normal rule

[cayenne]

Hello all,

I was going to try to troubleshoot my sound not working...I apparently have and Intel ICH5 w/AD1981B on the motherboard.

Anyway, I was going to check my kernel config with make menuconfig and I got an error I've not seen before:

[Hu]

What kernel are you trying to build? That affects the exact text of the Makefile, so we cannot predict what that line says. You could also share sed -n -e 430,450p < Makefile | nl -ba -v 430.

[cayenne]

[hedmo]

cayenne


try this.set the line:

442 config %config: scripts_basic outputmakefile FORCE

to:

442 %config: scripts_basic outputmakefile FORCE

[cayenne]

[Hu]

What is the output of emerge --info ; ls -l /usr/src?

[cayenne]

[hedmo]

cayenne


set the line:

1610 / %/: prepare scripts FORCE

to

1610 %/: prepare scripts FORCE

[krinn]

or take the problem the other way :

- as emerge -a =make-3.80* to install an older make that will understand your older kernel config
- or emerge a newer kernel that will be understand by your newer make

- first option: you should build make-3.82 binary package for safety.
- second one: imo, the best, as you will end with a newer fully support kernel, also might stop yourself playing with headers at 2.6.36 with a 2.6.28 more than old kernel.

[cayenne]

[hedmo]

cayenne

i am using mm-sources my self and one day i had to recompile my 2.6.28 kernel.thats why i had this problem to.
as far as i understand from krinn,you can have an old kernel running and updating your system.but when it comes to
like in this case "checking kernel config" the problem starts.it is the same as if you find a cool thing to emerge
but it depends on a newer version of an other program you have already in your system,in that case the compile will
stop and you have to update that other program first.

please someone correct me if i am wrong.

cayenne wrote:

I'm not sure why it is looking at the newer kernels..when the symlink is still pointing at the old one...

=you have updated your system after compiling your kernel and bulled in a new headers

It sounds like your saying it is mixing old with new...and I don't understand how that could happen

=mixed new headers with old kernel

That being said...do you recommend that I just follow the upgrade kernel document...and go that route?

well... the handbook say "keep your portage up to date" =keep your system up to date

[krinn]

what "i think" is happening to you is :

you have an old kernel source made in dutch language, it was ok to build that with a dutch make tool

make evolve to dutch+english
kernel evolve to add english (knowing dutch would be gone soon or later)

make evolve to only speak english
kernel evolve to speak english too (or maybe still speak dutch for old make users)

but now:
you have an english speaking make trying to discuss a dutch written kernel, see where it fail.

It's clearer now ?

that's why i suggest you get an older make to get one that still understand "the dutch" language. And no i'm not sure it comes even from make, but as your make is brand new and your kernel really old, and as it's make that is complaining, it should be make that is too new (or your kernel too old ^^ ), i also highly doubt your make-3.82 was the make version that build your "jun, 6 2009" kernel
and that's also why i suggest you to use a newer kernel


What you should have made ?
1st thing to do (contrary to what you are saying you didn't do) would have been to not update blindly or doing it knowing you will upgrade until its end where all your programs are upto date

Because now your make file is newer, your kernel headers are newer... many things have been update, all programs portage could have update for you without your need have been update.

Next time, read the -vp output and pick choices you like: many as always, and upto your favorite way to admin your system, like for example you could have just mask kernel headers, make...
You could still try to mask them, but you've update some programs that will now only work with the newer version you have, and getting back (as always) is harder (not impossible, but more risky)
And you've done it while gentoo have a big update in between with stabilization of openrc, that need newer udev (and udev need fresh kernel headers....), the bad move in the worst time.

And if you doubt, yes you're mixing old & new, because you're in between the upgrade and portage stopped as it need your choices to go futher, and for you choices are now : upgrade your kernel or downgrade all tools that need a newer kernel because even you success at rebuild your kernel, you'll then see many programs versions assume your kernel have some option your old kernel doesn't have.

You could have avoid that by just looking at what portage was about to do, and even, you could have just guessing it knowing your system wasn't update for long days. Except if all devs were gone fishing, long delays between update mean always big changes, the longer the delay the higher the number of changes.

I would say you have 4 ways to upgrade
1- big delays between upgrade, and special care taken when doing an upgrade
2- big delays, don't care & upgrade eyes closed
3- small delays, don't care upgrade blindly
4- small delays and taking care of what is about to be upgrade

choice 1 & 4 are of course the safer, choice 3 is generally acceptable but still could fail if blindly upgrade but taking a "special" thing in the way, like baselayout/openrc stabilisation or some little troubles we saw one day or another (like a kernel version stabilise and then remove, libpng-1.4, e2fsprogs...)
but choice 2 is the best way to end querying help in the forum

[cayenne]