Originally created by: *anonymous
Originally created by: brownian.box@gmail.com
Originally owned by: dak@gnu.org
Reported by David Kastrup,
http://lists.gnu.org/archive/html/bug-lilypond/2011-09/msg00215.html:
%-------------------8<--------------------------
When configured with
./configure CXXFLAGS=-fkeep-inline-functions
(which does not optimize unused functions away)
make test fails in the flower subdirectory in the linking stage with quite inscrutable error messages.
I don't have the error message handy right now, but since this has been bugging me on and off for at least a month (basically the only thing failing with make check for me) and I have not been able to make any progress on figuring out just what to do (spent about a day on it), I decided to report this before I forget again.
%-------------------8<--------------------------
Originally posted by: reinhold...@gmail.com
I'm able to reproduce this (with "./configure CXXFLAGS=-fkeep-inline-functions
--disable-optimising").
If I do "cd flower; make clean; make test", I get the following error:
g++ -o out/test-flower ./out/test-file-name.o ./out/test-file-path.o
./out/test-std.o ./out/test-string.o ./out/../../flower/out/library.a
./out/test-file-name.o: In function `recursive_init_error':
/usr/include/c++/4.5/cxxabi.h:623: undefined reference to `vtable for
__gnu_cxx::recursive_init_error'
collect2: ld returned 1 exit status
make: *** [out/test-flower] Fehler 1
A quick google search for the error message brings this up:
http://www.daniweb.com/software-development/cpp/threads/114299
http://gcc.gnu.org/faq.html#vtables
The problem appears to be in flower/include/yaffut.hh, because if I strop down
test-file-name.cc to only include that file (instead of yaffuf-parameters.hh)
and remove all other code there, I still get the linker error...
Originally posted by: dak@gnu.org
Actually, just a file with
#include <cxxabi.h>
will bomb out when compiled with -fkeep-inline-functions. I'll try figuring out whether we can get a workaround until upstream has a fix.
Originally posted by: dak@gnu.org
As mentioned, just #include <cxxabi.h> causes the make check failure when using gcc 4.6.1 (Ubuntu Oneiros). The developer I contacted about it checked with gcc 4.4.x, and there was no problem.
I don't understand yaffut.hh enough to figure out whether one can create a version not including cxxabi.h: it is probably needed for prettifying error messages via demangle and hopefully not much else, and it might be feasible to just rip this out without affecting functionality.
There are other (sparse) reports about this error message under various circumstances. I have no idea whether the recent 4.6.2 release might have fixed this.
Originally posted by: dak@gnu.org
Keep yaffut from attempting to demangle.
Issue 1875
One can get the pretty output by piping the results through "c++filt
-t", but alas, the stepmake stuff is so totally inscrutable that I
have no idea how one would make the test target do that.
But non-demangled output is better than a complete failure.
http://codereview.appspot.com/5375051
Labels: Patch-new
Originally posted by: pkx1...@gmail.com
Passes make and no reg test diffs
james
Labels: -Patch-new Patch-review
Owner: dak@gnu.org
Originally posted by: ColinPKC...@gmail.com
(No comment was entered for this change.)
Labels: -Patch-review Patch-countdown
Originally posted by: dak@gnu.org
Keep yaffut from attempting to demangle.
Issue 1875
One can get the pretty output by piping the results through "c++filt
-t", but alas, the stepmake stuff is so totally inscrutable that I
have no idea how one would make the test target do that.
But non-demangled output is better than a complete failure.
http://codereview.appspot.com/5375051
Labels: Patch-new
Originally posted by: dak@gnu.org
In order to preserve my own sanity, I pushed a somewhat streamlined version of the last patch using autoconf to dev/staging as [rbe9de62c7e951ea7e7cfc932466a40370909bf2d] (I decided that if yaffut.hh checks conditionals from config.hh it should include it itself instead of relying on other files).
This fixes the reported build issue by not demangling if demangling is impossible to do via cxxabi.h on the given platform.
Anybody wanting to turn this into a fancier issue is welcome to do so. But _this_ issue is fixed.
If somebody wants to verify: when using g++ 4.6.1, try in the top directory
./autogen.sh; cd flower; make clean && make && make check
and this should give demangled C++ names on the final dozen lines of output. Then try
CXXFLAGS=-fkeep-inline-functions ./autogen.sh; cd flower; make clean && make && make check
and this will give non-demangled C++ names with this particular compiler (as on Ubuntu 11.10) since including cxxabi.h with that option would cause a link time failure (the previous behavior).
Labels: -Patch-new Fixed_2_5_18
Status: Fixed
Originally posted by: PhilEHol...@googlemail.com
(No comment was entered for this change.)
Status: Verified
Originally posted by: dak@gnu.org
Better fix for issue 1875: use -lsupc++ if required.
This will cause working demangling even when using
CXXFLAGS=-fkeep-inline-functions ./autogen.sh
http://codereview.appspot.com/5441046
Labels: Patch-new
Originally posted by: dak@gnu.org
(No comment was entered for this change.)
Labels: -Fixed_2_5_18
Status: Started
Originally posted by: pkx1...@gmail.com
David,
Is there a specific way you want me to test this against whatever current master is?
I'm slightly unsure if just applying patch, doing a make and make check is enough for this specific change.
let me know
James
Originally posted by: dak@gnu.org
The important angle is that with both
CXXFLAGS=-fkeep-inline-functions ./autogen.sh
and with
./autogen.sh
make test in the flower subdirectory does not break (which is the
current state) but also will in either case display the list of
filenames at the end of its run in "demangled" state, namely using :: in
the filenames instead of weird sequences with underlines (the current
state is that with -fkeep-inline-functions it does not try to demangle
in order to avoid a link-time error for which I did not know the cure up
to now).
The problem for which this is a fix only occurs with gcc-4.6, like on
Ubuntu 11.10.
It's actually totally not worth fixing, but I reported the original
problem to the gcc bug database and would have considered it dishonest,
after actually hearing about what to do, not to put it in there as well.
I have already wasted far more time and bad blood on this non-issue than
it has been worth, so I might as well commit the correct fix.
I checked the respective behaviors on my computer. I leave it to your discretion whether you want to go to the effort of doing the full monty as well.
Originally posted by: pkx1...@gmail.com
hello,
I really am not sure here. I cannot get the same error as reported initially and whatever I do (patch or no patch) i get an error.
--snip--
jlowe@jlowe-lilybuntu2:~/lilypond-git/flower$ CXXFLAGS=-fkeep-inline-functions ./autogen.sh
...etc... runs through until prompt.
jlowe@jlowe-lilybuntu2:~/lilypond-git$ cd flower/
jlowe@jlowe-lilybuntu2:~/lilypond-git/flower$ make test
mkdir -p ./out
touch ./out/dummy.dep
echo '*' > ./out/.gitignore
cp -p /home/jlowe/lilypond-git/config.hh out/config.hh
rm -f ./out/test-file-name.dep; DEPENDENCIES_OUTPUT="./out/test-file-name.dep ./out/test-file-name.o" g++ -c -I/usr/include/python2.6 -I/usr/include/python2.6 -fno-strict-aliasing -g -fwrapv -DHAVE_CONFIG_H -DNDEBUG -I./include -I./out -I../flower/include -I../flower/./out -fkeep-inline-functions -O2 -finline-functions -g -pipe -pthread -I/usr/include/freetype2 -pthread -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -W -Wall -Wconversion -o out/test-file-name.o test-file-name.cc
rm -f ./out/test-file-path.dep; DEPENDENCIES_OUTPUT="./out/test-file-path.dep ./out/test-file-path.o" g++ -c -I/usr/include/python2.6 -I/usr/include/python2.6 -fno-strict-aliasing -g -fwrapv -DHAVE_CONFIG_H -DNDEBUG -I./include -I./out -I../flower/include -I../flower/./out -fkeep-inline-functions -O2 -finline-functions -g -pipe -pthread -I/usr/include/freetype2 -pthread -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -W -Wall -Wconversion -o out/test-file-path.o test-file-path.cc
test-file-path.cc: In constructor '<unnamed>::Find::Find()':
test-file-path.cc:13: warning: ignoring return value of 'char* getcwd(char*, size_t)', declared with attribute warn_unused_result
test-file-path.cc: In constructor '<unnamed>::Find::Find()':
test-file-path.cc:13: warning: ignoring return value of 'char* getcwd(char*, size_t)', declared with attribute warn_unused_result
test-file-path.cc: In constructor '<unnamed>::Find::Find()':
test-file-path.cc:13: warning: ignoring return value of 'char* getcwd(char*, size_t)', declared with attribute warn_unused_result
rm -f ./out/test-std.dep; DEPENDENCIES_OUTPUT="./out/test-std.dep ./out/test-std.o" g++ -c -I/usr/include/python2.6 -I/usr/include/python2.6 -fno-strict-aliasing -g -fwrapv -DHAVE_CONFIG_H -DNDEBUG -I./include -I./out -I../flower/include -I../flower/./out -fkeep-inline-functions -O2 -finline-functions -g -pipe -pthread -I/usr/include/freetype2 -pthread -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -W -Wall -Wconversion -o out/test-std.o test-std.cc
rm -f ./out/test-string.dep; DEPENDENCIES_OUTPUT="./out/test-string.dep ./out/test-string.o" g++ -c -I/usr/include/python2.6 -I/usr/include/python2.6 -fno-strict-aliasing -g -fwrapv -DHAVE_CONFIG_H -DNDEBUG -I./include -I./out -I../flower/include -I../flower/./out -fkeep-inline-functions -O2 -finline-functions -g -pipe -pthread -I/usr/include/freetype2 -pthread -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -W -Wall -Wconversion -o out/test-string.o test-string.cc
make: *** No rule to make target `../flower/./out/library.a', needed by `out/test-flower'. Stop.
jlowe@jlowe-lilybuntu2:~/lilypond-git/flower$
--snip--
?
Originally posted by: dak@gnu.org
Uh, IIRC that's the usual behavior since the dependencies are crap. Sorry, I forgot.
You need to do "make" before doing "make test". I am not even sure that "make all test" works: it might be that the default target is called other than "all".
Originally posted by: pkx1...@gmail.com
David, thanks for your patience. I still cannot get any failure (I use LilyDev if that matters?). After I do 'make' I get
--snip--
jlowe@jlowe-lilybuntu2:~/lilypond-git/flower$ make test
rm -f ./out/test-file-name.dep; DEPENDENCIES_OUTPUT="./out/test-file-name.dep ./out/test-file-name.o" g++ -c -I/usr/include/python2.6 -I/usr/include/python2.6 -fno-strict-aliasing -g -fwrapv -DHAVE_CONFIG_H -DNDEBUG -I./include -I./out -I../flower/include -I../flower/./out -fkeep-inline-functions -O2 -finline-functions -g -pipe -pthread -I/usr/include/freetype2 -pthread -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -W -Wall -Wconversion -o out/test-file-name.o test-file-name.cc
rm -f ./out/test-file-path.dep; DEPENDENCIES_OUTPUT="./out/test-file-path.dep ./out/test-file-path.o" g++ -c -I/usr/include/python2.6 -I/usr/include/python2.6 -fno-strict-aliasing -g -fwrapv -DHAVE_CONFIG_H -DNDEBUG -I./include -I./out -I../flower/include -I../flower/./out -fkeep-inline-functions -O2 -finline-functions -g -pipe -pthread -I/usr/include/freetype2 -pthread -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -W -Wall -Wconversion -o out/test-file-path.o test-file-path.cc
test-file-path.cc: In constructor '<unnamed>::Find::Find()':
test-file-path.cc:13: warning: ignoring return value of 'char* getcwd(char*, size_t)', declared with attribute warn_unused_result
test-file-path.cc: In constructor '<unnamed>::Find::Find()':
test-file-path.cc:13: warning: ignoring return value of 'char* getcwd(char*, size_t)', declared with attribute warn_unused_result
test-file-path.cc: In constructor '<unnamed>::Find::Find()':
test-file-path.cc:13: warning: ignoring return value of 'char* getcwd(char*, size_t)', declared with attribute warn_unused_result
rm -f ./out/test-std.dep; DEPENDENCIES_OUTPUT="./out/test-std.dep ./out/test-std.o" g++ -c -I/usr/include/python2.6 -I/usr/include/python2.6 -fno-strict-aliasing -g -fwrapv -DHAVE_CONFIG_H -DNDEBUG -I./include -I./out -I../flower/include -I../flower/./out -fkeep-inline-functions -O2 -finline-functions -g -pipe -pthread -I/usr/include/freetype2 -pthread -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -W -Wall -Wconversion -o out/test-std.o test-std.cc
rm -f ./out/test-string.dep; DEPENDENCIES_OUTPUT="./out/test-string.dep ./out/test-string.o" g++ -c -I/usr/include/python2.6 -I/usr/include/python2.6 -fno-strict-aliasing -g -fwrapv -DHAVE_CONFIG_H -DNDEBUG -I./include -I./out -I../flower/include -I../flower/./out -fkeep-inline-functions -O2 -finline-functions -g -pipe -pthread -I/usr/include/freetype2 -pthread -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -W -Wall -Wconversion -o out/test-string.o test-string.cc
make --no-builtin-rules -C ../flower && true
make[1]: Entering directory `/home/jlowe/lilypond-git/flower'
make PACKAGE=LILYPOND package=lilypond -C include all && true
make[2]: Entering directory `/home/jlowe/lilypond-git/flower/include'
true
make[2]: Leaving directory `/home/jlowe/lilypond-git/flower/include'
make[1]: Leaving directory `/home/jlowe/lilypond-git/flower'
g++ -o out/test-flower ./out/test-file-name.o ./out/test-file-path.o ./out/test-std.o ./out/test-string.o ./out/../../flower/out/library.a
./out/test-flower
pid(12877)
::parray_concat [OK]
::parray_uniq [OK]
::string_split_join [OK]
::vector_erase [OK]
::vector_insert [OK]
::vector_search [OK]
::vector_slice [OK]
::vector_sorting [OK]
File_name::Canonicalize [OK]
File_name::CaseB [OK]
File_name::Mingw_slashify [OK]
File_name::Mingw_slashify_2 [OK]
File_name::Mingw_slashify_3 [OK]
File_name::Mingw_slashify_4 [OK]
File_path::Find [OK]
[TOTAL](15/15)
[OK](15/15)
jlowe@jlowe-lilybuntu2:~/lilypond-git/flower$
--snip--
This is the same before and after the patch is applied.
Regards
james
Originally posted by: dak@gnu.org
> I still cannot get any failure (I use LilyDev if that matters?).
Well, I wrote
>> The problem for which this is a fix only occurs with gcc-4.6, like on Ubuntu 11.10.
So you can't verify the problem is fixed with your setup, but at least you could verify that on LilyDev the situation does not get any worse.
I verified the fix to work myself, so I'd say we call this good enough. If someone with gcc-4.6 wants to verify independently: Countdown gives him plenty of time.
Originally posted by: pkx1...@gmail.com
Fair enough.
James
Labels: -Patch-new Patch-review
Originally posted by: ColinPKC...@gmail.com
(No comment was entered for this change.)
Labels: -Patch-review Patch-countdown
Originally posted by: ColinPKC...@gmail.com
Counted down to 20111204
Labels: -Patch-countdown Patch-push
Originally posted by: dak@gnu.org
Pushed as [ra4fb364a0058f701e4e25e799b5ddef511effd72] if I haven't gotten all too confused about the gazillions of branches and issues I have by now flying around.
Labels: -Patch-push
Status: Fixed
Originally posted by: ColinPKC...@gmail.com
Verified on Ubuntu 11.10 and lilypond 2.15.24: I see the function and file names containing the do9uble colon separator.
Status: Verified