After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 610854 - glibmm_valuearray fails to run on some systems
glibmm_valuearray fails to run on some systems
Status: RESOLVED FIXED
Product: glibmm
Classification: Bindings
Component: tests
2.22.x
Other Linux
: Normal normal
: ---
Assigned To: David King
gtkmm-forge
: 598123 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2010-02-23 17:17 UTC by Pacho Ramos
Modified: 2010-03-23 09:39 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
build.log (108.10 KB, text/plain)
2010-02-27 20:24 UTC, Samuli Suominen
  Details
tests/glibmm_valuearray/test (4.09 KB, text/plain)
2010-03-01 23:30 UTC, Samuli Suominen
  Details
glibmm-2.22.1/libtool (258.16 KB, text/plain)
2010-03-02 12:09 UTC, Samuli Suominen
  Details
glibmm-2.22.1/glib/glibmm/libglibmm-2.4.la (1.24 KB, text/plain)
2010-03-02 12:11 UTC, Samuli Suominen
  Details
patch to reorder LDADD and giomm_ldadd flags (1.28 KB, patch)
2010-03-10 09:41 UTC, David King
committed Details | Review
test wrapper script from patched glibmm build (4.11 KB, application/octet-stream)
2010-03-10 09:44 UTC, David King
  Details

Description Pacho Ramos 2010-02-23 17:17:35 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
Comment 1 Murray Cumming 2010-02-26 23:07:41 UTC
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.
Comment 2 Pacho Ramos 2010-02-26 23:30:39 UTC
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
Comment 3 Murray Cumming 2010-02-26 23:37:53 UTC
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.
Comment 4 Daniel Elstner 2010-02-27 03:11:03 UTC
(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.
Comment 5 Pacho Ramos 2010-02-27 09:44:56 UTC
What exact flags do you think shouldn't be used? Thanks
Comment 6 Daniel Elstner 2010-02-27 11:20:08 UTC
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.
Comment 7 Pacho Ramos 2010-02-27 11:52:02 UTC
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 :-/)
Comment 8 Pacho Ramos 2010-02-27 15:38:20 UTC
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
Comment 9 Samuli Suominen 2010-02-27 15:45:56 UTC
(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. ;-)
Comment 10 Daniel Elstner 2010-02-27 20:12:30 UTC
(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.
Comment 11 Samuli Suominen 2010-02-27 20:24:42 UTC
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.
Comment 12 Samuli Suominen 2010-02-27 20:33:17 UTC
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.
Comment 13 Daniel Elstner 2010-02-27 22:07:24 UTC
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.
Comment 14 Samuli Suominen 2010-02-28 22:14:33 UTC
(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)

[ .. ]
Comment 15 Samuli Suominen 2010-02-28 22:20:28 UTC
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
Comment 16 Daniel Elstner 2010-02-28 22:59:17 UTC
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.
Comment 17 Gilles Dartiguelongue 2010-03-01 20:53:07 UTC
*** Bug 598123 has been marked as a duplicate of this bug. ***
Comment 18 Samuli Suominen 2010-03-01 21:11:08 UTC
(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.
Comment 19 Samuli Suominen 2010-03-01 21:12:46 UTC
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
Comment 20 Daniel Elstner 2010-03-01 21:42:04 UTC
(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. :)
Comment 21 Samuli Suominen 2010-03-01 21:53:54 UTC
(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 $
Comment 22 Daniel Elstner 2010-03-01 23:24:10 UTC
Could you attach the generated wrapper script, please?
Comment 23 Samuli Suominen 2010-03-01 23:30:26 UTC
Created attachment 154989 [details]
tests/glibmm_valuearray/test
Comment 24 Daniel Elstner 2010-03-02 12:02:24 UTC
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.
Comment 25 Samuli Suominen 2010-03-02 12:09:54 UTC
Created attachment 155026 [details]
glibmm-2.22.1/libtool
Comment 26 Samuli Suominen 2010-03-02 12:11:32 UTC
Created attachment 155027 [details]
glibmm-2.22.1/glib/glibmm/libglibmm-2.4.la
Comment 27 Rafał Mużyło 2010-03-10 09:13:12 UTC
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.
Comment 28 David King 2010-03-10 09:41:44 UTC
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.
Comment 29 David King 2010-03-10 09:44:03 UTC
Created attachment 155713 [details]
test wrapper script from patched glibmm build

Note the reordered LD_LIBRARY_PATH in the attached test libtool wrapper.
Comment 30 Murray Cumming 2010-03-10 09:46:47 UTC
Thanks, David, feel free to commit.
Comment 31 David King 2010-03-10 10:01:04 UTC
I pushed a modified patch in commit da417903cdee2a7581757778baacdd52602e6f8e.

Pacho and Samuli, can you confirm that this fixes the problem?
Comment 32 Pacho Ramos 2010-03-11 15:08:02 UTC
Seems to fix the bug to me 

Thanks a lot! :-D
Comment 33 Pacho Ramos 2010-03-11 15:41:24 UTC
Will this be fixed also in 2.22 branch or only master?
Comment 34 David King 2010-03-11 16:00:42 UTC
(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.
Comment 35 Pacho Ramos 2010-03-11 16:21:18 UTC
Thanks a lot, I think that this is fixed then ;-)

Best regards