Re: [Monotone-devel] Compiling from source

[Emile Snyder]

I believe I had exactly this problem on a newer redhat system at work.
I don't pretend to understand exactly what's going on, but for me it
appeared that /lib/tls/libc.so.6 didn't like exceptions at all (a
trivial small test program that tried throwing and catching an exception
died in the same way.)

I managed to work around it by doing:

LD_PRELOAD=/lib/libc.so.6 monotone

(It looks like, from your ld output, that there's more /lib/tls
libraries linked against your build than I had, I don't know if you
would need to do this for all of them or what.)

Hope it helps, or that someone who understands this better can pipe up,
-emile

On Thu, 2005-10-13 at 13:53 +0200, Zbynek Winkler wrote:
> Hello,
> 
> I've managed to compile latest monotone (took about 45min) with 
> gcc-4.0.2 (BTW: thanks the great INSTALL instructions!). Something 
> changed since the last time I tried. Either gcc has improved in memory 
> consumption or the sources changed in away that it takes less memory to 
> compile (the last time I couldn't compile database.cc because 256MB of 
> RAM was not enough). So hooray!
> 
> And now the problem :(. Any command I try fails...
> 
> $ ./monotone help    
> terminate called after throwing an instance of 'std::length_error'
>   what():  basic_string::_S_create
> Aborted
> 
> The gdb says:
> 
> (gdb) run
> Starting program: /home/zbynek/devel/net.venge.monotone/_default/monotone
> [Thread debugging using libthread_db enabled]
> [New Thread -1212581376 (LWP 13938)]
> 
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread -1212581376 (LWP 13938)]
> 0xb7cdc5ef in memcpy () from /lib/tls/libc.so.6
> (gdb) bt
> #0  0xb7cdc5ef in memcpy () from /lib/tls/libc.so.6
> #1  0xb7e5d8ee in std::basic_streambuf<char, std::char_traits<char> 
>  >::xsputn ()
>    from /usr/lib/libstdc++.so.6
> #2  0xb7e52c5a in std::operator<< <char, std::char_traits<char>, 
> std::allocator<char> > ()
>    from /usr/lib/libstdc++.so.6
> #3  0x08061d4a in boost::io::detail::put<char, std::char_traits<char>, 
> std::allocator<char>, std::string const&> (address@hidden, 
> address@hidden, address@hidden, address@hidden, loc_p=0xbfb88494) at 
> feed_args.hpp:93
> #4  0x080625ae in boost::io::detail::distribute<char, 
> std::char_traits<char>, std::allocator<char>, std::string const&> 
> (address@hidden, address@hidden) at feed_args.hpp:233
> #5  0x08062673 in boost::io::detail::feed<char, std::char_traits<char>, 
> std::allocator<char>, std::string const&> (address@hidden, 
> address@hidden) at feed_args.hpp:243
> #6  0x082811b4 in cpp_main (argc=1, argv=0xbfb88d94) at format_class.hpp:64
> #7  0x082837f0 in main_with_signal_handlers (argc=1, argv=0xbfb88d94) at 
> ../main.cc:294
> #8  0x082838db in main (argc=1, argv=0xbfb88d94) at ../main.cc:349
> 
> Do I have some library mismatch? ldd monotone says:
> 
> $ ldd monotone
>         linux-gate.so.1 =>  (0xffffe000)
>         libz.so.1 => /usr/lib/libz.so.1 (0xb7f0e000)
>         libdl.so.2 => /lib/tls/libdl.so.2 (0xb7f0a000)
>         libboost_regex-gcc-mt-1_32.so.1.32.0 => 
> /usr/lib/libboost_regex-gcc-mt-1_32.so.1.32.0 (0xb7e90000)
>         libboost_date_time-gcc-mt-1_32.so.1.32.0 => 
> /usr/lib/libboost_date_time-gcc-mt-1_32.so.1.32.0 (0xb7e7d000)
>         libboost_filesystem-gcc-mt-1_32.so.1.32.0 => 
> /usr/lib/libboost_filesystem-gcc-mt-1_32.so.1.32.0 (0xb7e6b000)
>         libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7d90000)
>         libm.so.6 => /lib/tls/libm.so.6 (0xb7d6a000)
>         libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7d5f000)
>         libc.so.6 => /lib/tls/libc.so.6 (0xb7c27000)
>         libpthread.so.0 => /lib/tls/libpthread.so.0 (0xb7c15000)
>         /lib/ld-linux.so.2 (0xb7f2f000)
>         librt.so.1 => /lib/tls/librt.so.1 (0xb7c0d000)
>         libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0xb7b52000)
> 
> I am running debian testing with boost-1.32. I also used aclocal-1.8 
> instead of 1.7 but except couple of warnings about some quoting issues 
> everything went fine...
> 
> Any help appreciated. Thanks.
> 
> Zbynek
>