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