Web lists-archives.com

Re: Strange errors running gcc tests on Cygwin




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