I did threading=single because multi used to demand the "-mt" variant of the 
boost libraries, which I've never quite understood. But I just tried again with 
"threading=multi" and everything works, with that commit below. Thanks again.

matt


> On Feb 16, 2015, at 1:56 PM, Kenneth Heafield <[email protected]> wrote:
> 
> Hi,
> 
>       Adding Fabienne because this was the same problem.
> 
>       I've pushed commit 93ab057eda69a7915efbc9fa92d4ce6341e6ca02 which will
> hopefully handle BOOST_TEST_DYN_LINK correctly.
> 
>       Still unclear what the behavior should be for threading=single.
> Compile it anyway, forcing two compiles of kenlm?  Warning message that
> will probably be ignored?
> 
> Kenneth
> 
> On 02/16/2015 01:41 PM, Kenneth Heafield wrote:
>> Actually, that's by design.  Your command line has threading=single and
>> lmplz doesn't have a single-threaded option.
>> 
>> Kenneth
>> 
>> On 02/16/2015 01:29 PM, Matt Post wrote:
>>> Okay, that worked. The whole project now builds, EXCEPT there is no 
>>> bin/lmplz. fragment, build_binary, and query all exist, but not lmplz. It 
>>> is not mentioned in the logs...
>>> 
>>> But that's okay, because I'll just copy it from KenLM directly.
>>> 
>>> Thanks for your help.
>>> 
>>> matt
>>> 
>>> 
>>>> On Feb 16, 2015, at 1:01 PM, Kenneth Heafield <[email protected]> wrote:
>>>> 
>>>> Tests to be dynamically linked must be _compiled_ using
>>>> -DBOOST_TEST_DYN_LINK .  The build system did this prior to Hieu's change.
>>>> 
>>>> After reverting Hieu's change, force it to recompile the object file:
>>>> 
>>>> rm util/bin/gcc-4.9.2/release/file_piece_test.o
>>>> 
>>>> (or just run with -a and rebuild everything).
>>>> 
>>>> Kenneth
>>>> 
>>>> On 02/16/2015 12:53 PM, Matt Post wrote:
>>>>> Hmm; I got a bit further, but still have linking errors for the tests.
>>>>> build_binary built, but still no lmplz, and it's not mentioned at all in
>>>>> the log output.
>>>>> 
>>>>> I was able to get lmplz to build by modifying Jamroot to build only the
>>>>> "lm" project, but still get all these linking errors when I try a full
>>>>> build.
>>>>> 
>>>>> Maybe this is my environment? Or a Boost change? What version do you all
>>>>> build against?
>>>>> 
>>>>> gcc.link util/bin/file_piece_test.test/gcc-4.9.2/release/file_piece_test
>>>>> 
>>>>>   "g++"-L"/opt/boost/lib"-L"/opt/boost/lib64"-Wl,-R
>>>>> -Wl,"/opt/boost/lib"-Wl,-R -Wl,"/opt/boost/lib64"-Wl,-rpath-link
>>>>> -Wl,"/opt/boost/lib"-Wl,-rpath-link -Wl,"/opt/boost/lib64"-o
>>>>> "util/bin/file_piece_test.test/gcc-4.9.2/release/file_piece_test"-Wl,--start-group
>>>>> "util/bin/gcc-4.9.2/release/file_piece_test.o""util/bin/gcc-4.9.2/release/parallel_read.o""util/bin/gcc-4.9.2/release/read_compressed.o""util/double-conversion/bin/gcc-4.9.2/release/cached-powers.o""util/double-conversion/bin/gcc-4.9.2/release/double-conversion.o""util/double-conversion/bin/gcc-4.9.2/release/diy-fp.o""util/double-conversion/bin/gcc-4.9.2/release/fast-dtoa.o""util/double-conversion/bin/gcc-4.9.2/release/bignum.o""util/double-conversion/bin/gcc-4.9.2/release/bignum-dtoa.o""util/double-conversion/bin/gcc-4.9.2/release/strtod.o""util/double-conversion/bin/gcc-4.9.2/release/fixed-dtoa.o""util/bin/gcc-4.9.2/release/bit_packing.o""util/bin/gcc-4.9.2/release/ersatz_progress.o""util/bin/gcc-4.9.2/release/exception.o""util/bin/gcc-4.9.2/release/file.o""util/bin/gcc-4.9.2/release/file_piece.o""util/bin/gcc-4.9.2/release/mmap.o""util/bin/gcc-4.9.2/release/murmur_hash.o""util/bin/gcc-4.9.2/release/pool.o""util/bin/gcc-4.9.2/release/scoped.o""util/bin/gcc-4.9.2/rele!
 a!
> s!
>> e/!
>>>> string_pi
>>>> e
>>>> ce.o""util/bin/gcc-4.9.2/release/usage.o" 
>>>>> -Wl,-Bstatic  -Wl,-Bdynamic -lboost_unit_test_framework -llzma -lbz2 -lz
>>>>> -lrt -ldl -lboost_system -lboost_filesystem -Wl,--end-group
>>>>> 
>>>>> 
>>>>> /usr/lib/../lib64/crt1.o: In function `_start':
>>>>> (.text+0x20): undefined reference to `main'
>>>>> collect2: error: ld returned 1 exit status
>>>>> 
>>>>>> From: Kenneth Heafield <moses@...
>>>>>> <http://gmane.org/get-address.php?address=moses%2dbghys1TANAP2eFz%2f2MeuCQ%40public.gmane.org>>
>>>>>> Subject: Re: compilation problems
>>>>>> <http://news.gmane.org/find-root.php?message_id=54E21FBC.70001%40kheafield.com>
>>>>>> Newsgroups: gmane.comp.nlp.moses.user
>>>>>> <http://news.gmane.org/gmane.comp.nlp.moses.user>
>>>>>> Date: 2015-02-16 16:50:04 GMT (49 minutes ago)
>>>>>> Hi Matt,
>>>>>> 
>>>>>>  lmplz should be compiling anyway, despite the tests failing.  Try
>>>>>> reverting this commit, which broke shared compilation for tests:
>>>>>> 
>>>>>> commit d7f5bb41faaac5ca93b9cbb723ad558b2c67d3c2
>>>>>> Author: Hieu Hoang <hieuhoang@... 
>>>>>> <http://gmane.org/get-address.php?address=hieuhoang%2dRe5JQEeQqe8AvxtiuMwx3w%40public.gmane.org>>
>>>>>> Date:   Tue Jan 27 16:22:15 2015 +0000
>>>>>> 
>>>>>> Regarding boost_filesystem we'll probably have to add that dependency
>>>>>> since Boost doesn't really document which of their libraries depend on
>>>>>> other libraries.
>>>>>> 
>>>>>> Kenneth
>>>>>> 
>>>>>>> On Feb 16, 2015, at 11:42 AM, Matt Post <[email protected]
>>>>>>> <mailto:[email protected]>> wrote:
>>>>>>> 
>>>>>>> Hi,
>>>>>>> 
>>>>>>> I am running into a number of problems compiling Moses 3.0. I am
>>>>>>> using GCC 4.9.2 and a custom (correct) install of Boost 1.57.0.
>>>>>>> 
>>>>>>> 1. First, I had to add this:
>>>>>>> 
>>>>>>> <library>boost_filesystem
>>>>>>> 
>>>>>>> to line 174 of Jamroot (per this
>>>>>>> discussion: https://github.com/moses-smt/mosesdecoder/issues/89 )
>>>>>>> 
>>>>>>> 2. Things like lmplz do not compile, and aren't even attempted,
>>>>>>> perhaps because all of the tests fail.
>>>>>>> 
>>>>>>> ./bjam --max-factors=1 --max-kenlm-order=5 debug-symbols=off -j4 -d2
>>>>>>> --with-boost=/opt/boost threading=single --notrace link=shared
>>>>>>> --without-libsegfault
>>>>>>> [snip]
>>>>>>> ...failed updating 30 targets...
>>>>>>> ...skipped 36 targets...
>>>>>>> 
>>>>>>> It seems like something with boost unit tests?  e.g.,
>>>>>>> 
>>>>>>> "g++" -L"/opt/boost/lib" -L"/opt/boost/lib64" -Wl,-R
>>>>>>> -Wl,"/home/hltcoe/mpost/code/mosesdecoder/mert/bin/gcc-4.9.2/release"
>>>>>>> -Wl,-R -Wl,"/opt/boost/lib" -Wl,-R -Wl,"/opt/boost/lib64"
>>>>>>> -Wl,-rpath-link
>>>>>>> -Wl,"/home/hltcoe/mpost/code/mosesdecoder/mert/bin/gcc-4.9.2/release"
>>>>>>> -Wl,-rpath-link -Wl,"/opt/boost/lib" -Wl,-rpath-link
>>>>>>> -Wl,"/opt/boost/lib64" -o "mert/bin/gcc-4.9.2/release/timer_test"
>>>>>>> -Wl,--start-group
>>>>>>> "mert/bin/gcc-4.9.2/release/TimerTest.o" 
>>>>>>> "mert/bin/gcc-4.9.2/release/libmert_lib.so"  -Wl,-Bstatic  -Wl,-Bdynamic
>>>>>>> -lboost_unit_test_framework -ldl -lboost_system -lboost_filesystem
>>>>>>> -Wl,--end-group
>>>>>>> /usr/lib/../lib64/crt1.o: In function `_start':
>>>>>>> (.text+0x20): undefined reference to `main'
>>>>>>> collect2: error: ld returned 1 exit status
>>>>>>> 
>>>>>>> Debug file attached. Any ideas what's wrong?
>>>>>>> 
>>>>>>> matt
>>>>>>> 
>>>>>>> <build.log.gz>
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> Moses-support mailing list
>>>>> [email protected]
>>>>> http://mailman.mit.edu/mailman/listinfo/moses-support
>>>>> 
>>>> _______________________________________________
>>>> Moses-support mailing list
>>>> [email protected]
>>>> http://mailman.mit.edu/mailman/listinfo/moses-support
>>> 
>> _______________________________________________
>> Moses-support mailing list
>> [email protected]
>> http://mailman.mit.edu/mailman/listinfo/moses-support
>> 
> _______________________________________________
> Moses-support mailing list
> [email protected]
> http://mailman.mit.edu/mailman/listinfo/moses-support


_______________________________________________
Moses-support mailing list
[email protected]
http://mailman.mit.edu/mailman/listinfo/moses-support

Reply via email to