The PATH is set correctly when we enter the build. perhaps 1 or 2
invocations of a particular command e.g. "cp" (the coretools copy
command) will fail with "cp: command not found" but the other N
thousand invocations will work.
We think that either:
1) The path is randomly corrupted in particular invocations of bash (3.1 BTW).
2) The logic that searches the path fails randomly.
We suspect environment corruption of the PATH variable because we
occasionally see corruption in the TMP variable so it is possible that
this is affecting PATH too.
We are trying to get a reproducable test case at the moment. It's
very hard - the problem happens for different targets in different
builds and it seems extremely difficult to isolate the circumstances.
The reproducability problem is what makes me hesitate from filing a
bug until I have had a chance to discuss it a bit.
Eventually we might be able to fix this stuff ourselves in which case,
expect a patch! It's just that we have so much stuff to sort out,
that we are a bit exhausted at the thought of becoming MSYS
developers. Never mind we will - but probably slowly.
I was looking at environ.cc in winsup and wondering if there was scope
for corruption of environment variables there when they were being
converted. There seems to be some caching of converted paths and I
wondered if there is some sort of potential for race conditions.
2008/10/14 Greg Chicares <gchicares@...>:
> On 2008-10-14 12:53Z, Tim Murphy wrote:
>> I am working on a build system that is meant to work on Linux and
>> Windows. We use MSYS for the windows side of things - we use bash and
>> coretools but our make is the mingw make because we had problems with
>> stackdumps from the msys one in the distant past.
> Did you report the problems?
> Can you definitely tell whether they're problems with 'make'
> and not with the commands in the makefile?
> Have you tried a newer MSYS 'make'?
>> One of the many problems that we have seen is commands that fail to
>> execute either because:
>> 1) They cannot be found on the path
> Is that because you aren't using the MSYS version of 'make'?
>> 2) They use the TMP or TEMP variables which turn out to have
>> nonsensical contents.
> You can do something like this:
> # Make sure a temporary directory exists.
> TMPDIR ?= /tmp
> +@[ -d $@ ] || $(MKDIR) --parents $@
>> These problems are very hard to reproduce and happen randomly
>> throughout our build.
>> We have found ways of working around the problem (using full paths for
>> executables and forcing TMP to be a certain value). It's still
>> bothersome and we'd like to solve it.
>> I'm posting this in case anyone has ever come across these problems
>> and in case anyone ever does - they'll know they weren't alone.
> But you say you'd like the problems solved, so why not file a
> defect report with a minimal, standalone, reproducible testcase?
> You say the problems are hard to reproduce, but how can the first
> one (for example) be so? Either a program is found on the path,
> or it isn't, right?
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> Mingw-msys mailing list
You could help some brave and decent people to have access to
uncensored news by making a donation at: