release: 0.1.41

[lilypond.git] / BUGS

diff --git a/BUGS b/BUGS
index 433d3c5f3f0a18d65815501500a5bd89c7f41085..810766b46ed396d25b94e59c66651af9b86f0fe7 100644 (file)
--- a/BUGS
+++ b/BUGS
@@ -1,17 +1,11 @@
 Document Really Ugly Bugs (coredumps, assert fails, etc)
 
-[Solaris]
 
-Stack frame overwrite on Solaris 2.x (this will produce a seg
-fault, signal 11).  Stacktrace
+[GNU libc]
 
-       Engraver_group_engraver::Engraver_group_engraver(int)
-       Score_engraver::Score_engraver( )
-       get_group_engraver_p()
-
-We don't know a fix or workaround, but compiling without optimisation
-might help (Without -O2 optimisation, my execs run fine on Solaris;
-without -O2, but with purify, it dumps core)
+The GNU extension memmem() is known to be buggy on linux libc 5.0.9
+and before. Glibc upto 2.0.5 also has problems with memmem (), but
+these should not affect LilyPond.
 
 
 [Linux Intel]
@@ -39,4 +33,22 @@ Typical stacktrace:
 
 
 I get bitten by this every once in a while, and I am very interested
-in hints what might be wrong.
+in hints what might be wrong.  This problem has only been identified
+with libc-5.3 and libc-5.4 platforms, so you might try upgrading to
+6.0, ie. GNU libc-2.
+
+
+[Linux Intel]
+
+A problem resembling the previous: usage of libg++.2.8.x with the
+wrong version of libc results in a coredump from the scanner while
+reading the init files.  Stacktrace:
+
+       ios::eof (this=0x0)
+       
+       yyFlexLexer::LexerInput (this=0x8294848, buf=0x82955f0 "", max_size=8192)
+       yyFlexLexer::yy_get_next_buffer (this=0x8294848)
+       My_lily_lexer::yylex (this=0x8294848) 
+
+Fix: follow the install instructions of libg++: match the right
+library versions.