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/trunk mgizapp-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
_______________________________________________ Moses-support mailing list [email protected] http://mailman.mit.edu/mailman/listinfo/moses-support
