Follow-up Comment #22, bug #33034 (project make):
i don't agree and i see a possible attack
i'm tryign to compile gcc4 with glibc2.11 and seeing Makefile damage
you made comments impact upon linux, compatibility, does not matter
you then say all past Makefiles should be edited by everyone but
On Sun, Oct 20, 2013 at 11:58:00PM -0400, Paul Smith wrote:
On Sun, 2013-10-20 at 20:15 -0700, David Boyce wrote:
Paul.
Thank you very much! This means I'll be able to make professional use
the many features and bugfixes which have arrived post-3.81 at some
point. Given the flurry of
Update of bug #33034 (project make):
Status: Not A Bug = Fixed
Assigned to:None = psmith
Fixed Release:None = SCM
Paul.
Thank you very much! This means I'll be able to make professional use
the many features and bugfixes which have arrived post-3.81 at some
point. Given the flurry of other fit-and-finish fixes lately, would it
be safe to assume there will be a 4.01 or equivalent upcoming in the
foreseeable
On Sun, 2013-10-20 at 20:15 -0700, David Boyce wrote:
Paul.
Thank you very much! This means I'll be able to make professional use
the many features and bugfixes which have arrived post-3.81 at some
point. Given the flurry of other fit-and-finish fixes lately, would it
be safe to assume
Follow-up Comment #15, bug #33034 (project make):
David Boyce wrote:
I agree with some of your points but there was a bit of cherrypicking
involved in the quoting:
... really, what's the chance a trivial one-line change to the top-level
makefile will actually break your driver?
I'm not
Follow-up Comment #16, bug #33034 (project make):
I admit I didn't understand the frustration level with this change. The Linux
kernel was the only package that ever reported any real issues, and there were
(by my count) a total of three patches (all minor) over the span of a couple
of months
Follow-up Comment #17, bug #33034 (project make):
If it turns out that simply changing the fatal() to an error() is sufficient
to resolve this, I'm willing to make that change (I won't add a flag for it;
the message will simply say the syntax is unsupported and should be updated).
Thank you.
Follow-up Comment #12, bug #33034 (project make):
I'm uploading a patch that adds an --allow-mixed-rules option which converts
the fatal error to a warning. This is the only testing it's been subjected
to:
% cat Makefile
all %.o:
@echo Making $@
% make-4.0
Makefile:1: *** mixed implicit
Follow-up Comment #14, bug #33034 (project make):
Yes, I realize it's a bit of a wing and a prayer but from the git log it looks
like this fix got into the same commit as a rewrite of major sections of
read.c. Without reading and thinking through all of it, I figured there was a
chance that
On Thu, 2011-11-10 at 14:51 -0500, tz wrote:
On Nov 10, 2011 2:32 PM, Paul Smith psm...@gnu.org wrote:
On Thu, 2011-11-10 at 10:36 -0500, tz wrote:
You don't need to cross-compile: you can compile natively. What you
can't do is rely on your upstream vendor to provide you the toolchain
Judging from the outpouring of support I received when I made the same
suggestion/offer :-( I'm unsurprised at seeing no public response to
yours either. But disappointed. I agree that this is a real problem
which does not seem to resonate with those not directly affected by
it.
I think the best
I doubt there is much reason to expect public support. Remember the
response to my request:
I really am not interested in changing all the error messages to give
details
about which version of GNU make that error was introduced, and I'm also not
interested in adding flags to every version of GNU
David Boyce wrote:
I'm unsurprised at seeing no public response to
yours either. But disappointed.
I'm not disappointed. Paul doesn't work for me so there is no obligation
for him to write patches or design specs supporting my use cases. And
neverthless, so far I've had no reason to be
On Thu, 2011-11-10 at 10:36 -0500, tz wrote:
Unfortunately, in the embedded world, not everything is updated
constantly. Even the desktop is not updated weekly. ARM is still at
Fedora 12, though 16 was just released. I don't and won't have an
updated kernel tree that works unless I find
Paul Smith wrote:
Today you're having an issue with make, but tomorrow it will be a change
in GCC, or binutils, or whatever... then what? Will you be asking GCC
to add a special flag to switch back to old behavior just to support
older Linux kernels? Not going to happen. Why is this
On Nov 10, 2011 2:32 PM, Paul Smith psm...@gnu.org wrote:
On Thu, 2011-11-10 at 10:36 -0500, tz wrote:
I doubt the entire tree in the FSF repository can be properly
cross-compiled. Debian has taken to arrays of the various processors
so they can go native.
You don't need to
Follow-up Comment #7, bug #33034 (project make):
Just for the record, I have been looking for a spare moment to come up with a
patch to fix this compatibility problem (which affects many projects other
than the Linux kernel, too).
If that's a bad idea for some reason, please feel free to let me
Follow-up Comment #4, bug #33034 (project make):
It would help if for the next version there was a backward compatibility
switch - there are a lot of archived kernel source trees (and probably a lot
of other projects) that this breaks.
It would also help if the error message noted it was a
Follow-up Comment #5, bug #33034 (project make):
I'm not trying to be flip, but what do you do when you upgrade to a new
version of the compiler and older code no longer builds correctly due to more
stringent requirements? I see this in code all the time (not GNU make) with
new versions of GCC
Follow-up Comment #6, bug #33034 (project make):
In fairness, this is a special situation. I have the same problem as tz, and
I expect quite a few other people do too.
My company makes drivers. The corollary is that we keep dozens if not hundreds
of entire Linux kernel source build trees going
On Fri, May 20, 2011 at 12:46 PM, David Boyce invalid.nore...@gnu.org wrote:
My company makes drivers. The corollary is that we keep dozens if not hundreds
of entire Linux kernel source build trees going back 10 years or so in order
to build drivers for them. The way Linux kernel drivers are
Update of bug #33034 (project make):
Status:None = Not A Bug
Open/Closed:Open = Closed
___
Follow-up Comment #3:
This is an intentional
Follow-up Comment #2, bug #33034 (project make):
As workaround for coLinux can change the template scripts/mkmakefile.
*** old:
%/: all
@:
*** new:
$(all) %/: all
ifneq ($(all),)
$(all): all
@:
See also the attached patch.
(file #23162)
Follow-up Comment #1, bug #33034 (project make):
Sorry. forgotten to login while creating this bug.
The bug was original reported by a coLinux user:
http://article.gmane.org/gmane.linux.colinux.general/5230
Make 3.81 works.
___
Reply to
URL:
http://savannah.gnu.org/bugs/?33034
Summary: Makefile:23: *** mixed implicit and normal rules.
Stop. for Linux kernel out of source builds
Project: make
Submitted by: None
Submitted on: Sa 09 Apr 2011 10:42:24 UTC
26 matches
Mail list logo
