Linux - Software This forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum. |
Notices |
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
Are you new to LinuxQuestions.org? Visit the following links:
Site Howto |
Site FAQ |
Sitemap |
Register Now
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
|
 |
08-17-2010, 11:31 AM
|
#1
|
Senior Member
Registered: Jun 2010
Location: Wiltshire, UK
Distribution: Void, Linux From Scratch, Slackware64
Posts: 3,219
|
error "mixed implicit and normal rules" while trying to build busybox
Hi I get this error when trying to build busybox on slackware64:
Code:
Makefile:1288: *** mixed implicit and normal rules. Stop.
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?
|
|
|
Click here to see the post LQ members have rated as the most helpful post in this thread.
|
08-17-2010, 02:25 PM
|
#2
|
Senior Member
Registered: Jun 2010
Location: Wiltshire, UK
Distribution: Void, Linux From Scratch, Slackware64
Posts: 3,219
Original Poster
|
Well solved this myself!
Seems newer versions of make don't like lines like:
Code:
config %config: scripts_basic outputmakefile FORCE
just changed them to:
Code:
%config: scripts_basic outputmakefile FORCE
and it compiled fine
|
|
|
12-21-2011, 12:13 AM
|
#3
|
LQ Newbie
Registered: Apr 2007
Posts: 3
Rep:
|
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.
|
|
3 members found this post helpful.
|
12-21-2011, 05:16 AM
|
#4
|
Senior Member
Registered: Jun 2010
Location: Wiltshire, UK
Distribution: Void, Linux From Scratch, Slackware64
Posts: 3,219
Original Poster
|
Thanks for the CORRECT way of dong this
|
|
|
01-02-2015, 09:07 PM
|
#5
|
Member
Registered: Oct 2014
Location: U.S.A.
Distribution: mixed, mostly debian slackare today
Posts: 207
Rep: 
|
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
|
|
|
01-02-2015, 10:33 PM
|
#6
|
Member
Registered: Oct 2014
Location: U.S.A.
Distribution: mixed, mostly debian slackare today
Posts: 207
Rep: 
|
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)
|
|
|
01-02-2015, 11:19 PM
|
#7
|
Member
Registered: Oct 2014
Location: U.S.A.
Distribution: mixed, mostly debian slackare today
Posts: 207
Rep: 
|
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 $@
|
|
|
01-02-2015, 11:24 PM
|
#8
|
Member
Registered: Oct 2014
Location: U.S.A.
Distribution: mixed, mostly debian slackare today
Posts: 207
Rep: 
|
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)
Last edited by debguy; 01-02-2015 at 11:27 PM.
|
|
|
All times are GMT -5. The time now is 01:52 AM.
|
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
|
Latest Threads
LQ News
|
|