This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug faq/333] Do not report build errors in bugzilla!
- From: "joseph at codesourcery dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: 5 Feb 2010 20:45:19 -0000
- Subject: [Bug faq/333] Do not report build errors in bugzilla!
- References: <20040816203830.333.roland@gnu.org>
- Reply-to: sourceware-bugzilla at sourceware dot org
------- Additional Comments From joseph at codesourcery dot com 2010-02-05 20:45 -------
Subject: Re: Do not report build errors in bugzilla!
Build problems generally have extremely complicated dependence on the
exact details of the build environment, such that it is effectively
impossible to debug them without access to that environment; attempting to
debug one by mail would likely involve dozens of questions back and forth
asking for details of logs, of the effects of particular changes or of
other aspects of the environment, and hours of wasted time. Instead, if
you have a build problem you should trace it through the build system
yourself and send a report with a detailed analysis of the cause of the
failure and why it indicates a glibc bug, so that readers can understand
the analysis without needing access to your system.
> ./configure CC="/actual/path/to/gcc" CFLAGS='-march=native -mtune=native -g
> -O2' --with-binutils=/path/to/binutils --prefix=/some/common/dir/INSTALL_SUBDIR
Using --prefix other than --prefix=/usr is an extremely unusual
configuration that is unlikely to be well-tested.
> The question: is it normal that 'configure' fails for some 'glibc' versions and
> not the others ?
It is normal to have complicated dependencies on your environment, which
may also involve dependencies on the glibc version. "fails" is never a
useful bug report; a useful one would be along the lines of "configure
test X produces error Y because command A produces result B, whereas for
previous version N command A' is run instead, and distribution builds of
version P do not see the problem because they are configuring with version
Q of command A and with different configure option W; by making change V
the problem would be avoided without affecting the options used in the
distribution builds".
--
http://sourceware.org/bugzilla/show_bug.cgi?id=333
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.