(Moving this discussion to Rosegarden-devel, keeping you on CC, just in
case...)
On Tuesday 11 October 2005 01:03, Eric Laffoon wrote:
> I have this. I'm going to check my Gentoo docs because I seem to have two
> glibc libraries and I'm not sure if that is for compatibility or I screwed
> up and didn't remove an old one when upgrading.
You can have several *runtime* libraries installed at the same time, coming
from different releases. This souldn't be a problem while you have only one
development library with the matching headers installed.
> following are the gdb outpout and the stacktrace.
>
> gdb startup from core:
> [EMAIL PROTECTED] ~ $ gdb rosegarden core
> GNU gdb 6.0
[...]
> Reading symbols
> from /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.3/libstdc++.so.5...done.
> Loaded symbols for
> /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.3/libstdc++.so.5 Reading symbols
> from /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/libstdc++.so.6... done.
> Loaded symbols for /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/libstdc++.so.6
Here you have an example. This is the runtime library for C++ programs. You
have two versions of libstdc++, 3.3.3 and 3.4.4, some programs need the old
one, but most can use the newer. This is possible because the linker includes
the major library version number along with the name (the "soname") at build
time, then the dynamic loader can locate the right library for each object
at runtime.
[...]
> stacktrace:
> (gdb) where
> #0 0x00002aaaadd93786 in std::__default_alloc_template<true,
> 0>::allocate(unsigned long) ()
> from /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.3/libstdc++.so.5
> #1 0x00002aaaadd98567 in std::string::_Rep::_S_create(unsigned long,
> std::allocator<char> const&) ()
> from /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.3/libstdc++.so.5
> #2 0x00002aaaadd992f9 in std::string& std::string::_M_replace_safe<char
> const*>(__gnu_cxx::__normal_iterator<char*, std::string>,
> __gnu_cxx::__normal_iterator<char*, std::string>, char const*, char const*)
> ()
> from /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.3/libstdc++.so.5
> #3 0x00002aaaadd960d3 in std::string::string(char const*,
> std::allocator<char> const&) ()
> from /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.3/libstdc++.so.5
> #4 0x0000000000725a6e in qstrtostr(QString const&) ([EMAIL PROTECTED])
> at rosestrings.cpp:36
[...]
This is strange, and somewhat wrong. Your Rosegarden executable is linked
against libstdc+++.so.5 instead of the newer library. This means that you
have something wrong with the development environment. If you use this
commnand:
$ locate libstdc++.so
You will see that it is a symlink to the real library binary, wich has a name
like libstdc++.so.5.0.0; this symlink is used by the ld linker only (it is
not needed at runtime).
There is a good explanation about the dynamic linking, sonames and ld
behavior, here:
http://wiki.linuxquestions.org/wiki/Library-related_Commands_and_Files
I don't know which is the way in Gentoo, but you should have the matching
headers and the symlink pointing to the new libstdc++ library.
The segmentation fault is due to a call in qstrtostr() (rosestrings.cpp:36)
trying to convert an empty QString to a std::string. The STL allocator for
the string receives 0 as length argument, and segfaults. I don't know why.
This works here. It may be a problem with the old libstdc++ version, or a 64
bit problem. We could include a workaround but, I'm not sure if it is worth.
I would prefer to wait until your development environment is fixed.
Regards,
Pedro
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Rosegarden-devel mailing list
[email protected] - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
