This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: Some weird bug with non gnu-make
On Sat, Jul 14, 2001 at 12:30:47PM -0600, Tom Tromey wrote:
> >>>>> "Marc" == Marc Espie <espie@schutzenberger.liafa.jussieu.fr> writes:
>
> Marc> Nope, this thing is completely broken. Since this list is
> Marc> somewhat politically correct, I won't use the words that come to
> Marc> my mind, suffice it to say I hate those automated tools that
> Marc> never ever work, are always inflexible when I need them to flex,
> Marc> and never ever produce files that work on anything but
> Marc> GNU/Linux.
>
> Marc> Why can't those magic tools `just work' ?
>
> This isn't specific enough for me to do anything about. I'm sorry
> that you are angry. But venting is unlikely to induce anybody to
> address your complaints, even if they were detailed enough to address.
> Mostly it makes me want to flame you. Saying that these tools "never
> ever work" and that they are "completely broken" is unwarranted,
> annoying hyperbole.
Yes, it's sad, isn't it ? It looks like I always have to exagerate to get
some kind of reaction to my bug-reports...
What is not substantiated about what I am saying ? I might be a bit
annoyed at having spent over 15 hours trying to track this extra space
down... and having to wade through libtool and automake does not help.
Because one thing the documentation doesn't do is alleviate the pain
when you actually have to read through the generated Makefiles and
shell-scripts---and I don't even think I'm that bad at reading Makefiles
and shell-scripts, it's just become too gigantic.
> As far as only working on GNU/Linux, that is simply false, at least
> for automake. Automake-generated Makefiles, when Makefile.am is
> correctly written, are extremely portable. For instance, they work
> around bugs in vendor makes and shells.
Something in gcc does not work around a difference between gnu-make and
bsdmake or solaris make. There is an extra space that crops up in a libtool
invocation in multilib mode and confuses libtool. Care to help me track
it down ? after all, you might be lucky and find it right away...
> Yes, if you enable automatic dependency tracking with automake 1.4,
> then you get a nonportable Makefile. This is documented, and
> endlessly discussed on the automake list (perhaps the most frequent
> complaint -- we probably got the default wrong here). This problem is
> eliminated in the cvs automake. If this is what you're referring to
> then RTFM.
Why isn't there an automake release that fixes the problem ?
In case you haven't noticed, people usually ship programs with Makefile.in.
In some cases, quite frequently, they *do* modify the Makefile.in before
shipping them. In that case, I can RTFM all I want, it won't do any good.
The problem already exists in the generated Makefile, and all I can do is
patch the Makefile. Also note that people that use automake and build
Makefile.in and ship them don't have much of a choice. You don't recommend
they use the cvs version, do you ?
Why isn't there an automake release that fixes the problem ?
> Write your own .c.lo rule:
>
> .c.lo:
> $(LTCOMPILE) --tag CC [ ... ]
>
> That ought to work as a workaround.
Nice one. I'll build a patch based on it. This is a useful suggestion.
> Marc> Now for the $10000 question: why doesn't
> Marc> c.lo:
> Marc> $(LIBTOOL) --mode=compile $(COMPILE) -c $<
> Marc> use LTCOMPILE ???
>
> I don't know. It does in cvs.
Why isn't there an automake release that does this ?
If it's fixed in cvs, it's because someone noticed it. But if it isn't
released, it doesn't serve any good. Because other projects released *now*
use the buggy release of automake.