On 03/13/2017 12:25 PM, Marco Atzeri wrote:
The risk of collision is very low on 64 bit.
It is higher on 32 bit but as gcc don't depend on other libraries,
I don't expect that to happen.
If happens you can rebase in tree before running the tests,
providing the list of new dll to rebase.
I used it when I had problem on testing Octave; but Octave
dlls with debugging symbols are huge and pull tons of
other dlls so the collision was almost sure on 32bit
I'm not so much concerned about the outcome of an individual run, but of
test integrity, reliability and repeatability. gcc's testsuite should
be something you can fire off and forget about until it finishes (it
current takes about 14 hours 100). A test should fail when there's a
bug and not when the god of random numbers frowns. The possibility of
this type of problem means that fewer developers are going to be willing
to get on Cygwin and so gcc will be crappier and tend to break on
Cygwin. (This is combined with the fact that SO much of DejaGnu & gcc
tests are already broken on Cygwin). If this is a possible issue at
all, it should be managed somewhere IN gcc's build process. I've been
through a few of weeks of BS now and I'm just starting on my 32-bit tests.
I would very much like to be able to come up with an automated process
that can be run on a server somewhere under a VM using an LVM read/write
snapshot, so that the environment can be easily reset to a pristine
state (i.e., freshly installed Windows & Cygwin) with minimal I/O. If I
can solve this problem and the "broken pipe" issue then we might be
getting close!
Daniel
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
