I'm not too sure. Maybe you should try to compile boost yourself. The instructions are here http://www.statmt.org/moses/?n=Development.GetStarted
On 3 April 2014 16:23, Gideon <[email protected]> wrote: > I have done what you asked, and removed all occurrences of "-mt" in > compile.sh. However: > > /usr/bin/ld: cannot find -lboost_system > /usr/bin/ld: cannot find -lboost_thread > > /usr/bin/ld: cannot find -lpthread > /usr/bin/ld: cannot find -lstdc++ > /usr/bin/ld: cannot find -lm > /usr/bin/ld: cannot find -lc > collect2: error: ld returned 1 exit status > > Two other things I noticed: > > - The script expects a $BOOST_ROOT/include, although there exists no > include directory in /home/kotzegj/tools/boost_1_54_0 > - Even if I change $BOOST_ROOT to, say, "/usr" (which does contain > "include" which on its own contains "boost"), the error output is exactly > the same. > > I have run "locate boost" and attached the output in case you wanted to > look at it. Perhaps you can tell from it if I have a faulty installation? > > Thanks again. > > Gideon > > > > --- > [email protected] > www.gideonkotze.nl > +27 78 739 8923 (Mobile) > > > On Thu, Apr 3, 2014 at 4:59 PM, Hieu Hoang <[email protected]> wrote: > >> change >> -lboost_*-mt >> to >> -lboost_* >> >> i'm not sure why you're linking to stdc++, m, c. >> >> Check there's not typo in your compile.sh >> >> On 3 April 2014 15:52, Gideon <[email protected]> wrote: >> >>> Thank you, I have now managed with SVN, it turns out that I had to >>> change the configuration for my (university) proxy settings. However, there >>> are still compilation errors it seems. I have warnings such as this: >>> >>> /home/kotzegj/tools/mgiza/mgizapp-code/mgizapp/src/mkcls/KategProblem.cpp:446:9: >>> warning: deprecated conversion from string constant to 'char*' >>> [-Wwrite-strings] >>> in="other "; >>> >>> And perhaps more importantly, some files that are not found: >>> >>> /usr/bin/ld: cannot find -lboost_system-mt >>> /usr/bin/ld: cannot find -lboost_thread-mt >>> /usr/bin/ld: cannot find -lpthread >>> /usr/bin/ld: cannot find -lstdc++ >>> /usr/bin/ld: cannot find -lm >>> /usr/bin/ld: cannot find -lc >>> >>> which would indicate that there are still some problems with (finding) >>> Boost. >>> >>> And still no mgiza binary. >>> >>> Some context (fnd is an alias for "find . -name"): >>> >>> [kotzegj@lt-2433323 usr]$ fnd "*boost_thread*" >>> ./lib64/libboost_thread.so >>> ./lib64/libboost_thread.so.1.54.0 >>> >>> [kotzegj@lt-2433323 usr]$ fnd "*boost_system*" >>> ./lib64/libboost_system.so.1.54.0 >>> ./lib64/libboost_system.so >>> >>> As mentioned, I installed Boost using yum, and these are my current >>> variables in compile.sh: >>> >>> SRC_DIR=/home/kotzegj/tools/mgiza/mgizapp-code/mgizapp/src >>> BOOST_ROOT=/home/kotzegj/tools/boost_1_54_0 >>> BOOST_LIBRARYDIR=/usr/lib64 >>> >>> BOOST_ROOT is pointing to the uncompiled unbuilt Boost - perhaps it >>> should point somewhere else? >>> >>> Thank you for your time. >>> >>> Best, >>> >>> Gideon Kotzé >>> >>> >>> >>> >>> --- >>> [email protected] >>> www.gideonkotze.nl >>> >>> >>> On Thu, Apr 3, 2014 at 3:05 PM, Hieu Hoang <[email protected]> wrote: >>> >>>> You should use the version in svn, rather than a packaged version. >>>> mgiza isn't really looked after by anyone anymore, bug fixes go straight >>>> into the svn and nowhere else. >>>> >>>> I've just pushed a fix for a minor OSX compile error >>>> https://sourceforge.net/p/mgizapp/code/48/ >>>> >>>> Try to download it via svn. If it doesn't work, i will consider moving >>>> it to github. >>>> >>>> >>>> >>>> >>>> On 2 April 2014 14:34, Gideon <[email protected]> wrote: >>>> >>>>> Dear Hieu Hoang >>>>> >>>>> Thank you for you reply. I made some changes: >>>>> >>>>> - uncommented out the top variables and commented out the Mac ones >>>>> - set BOOST_ROOT to /home/kotzegj/tools/boost_1_54_0 and >>>>> BOOST_LIBRARYDIR to /usr/lib64 >>>>> - set SRC_DIR to /home/kotzegj/tools/mgiza/mgizapp/src >>>>> >>>>> and ran ./compile.sh. >>>>> >>>>> Two issues remain so far: >>>>> >>>>> 1) I can't find any MGIZA++/mgiza++/etc. binary (find . -name). Is >>>>> there a way to test if MGIZA++ has installed correctly? I did not notice >>>>> any other error messages, apart from the files the script tries to remove >>>>> at the beginning, which do not exist. >>>>> >>>> it should be called >>>> manual-compile/mgiza >>>> If not, there was a compile error >>>> >>>>> >>>>> 2) When compiling, this warning pops up all the time (you are probably >>>>> aware of it) >>>>> >>>>> /usr/include/c++/4.8.2/backward/backward_warning.h:32:2: warning: >>>>> #warning This file includes at least one deprecated or antiquated header >>>>> which may be removed without further notice at a future date. Please use a >>>>> non-deprecated interface with equivalent functionality instead. For a >>>>> listing of replacement headers and interfaces, consult the file >>>>> backward_warning.h. To disable this warning use -Wno-deprecated. [-Wcpp] >>>>> >>>>> So I assume this is OK for now but there needs to be an update in the >>>>> future? >>>>> >>>> i see it. Be my guest if you wanna update it >>>> >>>>> >>>>> and (just to test) >>>>> >>>>> 2) [kotzegj@lt-2433323 manual-compile]$ ./mkcls >>>>> ERROR: can not open file train. >>>>> Error: Could not read the file 'train'. >>>>> >>>>> But perhaps this is the default? >>>>> >>>> I don't know. Try running it with valid arguments, eg >>>> >>>> http://www.statmt.org/moses/RELEASE-2.1/models/cs-en/steps/1/TRAINING_prepare-data.1.STDERR >>>> >>>> >>>>> >>>>> 3) svn checkout http://svn.code.sf.net/p/mgizapp/code/trunkmgizapp-code >>>>> --> did not work (timeout). I downloaded 0.7.3 from here instead: >>>>> http://www.kyloo.net/software/doku.php/mgiza:overview >>>>> >>>>> svn: E000110: Unable to connect to a repository at URL ' >>>>> http://svn.code.sf.net/p/mgizapp/code/trunk' >>>>> svn: E000110: Error running context: Connection timed out >>>>> >>>>> Thank you for your time. >>>>> >>>>> Best regards, >>>>> >>>>> Gideon >>>>> >>>>> >>>>> >>>>> --- >>>>> [email protected] >>>>> www.gideonkotze.nl >>>>> >>>>> >>>>> On Wed, Apr 2, 2014 at 2:38 PM, Hieu Hoang <[email protected]>wrote: >>>>> >>>>>> the cmake build system on mgiza is difficult to use. >>>>>> >>>>>> I create an alternative compile script for mgiza. If you've download >>>>>> mgiza via svn, you should find my script in >>>>>> mgizapp/manual-compile/compile.sh >>>>>> Look at it, change the paths for your own needs >>>>>> >>>>>> >>>>>> On 02/04/2014 11:34, Gideon wrote: >>>>>> >>>>>> Dear Moses support team >>>>>> >>>>>> I was wondering if MGIZA++ has been test-compiled on a Fedora Linux >>>>>> system where Boost has been installed using yum, as I'm encountering some >>>>>> problems. I'm working on a Fedora 20 system with x86_64 architecture. So >>>>>> far I have done the following: >>>>>> >>>>>> yum install boost.x86_64 >>>>>> yum install boost-devel.x86_64 (version 1.54 was installed) >>>>>> yum install gcc >>>>>> yum install gcc-c++ >>>>>> yum install gperftools >>>>>> Downloaded and installed IRSTLM >>>>>> ./bjam --with-irstlm=/home/kotzegj/tools/irstlm-5.80.03 -j4 >>>>>> --with-boost=/usr/lib64 >>>>>> export BOOST_ROOT=/usr/lib64 >>>>>> export >>>>>> BOOST_BUILD_PATH=/home/kotzegj/tools/mosesdecoder/jam-files/boost-build >>>>>> ./bjam --with-irstlm=/usr/local/irstlm -j4 >>>>>> >>>>>> I have tested Moses with sample-models and it seems OK. >>>>>> >>>>>> However, MGIZA++ does not find Boost on its own: >>>>>> >>>>>> -- Could NOT find Boost >>>>>> CMake Error at CMakeLists.txt:59 (MESSAGE): >>>>>> Boost not found, please set the BOOST_ROOT and BOOST_LIBRARYDIR >>>>>> environment >>>>>> variables >>>>>> >>>>>> I have no success with setting either of these variables to: >>>>>> >>>>>> - /usr/lib64 >>>>>> - /usr/include >>>>>> - /usr/include/boost >>>>>> - /home/kotzegj/tools/mosesdecoder/jam-files/boost-build >>>>>> etc. >>>>>> >>>>>> or if I download Boost manually, set the decompressed directory as >>>>>> BOOST_ROOT, and symlink lib64 as a child and set that as >>>>>> BOOST_LIBRARYDIR. >>>>>> (I've tried all kinds of stuff.) >>>>>> >>>>>> I have the feeling (after some Googling) that the yum installation >>>>>> does not result in the file structure that cmake is looking for, and that >>>>>> instead I should try a manual installation. I hope that I'm wrong? >>>>>> >>>>>> Thank you for your time. >>>>>> >>>>>> Best regards, >>>>>> >>>>>> Gideon Kotzé >>>>>> >>>>>> --- >>>>>> [email protected] >>>>>> www.gideonkotze.nl >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Moses-support mailing >>>>>> [email protected]http://mailman.mit.edu/mailman/listinfo/moses-support >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Moses-support mailing list >>>>>> [email protected] >>>>>> http://mailman.mit.edu/mailman/listinfo/moses-support >>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> Hieu Hoang >>>> Research Associate >>>> University of Edinburgh >>>> http://www.hoang.co.uk/hieu >>>> >>>> >>> >> >> >> -- >> Hieu Hoang >> Research Associate >> University of Edinburgh >> http://www.hoang.co.uk/hieu >> >> > -- Hieu Hoang Research Associate University of Edinburgh http://www.hoang.co.uk/hieu
_______________________________________________ Moses-support mailing list [email protected] http://mailman.mit.edu/mailman/listinfo/moses-support
