Yep. the fork bomb is gone with 3990. Let's hope it doesn't
re-appear. 

Tom 

On Tue, 24 May 2011 10:49:18 +0100, "Barry Haddow" 
wrote:  

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"

Date: Tue, May 24, 2011 09:14
Subject: [Moses-support] configure fails
to recognize option --with-boost-thread
To: "Moses support" 
Cc: "Barry
Haddow" 

 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 
 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/bashnecho 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
>> 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
[1]
>>>
>>>
>>> 
>>>
http://forums.opensuse.org/english/other-forums/development/programming-scripting/402683-kdevelop-problem.html
[2]
>>>
>>>
http://www.handle.net/mail-archive/handle-info/msg00442.html [3]
>>>
>>>
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
>>>> 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.




Links:
------
[1]
http://mail-index.netbsd.org/netbsd-bugs/2001/11/24/0006.html
[2]
http://forums.opensuse.org/english/other-forums/development/programming-scripting/402683-kdevelop-problem.html
[3]
http://www.handle.net/mail-archive/handle-info/msg00442.html
_______________________________________________
Moses-support mailing list
[email protected]
http://mailman.mit.edu/mailman/listinfo/moses-support

Reply via email to