GNOME Bugzilla – Bug 610854
glibmm_valuearray fails to run on some systems
Last modified: 2010-03-23 09:39:43 UTC
We are seeing this problem downstream in http://bugs.gentoo.org/show_bug.cgi?id=295726 : The date a year and a month from yesterday will be: 1/1/2011. The copied date is: 1/1/2011. Compose strings: constant string Compose strings: constant string and string_literal Compose strings: 123 and 123.457 Compose strings: 123 and 123.457 Compose strings: foo and goo Compose strings: f and 0xffc88928 12 is lower than 0x10. /var/tmp/portage/dev-cpp/glibmm-2.22.1/work/glibmm-2.22.1/tests/glibmm_valuearray/.libs/test: symbol lookup error: /var/tmp/portage/dev-cpp/glibmm-2.22.1/work/glibmm-2.22.1/tests/glibmm_valuearray/.libs/test: undefined symbol: _ZN4Glib10ValueArrayC1Ev More info: CFLAGS="-O2 -pipe" LDFLAGS="-Wl,-O1" Feel free to ask for any more info you need Thanks a lot
This report is very unclear. Is this a runtime problem or a build error? If this is just about the undefined symbol then you probably have some compiler (or compiler options) incompatibility. Note that I have very little patience for gentoo weirdness. If you enjoy breaking things then you get to enjoy fixing them.
The problem appears when running tests while building glibmm, about compiler options, you can check them in http://bugs.gentoo.org/show_bug.cgi?id=295726#c0 but, if something is missing, feel free to ask for it and I will ask it downstream also
No, I'm not interested in fixing your system. Try to show when this problem appeared in glibmm if you really think it's a glibmm problem.
(In reply to comment #2) > The problem appears when running tests while building glibmm, about compiler > options, you can check them in http://bugs.gentoo.org/show_bug.cgi?id=295726#c0 I checked the valuearray source files for suspicious code, but could not find anything unusual there. The default constructor is declared in the header and defined in the source file; very ordinary. Therefore I strongly suspect that the rather fancy linker flags used are causing the problem. The build log I can inspect at the Gentoo bug report still shows the fancy linker flags.
What exact flags do you think shouldn't be used? Thanks
I'm sorry, but Murray is right here. If you deviate from the defaults, it's your job to track down the resulting problems. The odd linker flags have already been noticed independently by a commenter in the Gentoo bug report, and as I said the build log still shows them being used.
The problem is that in downstream bug report there are two users with this problem: 1. The first one is using default setting as can be seen in: http://bugs.gentoo.org/show_bug.cgi?id=295726#c0 http://bugs.gentoo.org/show_bug.cgi?id=295726#c1 then, this is the case that should maybe be investigated 2. The second one is using some odd linker flags: http://bugs.gentoo.org/show_bug.cgi?id=295726#c5 This is why I asked the last one to use simpler LDFLAGS (I am that commenter you are referring to ;-)): http://bugs.gentoo.org/show_bug.cgi?id=295726#c6 And he reported that was still suffering the problem: http://bugs.gentoo.org/show_bug.cgi?id=295726#c7 (but maybe he should rebuild more apps :-/)
We found were is the problem (and now I am also able to reproduce), it appears when were are updating from 2.20.1 to 2.22.1 , maybe test suite is linking to old glibmm instead of new one
(In reply to comment #8) > We found were is the problem (and now I am also able to reproduce), it appears > when were are updating from 2.20.1 to 2.22.1 , maybe test suite is linking to > old glibmm instead of new one Indeed. Can be reproduced by having system installation of 2.20.1, and then running "make check" on 2.22.1 source tree before "make install" is done. It will fail because the test suite is linking to old glibmm in the system, instead to the one you just built in the source tree... Bug in upstream tests/Makefile.am ordering. Not a bug with so called fancy linker flags. ;-)
(In reply to comment #9) > Bug in upstream tests/Makefile.am ordering. Not a bug with so called fancy > linker flags. ;-) Guys, this is not a pissing contest. I checked the build files yesterday as well, and I couldn't find anything unusual there either. Your own build logs show a correct linker command line: libtool: link: x86_64-pc-linux-gnu-g++ -Wall -march=core2 -O2 -pipe -msse4.1 -Wl,-O1 -Wl,-z -Wl,relro -Wl,-z -Wl,now -o glibmm_valuearray/.libs/test glibmm_valuearray/main.o -Wl,--export-dynamic -Wl,--as-needed ../glib/glibmm/.libs/libglibmm-2.4.so /usr/lib64/libsigc-2.0.so /usr/lib64/libgobject-2.0.so /usr/lib64/libgmodule-2.0.so -ldl /usr/lib64/libglib-2.0.so The fancy linker flags are still there by the way. If this build log is outdated then please update it. I don't think it's impossible that using late symbol resolution could cause a problem like this, maybe in combination with a linker bug.
Created attachment 154863 [details] build.log build.log from system where glibmm-2.20.1 is installed, and glibmm-2.22.1 has been ./configure ; make ; make check and with empty CFLAGS, CXXFLAGS and LDFLAGS.
And, you are right. It's a ebuild bug. The ebuild is running ./tests/glibmm_valuearray/test (and others) without setting e.g. LD_LIBRARY_PATH to the directory where the new libs are. Please close this as INVALID and sorry for the inconvience.
I think libtool should normally take care of that. I saw in the logs that you are apparently doing quite some modifications to the build files (running autoconf in cross-compile mode, elibtoolize, the as-needed patch, rpath is being used, etc.), so that may be the problem. However, before closing this bug I'd like to confirm that the same thing does not happen with a pristine tarball, and *no* LD_LIBRARY_PATH set in the environment. The wrapper script created by libtool should set LD_LIBRARY_PATH to pick up the uninstalled libraries living in the build tree.
(In reply to comment #13) > I think libtool should normally take care of that. I saw in the logs that you > are apparently doing quite some modifications to the build files (running > autoconf in cross-compile mode, elibtoolize, the as-needed patch, rpath is > being used, etc.), so that may be the problem. > > However, before closing this bug I'd like to confirm that the same thing does > not happen with a pristine tarball, and *no* LD_LIBRARY_PATH set in the > environment. The wrapper script created by libtool should set LD_LIBRARY_PATH > to pick up the uninstalled libraries living in the build tree. It's same with pristine tarball (this is output from ./configure ; make ; make check) and entering tests/glibmm_valuearray/ to execute ./test. At this stage, system has glibmm-2.20.1 still installed. ssuominen@foo /tmp/glibmm-2.22.1/tests/glibmm_valuearray $ ./test /tmp/glibmm-2.22.1/tests/glibmm_valuearray/.libs/test: symbol lookup error: /tmp/glibmm-2.22.1/tests/glibmm_valuearray/.libs/test: undefined symbol: _ZN4Glib10ValueArrayC1Ev ssuominen@foo /tmp/glibmm-2.22.1/tests/glibmm_valuearray $ ldd .libs/test linux-vdso.so.1 => (0x00007ffff07ff000) libglibmm-2.4.so.1 => /usr/lib/libglibmm-2.4.so.1 (0x00007f8fb01c9000) libsigc-2.0.so.0 => /usr/lib/libsigc-2.0.so.0 (0x00007f8faffc3000) libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/libstdc++.so.6 (0x00007f8fafcb4000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f8fafa9d000) libc.so.6 => /lib/libc.so.6 (0x00007f8faf744000) libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x00007f8faf500000) libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x00007f8faf2fc000) libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x00007f8faf01b000) [ .. ]
Some more output to demonstrate the problem suominen@foo /tmp/glibmm-2.22.1/tests/glibmm_valuearray $ export LD_LIBRARY_PATH="/usr/lib64:/tmp/glibmm-2.22.1/glib/glibmm/.libs:$LD_LIBRARY_PATH" ssuominen@foo /tmp/glibmm-2.22.1/tests/glibmm_valuearray $ ./.libs/test ./.libs/test: symbol lookup error: ./.libs/test: undefined symbol: _ZN4Glib10ValueArrayC1Ev ssuominen@foo /tmp/glibmm-2.22.1/tests/glibmm_valuearray $ export LD_LIBRARY_PATH="/tmp/glibmm-2.22.1/glib/glibmm/.libs:$LD_LIBRARY_PATH" ssuominen@foo /tmp/glibmm-2.22.1/tests/glibmm_valuearray $ ./.libs/test Array members before sorting: 10 9 8 7 6 5 4 3 2 1 Array members after sorting without last element: 1 2 3 4 5 6 7 8 9 ssuominen@foo /tmp/glibmm-2.22.1/tests/glibmm_valuearray $ ./test /tmp/glibmm-2.22.1/tests/glibmm_valuearray/.libs/test: symbol lookup error: /tmp/glibmm-2.22.1/tests/glibmm_valuearray/.libs/test: undefined symbol: _ZN4Glib10ValueArrayC1Ev
Hm, this is odd. The wrapper script definitely does add the build directory to LD_LIBRARY_PATH, or it would not work if there is no system glibmm library. It follows that either the script additionally incorrectly prefixes /usr/lib64 to the path, or /usr/lib64 gets precedence for some other reason (perhaps an evil -rpath or funky preloading magic). Is LD_LIBRARY_PATH initially set to anything? Could you run the libtool wrapper script with bash -x (trace mode) and capture the output, please? Unfortunately I can't easily reproduce the same combination of libraries on my own system. Maybe I'll set up a virtual machine or a chroot environment when I have time. But hopefully the bash trace will already provides us with some helpful clues. Also, which is the canonical library location on Gentoo AMD64, "/usr/lib" or "/usr/lib64"? Although one is usually symlinked to the other, it could be that the libtool-generated wrapper script becomes confused if the canonical directory is not consistently used.
*** Bug 598123 has been marked as a duplicate of this bug. ***
(In reply to comment #16) > Hm, this is odd. The wrapper script definitely does add the build directory to > LD_LIBRARY_PATH, or it would not work if there is no system glibmm library. It > follows that either the script additionally incorrectly prefixes /usr/lib64 to > the path, or /usr/lib64 gets precedence for some other reason (perhaps an evil > -rpath or funky preloading magic). > > Is LD_LIBRARY_PATH initially set to anything? Could you run the libtool > wrapper script with bash -x (trace mode) and capture the output, please? + Xsed='/bin/sed -e 1s/^X//' + sed_quote_subst='s/\([`"$\\])/\\\1/g' + test -n '' + case `(set -o) 2>/dev/null` in + set -o posix + BIN_SH=xpg4 + export BIN_SH + DUALCASE=1 + export DUALCASE + unset CDPATH + relink_command= + test '' = '%%%MAGIC variable%%%' + test '' '!=' '%%%MAGIC variable%%%' + ECHO=echo + file=./test + test X = X--no-reexec + test 'X\t' = 'X\t' + : ++ echo X./test ++ /bin/sed -e '1s/^X//' -e 's%/[^/]*$%%' + thisdir=. + test x. = x./test ++ ls -ld ./test ++ /bin/sed -n 's/.*-> //p' + file= + test -n '' + WRAPPER_SCRIPT_BELONGS_IN_OBJDIR=no + test no = yes ++ cd . ++ pwd + absdir=/tmp/glibmm-2.22.1/tests/glibmm_valuearray + test -n /tmp/glibmm-2.22.1/tests/glibmm_valuearray + thisdir=/tmp/glibmm-2.22.1/tests/glibmm_valuearray + program=test + progdir=/tmp/glibmm-2.22.1/tests/glibmm_valuearray/.libs + test -f /tmp/glibmm-2.22.1/tests/glibmm_valuearray/.libs/test + LD_LIBRARY_PATH=/usr/lib64:/tmp/glibmm-2.22.1/glib/glibmm/.libs: ++ echo X/usr/lib64:/tmp/glibmm-2.22.1/glib/glibmm/.libs: ++ /bin/sed -e '1s/^X//' -e 's/::*$//' + LD_LIBRARY_PATH=/usr/lib64:/tmp/glibmm-2.22.1/glib/glibmm/.libs + export LD_LIBRARY_PATH + test '' '!=' '%%%MAGIC variable%%%' + exec /tmp/glibmm-2.22.1/tests/glibmm_valuearray/.libs/test /tmp/glibmm-2.22.1/tests/glibmm_valuearray/.libs/test: symbol lookup error: /tmp/glibmm-2.22.1/tests/glibmm_valuearray/.libs/test: undefined symbol: _ZN4Glib10ValueArrayC1Ev > Also, which is the canonical library location on Gentoo AMD64, "/usr/lib" or > "/usr/lib64"? Although one is usually symlinked to the other, it could be that > the libtool-generated wrapper script becomes confused if the canonical > directory is not consistently used. On my system, /usr/lib is a symlink to /usr/lib64.
ssuominen@foo /tmp/glibmm-2.22.1/tests/glibmm_valuearray $ cp test test.orig ssuominen@foo /tmp/glibmm-2.22.1/tests/glibmm_valuearray $ vim test ssuominen@foo /tmp/glibmm-2.22.1/tests/glibmm_valuearray $ diff -u test.orig test --- test.orig 2010-03-01 23:14:26.000000000 +0200 +++ test 2010-03-01 23:20:22.000000000 +0200 @@ -104,7 +104,7 @@ if test -f "$progdir/$program"; then # Add our own library path to LD_LIBRARY_PATH - LD_LIBRARY_PATH="/usr/lib64:/tmp/glibmm-2.22.1/glib/glibmm/.libs:$LD_LIBRARY_PATH" + LD_LIBRARY_PATH="/tmp/glibmm-2.22.1/glib/glibmm/.libs:$LD_LIBRARY_PATH" # Some systems cannot cope with colon-terminated LD_LIBRARY_PATH # The second colon is a workaround for a bug in BeOS R4 sed ssuominen@foo /tmp/glibmm-2.22.1/tests/glibmm_valuearray $ ./test Array members before sorting: 10 9 8 7 6 5 4 3 2 1 Array members after sorting without last element: 1 2 3 4 5 6 7 8 9
(In reply to comment #18) > (In reply to comment #16) Thanks for the trace. So apparently /usr/lib64 is prefixed to the path for some reason. > > Is LD_LIBRARY_PATH initially set to anything? I'd really like to know. :)
(In reply to comment #20) > (In reply to comment #18) > > (In reply to comment #16) > > Thanks for the trace. So apparently /usr/lib64 is prefixed to the path for some > reason. > > > > Is LD_LIBRARY_PATH initially set to anything? > > I'd really like to know. :) No ssuominen@foo /tmp/glibmm-2.22.1 $ echo $LD_LIBRARY_PATH ssuominen@foo /tmp/glibmm-2.22.1 $
Could you attach the generated wrapper script, please?
Created attachment 154989 [details] tests/glibmm_valuearray/test
OK, please attach the libtool script found in the top-level build directory, as well as the glib/glibmm/libglibmm-2.4.la file. Thanks.
Created attachment 155026 [details] glibmm-2.22.1/libtool
Created attachment 155027 [details] glibmm-2.22.1/glib/glibmm/libglibmm-2.4.la
Seeing the attachment in comment 23, my private guess is everything in libtool works just like it should. Surprising, ain't it ? This had be once on libtool mailing list, only a while later I've had it figured out. The result was bug 609277 - same solution will probably apply here - in tests/Makefile.am the order of LDADD and giomm_ldadd will need to be changed, so that the in-source-tree libs come before in-system ones.
Created attachment 155712 [details] [review] patch to reorder LDADD and giomm_ldadd flags This patch fixes the LDADD ordering for me, and allows me to run the valuearray test fine.
Created attachment 155713 [details] test wrapper script from patched glibmm build Note the reordered LD_LIBRARY_PATH in the attached test libtool wrapper.
Thanks, David, feel free to commit.
I pushed a modified patch in commit da417903cdee2a7581757778baacdd52602e6f8e. Pacho and Samuli, can you confirm that this fixes the problem?
Seems to fix the bug to me Thanks a lot! :-D
Will this be fixed also in 2.22 branch or only master?
(In reply to comment #33) > Will this be fixed also in 2.22 branch or only master? Also applied to glibmm-2-22 branch in git.
Thanks a lot, I think that this is fixed then ;-) Best regards