[Bug faq/333] Do not report build errors in bugzilla!

["sergstesh at yahoo dot com" <sourceware-bugzilla at sourceware dot org>]

------- Additional Comments From sergstesh at yahoo dot com  2010-02-05 19:02 -------
(In reply to comment #96)
> I very carefully consider behavior of those whom I might help. Developers of
> 'glibc' are absolutely no freaking way such people - because first and foremost
> they are not ready to admit they have bugs.
> 
> Regarding "Building glibc properly is a complex operation with many particular
> dependencies" - let me translate it for you: build documentation is of
> unbelievably low quality. It was enough for me to discover that having _exactly_
> the same settings (i.e. both dependencies and command line options) I can
> successfully build one 'glibc' version and fail to build another.
> 
> Yes, I started looking into build code - it does nasty things not documented
> anywhere. IIRC, it, for example, discards CPPFLAGS, even though 'configure' help
> message traditionally says the environment variable is supported.

You know what, I've played with 'glibc' a little bit more and decided that maybe
I'm too harsh on 'glibc' developers.

So, upon uncovering new facts I want to perform a test, or, rather, even two
tests of 'glibc' developers' honesty, courage (to admit existence of bugs) and
integrity.

The tests consist of making simple statements regarding my build environment and
observed behavior, and asking question WRT the environment and behavior. If
'glibc' developers answer the questions honestly, then I was too harsh.

Here are the tests.

Test 1 BEGIN.

I've played with the following 'glibc' versions: 2.9, 2.10.1, 2.11.1.

While playing with them I had _exactly_ the same build environment, i.e. exactly
the same versions of tools and libraries needed to build 'glibc'.

I also used the same command lines to run 'configure' - except for prefix.

'configure' command line was of the following kind:

./configure  CC="/actual/path/to/gcc" CFLAGS='-march=native -mtune=native -g
-O2' --with-binutils=/path/to/binutils --prefix=/some/common/dir/INSTALL_SUBDIR

, i.e. the only variable part was INSTALL_SUBDIR.

I am pretty sure that build environment is exactly the same for all three cases
because the build is done by a tool of mine, so no manual actions are involved -
except for changing 'glibc' version in the configuration file.

If anybody is interested, I can provide the tool, it's open source (GPL + LGPL +
Artistic licenses) and it builds and installs everything _not_requiring root
permission, so your systems are safe.


For some of the versions 'configure' fails, and for some - not. Rest assured
that the needed utilities are quite new.

The question: is it normal that 'configure' fails for some 'glibc' versions and
not the others ?

If you intend to answer the question, here's two pieces of additional info:

1) if 'configure' doesn't fail, 'make' is also OK;
2) I am warning you in advance that the problem is in 'glibc' build system, and
it looks like you, the developers, have already fixed it, so the question really
is: "Are you, 'glibc' developers, ready to admit that your build system _does_
have bugs - at least from time to time ?".

Test 1 END.


Test 2 BEGIN.

glibc-2.11.1 comes with a file called FAQ, and an interesting item in the FAQ is:

"
1.16.   I get failures during `make check'.  What should I do?

{AJ} The testsuite should compile and run cleanly on your system; every
failure should be looked into.  Depending on the failures, you probably
should not install the library at all.

You should consider reporting it in bugzilla
<http://sourceware.org/bugzilla/> providing as much detail as possible.
If you run a test directly, please remember to set up the environment
correctly. You want to test the compiled library - and not your installed
one. The best way is to copy the exact command line which failed and run
the test from the subdirectory for this test in the sources.

There are some failures which are not directly related to the GNU libc:
- Some compilers produce buggy code.  No compiler gets single precision
  complex numbers correct on Alpha.  Otherwise, gcc-3.2 should be ok.
- The kernel might have bugs.  For example on Linux/Alpha 2.0.34 the
  floating point handling has quite a number of bugs and therefore most of
  the test cases in the math subdirectory will fail.  Linux 2.2 has
  fixes for the floating point support on Alpha.  The Linux/SPARC kernel has
  also some bugs in the FPU emulation code (as of Linux 2.2.0).
- Other tools might have problems.  For example bash 2.03 gives a
  segmentation fault running the tst-rpmatch.sh test script.
".

I managed to build some versions of 'glibc' using the standard

./configure ...
make

sequence, and, as stated above, the environment is generated automatically, i.e.
ultimately by 'configure'. Still, 'make check' fails. I.e. 'configure' either
doesn't check all that needs to be checked, or there are problems somewhere
else in the build mechanism.

The question:

if I _do_ file a bug report as the FAQ suggests, will you consider it in detail
or just mark the bug report as duplicate of this one ?

A similar to the above warning: I am pretty sure it's a bug in 'glibc' build
mechanism, i.e. I am pretty sure what build mechanism fails to do what it needs
to do, and I need to better confirm my findings by trying to work around the
problem in the build mechanism.

Other build mechanisms behave correctly under similar circumstances.

Test 2 END.

-- 


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.