Hi Tom
Do you mean the ltmain.sh fork bomb is fixed? Don't really understand why.
Beginning to despise automake....
Cheers - Barry
Sent from my ZX81
----- Reply message -----
From: "Tom Hoar" <[email protected]>
Date: Tue, May 24, 2011 09:14
Subject: [Moses-support] configure fails to recognize option --with-boost-thread
To: "Moses support" <[email protected]>
Cc: "Barry Haddow" <[email protected]>
Barry,
Your latest configure updates in svn rev 3990 resolved the problem.
configure/make now work without the need to manipulate ltmain.sh
(below).
Thanks,
Tom
On Fri, 20 May 2011 01:16:10 -0400, Kenneth Heafield
<[email protected]> wrote:
> I was able to resolve the other (fork bomb) issue, which is
> orthogonal
> to the --with-boost-thread issue, by
>
> rm ltmain.sh
> touch ltmain.sh
> ./regenerate-makefiles.sh
> ./configure --favorite-options
> make -jN
>
> It appears that the ltmain.sh distributed with Moses should never be
> used. It's only there because automake checks for it (but does
> nothing
> with it, so an empty file sufficies) and is then overwritten with a
> symlink by the later libtoolize.
>
> So if nobody objects (read: I'm afraid this will break the build for
> somebody and want to spread the blame), I'll svn rm ltmain.sh and
> edit
> regnerate-makefiles.sh to add
>
> if [ ! -f ltmain.sh ]; then
> echo -e "#!/bin/bash\necho Run libtoolize 1>&2"> ltmain.sh
> chmod +x ltmain.sh
> fi
>
> before automake.
>
> That will prevent people from fork bombing their machine. This will
> also get rid of that annoying commit message because ltmain.sh won't
> be
> in the repository.
>
> On 05/19/11 23:47, Tom Hoar wrote:
>> I'm glad you can replicate the problem. Easier to fix that way.
>>
>> On Thu, 19 May 2011 23:42:55 -0400, Kenneth Heafield
>> <[email protected]> wrote:
>>> Apparently this is a libtool issue, not one with my code. Probably
>>> what
>>> happened is a new libtool went out and broke everything. Somebody
>>> with
>>> more experience with GNU awfultools should fix this.
>>>
>>> I'm able to reproduce this on one machine. If you watch ps, you'll
>>> notice that libtool is fork bombing you:
>>>
>>> /bin/sh ../libtool --no-reexec
>>> /bin/sed s%^.*/%%
>>>
>>> It appears to be the same as these bugs:
>>>
>>> http://mail-index.netbsd.org/netbsd-bugs/2001/11/24/0006.html
>>>
>>>
>>>
>>> http://forums.opensuse.org/english/other-forums/development/programming-scripting/402683-kdevelop-problem.html
>>>
>>> http://www.handle.net/mail-archive/handle-info/msg00442.html
>>>
>>> My code compiles correctly and you can verify this by running
>>>
>>> cd kenlm
>>> ./compile.sh
>>>
>>> On 05/19/11 23:17, Tom Hoar wrote:
>>>> Thanks Ken. It's possible I have other problems on this host. So,
>>>> if
>>>> you
>>>> can't reproduce I'll have to rebuild.
>>>>
>>>> @Others: regarding configure's WARNING: unrecognized options:
>>>> --with-boost-thread, is this option still required?
>>>>
>>>> Tom
>>>>
>>>>
>>>>
>>>> On Thu, 19 May 2011 23:05:53 -0400, Kenneth Heafield
>>>> <[email protected]> wrote:
>>>>> Hmmm. . . looks like it's crashing on lm/lm_exception.cc and
>>>>> lm/config.cc which are mine. But the compiler should throw you
>>>>> an
>>>>> error
>>>>> instead of taking infinite memory. See if I can reproduce.
>>>>>
>>>>> On 05/19/11 22:58, [email protected] wrote:
>>>>>> I'm updating to the newest moses trunk thread, 3981. This
>>>>>> command
>>>>>> line
>>>>>> worked with rev 3675 but now fails:
>>>>>>
>>>>>> ./configure --with-srilm=/opt/lib/srilm \
>>>>>> --with-irstlm=/opt/lib/irstlm \
>>>>>> --with-randlm=/opt/lib/randlm \
>>>>>> --enable-threads \
>>>>>> --with-xmlrpc-c \
>>>>>> --with-boost-thread
>>>>>>
>>>>>> Configure reports the boost libraries are installed but then
>>>>>> fails (see
>>>>>> configure output below). Has there been a change that obsoletes
>>>>>> the
>>>>>> --with-boost-thread option?
>>>>>>
>>>>>> Without the --with-boost-thread option, configure still finds
>>>>>> the
>>>>>> boost
>>>>>> libraries and completes without error. However, "make -j 2"
>>>>>> starts with
>>>>>> the following output and hangs. Both CPUs peg 100%, RAM reaches
>>>>>> +90%
>>>>>> quickly and swap file usage grows. It's still running, but I
>>>>>> expect it
>>>>>> will crash.
>>>>>>
>>>>>> Other details:
>>>>>> OS: Ubuntu 10.04 server
>>>>>> Build environment: apt-get install linux-headers-`uname -r`
>>>>>> build-essential zlib1g-dev automake libtool libboost-all-dev
>>>>>> libxmlrpc-c3-dev
>>>>>> SRILM release 1.5.12
>>>>>> IRSTLM release 5.60.03
>>>>>> RANDLM release 0.20
>>>>>>
>>>>>> Thanks,
>>>>>> Tom
>>>>>>
>>>>>> user@host:~$ make -j 2
>>>>>> (CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/bash
>>>>>> /opt/src/mosesdecoder/missing --run autoheader)
>>>>>> rm -f stamp-h1
>>>>>> touch config.h.in
>>>>>> cd . && /bin/bash ./config.status config.h
>>>>>> config.status: creating config.h
>>>>>> config.status: config.h is unchanged
>>>>>> make all-recursive
>>>>>> make[1]: Entering directory `/opt/src/mosesdecoder'
>>>>>> Making all in kenlm
>>>>>> make[2]: Entering directory `/opt/src/mosesdecoder/kenlm'
>>>>>> /bin/bash ../libtool --tag=CXX --mode=compile g++
>>>>>> -DHAVE_CONFIG_H
>>>>>> -I.The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
_______________________________________________
Moses-support mailing list
[email protected]
http://mailman.mit.edu/mailman/listinfo/moses-support
