an update to automake-1.11?

[Sam Varshavchik]

Orcan Ogetbil writes:

> On Mon, Jul 6, 2009 at 9:13 PM, Sam Varshavchik wrote:

>> I specifically cited the potential danger from rebuilding configure that
>> came out of a different version of autoconf than what the upstream used --
>> and I explicitly stated this three or four times.
>>
> 
> Yes you did say that it is dangerous a few times. But you never said
> what the consequences would be, what the dangers actually are.

I see. You want me to explain the possible consequences of a broken build?

> Hold on there. I am not ignoring. I am curiously reading because, as I
> said, I'm willing to learn.
> 
> I am completely neutral about this issue. You don't need to fight me
> :) Just show me some evidence so I'll get convinced into your side.

There is no universal consequence of a broken build, and there is no tell 
tale symptom to watch for.

One example from memory occured about four years ago. Someone else, at 
$dayjob$, was trying to bootstrap the entire toolchain, including gcc. On 
multiple platforms.

Everything seemed to build, and work. Yet, when it was time to build other 
applications, gcc on x86_64 was barfing every time it tried to compile a 64 
bit shared library. Only on x86_64. An error was coming out of the linker. 
Just a typical undecipherable ld error message, that seems to be written in 
English words, but in a language other than English.

Anyway, to make a long story short, I ended up running some sample code 
through both the native (red hat) gcc compiler, and the bootstrapped 
compiler, producing .s assembly files.  Of course, I know x86_64 machine 
language as much as I know Latin, but there were differences. By staring at 
what ended up in the .s files, and some Googling, I eventually traced it 
down to an obscure breakage in one of the configure scripts. It was frobbing 
the version of ld, and, based on the results, making some decision as to 
what features to enable or disable. The breakage was that it was picking up 
the wrong ld (the native one, rather than the one being bootstrapped).

This is just one example of the results of a broken configure script. 
Everything would seem to build, apparently, but with the wrong options for 
the given platform, and you wouldn't realize that something was broken until 
a lot of other people already wasted a lot of time.

> What is this "something"? I am begging you to give me one (1) example.
> I am not sarcastic at all. I am very sincere in this statement.

All you really have to observe is that configure does not run with the -e 
flag set, so if something in the massive shell script fails with a non-zero 
exit code, the rest of the configure script continues to plod along, with 
just a diagnostic message on stderr, which is easily lost amidst all the 
other noisy output produced by configure.

> No, I don't really check what version of autotools upstream used. But
> I look at the build logs and check the resulting binary.  If

Unfortunately, it's not that easy. You may not very well realize that, on 
your platform, the result of some specific "checking for foo" should be 
"yes", instead of "no" (or the other way around), but breakage introduced by 
a rebuild by a different version of autoconf flipped that setting.

> So, let us start from the beginning: Let's say I modify configure.ac
> and use automake/autoconf during building my package. The package
> builds and seems to work "fine". In what step can I miss "something"?

You want me to give you a universal answer how to detect a problem caused by 
breakage due to a rebuild by a different version of autoconf?

As if this can only fail in one specific way, no matter what the break is. 
You believe that a single, specific, light bulb goes on, when configure 
produces wrong results, no matter what those wrong results are.

Riiiiight.

> What will this "something" be?

Could be anything. There is no single error message that is a tell-tale 
indication that it's broke.

And the chances of happening that as a result of making a targeted patch to 
configure, with well defined consequences, are orders of magnitude less than 
patching configure.ac, and then generating a brand. new. script.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20090706/595cbcd9/attachment.bin