Testsuite breakages on Cygwin

Testsuite breakages on Cygwin

[Daniel Santos]

Hello,

I've been trying to get some clean test results on Cygwin and have 
encountered a number of problems.  I've opened a report for the one I'm 
most concerned with 
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79867). When an executable 
is being loaded, Windows searches for dlls based upon a few silly 
ms-like rules (https://msdn.microsoft.com/en-us/library/7d83bc18.aspx), 
followed by the PATH environment variable.  LD_LIBRARY_PATH is only used 
in Cygwin when loading a dll at run-time via dlopen().  This means that 
ALL tests are performed by linking in the shared libs that are installed 
on the *system* and not those built in the bootstrap.  If the dll is not 
installed on the system then the test fails.  Example:

FAIL: gfortran.dg/coarray/sync_3.f90 -fcoarray=single  -O2   output 
pattern test, is 
D:/builds/head-test-moutline-x86_64-pc-cygwin/gcc/testsuite/gfortran/sync_3.exe: 
error while loading shared libraries: cyggfortran-4.dll: cannot open 
shared object file: No such file or directory

I've written a crude patch to fix this, but I'm still new to DejaGnu, 
the gcc testsuite, et. al., and I am quite daunted by a few things.  
First, gcc has some code for maintaining the (dynamic) library path in 
target-libpath.exp and DejaGnu does some of this in in 
/usr/share/dejagnu/config/unix.exp.  But gcc has two slightly differing 
copies of target-libpath.exp, under {gcc,libffi}/testsuite/lib.  Also, 
LD_LIBRARY_PATH and SHLIB_PATH are directly modified in a few other gcc 
tests.

So my questions are:

1. Why are there two slightly different target-libpath.exp files? (The 
libffi version looks like it has some code to address this Cygwin 
problem; I haven't tested that yet.)
2. Can they be consolidated?
3. Wouldn't it be better to move this logic up into DejaGnu and restrict 
gcc to using a black-box interface for modifying the environment?

Still being new to DejaGnu, I may not fully understand it's intended 
scope, but it seems like the place to manage the subtleties of various 
OSes.  Either way, having the logic scattered about makes maintenance ugly.

Daniel

Re: Testsuite breakages on Cygwin

[Jonathan Wakely]

On 10 March 2017 at 06:39, Daniel Santos wrote:
> Hello,
>
> I've been trying to get some clean test results on Cygwin and have
> encountered a number of problems.  I've opened a report for the one I'm most
> concerned with (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79867). When an
> executable is being loaded, Windows searches for dlls based upon a few silly
> ms-like rules (https://msdn.microsoft.com/en-us/library/7d83bc18.aspx),
> followed by the PATH environment variable.  LD_LIBRARY_PATH is only used in
> Cygwin when loading a dll at run-time via dlopen().  This means that ALL
> tests are performed by linking in the shared libs that are installed on the
> *system* and not those built in the bootstrap.  If the dll is not installed
> on the system then the test fails.  Example:
>
> FAIL: gfortran.dg/coarray/sync_3.f90 -fcoarray=single  -O2   output pattern
> test, is
> D:/builds/head-test-moutline-x86_64-pc-cygwin/gcc/testsuite/gfortran/sync_3.exe:
> error while loading shared libraries: cyggfortran-4.dll: cannot open shared
> object file: No such file or directory

This is the cause of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66530

Re: Testsuite breakages on Cygwin

[Joseph Myers]

On Fri, 10 Mar 2017, Daniel Santos wrote:

> 3. Wouldn't it be better to move this logic up into DejaGnu and restrict gcc
> to using a black-box interface for modifying the environment?

GCC is meant to work with a wide range of different DejaGnu versions.  
There would be a long gap between adding board-file interfaces for 
controlling library paths - because that's the right level, interfaces 
that a board file can define alongside open, close, load, exec, spawn, 
etc. - and being able to assume they are available.  Of course you might 
try to arrange things so that existing board files not defining such 
interfaces continue to work (most custom board files are likely to be for 
bare metal where shared libraries don't exist) and so that GCC continues 
to work with versions of DejaGnu without such interfaces.

Finding shared libraries is generally simpler with installed testing, in 
that it becomes the responsibility of the board file, site.exp and the 
rest of the user-provided test environment to arrange for shared libraries 
to be in locations where they are found automatically.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Testsuite breakages on Cygwin

[Daniel Santos]

On 03/10/2017 11:23 AM, Joseph Myers wrote:
> On Fri, 10 Mar 2017, Daniel Santos wrote:
>
>> 3. Wouldn't it be better to move this logic up into DejaGnu and restrict gcc
>> to using a black-box interface for modifying the environment?
> GCC is meant to work with a wide range of different DejaGnu versions.
> There would be a long gap between adding board-file interfaces for
> controlling library paths - because that's the right level, interfaces
> that a board file can define alongside open, close, load, exec, spawn,
> etc. - and being able to assume they are available.  Of course you might
> try to arrange things so that existing board files not defining such
> interfaces continue to work (most custom board files are likely to be for
> bare metal where shared libraries don't exist) and so that GCC continues
> to work with versions of DejaGnu without such interfaces.

Thanks for the explanation.  So maybe the best approach is to migrate 
this upstream, but also corral this functionality into a single place in 
gcc and use gcc's implementation when the DejaGnu doesn't have the new 
interface.

> Finding shared libraries is generally simpler with installed testing, in
> that it becomes the responsibility of the board file, site.exp and the
> rest of the user-provided test environment to arrange for shared libraries
> to be in locations where they are found automatically.

In my case I have 8 full tests that need to be run, so this would mean 
installing and uninstalling 8 times.  I have a crude patch set that 
seems to be doing the job for now.  I guess I'm trying to work out a 
reasonable and clean solution for a patch set that I would actually 
submit. :)  It would be a lot easier if cygwin had an ldconfig 
implementation, but almost all shared libs just sit in /bin.

Daniel