error "mixed implicit and normal rules" while trying to build busybox
 

Hi I get this error when trying to build busybox on slackware64:I've tried googling and there seems to be no mention of this error, if I download the precompiled binary it works fine any ideas?

Well solved this myself!
Seems newer versions of make don't like lines like:just changed them to: and it compiled fine

Correct Fix
 

Your fix:

config %config: scripts_basic outputmakefile FORCE
changed to
%config: scripts_basic outputmakefile FORCE

is incorrect because the original line has both an implicit rule and an explicit rule, and you deleted one.

The correct fix is to split the rules. I suspect that there were 1 or more make commands below that rule. Your fix ignored one of the rules. The proper fix is to split the 2 rule line into two separate sections:

config: scripts_basic outputmakefile FORCE
some make command(s) here
%config: scripts_basic outputmakefile FORCE
same make command(s) here again

see http://osdir.com/ml/bug-make-gnu/2011-04/msg00011.html

I learned this by applying your fix, and my compile of my ARM linux kernel worked, but I found I could still not configure the kernel with "make menuconfig" until I changed the fix to the proper format as I have shown above.

Thanks for the CORRECT way of dong this

I disagree
 

what i more see is glibc NOT building where it had worked fine before they broke it. i dont believe it was broken - i have no reason to beleive everthing they say.

i do believe they are intently seeking non-compatibility (their own words) and to break linux.

i do no appreciate it. in the USA their is an ANTI TRUST act, the sherman act, which, et alia, prevents persons from a competing platform from tamperously editing critical files in another platform in ways that delay and damage the normal operation of the OS and the business of the people using it. also i see many editing the american product running on computers in the USA on USA servers aren't from the USA and might have agendas. i'm sure allot of good work comes from overseas i'm also sure allot of attacks and even killings do as well.

i really dont care if others agree with me. you keep your opinion i dont care.

########################

"My opinion on backward-compat is that we make an effort to avoid backward-incompatibilities and try to ensure they have the smallest possible impact. This change would likely have never been noticed if it hadn't affected Linux"

bug #33034: "Makefile:23: *** mixed implicit and normal rules. Stop." for Linux kernel out of source builds

2010-07-18 Paul Smith <psmith@gnu.org>

* configure.in: Switch bsd_signal to AC_CHECK_DECLS() to make sure
we have a declaration. Fixes Savannah bug #25713 (maybe?)
* doc/make.texi (Complex Makefile): Cleanup variable assignments.
(One Shell): New subsection for the .ONESHELL special target.

Patches by Ozkan Sezer <sezeroz@gmail.com>:

* misc.c (strncasecmp): Local implementation for systems without.
* config.h.W32.template (HAVE_STRNICMP): Define on Windows.
* configure.in: Check for strncasecmp/strncmpi/strnicmp.
* job.c [WINDOWS32]: Don't define dup2 on Windows.
(pid2str): Use "%Id" even with MSVC
(exec_command): Cast to pid_t when calling pid2str().
* w32/subproc/sub_proc.c [WINDOWS32]: Include config.h first.
Use stddef.h on MSVC to get intptr_t.
* w32/subproc/misc.c [WINDOWS32]: Include config.h first.
* w32/compat/dirent.c [WINDOWS32]: Include config.h first.
(readdir): Cast -1 to correct type for d_ino.
* w32/pathstuff.c [WINDOWS32]: Ensure make.h is included first.
* make.h [WINDOWS32]: Don't prototype alloca() on Windows.

---------- Post added 01-02-15 at 10:07 PM ----------

Thanks for the WRONG way of dong this

i tried the above advice it did not work

glibc-2.1x

make subdir=manual -C manual ..=../ subdir_lib
make[2]: Entering directory `/usr/src/glibc-2.11.2/manual'
Makefile:235: *** mixed implicit and normal rules. Stop.
make[2]: Leaving directory `/usr/src/glibc-2.11.2/manual'
make[1]: *** [manual/subdir_lib] Error 2
make[1]: Leaving directory `/usr/src/glibc-2.11.2'
make: *** [all] Error 2

$(objpfx)stubs ../po/manual.pot $(objpfx)stamp%:

OR

$(objpfx)stamp% $(objpfx)stubs ../po/manual.pot:
$(make-target-directory)
touch $@

same error. i tried other makefiles thinking a possible change in target but dont have all day to read every Makefile

i only found a Makefile with % as part of "rule" shown above.

i'm guessing the problem is hackers adding 2000 country .po support (i still refuse to see how i need every language on every PC by default)

i'm guessing they broke C locale compiles in favor of "hey mine works too bad yours is taking so long there are so many obstrctions"

because last pass it had worked - i still have a chroot of the build

perhaps it was upgrade to make-3.82 that "broke rules in favor of WINDOWS32" support (see make ChangeLog - they commented, not my opion their own comment, compatibility didn't matter and linux users could hack every makefile they have past and present to fit their win32 needs)

so i saw this on another article and THIS TIME (mind you it is hackY) it worked:


$(objpfx)stubs:
$(make-target-directory)
touch $@

../po/manual.pot:
$(make-target-directory)
touch $@

$(objpfx)stamp%:
$(make-target-directory)
touch $@

I do take 3 big issues quickly with that

1) how do i distribute suck a hack fix in a Makefile made by configure? anyone would know that wrong.

2) this build it might have worked but many builds clobber Makefile as part of the build process , meaning m4 hacking is needed - much more complicated

3) i dont want 2000 languages on every pc with huge .po directories i like C locale. i want it optional and at most see other languages in X11 if i choose to make it so. i dont want zwahili in my bash .po i dont even want .po i can only imagine it will be used for treason or injury not anything good - the direction the "everyone cannot hack out required features and languages" agenda that seems to evolve from certian hacks for force it to work

4) i lied theres 4. it only happened that splitting it up worked in this case. quite predictably there could be commands using <@ <% <+ whatever that peek at "the whole list" or use the whole list at once: which IS BARRED FROM OCCURING above

to fix it - just a huge mess. nothign is specific everythign in glib's makefile is 3 deep symbolics - which isn't necessarily a good practice when un-necessary (when the real list can be known and does not change during the compile)