I thought the linkers were clever enough to differentiate between 32 & 64 bit libraries. Glad you managed to solve it somehow
Found out the reason for the unit test failed - they were using the boost shared libraries. Compiling and linking to your own static boost as per Moses instructions will make it succeed. http://www.statmt.org/moses/?n=Development.GetStarted I've seen that for some time but never been able to find out why. Also passes regression tests, other than some rounding errors. * Looking for MT/NLP opportunities * Hieu Hoang http://moses-smt.org/ On 1 March 2017 at 12:58, Mike Ladwig <mdlad...@gmail.com> wrote: > That compiled (I'll start testing soon) fine. I think the issue with > libSegFault is that I have both 32 and 64 bit versions of glibc installed > which puts the 32bit version of libSegFault in /usr/lib and 64 bit version > in /usr/lib64. The way moses gcc.link is setup, it seems ldd is searching > /usr/lib before /usr/lib64. > > On Wed, Mar 1, 2017 at 7:04 AM, Hieu Hoang <hieuho...@gmail.com> wrote: > >> I tried Moses version 3 and master on a plain Redhat Enterprise 7. I had >> to make some changes to master >> https://github.com/moses-smt/mosesdecoder/commits/master >> Both versions compiled ok but there were errors in the unit tests, which >> can be ignored for another time. These are the build logs, fyi: >> https://www.dropbox.com/sh/h55chvo41586cit/AAAwv6kESmIinMeOI >> 82wXrxta?dl=0 >> >> I'm not sure why you're getting problems with -lSegFault. Maybe there's >> some remants of an older OS left when the server was upgraded. >> >> fyi: >> >> $ gcc --version >> gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11) >> Copyright (C) 2015 Free Software Foundation, Inc. >> This is free software; see the source for copying conditions. There is NO >> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR >> PURPOSE. >> >> $ cat /proc/version >> Linux version 3.10.0-514.el7.x86_64 (mockbu...@x86-039.build.eng.b >> os.redhat.com) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-11) (GCC) ) #1 >> SMP Wed Oct 19 11:24:13 EDT 2016 >> >> compile command: >> ./bjam -j10 --with-xmlrpc-c=/home/hieu/workspace/xmlrpc-c-1.39.12 >> --with-cmph=/home/hieu/workspace/cmph-2.0 --with-irstlm=/home/hieu/works >> pace/irstlm-5.80.08/trunk >> >> >> Hieu Hoang >> http://moses-smt.org/ >> * Looking for MT/NLP opportunities * >> >> On 28 February 2017 at 15:33, Mike Ladwig <mdlad...@gmail.com> wrote: >> >>> I've build moses 3.x previously without issue, but something has changed >>> in the last few months (fresh checkout this morning) and the build is now >>> failing on RHEL 7.x. I setup LIBRARY_PATH and CPATH to link with a locally >>> compiled zlib (the RHEL zlib is broken). >>> >>> I use the following commands: >>> export LIBRARY_PATH=/usr/local/lib64 >>> export CPATH=/usr/local/include >>> ./bjam --with-cmph=/usr/local >>> >>> It looks like it is generally failing in link steps trying to link x86 >>> instead of x86_64 libraries (/usr/lib instead of /usr/lib64): >>> >>> [mike@c7test mosesdecoder]$ file /usr/lib64/librt-2.17.so >>> /usr/lib64/librt-2.17.so: ELF 64-bit LSB shared object, x86-64, version >>> 1 (GNU/Linux), dynamically linked, >>> BuildID[sha1]=82e77ade22bc9fff8d3458bd37331e7edf174c28, >>> for GNU/Linux 2.6.32, not stripped >>> [mike@c7test mosesdecoder]$ file /usr/lib64/libSegFault.so >>> /usr/lib64/libSegFault.so: ELF 64-bit LSB shared object, x86-64, version >>> 1 (SYSV), dynamically linked, >>> BuildID[sha1]=2fdc95c4323c554e206e16fb01571970c9c0afd5, >>> for GNU/Linux 2.6.32, not stripped >>> >>> >>> _______________________________________________ >>> Moses-support mailing list >>> Moses-support@mit.edu >>> http://mailman.mit.edu/mailman/listinfo/moses-support >>> >>> >> >
_______________________________________________ Moses-support mailing list Moses-support@mit.edu http://mailman.mit.edu/mailman/listinfo/moses-support
