General Information about filing bugs

What bugs should be reported?

Most users do not compile the GNU C Library from the sources released by the GNU developers. Most people are using glibc binaries supplied with a complete operating system distribution. Distributions may include their own modifications to glibc in the binaries and sources you get with the operating system. If the glibc you are using comes from a complete operating system distribution, you should report bugs to that distribution project first. Your distribution's own documentation and web pages should refer you to their bug-reporting system. Your distribution's maintainers will determine whether the problem is specific to their modifications or other details of that particular system. If the problem does exist in the standard GNU C Library code, they will report it to the GNU maintainers or direct you how to do so.

So you still want to file a bug?

If you have determined that your bug should be directed directly to the GNU developers and not your distribution maintainers, your next step should be to check the latest sources. Information on the glibc source repository can be found here.

As a rule, bug reports should generally be filed against the current source versions at the time you file the bug. glibc development can move quickly at times and you may find your specific bug has already been fixed. Where to file a bug?

Glibc has a bug database. File bugs against the product name "glibc" and select the appropriate version you are reporting the problem against.

Bug reporting instructions

Step 1. Check your bug against current glibc sources

You might save yourself significant effort by simply checking the problem still exists with current development branch. Building glibc is a tricky business, and glibc maintainers will generally not offer generous support for people having problems building the library. However, you can always ask any question on the help mailing list.

Step 2. Search for existing bugs

Your bug may already have been reported. Firstly, use a general web search engine such as Google to investigate your problem. Search engines should index many different mailing lists where others may have explored the same problem.

Secondly, try your search via the search functionality provided at by the glibc mailing lists. These are the main lists where the GNU developers discuss glibc issues.

Finally, use the query existing bug reports and the most frequently reported bugs forms to attempt to identify your bug in Bugzilla.

If you find your bug some relevant actions (in increasing order of usefulness) might be

Step 3. File a new bug

If your bug does not appear to exist, you may file a new bug with the new bug form. Bugzilla contains a general bug writing guide explaining the interface.

Please take into account the following guidelines:

Duplicate Bugs

Even if you think a bug is new, expert glibc bug hunters may recognise it as a symptom of an existing problem and mark it as duplicate.

Support Categories

Support is broadly divided up into components relating to divisions in the libc source code. Please read the component descriptions and file your bug appropriately.

What to put in a new report

What not to put in a new report

None: FilingBugs (last edited 2016-11-26 03:36:42 by CarlosODonell)