1 and 2: Sadly the build system is a bit stupid when you change configuration behind its back. You need to recompile with -a.
For points 3 and 4: - Try installing Boost 1.50.0 in /usr and /usr/lib64. - Check that the symlinks are in /usr/lib64 and point to your installation. - Make sure the headers match; you may want to rm -rf /usr/include/boost first. - You meant link=static,shared with an equals sign, not with a dash. - Don't forget zlib. You're on your own when it comes to autotools. Kenneth On 08/06/2012 06:47 PM, Sumita Sami wrote: > Thanks Kenneth and Tom, for the updates and confirmation. > > I think I've missed something in these threads. I pulled from Git and > did the following: > > 1. ./bjam --without-libsegfault > > 2. ldd `which moses` to determine which libs are dynamically linked > > Output: > > ldd `which moses`____ > > linux-vdso.so.1 => (0x00007fff57f97000)____ > > libz.so.1 => /lib64/libz.so.1 (0x000000356f400000)____ > > libboost_system-mt.so.5 => /usr/lib64/libboost_system-mt.so.5 > (0x0000003581800000)____ > > libboost_thread-mt.so.5 => /usr/lib64/libboost_thread-mt.so.5 > (0x00007fbae6510000)____ > > libSegFault.so => /lib64/libSegFault.so (0x00007fbae630b000)____ > > librt.so.1 => /lib64/librt.so.1 (0x000000356f800000)____ > > libstdc++.so.6 => /usr/lib64/libstdc++.so.6 > (0x000000357a800000)____ > > libm.so.6 => /lib64/libm.so.6 (0x000000356e800000)____ > > libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003578800000)____ > > libpthread.so.0 => /lib64/libpthread.so.0 (0x000000356f000000)____ > > libc.so.6 => /lib64/libc.so.6 (0x000000356e400000)____ > > /lib64/ld-linux-x86-64.so.2 (0x000000356e000000) > > > libSegFault shows up here still. > > > 3. ./bjam --static > > 4. I still get errors "Could not statically link against lib > boost_program_options." and "... for lib z". To confirm, running ./bjam > --debug-configuration gives me exit status 1 for: > > a) -lboost_program_options > b) -lSegFault > c) -lz > > I tried re-building boost (1.5.0) statically: > > sudo ./b2 --prefix=/usr/local --libdir=/usr/local/lib64 --layout=tagged > link-static,shared threading=multi install > > But it seems to still be building dynamically. > > And why would libSegFault still show up after I've used the > --without-libsegfault option? I am probably missing something really > basic, so any help would be appreciated. > > Thanks, > > Sumita Sami > > > On Mon, Aug 6, 2012 at 12:10 PM, Tom Hoar > <tah...@precisiontranslationtools.com > <mailto:tah...@precisiontranslationtools.com>> wrote: > > Just confirmed the update: > > > bjam --without-libsegfault > tahoar@library1:~$ ldd `which moses` > linux-vdso.so.1 => (0x00007fff0d7ff000) > librt.so.1 => /lib/librt.so.1 (0x00007f43de730000) > libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f43de41c000) > libm.so.6 => /lib/libm.so.6 (0x00007f43de198000) > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f43ddf81000) > libpthread.so.0 => /lib/libpthread.so.0 (0x00007f43ddd64000) > libc.so.6 => /lib/libc.so.6 (0x00007f43dd9e0000) > /lib64/ld-linux-x86-64.so.2 (0x00007f43de95c000) > > bjam --static > tahoar@library1:~$ ldd `which moses` > not a dynamic executable > > Thanks > > > On Mon, 06 Aug 2012 12:39:42 -0400, Kenneth Heafield > <mo...@kheafield.com <mailto:mo...@kheafield.com>> wrote: > > Ok, committed. Here's how the build system now behaves: > > > > link=shared: Everything linked dynamically. > > > > Default: internal libraries are statically linked. Boost and zlib > > statically linked if possible. libSegFault dynamically linked. > > Dynamically linked executable. > > > > --without-libsegfault: Same as default but no libSegFault. Still a > > dynamically linked executable, even if you have static boost and > > zlib. > > It's complicated to do detect then be automatic. > > > > --static: No libSegFault. Print warning messages if you're missing > > static libraries, but keep building anyway. Static executable. > > > > Kenneth > > > > On 08/06/2012 12:00 PM, Kenneth Heafield wrote: > >> D'oh, it's a feature, not a bug. Add runtime-link=static and you'll > >> get > >> a fully-static executable. > >> > >> Plan to add this to the Moses build system. Testing now. > >> > >> Kenneth > >> > >> On 08/06/2012 11:31 AM, Tom Hoar wrote: > >>> FYI, this build is on U-10.04.4 using the bjam shipped with Moses. > >>> I can > >>> send you the complete log if it helps. Let me know if you need > >>> anything > >>> else. > >>> > >>> Tom > >>> > >>> > >>> On Mon, 06 Aug 2012 11:27:27 -0400, Kenneth Heafield > >>> <mo...@kheafield.com <mailto:mo...@kheafield.com>> wrote: > >>>> Hi, > >>>> > >>>> There appears to be a bug in boost-build that prevents it from > >>>> making > >>>> fully-static binaries with g++. This might take a while to sort > >>>> out. > >>>> > >>>> Kenneth > >>>> > >>>> On 08/06/2012 10:48 AM, Tom Hoar wrote: > >>>>> Thanks, Ken. I think this is easier than adding another option to > >>>>> Moses > >>>>> if we can understand the output. The ldd manpage says "ldd prints > >>>>> the > >>>>> shared libraries required by each program or shared library > >>>>> specified on > >>>>> the command line." I assume "shared libraries" means not > >>>>> statically > >>>>> linked? > >>>>> > >>>>> Here's the output on the moses I just built with today's github > >>>>> updates. > >>>>> The log output reported exit code 0 for all lines with "g++ > >>>>> -static". > >>>>> > >>>>> tahoar@library1:~$ ldd `which moses` > >>>>> linux-vdso.so.1 => (0x00007fffa2954000) > >>>>> librt.so.1 => /lib/librt.so.1 (0x00007f818aa7b000) > >>>>> libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f818a767000) > >>>>> libm.so.6 => /lib/libm.so.6 (0x00007f818a4e3000) > >>>>> libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f818a2cc000) > >>>>> libpthread.so.0 => /lib/libpthread.so.0 (0x00007f818a0af000) > >>>>> libc.so.6 => /lib/libc.so.6 (0x00007f8189d2b000) > >>>>> /lib64/ld-linux-x86-64.so.2 (0x00007f818aca7000) > >>>>> > >>>>> Is this what I should expect if all of the libboost libraries are > >>>>> statically linked? I think so because there are no references to > >>>>> the > >>>>> lboost_* or lz libraries in the log file. > >>>>> > >>>>> Tom > >>>>> > >>>>> > >>>>> On Mon, 06 Aug 2012 10:14:35 -0400, Kenneth Heafield > >>>>> <mo...@kheafield.com <mailto:mo...@kheafield.com>> wrote: > >>>>>> On linux, > >>>>>> > >>>>>> ldd bin/moses > >>>>>> > >>>>>> On 08/06/2012 10:03 AM, Tom Hoar wrote: > >>>>>>> Thanks Ken. I downloaded/compiled with the latest changes up to > >>>>>>> BOOST_CHECK_CLOSE. The exit code 1 disappeared and everything > >>>>>>> seems > >>>>>>> okay. > >>>>>>> > >>>>>>> One more question. Other than the log output at compile time, > >>>>>>> is there > >>>>>>> any way to query the Moses binary to see which libraries are > >>>>>>> statically > >>>>>>> vs dynamically linked? > >>>>>>> > >>>>>>> For example, a while back, someone on the list gave this > >>>>>>> command to > >>>>>>> test > >>>>>>> if the binary was compiled --with-srilm, and there are others > >>>>>>> for > >>>>>>> IRSTLM, RANDLM and KENLM. > >>>>>>> > >>>>>>> nm -C "/path/to/moses" | grep "vtable for > >>>>>>> Moses::LanguageModelSRI"` > >>>>>>> > >>>>>>> I tried the obvious two grep searches "static" and "dynamic" > >>>>>>> (below), > >>>>>>> but they don't seem to relate to the libraries. Does anyone > >>>>>>> know a way > >>>>>>> to find/test if libraries are dynamically or statically linked? > >>>>>>> > >>>>>>> Thanks, > >>>>>>> Tom > >>>>>>> > >>>>>>> > >>>>>>> tahoar@library1:~/domy-2.5$ nm -C `which moses` | grep "static" > >>>>>>> 00000000005ddbc0 t > >>>>>>> __static_initialization_and_destruction_0(int, int) > >>>>>>> 00000000005de7c1 t > >>>>>>> __static_initialization_and_destruction_0(int, int) > >>>>>>> 00000000005ded37 t > >>>>>>> __static_initialization_and_destruction_0(int, int) > >>>>>>> 00000000005e0067 t > >>>>>>> __static_initialization_and_destruction_0(int, int) > >>>>>>> 00000000005e2fc6 t > >>>>>>> __static_initialization_and_destruction_0(int, int) > >>>>>>> 00000000005ecae3 t > >>>>>>> __static_initialization_and_destruction_0(int, int) > >>>>>>> 00000000005ef140 t > >>>>>>> __static_initialization_and_destruction_0(int, int) > >>>>>>> 00000000005f475f t > >>>>>>> __static_initialization_and_destruction_0(int, int) > >>>>>>> 00000000005f4cd9 t > >>>>>>> __static_initialization_and_destruction_0(int, int) > >>>>>>> 00000000005f5e53 t > >>>>>>> __static_initialization_and_destruction_0(int, int) > >>>>>>> 00000000005f6f8e t > >>>>>>> __static_initialization_and_destruction_0(int, int) > >>>>>>> 00000000005f7183 t > >>>>>>> __static_initialization_and_destruction_0(int, int) > >>>>>>> 0000000000883cc0 d static_bl_desc > >>>>>>> 0000000000883ca0 d static_d_desc > >>>>>>> 0000000000610680 r static_dtree > >>>>>>> 0000000000883c80 d static_l_desc > >>>>>>> 0000000000610200 r static_ltree > >>>>>>> > >>>>>>> tahoar@library1:~/domy-2.5$ nm -C `which moses` | grep > >>>>>>> "dynamic" > >>>>>>> 0000000000570c50 W > >>>>>>> boost::unordered_detail::hash_table_unique_keys<std::pair<float > >>>>>>> const, > >>>>>>> boost::dynamic_bitset<unsigned long, std::allocator<unsigned > >>>>>>> long> > >>>>>>>>> , > >>>>>>> float, boost::hash<float>, std::equal_to<float>, > >>>>>>> std::allocator<std::pair<float const, > >>>>>>> boost::dynamic_bitset<unsigned > >>>>>>> long, std::allocator<unsigned long> > > > > >>>>>>> >::operator[](float const&) > >>>>>>> 000000000057baf0 W > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > > boost::unordered_detail::hash_table_data_unique_keys<std::allocator<std::pair<std::pair<unsigned > >>>>>>> > >>>>>>> > >>>>>>> char, unsigned char> const, boost::dynamic_bitset<unsigned > >>>>>>> long, > >>>>>>> std::allocator<unsigned long> > > > > >>>>>>> >::~hash_table_data_unique_keys() > >>>>>>> 0000000000570af0 W > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > > boost::unordered_detail::hash_table_data_unique_keys<std::allocator<std::pair<float > >>>>>>> > >>>>>>> > >>>>>>> const, boost::dynamic_bitset<unsigned long, > >>>>>>> std::allocator<unsigned > >>>>>>> long> > > > >::create_buckets() > >>>>>>> 0000000000570c00 W > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > > boost::unordered_detail::hash_table_data_unique_keys<std::allocator<std::pair<float > >>>>>>> > >>>>>>> > >>>>>>> const, boost::dynamic_bitset<unsigned long, > >>>>>>> std::allocator<unsigned > >>>>>>> long> > > > >::node_constructor::~node_constructor() > >>>>>>> 0000000000570b70 W > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > > boost::unordered_detail::hash_table_data_unique_keys<std::allocator<std::pair<float > >>>>>>> > >>>>>>> > >>>>>>> const, boost::dynamic_bitset<unsigned long, > >>>>>>> std::allocator<unsigned > >>>>>>> long> > > > >::~hash_table_data_unique_keys() > >>>>>>> 000000000057ba60 W > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > > boost::unordered_detail::hash_table_data_unique_keys<std::allocator<std::pair<unsigned > >>>>>>> > >>>>>>> > >>>>>>> int const, boost::dynamic_bitset<unsigned long, > >>>>>>> std::allocator<unsigned > >>>>>>> long> > > > >::~hash_table_data_unique_keys() > >>>>>>> U __dynamic_cast@@CXXABI_1.3 > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On Mon, 06 Aug 2012 08:20:00 -0400, Kenneth Heafield > >>>>>>> <mo...@kheafield.com <mailto:mo...@kheafield.com>> wrote: > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>> You're correct. There doesn't seem to be a static version of > >>>>>>>> this > >>>>>>>> library. I've added the --nosegfault option (which isn't as > >>>>>>>> cool as > >>>>>>>> it sounds) to skip this library. > >>>>>>>> > >>>>>>>> Kenneth > >>>>>>>> > >>>>>>>> On 08/06/2012 02:08 AM, Tom Hoar wrote: > >>>>>>>>> I read the comment "In order to obtain a fully static Moses, > >>>>>>>>> every g++ > >>>>>>>>> command line that includes "-static" must pass with exit code > >>>>>>>>> 0." > >>>>>>>>> with > >>>>>>>>> interest. > >>>>>>>>> > >>>>>>>>> When we compile moses, this log output line shows an exit > >>>>>>>>> code 1. > >>>>>>>>> All > >>>>>>>>> the others are 0. > >>>>>>>>> > >>>>>>>>> bash -c "g++ -static -lSegFault -x c++ -<<<'int main() {}' -o > >>>>>>>>> /dev/null > >>>>>>>>>> /dev/null 2>/dev/null" > >>>>>>>>> 1 > >>>>>>>>> > >>>>>>>>> Any suggestions as to what's missing/how to correct so we > >>>>>>>>> have a > >>>>>>>>> fully-static Moses? > >>>>>>>>> > >>>>>>>>> Thanks, > >>>>>>>>> Tom > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On Fri, 03 Aug 2012 18:13:47 -0400, Kenneth Heafield > >>>>>>>>> <mo...@kheafield.com <mailto:mo...@kheafield.com>> wrote: > >>>>>>>>>> Hi, > >>>>>>>>>> > >>>>>>>>>> Moses attempts to link statically by default but falls back > >>>>>>>>>> to > >>>>>>>>>> dynamic > >>>>>>>>>> links. You must have static versions of all the dependencies > >>>>>>>>>> installed > >>>>>>>>>> as well. Run > >>>>>>>>>> > >>>>>>>>>> bjam --debug-configuration > >>>>>>>>>> > >>>>>>>>>> and, near the top, it will show you some command lines > >>>>>>>>>> followed by > >>>>>>>>>> their > >>>>>>>>>> exit code. In order to obtain a fully static Moses, every > >>>>>>>>>> g++ > >>>>>>>>>> command > >>>>>>>>>> line that includes "-static" must pass with exit code 0. > >>>>>>>>>> > >>>>>>>>>> Kenneth > >>>>>>> > >>>>> > >>> > >> _______________________________________________ > >> Moses-support mailing list > >> Moses-support@mit.edu <mailto:Moses-support@mit.edu> > >> http://mailman.mit.edu/mailman/listinfo/moses-support > > _______________________________________________ > > Moses-support mailing list > > Moses-support@mit.edu <mailto:Moses-support@mit.edu> > > http://mailman.mit.edu/mailman/listinfo/moses-support > > _______________________________________________ > Moses-support mailing list > Moses-support@mit.edu <mailto:Moses-support@mit.edu> > http://mailman.mit.edu/mailman/listinfo/moses-support > > _______________________________________________ Moses-support mailing list Moses-support@mit.edu http://mailman.mit.edu/mailman/listinfo/moses-support
