This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Some weird bug with non gnu-make
- To: Phil Edwards <pedwards at disaster dot jaj dot com>
- Subject: Re: Some weird bug with non gnu-make
- From: Marc Espie <espie at schutzenberger dot liafa dot jussieu dot fr>
- Date: Sat, 14 Jul 2001 17:01:00 +0200
- Cc: Alexandre Oliva <aoliva at redhat dot com>, gcc-bugs at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org
- References: <20010711145532.A15168@schutzenberger.liafa.jussieu.fr> <oru20jigep.fsf@guarana.lsd.ic.unicamp.br> <20010713012233.A22971@schutzenberger.liafa.jussieu.fr> <20010712205241.A27627@disaster.jaj.com> <20010714161400.A22387@schutzenberger.liafa.jussieu.fr>
- Reply-To: Marc dot Espie at liafa dot jussieu dot fr
Nope, this thing is completely broken. Since this list is somewhat
politically correct, I won't use the words that come to my mind, suffice
it to say I hate those automated tools that never ever work, are always
inflexible when I need them to flex, and never ever produce files that
work on anything but GNU/Linux.
Why can't those magic tools `just work' ?
So, that patch doesn't fix the magic line that needs fixing.
Namely, the problem is compiling signbit.c, and THAT one is done through
the default target...
In the end, this comes from the libtool.am fragment of automake, which
looks like this:
NOTDEPEND.c.lo:
## Note that we explicitly set the libtool mode. This avoids any lossage
## if the program doesn't have a name that libtool expects.
NOTDEPEND $(LIBTOOL) --mode=compile $(COMPILE) -c $<
and I would tend to assume that changing this to insert --tag CC
is a bad idea.
Now for the $10000 question: why doesn't
.c.lo:
$(LIBTOOL) --mode=compile $(COMPILE) -c $<
use LTCOMPILE ???
Guess I will need to go back to hunt and find out that bloody extra space
that libtool is dumb enough to care about...