Send Moses-support mailing list submissions to
moses-support@mit.edu
To subscribe or unsubscribe via the World Wide Web, visit
http://mailman.mit.edu/mailman/listinfo/moses-support
or, via email, send a message with subject or body 'help' to
moses-support-request@mit.edu
You can reach the person managing the list at
moses-support-owner@mit.edu
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Moses-support digest..."
Today's Topics:
1. mosesdecoder.v211 compilation error (Lakshya)
2. Re: yum-installed Boost environment variables for MGIZA++ (Gideon)
----------------------------------------------------------------------
Message: 1
Date: Thu, 3 Apr 2014 20:13:04 +0530
From: Lakshya <elekshman@gmail.com>
Subject: [Moses-support] mosesdecoder.v211 compilation error
To: moses-support@MIT.EDU
Message-ID:
<CANiOhcMNOCcP+kkE+auw0zz8riB1vzj4BQm2xhG8=JMT8A5n=Q@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi Hieu,
I am trying to compile mosesdecoder.v211.
But I am getting the error
"...failed gcc.link
~/Documents/mosesdecoder.v211/lm/builder/bin/gcc-4.6/release/debug-symbols-on/link-static/threading-multi/lmplz...
...failed updating 44 targets...
...skipped 2 targets...
The build failed. "
I have attached the build.log file.
I am using boost_1_55_0. ---> dpkg -s libboost-dev Version: 1.48.0.2
I have one existing mosesdecoder-RELEASE-1.0 installation which is working
fine with *irstlm-5.80.03, *giza-pp-v1.0.7, *automake g++ make gawk gzip
tcl8.4 tcl8.4-dev tcsh tcl-dev tclx8.4 tclx8.4-dev libtool libboost-dev
libboost-graph-dev libboost-iostreams-dev libboost-program-options-dev
gcc-4.1 g++-4.1 git-core .*
*I am pointing the same GIZA, IRSTLM and boost locations for the
*mosesdecoder.v211
compilation on a different folder.
How can I compile mosesdecoder.v211 successfully..
Expecting your help
Lakshya
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/mailman/private/moses-support/attachments/20140403/67f36f73/attachment-0001.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: build.log
Type: text/x-log
Size: 1468 bytes
Desc: not available
Url : http://mailman.mit.edu/mailman/private/moses-support/attachments/20140403/67f36f73/attachment-0001.bin
------------------------------
Message: 2
Date: Thu, 3 Apr 2014 16:52:50 +0200
From: Gideon <gidi8ster@gmail.com>
Subject: Re: [Moses-support] yum-installed Boost environment variables
for MGIZA++
To: Hieu Hoang <Hieu.Hoang@ed.ac.uk>
Cc: moses-support <moses-support@mit.edu>
Message-ID:
<CALP7mv=ZoMKZZn0wWn33V2H7_aLJrdQ1+qe061Ruqw7z86Jghg@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
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?
---
gidi8ster@gmail.com
www.gideonkotze.nl
On Thu, Apr 3, 2014 at 3:05 PM, Hieu Hoang <Hieu.Hoang@ed.ac.uk> 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 <gidi8ster@gmail.com> 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
>>
>>
>>
>> ---
>> gidi8ster@gmail.com
>> www.gideonkotze.nl
>>
>>
>> On Wed, Apr 2, 2014 at 2:38 PM, Hieu Hoang <hieuhoang@gmail.com> 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?
>>>
>>> ---
>>> gidi8ster@gmail.com
>>> www.gideonkotze.nl
>>>
>>>
>>>
>>> _______________________________________________
>>> Moses-support mailing listMoses-support@mit.eduhttp://mailman.mit.edu/mailman/listinfo/moses-support
>>>
>>>
>>>
>>> _______________________________________________
>>> Moses-support mailing list
>>> Moses-support@mit.edu
>>> http://mailman.mit.edu/mailman/listinfo/moses-support
>>>
>>>
>>
>
>
> --
> Hieu Hoang
> Research Associate
> University of Edinburgh
> http://www.hoang.co.uk/hieu
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/mailman/private/moses-support/attachments/20140403/8f026e7c/attachment.htm
------------------------------
_______________________________________________
Moses-support mailing list
Moses-support@mit.edu
http://mailman.mit.edu/mailman/listinfo/moses-support
End of Moses-support Digest, Vol 90, Issue 7
********************************************
Subscribe to:
Post Comments (Atom)
0 Response to "Moses-support Digest, Vol 90, Issue 7"
Post a Comment