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.
Attachment:
pgp2rsPjXlB4G.pgp
Description: PGP signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
