Strange errors running gcc tests on Cygwin

Strange errors running gcc tests on Cygwin

[Daniel Santos]

Hello. I'm trying to validate a gcc patchset that affects msabi 
functions, so I need good test results on Cygwin, but my unpatched tests 
are getting hundreds of failures for which I cannot determine the cause. 
I'm running Cygwin 64 bit on Windows 7 in a qemu vm (with kvm).  My 
sources are on a C: drive (gcc's HEAD a from a few days ago), but I 
didn't make that device large enough, so I had to add a second device on 
D for the builds.  I have cygdrive set to /  (in /etc/fstab, I have 
"none            /       cygdrive binary,posix=0,user 0 0"), but the 
file names it's printing is using the D: format instead of /d.  Example:

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

That might not actually be the problem. I do NOT have fortran 
installed.  I have run a successful "make bootstrap" so the build tree 
should have the correct Fortran libs.  The file "cyggfortran-4.dll" does 
exist at the location 
/d/builds/head-test-unpatched-x86_64-pc-cygwin/x86_64-pc-cygwin/libgfortran/.libs/cyggfortran-4.dll. 
The even stranger part is that these errors aren't in the build from my 
patched sources.  Maybe something changed in my environment?  I ran my 
patched tests firsts, which resulted in much fewer failures and I 
haven't re-run them yet to see if it's failing now or not. Any ideas?

This is the snippet from the log for the above failure:

Executing on host: 
/d/builds/head-test-unpatched-x86_64-pc-cygwin/gcc/testsuite/gfortran2/../../gfortran 
-B/d/builds/head-test-unpatched-x86_64-pc-cygwin/gcc/testsuite/gfortran2/../../ 
-B/d/builds/head-test-unpatched-x86_64-pc-cygwin/x86_64-pc-cygwin/./libgfortran/ 
/c/Users/daniel/proj/sys/gcc/work0/gcc/testsuite/gfortran.dg/coarray/sync_3.f90 
-fno-diagnostics-show-caret -fdiagnostics-color=never -fcoarray=single  
-O2   -fcheck=all 
-B/d/builds/head-test-unpatched-x86_64-pc-cygwin/x86_64-pc-cygwin/./libgfortran/.libs 
-L/d/builds/head-test-unpatched-x86_64-pc-cygwin/x86_64-pc-cygwin/./libgfortran/.libs 
-B/d/builds/head-test-unpatched-x86_64-pc-cygwin/x86_64-pc-cygwin/./libquadmath/.libs 
-L/d/builds/head-test-unpatched-x86_64-pc-cygwin/x86_64-pc-cygwin/./libquadmath/.libs 
-o ./sync_3.exe    (timeout = 300)
spawn 
/d/builds/head-test-unpatched-x86_64-pc-cygwin/gcc/testsuite/gfortran2/../../gfortran 
-B/d/builds/head-test-unpatched-x86_64-pc-cygwin/gcc/testsuite/gfortran2/../../ 
-B/d/builds/head-test-unpatched-x86_64-pc-cygwin/x86_64-pc-cygwin/./libgfortran/ 
/c/Users/daniel/proj/sys/gcc/work0/gcc/testsuite/gfortran.dg/coarray/sync_3.f90 
-fno-diagnostics-show-caret -fdiagnostics-color=never -fcoarray=single 
-O2 -fcheck=all 
-B/d/builds/head-test-unpatched-x86_64-pc-cygwin/x86_64-pc-cygwin/./libgfortran/.libs 
-L/d/builds/head-test-unpatched-x86_64-pc-cygwin/x86_64-pc-cygwin/./libgfortran/.libs 
-B/d/builds/head-test-unpatched-x86_64-pc-cygwin/x86_64-pc-cygwin/./libquadmath/.libs 
-L/d/builds/head-test-unpatched-x86_64-pc-cygwin/x86_64-pc-cygwin/./libquadmath/.libs 
-o ./sync_3.exe
PASS: gfortran.dg/coarray/sync_3.f90 -fcoarray=single  -O2   (test for 
excess errors)
Setting LD_LIBRARY_PATH to 
.:/d/builds/head-test-unpatched-x86_64-pc-cygwin/x86_64-pc-cygwin/./libgfortran/.libs:/d/builds/head-test-unpatched-x86_64-pc-cygwin/x86_64-pc-cygwin/./libquadmath/.libs:/d/builds/head-test-unpatched-x86_64-pc-cygwin/gcc:.:/d/builds/head-test-unpatched-x86_64-pc-cygwin/x86_64-pc-cygwin/./libgfortran/.libs:/d/builds/head-test-unpatched-x86_64-pc-cygwin/x86_64-pc-cygwin/./libquadmath/.libs:/d/builds/head-test-unpatched-x86_64-pc-cygwin/gcc
spawn [open ...]
D:/builds/head-test-unpatched-x86_64-pc-cygwin/gcc/testsuite/gfortran2/sync_3.exe: 
error while loading shared libraries: cyggfortran-4.dll: cannot open 
shared object file: No such file or directory
PASS: gfortran.dg/coarray/sync_3.f90 -fcoarray=single  -O2 execution test
FAIL: gfortran.dg/coarray/sync_3.f90 -fcoarray=single  -O2   output 
pattern test, is 
D:/builds/head-test-unpatched-x86_64-pc-cygwin/gcc/testsuite/gfortran2/sync_3.exe: 
error while loading shared libraries: cyggfortran-4.dll: cannot open 
shared object file: No such file or directory
, should match Fortran runtime error: Invalid image number -1 in SYNC IMAGES
Executing on host: 
/d/builds/head-test-unpatched-x86_64-pc-cygwin/gcc/testsuite/gfortran2/../../gfortran 
-B/d/builds/head-test-unpatched-x86_64-pc-cygwin/gcc/testsuite/gfortran2/../../ 
-B/d/builds/head-test-unpatched-x86_64-pc-cygwin/x86_64-pc-cygwin/./libgfortran/ 
/c/Users/daniel/proj/sys/gcc/work0/gcc/testsuite/gfortran.dg/coarray/sync_3.f90 
-fno-diagnostics-show-caret -fdiagnostics-color=never -fcoarray=lib  
-O2  -lcaf_single  -fcheck=all 
-B/d/builds/head-test-unpatched-x86_64-pc-cygwin/x86_64-pc-cygwin/./libgfortran/.libs 
-L/d/builds/head-test-unpatched-x86_64-pc-cygwin/x86_64-pc-cygwin/./libgfortran/.libs 
-B/d/builds/head-test-unpatched-x86_64-pc-cygwin/x86_64-pc-cygwin/./libquadmath/.libs 
-L/d/builds/head-test-unpatched-x86_64-pc-cygwin/x86_64-pc-cygwin/./libquadmath/.libs 
-o ./sync_3.exe    (timeout = 300)
spawn 
/d/builds/head-test-unpatched-x86_64-pc-cygwin/gcc/testsuite/gfortran2/../../gfortran 
-B/d/builds/head-test-unpatched-x86_64-pc-cygwin/gcc/testsuite/gfortran2/../../ 
-B/d/builds/head-test-unpatched-x86_64-pc-cygwin/x86_64-pc-cygwin/./libgfortran/ 
/c/Users/daniel/proj/sys/gcc/work0/gcc/testsuite/gfortran.dg/coarray/sync_3.f90 
-fno-diagnostics-show-caret -fdiagnostics-color=never -fcoarray=lib -O2 
-lcaf_single -fcheck=all 
-B/d/builds/head-test-unpatched-x86_64-pc-cygwin/x86_64-pc-cygwin/./libgfortran/.libs 
-L/d/builds/head-test-unpatched-x86_64-pc-cygwin/x86_64-pc-cygwin/./libgfortran/.libs 
-B/d/builds/head-test-unpatched-x86_64-pc-cygwin/x86_64-pc-cygwin/./libquadmath/.libs 
-L/d/builds/head-test-unpatched-x86_64-pc-cygwin/x86_64-pc-cygwin/./libquadmath/.libs 
-o ./sync_3.exe
PASS: gfortran.dg/coarray/sync_3.f90 -fcoarray=lib  -O2 -lcaf_single  
(test for excess errors)
Setting LD_LIBRARY_PATH to 
.:/d/builds/head-test-unpatched-x86_64-pc-cygwin/x86_64-pc-cygwin/./libgfortran/.libs:/d/builds/head-test-unpatched-x86_64-pc-cygwin/x86_64-pc-cygwin/./libquadmath/.libs:/d/builds/head-test-unpatched-x86_64-pc-cygwin/gcc:.:/d/builds/head-test-unpatched-x86_64-pc-cygwin/x86_64-pc-cygwin/./libgfortran/.libs:/d/builds/head-test-unpatched-x86_64-pc-cygwin/x86_64-pc-cygwin/./libquadmath/.libs:/d/builds/head-test-unpatched-x86_64-pc-cygwin/gcc
spawn [open ...]
D:/builds/head-test-unpatched-x86_64-pc-cygwin/gcc/testsuite/gfortran2/sync_3.exe: 
error while loading shared libraries: cyggfortran-4.dll: cannot open 
shared object file: No such file or directory
PASS: gfortran.dg/coarray/sync_3.f90 -fcoarray=lib  -O2 -lcaf_single  
execution test
FAIL: gfortran.dg/coarray/sync_3.f90 -fcoarray=lib  -O2 -lcaf_single  
output pattern test, is 
D:/builds/head-test-unpatched-x86_64-pc-cygwin/gcc/testsuite/gfortran2/sync_3.exe: 
error while loading shared libraries: cyggfortran-4.dll: cannot open 
shared object file: No such file or directory
, should match Fortran runtime error: Invalid image number -1 in SYNC IMAGES


Also, this is how I have configured gcc:

/c/Users/daniel/proj/sys/gcc/work0/configure --host=x86_64-pc-cygwin 
--build=x86_64-pc-cygwin --target=x86_64-pc-cygwin 
--prefix=/home/daniel/local/gcc-head-test-unpatched-x86_64-pc-cygwin 
--enable-stage1-checking=yes,rtl --enable-lto --enable-gold=yes 
--enable-bootstrap --with-system-zlib


Thanks,
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

Re: Strange errors running gcc tests on Cygwin

[Tim Prince via cygwin]

On 3/4/2017 12:48 AM, Daniel Santos wrote:
> Hello. I'm trying to validate a gcc patchset that affects msabi
> functions, so I need good test results on Cygwin, but my unpatched
> tests are getting hundreds of failures for which I cannot determine
> the cause. I'm running Cygwin 64 bit on Windows 7 in a qemu vm (with
> kvm).  My sources are on a C: drive (gcc's HEAD a from a few days
> ago), but I didn't make that device large enough, so I had to add a
> second device on D for the builds.  I have cygdrive set to /  (in
> /etc/fstab, I have "none            /       cygdrive
> binary,posix=0,user 0 0"), but the file names it's printing is using
> the D: format instead of /d.  Example:
>
> FAIL: gfortran.dg/coarray/sync_3.f90 -fcoarray=single  -O2   output
> pattern test, is
> D:/builds/head-test-unpatched-x86_64-pc-cygwin/gcc/testsuite/gfortran2/sync_3.exe:
> error while loading shared libraries: cyggfortran-4.dll: cannot open
> shared object file: No such file or directory
>
> That might not actually be the problem. I do NOT have fortran
> installed.  I have run a successful "make bootstrap" so the build tree
> should have the correct Fortran libs.  The file "cyggfortran-4.dll"
> does exist at the location
> /d/builds/head-test-unpatched-x86_64-pc-cygwin/x86_64-pc-cygwin/libgfortran/.libs/cyggfortran-4.dll.
> The even stranger part is that these errors aren't in the build from
> my patched sources.  Maybe something changed in my environment?  I ran
> my patched tests firsts, which resulted in much fewer failures and I
> haven't re-run them yet to see if it's failing now or not. Any ideas?
> ....
> Also, this is how I have configured gcc:
>
> /c/Users/daniel/proj/sys/gcc/work0/configure --host=x86_64-pc-cygwin
> --build=x86_64-pc-cygwin --target=x86_64-pc-cygwin
> --prefix=/home/daniel/local/gcc-head-test-unpatched-x86_64-pc-cygwin
> --enable-stage1-checking=yes,rtl --enable-lto --enable-gold=yes
> --enable-bootstrap --with-system-zlib
>
>
In order to test gfortran 7.1 without installing, you will need to copy
cyggfortran-4.dll into a folder which is on LD_LIBRARY_PATH.  make check
uses only the dll paths associated with the active gcc (presumably your
bootstrap compiler).  Why not compare your configure and test results
against gcc test results posts?

-- 
Tim Prince


--
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

Re: Strange errors running gcc tests on Cygwin

[Daniel Santos]

HAH! Well I hadn't actually subscribed to the mailing list and decided 
to check the archive to see if anybody replied only to the list. (I'm 
subscribed now)

 > In order to test gfortran 7.1 without installing, you will need to copy
 > cyggfortran-4.dll into a folder which is on LD_LIBRARY_PATH. make check
 > uses only the dll paths associated with the active gcc (presumably your
 > bootstrap compiler).

There should be no reason to have to install gfortran.  The gcc 
documentation (https://gcc.gnu.org/install/prerequisites.html) states 
the compiler requirements to be a working ISO C++98 compiler and makes 
no mention of the need for an existing Fortran compiler or libraries.  
This has all been built in the bootstrap.

$ ll $(pwd)/x86_64-pc-cygwin/libgfortran/.libs/cyggfortran-4.dll
-rwxrwxr-x+ 1 daniel None 9124325 Mar  3 19:15 
/d/builds/head-test-unpatched-x86_64-pc-cygwin/x86_64-pc-cygwin/libgfortran/.libs/cyggfortran-4.dll*


 > Why not compare your configure and test results
 > against gcc test results posts?

Well, that's the silly thing; when I ran all of this on my patched code, 
I did not get these errors.   I'm planning on re-running them kind-of in 
hopes that I *will* get these errors so that my compare will be clean, 
but to me this is still not good. make check should NEVER be using any 
native compilers or gcc libraries because that would entirely defeat the 
purpose of doing the tests. I would like to understand what it causing 
this.  Perhaps it is some type of regression?  Note that it claims to be 
setting the LD_LIBRARY_PATH with this directory as the second element:


Setting LD_LIBRARY_PATH to 
.:/d/builds/head-test-unpatched-x86_64-pc-cygwin/x86_64-pc-cygwin/./libgfortran/.libs:/d/builds/head-test-unpatched-x86_64-pc-cygwin/x86_64-pc-cygwin/./libquadmath/.libs:/d/builds/head-test-unpatched-x86_64-pc-cygwin/gcc:.:/d/builds/head-test-unpatched-x86_64-pc-cygwin/x86_64-pc-cygwin/./libgfortran/.libs:/d/builds/head-test-unpatched-x86_64-pc-cygwin/x86_64-pc-cygwin/./libquadmath/.libs:/d/builds/head-test-unpatched-x86_64-pc-cygwin/gcc
spawn [open ...]
D:/builds/head-test-unpatched-x86_64-pc-cygwin/gcc/testsuite/gfortran2/sync_3.exe: 
error while loading shared libraries: cyggfortran-4.dll: cannot open 
shared object file: No such file or directory


This further implies that, if it is looking in the local environment for 
a library and not the build tree, then *all* test results could be 
invalid due to it using compilers and libraries locally installed rather 
than from the build tree, which would be very bad -- a regression that 
hides other regressions!

As much as I just want to get my own tests done, I suppose I better 
debug this. *sigh*

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

Re: Strange errors running gcc tests on Cygwin

[JonY]

[-- Attachment #1.1: Type: text/plain, Size: 2170 bytes --]

On 03/05/2017 02:52 AM, Daniel Santos wrote:
> Well, that's the silly thing; when I ran all of this on my patched code,
> I did not get these errors.   I'm planning on re-running them kind-of in
> hopes that I *will* get these errors so that my compare will be clean,
> but to me this is still not good. make check should NEVER be using any
> native compilers or gcc libraries because that would entirely defeat the
> purpose of doing the tests. I would like to understand what it causing
> this.  Perhaps it is some type of regression?  Note that it claims to be
> setting the LD_LIBRARY_PATH with this directory as the second element:
> 
> 
> Setting LD_LIBRARY_PATH to
> .:/d/builds/head-test-unpatched-x86_64-pc-cygwin/x86_64-pc-cygwin/./libgfortran/.libs:/d/builds/head-test-unpatched-x86_64-pc-cygwin/x86_64-pc-cygwin/./libquadmath/.libs:/d/builds/head-test-unpatched-x86_64-pc-cygwin/gcc:.:/d/builds/head-test-unpatched-x86_64-pc-cygwin/x86_64-pc-cygwin/./libgfortran/.libs:/d/builds/head-test-unpatched-x86_64-pc-cygwin/x86_64-pc-cygwin/./libquadmath/.libs:/d/builds/head-test-unpatched-x86_64-pc-cygwin/gcc
> 
> spawn [open ...]
> D:/builds/head-test-unpatched-x86_64-pc-cygwin/gcc/testsuite/gfortran2/sync_3.exe:
> error while loading shared libraries: cyggfortran-4.dll: cannot open
> shared object file: No such file or directory
> 

Cygwin does NOT use LD_LIBRARY_PATH, Cygwin uses PATH like all Windows
programs. It is one aspect that does not conform to *nix expectations.

Running tests under Cygwin is also complicated by the condition all DLLs
do not get rebased at runtime, or a fork() can fail.

> 
> This further implies that, if it is looking in the local environment for
> a library and not the build tree, then *all* test results could be
> invalid due to it using compilers and libraries locally installed rather
> than from the build tree, which would be very bad -- a regression that
> hides other regressions!
> 
> As much as I just want to get my own tests done, I suppose I better
> debug this. *sigh*
> 
> Daniel
> 
> 

I suppose you can try to run s/LD_LIBRARY_PATH/PATH/g to see how it goes.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 858 bytes --]

Re: Strange errors running gcc tests on Cygwin

[Daniel Santos]

On 03/04/2017 09:46 PM, JonY wrote:

> Cygwin does NOT use LD_LIBRARY_PATH, Cygwin uses PATH like all Windows
> programs. It is one aspect that does not conform to *nix expectations.

Wonderful, this simplifies it greatly!  I was wondering why the dlls 
were under /usr/bin. :)  Anyway, I'm waiting for the gcc bugzilla 
database to come back up and I'll file the bug.

> Running tests under Cygwin is also complicated by the condition all DLLs
> do not get rebased at runtime, or a fork() can fail.
>
>> This further implies that, if it is looking in the local environment for
>> a library and not the build tree, then *all* test results could be
>> invalid due to it using compilers and libraries locally installed rather
>> than from the build tree, which would be very bad -- a regression that
>> hides other regressions!
>>
>> As much as I just want to get my own tests done, I suppose I better
>> debug this. *sigh*
>>
>> Daniel
>>
>>
> I suppose you can try to run s/LD_LIBRARY_PATH/PATH/g to see how it goes.

Well since I've gone this far I might as well come up with a patch for 
the problem as well.  Luckily, I somehow made a mistake about the 
problem *not* happening on my first run of tests because I double 
checked and it did!  I guess the compare_tests script isn't perfect.  
Also, I should make certain that this doesn't affect other tests (for 
instance, we need to be certain that we're loading the correct libgcc).

Thanks for the help!
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

Re: Strange errors running gcc tests on Cygwin

[Daniel Santos]

Seeing how this means that gcc testsuite results are useless for 
exposing regressions in gcc libraries, I've opened a gcc bug report.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79867

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

Re: Strange errors running gcc tests on Cygwin

[Daniel Santos]

Is this a documentation error then? (from 
https://cygwin.com/cygwin-ug-net/setup-env.html)

     The LD_LIBRARY_PATH environment variable is used by the Cygwin function
     dlopen () as a list of directories to search for .dll files to 
load. This
     environment variable is converted from Windows format to UNIX 
format when a
     Cygwin process first starts. Most Cygwin applications do not make 
use of
     the dlopen () call and do not need this variable.

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

Re: Strange errors running gcc tests on Cygwin

[David Billinghurst]

On 5/03/2017 18:36, Daniel Santos wrote:

> Is this a documentation error then? (from 
> https://cygwin.com/cygwin-ug-net/setup-env.html)
>
>     The LD_LIBRARY_PATH environment variable is used by the Cygwin 
> function
>     dlopen () as a list of directories to search for .dll files to 
> load. This
>     environment variable is converted from Windows format to UNIX 
> format when a
>     Cygwin process first starts. Most Cygwin applications do not make 
> use of
>     the dlopen () call and do not need this variable.

No.

LD_LIBRARY_PATH is used by dlopen ().

PATH is one of the locations searched by Windows when starting 
applications, see https://msdn.microsoft.com/en-us/library/7d83bc18.aspx

--
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

Re: Strange errors running gcc tests on Cygwin

[Daniel Santos]

On 03/05/2017 05:08 AM, David Billinghurst wrote:
> No.
>
> LD_LIBRARY_PATH is used by dlopen ().
>
> PATH is one of the locations searched by Windows when starting 
> applications, see https://msdn.microsoft.com/en-us/library/7d83bc18.aspx

Thank you for this clarification.  So load-time dlls are resolved (in 
ntdll.exe or some such) using PATH and run-time dlls loaded with 
dlopen() are resolved with LD_LIBRARY_PATH?  I'm obviously not intimate 
with Cygwin's architecture, but I'm guessing that explicitly using 
LoadLibrary is still going to use PATH.

So it seems that libgcc on Cygwin is called cyggcc_s-seh-1.dll on lives 
in /usr/bin.  This makes the gcc test harness's attempt to switch 
between host and target compilers problematic because we can't remove 
/usr/bin from the PATH.  We can can prepend the built-tree's path, but 
it's still a bit unsettling that, if something goes wrong with the 
build-tree, we can still end up loading the installed libgcc instead of 
failing.  Still, it will be better than the current situation.

Thank you for your help with this.

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

Re: Strange errors running gcc tests on Cygwin

[cyg Simple]

On 3/6/2017 9:03 PM, Daniel Santos wrote:
> On 03/05/2017 05:08 AM, David Billinghurst wrote:
>> No.
>>
>> LD_LIBRARY_PATH is used by dlopen ().
>>
>> PATH is one of the locations searched by Windows when starting
>> applications, see https://msdn.microsoft.com/en-us/library/7d83bc18.aspx
> 
> Thank you for this clarification.  So load-time dlls are resolved (in
> ntdll.exe or some such) using PATH and run-time dlls loaded with
> dlopen() are resolved with LD_LIBRARY_PATH?  I'm obviously not intimate
> with Cygwin's architecture, but I'm guessing that explicitly using
> LoadLibrary is still going to use PATH.

You're obviously not intimate with Windows either.  The search algorithm
in Windows is more involved than PATH.  You need to study more.

-- 
cyg Simple

--
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

Re: Strange errors running gcc tests on Cygwin

[Daniel Santos]

On 03/07/2017 07:58 AM, cyg Simple wrote:
> On 3/6/2017 9:03 PM, Daniel Santos wrote:
>> On 03/05/2017 05:08 AM, David Billinghurst wrote:
>>> No.
>>>
>>> LD_LIBRARY_PATH is used by dlopen ().
>>>
>>> PATH is one of the locations searched by Windows when starting
>>> applications, see https://msdn.microsoft.com/en-us/library/7d83bc18.aspx
>> Thank you for this clarification.  So load-time dlls are resolved (in
>> ntdll.exe or some such) using PATH and run-time dlls loaded with
>> dlopen() are resolved with LD_LIBRARY_PATH?  I'm obviously not intimate
>> with Cygwin's architecture, but I'm guessing that explicitly using
>> LoadLibrary is still going to use PATH.
> You're obviously not intimate with Windows either.  The search algorithm
> in Windows is more involved than PATH.  You need to study more.
>
My concern is with the dynamic portion of this behavior -- what is 
affected by environment variables.

--
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

Re: Strange errors running gcc tests on Cygwin

[David Billinghurst]

On 8/03/2017 10:25, Daniel Santos wrote:

> My concern is with the dynamic portion of this behavior -- what is 
> affected by environment variables.

Many years ago I ran a nightly build/test of gcc under cygwin and 
reported the results to gcc-testresults.  There may be is discussion on 
the gcc mailing lists from c2000-2005.  If you search "site:gcc.gnu.org 
David Billinghurst cygwin" you ??might?? find something relevant.

 From memory, I got it all working by

  * building gcc and friends
  * using find to locate all the .exe and .dll files in the build tree
  * worked out by trial and error which files were needed at run time by
    the test suite.
  * setting PATH when running the testsuite so that the directories
    containing (new) required .exe and .dll were in front of any system
    directories
  * making sure that PATH wasn't reset by the testsuite
  * looking at places where LD_LIBRARY_PATH was set/modified by the
    testsuite and checking if cygwin needed PATH to match
  * (submitting patched to fix gcc testsuite under cygwin)

Once that was done it all "just worked" until it broke again. Good luck.





--
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

Re: Strange errors running gcc tests on Cygwin

[Daniel Santos]

On 03/07/2017 06:36 PM, David Billinghurst wrote:
> On 8/03/2017 10:25, Daniel Santos wrote:
>
>> My concern is with the dynamic portion of this behavior -- what is 
>> affected by environment variables.
>
> Many years ago I ran a nightly build/test of gcc under cygwin and 
> reported the results to gcc-testresults.  There may be is discussion 
> on the gcc mailing lists from c2000-2005.  If you search 
> "site:gcc.gnu.org David Billinghurst cygwin" you ??might?? find 
> something relevant.
>
> From memory, I got it all working by
>
>  * building gcc and friends
>  * using find to locate all the .exe and .dll files in the build tree
>  * worked out by trial and error which files were needed at run time by
>    the test suite.
>  * setting PATH when running the testsuite so that the directories
>    containing (new) required .exe and .dll were in front of any system
>    directories
>  * making sure that PATH wasn't reset by the testsuite
>  * looking at places where LD_LIBRARY_PATH was set/modified by the
>    testsuite and checking if cygwin needed PATH to match
>  * (submitting patched to fix gcc testsuite under cygwin)
>
> Once that was done it all "just worked" until it broke again. Good luck.
>

Thank you very much for this. This is the path that I was kind-of 
setting off on, I just wanted to try one more time to run the tests 
as-is, this time with only one make job and see if I could get the mass 
of failures to match so that I could say that my patches cause "no 
additional errors" (ignoring the fact that there's 16k total failures), 
but I can't even get the breakages to match up.  (This is another topic, 
when I run tests in parallel I eventually end up with some "broken pipe" 
errors and that make job hangs).

I found some of your patches, pity it got re-broken.  I have a bug open 
for this here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79867.  In 
the end, I think that this should be fixed by adding some new "black 
box" interfaces to DejaGnu that manage the executable and library search 
paths.  Then gcc's testsuite should deprecate ANY direct access to any 
of the *PATH environment variables in favor of this new interface in 
DejaGnu.  As it is, the gcc code already changes both LD_LIBRARY_PATH 
and SHLIB_PATH to support HP-UX (not sure if any other systems use the 
latter), so it's already gotten a little hairy.

In order to facilitate this cleanly, I think that libgcc needs to be 
moved out of /usr/bin and into /usr/lib/gcc/<triplet>/<version>/ and 
then have that added to the PATH and LD_LIBRARY_PATH somewhere 
(autoexec.bat? registry? I have no idea).  Having an /sbin/ldconfig 
would be the most ideal mechanism of managing this. (Anybody want a 
little project? :)  The test harness regularly toggles in between the 
host and target compiler.

We need a clean and reproducible set of steps for running tests on 
Cygwin.  Somewhere, these tests should be run regularly, maybe on a 
server/compiler farm somewhere under a VM, so that breakages can be 
addressed as soon as they appear rather than when somebody wants to 
touch the ms_abi code and has to test on Cygwin -- how I ended up here. :)

Thanks again for the help!
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

Re: Strange errors running gcc tests on Cygwin

[Brian Inglis]

On 2017-03-07 22:18, Daniel Santos wrote:
> On 03/07/2017 06:36 PM, David Billinghurst wrote:
>> On 8/03/2017 10:25, Daniel Santos wrote:
>>> My concern is with the dynamic portion of this behavior -- what
>>> is affected by environment variables.
>> Many years ago I ran a nightly build/test of gcc under cygwin and
>> reported the results to gcc-testresults. There may be is discussion
>> on the gcc mailing lists from c2000-2005. If you search
>> "site:gcc.gnu.org David Billinghurst cygwin" you ??might?? find
>> something relevant.
>> From memory, I got it all working by
>>  * building gcc and friends
>>  * using find to locate all the .exe and .dll files in the build
>>    tree
>>  * worked out by trial and error which files were needed at run time
>>    by the test suite.
>>  * setting PATH when running the testsuite so that the directories 
>>    containing (new) required .exe and .dll were in front of any
>>    system directories
>>  * making sure that PATH wasn't reset by the testsuite
>>  * looking at places where LD_LIBRARY_PATH was set/modified by the 
>>    testsuite and checking if cygwin needed PATH to match
>>  * (submitting patched to fix gcc testsuite under cygwin)
>> Once that was done it all "just worked" until it broke again. Good
>> luck.
> Thank you very much for this. This is the path that I was kind-of
> setting off on, I just wanted to try one more time to run the tests
> as-is, this time with only one make job and see if I could get the
> mass of failures to match so that I could say that my patches cause
> "no additional errors" (ignoring the fact that there's 16k total
> failures), but I can't even get the breakages to match up. (This is
> another topic, when I run tests in parallel I eventually end up with
> some "broken pipe" errors and that make job hangs).
> I found some of your patches, pity it got re-broken. I have a bug
> open for this here:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79867. In the end, I
> think that this should be fixed by adding some new "black box"
> interfaces to DejaGnu that manage the executable and library search
> paths. Then gcc's testsuite should deprecate ANY direct access to any
> of the *PATH environment variables in favor of this new interface in
> DejaGnu. As it is, the gcc code already changes both LD_LIBRARY_PATH
> and SHLIB_PATH to support HP-UX (not sure if any other systems use
> the latter), so it's already gotten a little hairy.
> In order to facilitate this cleanly, I think that libgcc needs to be
> moved out of /usr/bin and into /usr/lib/gcc/<triplet>/<version>/ and
> then have that added to the PATH and LD_LIBRARY_PATH somewhere
> (autoexec.bat? registry? I have no idea). Having an /sbin/ldconfig
> would be the most ideal mechanism of managing this. (Anybody want a
> little project? :) The test harness regularly toggles in between the
> host and target compiler.
> We need a clean and reproducible set of steps for running tests on
> Cygwin. Somewhere, these tests should be run regularly, maybe on a
> server/compiler farm somewhere under a VM, so that breakages can be
> addressed as soon as they appear rather than when somebody wants to
> touch the ms_abi code and has to test on Cygwin -- how I ended up
> here. :)

After any Windows Update, or a lot of package installs, you may want 
look at running
	rebase-trigger full[rebase] 
before rebooting to remove all Cygwin and Windows processes, then 
(with no Cygwin services or processes running) run Cygwin 
setup-x86{,_64} to rebase everything and maximize memory available 
to Cygwin processes.
This could be critical if you are doing any builds under Cygwin 32 
and have a lot of packages and/or large exes/dlls installed.

If you are running a lot of Cygwin services, cron or Scheduled Tasks, 
and/or background processes, you may want to look at running cygserver 
to cache process info and common system info (including SAM/AD).
Setup cygserver initially by running cygserver-config with 
elevated/admin rights, and start it at system startup by running 
cygrunsrv with elevated/admin rights.
If you ever expect to be running more than 62 simultaneous Cygwin 
processes on a system, bump kern.srv.process_cache_size in 
/etc/cygserver.conf created by cygserver-config to one of the higher 
values recommended in the man page.
I found this seemed to reduce process startup overhead and eliminated 
random broken pipes, hung, and failed processes due to a lot of shell 
forking.

Preallocate contiguous paging space at double RAM to reduce the chance 
that any set of Windows processes will reduce Windows free memory too 
low for an instant, and cause something to hang or fail, by giving 
Windows somewhere to page out a lot of LRU pages from inactive 
processes.
I found that if Windows (at least up to W7) free memory ever got too 
low, especially when all processors are pegged, it seemed unable to 
dynamically allocate and use more paging space to alleviate the 
crunch.
The situation may have improved on Windows 10, but I've already 
allocated the paging space, and uninstalled some (probably buggy) 
hogs that seemed to only ever allocate memory and never free any.

YMMV

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
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

Re: Strange errors running gcc tests on Cygwin

[Daniel Santos]

First of all, thank you for your response!

On 03/08/2017 02:21 AM, Brian Inglis wrote:
> After any Windows Update, or a lot of package installs, you may want
> look at running
> 	rebase-trigger full[rebase]
> before rebooting to remove all Cygwin and Windows processes, then
> (with no Cygwin services or processes running) run Cygwin
> setup-x86{,_64} to rebase everything and maximize memory available
> to Cygwin processes.

So does rebase organize the Cygwin dlls and reassign them all new base 
loading addresses?  So far I've only done the 64-bit tests using Cygwin. 
I haven't even gotten to 64-bit mingw or 32 bit. Also, I have *not* done 
a Windows Update since I have installed. Could this be an OS issue that 
was addressed in some patch?  I'm running Windows 7 Ultimate SP1.

> This could be critical if you are doing any builds under Cygwin 32
> and have a lot of packages and/or large exes/dlls installed.
>
> If you are running a lot of Cygwin services, cron or Scheduled Tasks,
> and/or background processes, you may want to look at running cygserver
> to cache process info and common system info (including SAM/AD).

I'm only running sshd -- no cron or "at" jobs (except whatever Windows 
installs by its self).  However, gcc's make check spawns a LOT of processes.

> Setup cygserver initially by running cygserver-config with
> elevated/admin rights, and start it at system startup by running
> cygrunsrv with elevated/admin rights.
> If you ever expect to be running more than 62 simultaneous Cygwin
> processes on a system, bump kern.srv.process_cache_size in
> /etc/cygserver.conf created by cygserver-config to one of the higher
> values recommended in the man page.
> I found this seemed to reduce process startup overhead and eliminated
> random broken pipes, hung, and failed processes due to a lot of shell
> forking.
I didn't know about cygserver, so I tried it out and set the 
kern.srv.process_cache_size to 256.  I ran a make -kj4 check and had 
broken pipes within a few short minutes.  I tried it again running make 
-k check, but on two directories at once and got broken pipes somewhere 
along the way (before they completed).  So I should probably try it with 
only a single make running at once.

Even with just the two instances of make (with one job each), there are 
many processes of bash, make, expect, etc.  That's just one of the 
challenges of a Cygwin venture -- Windows was never designed for light 
process creation (or thread creation for that matter).  A lot of the 
*nix software concepts are hinged upon that lightweight, copy-on-write 
fork, whereas Windows-based concepts seem to be centered more around 
pre-spawning and maintaining thread pools and task-specific services.

> Preallocate contiguous paging space at double RAM to reduce the chance
> that any set of Windows processes will reduce Windows free memory too
> low for an instant, and cause something to hang or fail, by giving
> Windows somewhere to page out a lot of LRU pages from inactive
> processes.

I'm not sure how to go about this.  Should I bring the VM down, mount 
the image with ntfs-g3 and dd if=/dev/zero it or is there another way?  
Also, I don't know what Windows expects to see in a pagefile.  Or maybe 
defrag. I'll look at it.

> I found that if Windows (at least up to W7) free memory ever got too
> low, especially when all processors are pegged, it seemed unable to
> dynamically allocate and use more paging space to alleviate the
> crunch.

 From watching the system monitor, I can see that I never get above 35% 
memory usage.  I've assigned 4GiB of ram to the VM and Windows never 
seems to use more than 280MiB for page cache (I guess that's due to the 
license-specific limitation) -- at least there is abundant caching 
happening at the host level (3-ish GiB).

> The situation may have improved on Windows 10, but I've already
> allocated the paging space, and uninstalled some (probably buggy)
> hogs that seemed to only ever allocate memory and never free any.
>
> YMMV

As far as the dll search path issue, I *think* I have a woorking 
patchset in gcc and DejaGnu to resolve the dll load problems.  (I 
haven't yet done the on-off switch yet, so it's basically hard-coded.  I 
found a Tcl "is_Cygwin" procedure in git-gui that I'm going to borrow 
for now.)  So while my make check is still failing with broken pipes, I 
appear to have resolved the issue with the dll search path.

It would probably help if I can figure out where the broken pipe 
actually occurs and try to get that piece to log more verbosly.  I'm 
guessing it's from expect.  This is the exact error message:

FAIL: gcc.c-torture/execute/20000822-1.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  execution test
parent: sync byte write: broken pipe^M
make[3]: Leaving directory 
'/d/builds/head-test-moutline-x86_64-pc-cygwin/gcc'

Don't worry about the FAILed test.  The main thing is that after each 
broken pipe message, I see make "leaving" that directory, so it doesn't 
finish the rest of the tests in that directory.

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

Re: Strange errors running gcc tests on Cygwin

[Brian Inglis]

On 2017-03-09 15:53, Daniel Santos wrote:
> First of all, thank you for your response!
> 
> On 03/08/2017 02:21 AM, Brian Inglis wrote:
>> After any Windows Update, or a lot of package installs, you may want
>> look at running
>>     rebase-trigger full[rebase]
>> before rebooting to remove all Cygwin and Windows processes, then
>> (with no Cygwin services or processes running) run Cygwin
>> setup-x86{,_64} to rebase everything and maximize memory available
>> to Cygwin processes.
> 
> So does rebase organize the Cygwin dlls and reassign them all new
> base loading addresses? So far I've only done the 64-bit tests using
> Cygwin. I haven't even gotten to 64-bit mingw or 32 bit. Also, I have
> *not* done a Windows Update since I have installed. Could this be an
> OS issue that was addressed in some patch? I'm running Windows 7
> Ultimate SP1.

Windows DLLs updated or added could increase in size and overlap 
Cygwin's assumed address space allocated by rebase.
Mingw has no problem as native Windows programs, but Cygwin emulates 
how Unix uses shared libraries [handwaving simplification], so 
Cygwin 32 has problems with limited 32 bit space available to programs.

>> This could be critical if you are doing any builds under Cygwin 32
>> and have a lot of packages and/or large exes/dlls installed.
>>
>> If you are running a lot of Cygwin services, cron or Scheduled Tasks,
>> and/or background processes, you may want to look at running cygserver
>> to cache process info and common system info (including SAM/AD).
> 
> I'm only running sshd -- no cron or "at" jobs (except whatever
> Windows installs by its self). However, gcc's make check spawns a LOT
> of processes.

Which was why I suggested it.

>> Setup cygserver initially by running cygserver-config with
>> elevated/admin rights, and start it at system startup by running
>> cygrunsrv with elevated/admin rights.
>> If you ever expect to be running more than 62 simultaneous Cygwin
>> processes on a system, bump kern.srv.process_cache_size in
>> /etc/cygserver.conf created by cygserver-config to one of the higher
>> values recommended in the man page.
>> I found this seemed to reduce process startup overhead and eliminated
>> random broken pipes, hung, and failed processes due to a lot of shell
>> forking.
> I didn't know about cygserver, so I tried it out and set the
> kern.srv.process_cache_size to 256. I ran a make -kj4 check and had
> broken pipes within a few short minutes. I tried it again running
> make -k check, but on two directories at once and got broken pipes
> somewhere along the way (before they completed). So I should probably
> try it with only a single make running at once.
> 
> Even with just the two instances of make (with one job each), there
> are many processes of bash, make, expect, etc. That's just one of the
> challenges of a Cygwin venture -- Windows was never designed for
> light process creation (or thread creation for that matter). A lot of
> the *nix software concepts are hinged upon that lightweight,
> copy-on-write fork, whereas Windows-based concepts seem to be
> centered more around pre-spawning and maintaining thread pools and
> task-specific services.

Bump to 310 as optimal max - see man cygserver. 
Should be started before sshd and any other Cygwin processes 
and should be configured to start sshd.
 
>> Preallocate contiguous paging space at double RAM to reduce the chance
>> that any set of Windows processes will reduce Windows free memory too
>> low for an instant, and cause something to hang or fail, by giving
>> Windows somewhere to page out a lot of LRU pages from inactive
>> processes.
> 
> I'm not sure how to go about this. Should I bring the VM down, mount
> the image with ntfs-g3 and dd if=/dev/zero it or is there another
> way? Also, I don't know what Windows expects to see in a pagefile. Or
> maybe defrag. I'll look at it.

<Win-Break> or Control Panel/System/Advanced system settings/
/Advanced tab/Performance [Settings] button/Advanced tab/
/Virtual memory [Change] button/Virtual Memory dialogue box:
[ ] Automatically manage...	uncheck
...
(@) Custom size:		select
Initial size (MB): [ 8192 ]	double RAM
Maximum size (MB): [ 16384 ]	just in case
( ) System managed size		deselect
( ) No paging file		deselect

then select *[Set]* button and reboot if prompted.
You may have to allocate more VM disk space if insufficent.

>> I found that if Windows (at least up to W7) free memory ever got too
>> low, especially when all processors are pegged, it seemed unable to
>> dynamically allocate and use more paging space to alleviate the
>> crunch.
> 
> From watching the system monitor, I can see that I never get above
> 35% memory usage. I've assigned 4GiB of ram to the VM and Windows
> never seems to use more than 280MiB for page cache (I guess that's
> due to the license-specific limitation) -- at least there is abundant
> caching happening at the host level (3-ish GiB).

Start Task Manager/Performance tab/Open Resource Monitor link at bottom/
/Resource Monitor/Memory tab/Physical Memory pane at bottom/
Free should never go much below 100MB and trouble is almost certain 
if you ever hit single digits even for an instant.

>> The situation may have improved on Windows 10, but I've already
>> allocated the paging space, and uninstalled some (probably buggy)
>> hogs that seemed to only ever allocate memory and never free any.

> As far as the dll search path issue, I *think* I have a woorking
> patchset in gcc and DejaGnu to resolve the dll load problems. (I
> haven't yet done the on-off switch yet, so it's basically hard-coded.
> I found a Tcl "is_Cygwin" procedure in git-gui that I'm going to
> borrow for now.) So while my make check is still failing with broken
> pipes, I appear to have resolved the issue with the dll search path.

Ensure that all Cygwin dlls including anything you build are included 
in every rebase, and do an incremental rebase after every build.

> It would probably help if I can figure out where the broken pipe
> actually occurs and try to get that piece to log more verbosly. I'm
> guessing it's from expect. This is the exact error message:
> 
> FAIL: gcc.c-torture/execute/20000822-1.c   -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects  execution test
> parent: sync byte write: broken pipe^M
> make[3]: Leaving directory '/d/builds/head-test-moutline-x86_64-pc-cygwin/gcc'
> 
> Don't worry about the FAILed test. The main thing is that after each
> broken pipe message, I see make "leaving" that directory, so it
> doesn't finish the rest of the tests in that directory.

BTDT PITA

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
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

Re: Strange errors running gcc tests on Cygwin

[Tim Prince via cygwin]

On 3/9/2017 6:51 PM, Brian Inglis wrote:
> On 2017-03-09 15:53, Daniel Santos wrote:
>
>>> If you are running a lot of Cygwin services, cron or Scheduled Tasks,
>>> and/or background processes, you may want to look at running cygserver
>>> to cache process info and common system info (including SAM/AD).
>> I'm only running sshd -- no cron or "at" jobs (except whatever
>> Windows installs by its self). However, gcc's make check spawns a LOT
>> of processes.
> Which was why I suggested it.
Even on linux, I don't find it satisfactory to run make check without
limiting processes to number of cores.  On cygwin and wsl, make check
seems to run into deadlocks or at least disastrous timeouts when running
multiple processes.  With a single process, cygwin runs it more reliably
than wsl does.  Conversely, sometimes (rarely) wsl can run make check-c
and make check-fortran simultaneously.
So it takes typically 2 full days to build and make check on cygwin.

-- 
Tim Prince


--
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

Re: Strange errors running gcc tests on Cygwin

[Achim Gratz]

Brian Inglis writes:
> Ensure that all Cygwin dlls including anything you build are included 
> in every rebase, and do an incremental rebase after every build.

Don't do this, it's not what incremental rebase is for.  I've
specifically implemented the "ephemeral" option to rebase to temporarily
deal with DLL in staging directories without polluting the global rebase
map.  The rebase map is still used if you specify that in order to work
around the address space used by the installation, but the newl rebased
libraries don't get recorded there.  Since that rebase is throw-away you
have to specify all the ephemeral DLL that can potentially collide in
each invocation of rebase.  That's still easier than doing a full rebase
once you're done building.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

--
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

Re: Strange errors running gcc tests on Cygwin

[Brian Inglis]

On 2017-03-10 11:56, Achim Gratz wrote:
> Brian Inglis writes:
>> Ensure that all Cygwin dlls including anything you build are
>> included in every rebase, and do an incremental rebase after every
>> build. 
> Don't do this, it's not what incremental rebase is for. I've 
> specifically implemented the "ephemeral" option to rebase to
> temporarily deal with DLL in staging directories without polluting
> the global rebase map. The rebase map is still used if you specify
> that in order to work around the address space used by the
> installation, but the newl rebased libraries don't get recorded
> there. Since that rebase is throw-away you have to specify all the
> ephemeral DLL that can potentially collide in each invocation of
> rebase. That's still easier than doing a full rebase once you're done
> building.

Has that been released yet or is it implied in options -O --oblivious 
and -T --filelist=FILE as documented in NEWS?

$ uname -srvmo
CYGWIN_NT-10.0 2.7.0(0.306/5/3) 2017-02-12 13:18 x86_64 Cygwin
$ rebase --version
rebase version 4.4.2 (imagehelper version 0.11)

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
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

Re: Strange errors running gcc tests on Cygwin

[Achim Gratz]

Brian Inglis writes:
> Has that been released yet or is it implied in options -O --oblivious 
> and -T --filelist=FILE as documented in NEWS?

Yes, -O is the option I was talking about (it now also implies -s, so
you don't need explicitly say that).  The typical use would be with -T
as you say, maybe feeding in the list of files from a pipe:

find … | rebase -OT -


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables

--
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

Re: Strange errors running gcc tests on Cygwin

[Daniel Santos]

On 03/10/2017 12:56 PM, Achim Gratz wrote:
> Brian Inglis writes:
>> Ensure that all Cygwin dlls including anything you build are included
>> in every rebase, and do an incremental rebase after every build.
> Don't do this, it's not what incremental rebase is for.  I've
> specifically implemented the "ephemeral" option to rebase to temporarily
> deal with DLL in staging directories without polluting the global rebase
> map.  The rebase map is still used if you specify that in order to work
> around the address space used by the installation, but the newl rebased
> libraries don't get recorded there.  Since that rebase is throw-away you
> have to specify all the ephemeral DLL that can potentially collide in
> each invocation of rebase.  That's still easier than doing a full rebase
> once you're done building.

Well this is interesting.  What happens if there is a collision? Will a 
detailed error message exist anywhere (syslogs, NT's event log, etc.)?

So when I run gcc's bootstrap, I'm building dlls that sit (temporarily) 
in the build directory.  If I do not explicitly rebase these, can I end 
up with collisions if I try to use them?

Thanks,
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

Re: Strange errors running gcc tests on Cygwin

[Marco Atzeri]

On 13/03/2017 17:39, Daniel Santos wrote:
> On 03/10/2017 12:56 PM, Achim Gratz wrote:
>> Brian Inglis writes:
>>> Ensure that all Cygwin dlls including anything you build are included
>>> in every rebase, and do an incremental rebase after every build.
>> Don't do this, it's not what incremental rebase is for.  I've
>> specifically implemented the "ephemeral" option to rebase to temporarily
>> deal with DLL in staging directories without polluting the global rebase
>> map.  The rebase map is still used if you specify that in order to work
>> around the address space used by the installation, but the newl rebased
>> libraries don't get recorded there.  Since that rebase is throw-away you
>> have to specify all the ephemeral DLL that can potentially collide in
>> each invocation of rebase.  That's still easier than doing a full rebase
>> once you're done building.
>
> Well this is interesting.  What happens if there is a collision? Will a
> detailed error message exist anywhere (syslogs, NT's event log, etc.)?
>
> So when I run gcc's bootstrap, I'm building dlls that sit (temporarily)
> in the build directory.  If I do not explicitly rebase these, can I end
> up with collisions if I try to use them?

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

> Thanks,
> Daniel

Regards
Marco

--
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

Re: Strange errors running gcc tests on Cygwin

[Daniel Santos]

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

Re: Strange errors running gcc tests on Cygwin

[Brian Inglis]

On 2017-03-15 10:54, Daniel Santos wrote:
> 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.

I've seen "won't happen" take from 6 minutes to 6 months *after* going 
into production while passing good, long QA tests ;^>

>> 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.

Do the local rebase on your build targets as detailed in my question 
to Achim and his response. Rerun after any system change or build.

> 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!

Have you checked the Cygwin BLODA list, uninstalled everything you can, 
disabled all services you're not using, and stopped packages from 
putting "accelerators" in the systray? There are some good web pages 
on disabling services useless to you but not MS ;^> I did this before 
and after W10 upgrades and life is quieter and more productive. YMMV

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
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

Re: Strange errors running gcc tests on Cygwin

[Daniel Santos]

On 03/15/2017 02:36 PM, Brian Inglis wrote:
> Do the local rebase on your build targets as detailed in my question
> to Achim and his response. Rerun after any system change or build.

Alright, I think I've got it now, thank you.  I'll experiment with it 
first and then I'm guessing that this might eventually belong in libtool 
or some such, although I'm guessing that that wouldn't work unless we 
could have two databases, the system database and a temporary build 
database.  I'm not yet sure what the correct solution should be.

>> 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!
> Have you checked the Cygwin BLODA list, uninstalled everything you can,
> disabled all services you're not using, and stopped packages from
> putting "accelerators" in the systray?

Thank you for the BLODA list.  There are currently no programs listed in 
the uninstall.

> There are some good web pages
> on disabling services useless to you but not MS ;^> I did this before
> and after W10 upgrades and life is quieter and more productive. YMMV

The first thing I've done when installing Windows in the past is to have 
the network cable unplugged and disable every service that I think I 
don't need because experience has taught me not to trust Windows.  
Occasionally, I've had to re-enable services that it turned out I did 
need.  Are there any pretty list of "stupid windows services" out there 
that you recommend?  Also, I'm not doing any windows/lanman networking, 
so I disable computer browser and the like.

I'm also building the current cygwin1.dll from git as I've seen a few 
messages about bugs being fixed that could be related.

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

Re: Strange errors running gcc tests on Cygwin

[Brian Inglis]

On 2017-03-16 14:59, Daniel Santos wrote:
> On 03/15/2017 02:36 PM, Brian Inglis wrote:
>> Do the local rebase on your build targets as detailed in my question
>> to Achim and his response. Rerun after any system change or build.
> 
> Alright, I think I've got it now, thank you. I'll experiment with it
> first and then I'm guessing that this might eventually belong in
> libtool or some such, although I'm guessing that that wouldn't work
> unless we could have two databases, the system database and a
> temporary build database. I'm not yet sure what the correct solution
> should be.

rebase -OT file - contains list of paths to all built DLLs - uses the 
existing database to relocate your DLLs above existing Cygwin uses.

>>> 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!
>> Have you checked the Cygwin BLODA list, uninstalled everything you can,
>> disabled all services you're not using, and stopped packages from
>> putting "accelerators" in the systray?
> 
> Thank you for the BLODA list. There are currently no programs listed
> in the uninstall.

You may not be installing much with Windows Setup but may want to ensure 
you uninstall any stuff like Adobe Flash, Adobe Reader, Oracle Java, 
MS Silverlight, games, other "conveniences", "freebies", utilities, etc. 
pushed on you. You may be able to uninstall MS SQL Server, its CLR, SSDT
but don't know impact. You have to keep MS.NET, PowerShell if installed 
as they may be used by MS processes.

>> There are some good web pages
>> on disabling services useless to you but not MS ;^> I did this before
>> and after W10 upgrades and life is quieter and more productive. YMMV
> 
> The first thing I've done when installing Windows in the past is to
> have the network cable unplugged and disable every service that I
> think I don't need because experience has taught me not to trust
> Windows. Occasionally, I've had to re-enable services that it turned
> out I did need. Are there any pretty list of "stupid windows
> services" out there that you recommend? Also, I'm not doing any
> windows/lanman networking, so I disable computer browser and the
> like.

https://blog.brankovucinec.com/2016/07/12/powershell-reclaim-windows-10/
and linked github forks I found informative and useful - key to customize 
as YMMV.

> I'm also building the current cygwin1.dll from git as I've seen a few
> messages about bugs being fixed that could be related.

You can download Cygwin snapshots: dll only, dbg, pkg, src, directly from 
https://cygwin.com/snapshots for x86{_64,} - instructions given on page.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
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

Re: Strange errors running gcc tests on Cygwin

[Daniel Santos]

On 03/17/2017 12:17 AM, Brian Inglis wrote:
> On 2017-03-16 14:59, Daniel Santos wrote:
>
>> Alright, I think I've got it now, thank you. I'll experiment with it
>> first and then I'm guessing that this might eventually belong in
>> libtool or some such, although I'm guessing that that wouldn't work
>> unless we could have two databases, the system database and a
>> temporary build database. I'm not yet sure what the correct solution
>> should be.
> rebase -OT file - contains list of paths to all built DLLs - uses the
> existing database to relocate your DLLs above existing Cygwin uses.

Yes, but that won't work from libtool.  libtool isn't going to know what 
other dlls you happen to be building in your project.  (I don't actually 
know libtools internals yet, and never really wanted to. :)  So this 
might need to be some ugly add-on to the Makefile *sigh*.

>> Thank you for the BLODA list. There are currently no programs listed
>> in the uninstall.
> You may not be installing much with Windows Setup but may want to ensure
> you uninstall any stuff like Adobe Flash, Adobe Reader, Oracle Java,
> MS Silverlight, games, other "conveniences", "freebies", utilities, etc.
> pushed on you. You may be able to uninstall MS SQL Server, its CLR, SSDT
> but don't know impact. You have to keep MS.NET, PowerShell if installed
> as they may be used by MS processes.

OMG! It puts SQL Server on there now?  Thanks for the info, I forgot 
about all of this crap.

>> The first thing I've done when installing Windows in the past is to
>> have the network cable unplugged and disable every service that I
>> think I don't need because experience has taught me not to trust
>> Windows. Occasionally, I've had to re-enable services that it turned
>> out I did need. Are there any pretty list of "stupid windows
>> services" out there that you recommend? Also, I'm not doing any
>> windows/lanman networking, so I disable computer browser and the
>> like.
> https://blog.brankovucinec.com/2016/07/12/powershell-reclaim-windows-10/
> and linked github forks I found informative and useful - key to customize
> as YMMV.

Ok, thanks. I have a license for Windows 7 and while I know that Windows 
10 is "free" I'm just not ready for that step.  I will probably have to 
eventually setup a win10 vm though.

>> I'm also building the current cygwin1.dll from git as I've seen a few
>> messages about bugs being fixed that could be related.
> You can download Cygwin snapshots: dll only, dbg, pkg, src, directly from
> https://cygwin.com/snapshots for x86{_64,} - instructions given on page.

Yeah, I usually prefer to build it myself.  I did test the git 
cygwin1.dll and it didn't fix the broken pipes (when running make check 
with more than one -j job).  As I've said before, I'm sure there's a 
race somewhere in Cygwin or some other Cygwin package(s). If I follow 
through with making this into a repeatable process, I'll likely have to 
try to diagnose it.

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

Re: Strange errors running gcc tests on Cygwin

[cyg Simple]

On 3/18/2017 9:52 AM, Daniel Santos wrote:
> 
> Ok, thanks. I have a license for Windows 7 and while I know that Windows
> 10 is "free" I'm just not ready for that step.  I will probably have to
> eventually setup a win10 vm though.
> 

For me moving from Win7 to Win10 was no big deal other than the time for
the updates but that occurred in the background. However, if you're like
me I prefer not to be working during such updates.

>>> I'm also building the current cygwin1.dll from git as I've seen a few
>>> messages about bugs being fixed that could be related.
>> You can download Cygwin snapshots: dll only, dbg, pkg, src, directly from
>> https://cygwin.com/snapshots for x86{_64,} - instructions given on page.
> 
> Yeah, I usually prefer to build it myself.  I did test the git
> cygwin1.dll and it didn't fix the broken pipes (when running make check
> with more than one -j job).  As I've said before, I'm sure there's a
> race somewhere in Cygwin or some other Cygwin package(s). If I follow
> through with making this into a repeatable process, I'll likely have to
> try to diagnose it.

Glad to hear you're working to improve Cygwin.

-- 
cyg Simple

--
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

Re: Strange errors running gcc tests on Cygwin

[Daniel Santos]

Thanks for the help Brian.

On 03/09/2017 05:51 PM, Brian Inglis wrote:
> Windows DLLs updated or added could increase in size and overlap
> Cygwin's assumed address space allocated by rebase.
> Mingw has no problem as native Windows programs, but Cygwin emulates
> how Unix uses shared libraries [handwaving simplification], so
> Cygwin 32 has problems with limited 32 bit space available to programs.

Well, I tried it anyway and there was no change.

> Bump to 310 as optimal max - see man cygserver.
> Should be started before sshd and any other Cygwin processes
> and should be configured to start sshd.

Ah! Well I didn't have sshd set as depending upon cygserver (I do not).  
There was no change in the outcome however.

> <Win-Break> or Control Panel/System/Advanced system settings/
> /Advanced tab/Performance [Settings] button/Advanced tab/
> /Virtual memory [Change] button/Virtual Memory dialogue box:
> [ ] Automatically manage...	uncheck
> ...
> (@) Custom size:		select
> Initial size (MB): [ 8192 ]	double RAM
> Maximum size (MB): [ 16384 ]	just in case
> ( ) System managed size		deselect
> ( ) No paging file		deselect
>
> then select *[Set]* button and reboot if prompted.
> You may have to allocate more VM disk space if insufficent.

Ok, that's done.

> Start Task Manager/Performance tab/Open Resource Monitor link at bottom/
> /Resource Monitor/Memory tab/Physical Memory pane at bottom/
> Free should never go much below 100MB and trouble is almost certain
> if you ever hit single digits even for an instant.

Well, I'm certainly not watching task manager for 11-12 hours straight. 
:) However, I seem to continuously have at least 2GiB free.

> Ensure that all Cygwin dlls including anything you build are included
> in every rebase, and do an incremental rebase after every build.

Hmm, so how do I do this?  Is this something that the gcc build *should* 
be doing?  If this is really required, I will open a gcc bug report for it.

> BTDT PITA

I've done a lot of work at the system and kernel level and this SCREAMS 
race condition to me -- and not necessarily in Cygwin.  In fact, I would 
venture to guess that we're dealing with more than one serious issue and 
I don't know where they are.  It is not at all uncommon for a very 
common piece of software to have a race condition that is never exposed 
on one OS but is exposed on another -- this is very common when running 
programs on Wine, for instance.

At current, I seem to be able to run the tests single threaded (one at a 
time) and get no broken pipes and only 8 time-outs.  I suppose that is 
close enough, but I have 8 total tests that need to be run (cygwin-64, 
cygwin-32, mingw64 and mingw64 -- both with and without my patches).  So 
this may simply take me many, many days to complete.  I'm experimenting 
with running under wine, but bash.exe is crashing right now (although my 
Wine had the staging patches, so building w/o them :)

Daniel



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