I've narrowed down further. The problem seems related to waitpid being called inside a thread spawned from the parent.
On Monday, October 6, 2014 10:41:00 AM UTC+2, Martin Croome wrote: > > I figured it out. Unfortunately there still seems to be this no child > process issue. > > On Monday, October 6, 2014 10:14:46 AM UTC+2, Martin Croome wrote: >> >> It seems like there is an install step that I'm missing where this script >> is run but this is make difficult by the fact that I'm cross compiling. >> >> make check obviously doesn't work since run-tests cannot work on my host. >> make tests/run-tests creates this libtool wrapper. I guess there is >> something inbetween. >> >> On Monday, October 6, 2014 10:07:00 AM UTC+2, Martin Croome wrote: >>> >>> Hi. Thanks for replying >>> >>> I'm using the configure .. make build route. The resulting run-tests >>> binary has a libtool shell wrapper around it which fails on my target since >>> the paths are all wrong. I saw the fixtures for the tests and have copied >>> all of those into an appropriate structure on the target. I've tried >>> compiling only the static libuv.a (using arguments to configure) and then >>> it seems to work ok (i.e. I get an elf executable) but then on my target >>> platform I get a bizarre error. Waitpid in run-tests always returns -1 (no >>> child process) even though everything seems to work ok (fork, exec >>> individual test). A normal fork exec waitpid process works on my target. I >>> built a test program to verify that. >>> >>> I'm wondering whether I shouldn't abandon autotools and try to build >>> with gyp. It is like looking for a needle in a haystack to figure out where >>> things are going wrong. >>> >>> >>> On Monday, October 6, 2014 8:47:41 AM UTC+2, Saúl Ibarra Corretgé wrote: >>>> >>>> On 04/10/14 14:46, Martin Croome wrote: >>>> > Hi >>>> > >>>> > I wonder if someone could give me a little help cross compiling the >>>> > libuv unit tests. I'm using 1.0 and running into libtool/automake >>>> > issues. The tests are built as a libtool executable with stuck on >>>> script >>>> > and all the paths are wrong for my target. Is there any simple way to >>>> > force a normal binary to be built? >>>> > >>>> >>>> What issues are you running into? How are you cross-compiling libuv? >>>> The >>>> tests are compiled as a static binary, but some of them do depend on >>>> some fixture files and the libuv directory structure a bit. >>>> >>>> >>>> Cheers, >>>> >>>> -- >>>> Saúl Ibarra Corretgé >>>> http://bettercallsaghul.com >>>> >>> -- You received this message because you are subscribed to the Google Groups "libuv" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/libuv. For more options, visit https://groups.google.com/d/optout.
