* Strange errors running gcc tests on Cygwin
@ 2017-03-04 5:44 Daniel Santos
2017-03-04 11:27 ` Tim Prince via cygwin
2017-03-05 2:49 ` Daniel Santos
0 siblings, 2 replies; 29+ messages in thread
From: Daniel Santos @ 2017-03-04 5:44 UTC (permalink / raw)
To: JonY, cygwin
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Strange errors running gcc tests on Cygwin
2017-03-04 5:44 Strange errors running gcc tests on Cygwin Daniel Santos
@ 2017-03-04 11:27 ` Tim Prince via cygwin
2017-03-05 2:49 ` Daniel Santos
1 sibling, 0 replies; 29+ messages in thread
From: Tim Prince via cygwin @ 2017-03-04 11:27 UTC (permalink / raw)
To: 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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Strange errors running gcc tests on Cygwin
2017-03-04 5:44 Strange errors running gcc tests on Cygwin Daniel Santos
2017-03-04 11:27 ` Tim Prince via cygwin
@ 2017-03-05 2:49 ` Daniel Santos
2017-03-05 3:49 ` JonY
1 sibling, 1 reply; 29+ messages in thread
From: Daniel Santos @ 2017-03-05 2:49 UTC (permalink / raw)
To: Tim Prince; +Cc: JonY, cygwin
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Strange errors running gcc tests on Cygwin
2017-03-05 2:49 ` Daniel Santos
@ 2017-03-05 3:49 ` JonY
2017-03-05 4:20 ` Daniel Santos
` (2 more replies)
0 siblings, 3 replies; 29+ messages in thread
From: JonY @ 2017-03-05 3:49 UTC (permalink / raw)
To: Daniel Santos, Tim Prince; +Cc: cygwin
[-- 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 --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Strange errors running gcc tests on Cygwin
2017-03-05 3:49 ` JonY
@ 2017-03-05 4:20 ` Daniel Santos
2017-03-05 7:23 ` Daniel Santos
2017-03-05 7:32 ` Daniel Santos
2 siblings, 0 replies; 29+ messages in thread
From: Daniel Santos @ 2017-03-05 4:20 UTC (permalink / raw)
To: JonY; +Cc: Tim Prince, cygwin
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Strange errors running gcc tests on Cygwin
2017-03-05 3:49 ` JonY
2017-03-05 4:20 ` Daniel Santos
@ 2017-03-05 7:23 ` Daniel Santos
2017-03-05 7:32 ` Daniel Santos
2 siblings, 0 replies; 29+ messages in thread
From: Daniel Santos @ 2017-03-05 7:23 UTC (permalink / raw)
To: JonY, Tim Prince; +Cc: cygwin
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Strange errors running gcc tests on Cygwin
2017-03-05 3:49 ` JonY
2017-03-05 4:20 ` Daniel Santos
2017-03-05 7:23 ` Daniel Santos
@ 2017-03-05 7:32 ` Daniel Santos
2017-03-05 11:08 ` David Billinghurst
2 siblings, 1 reply; 29+ messages in thread
From: Daniel Santos @ 2017-03-05 7:32 UTC (permalink / raw)
To: JonY, Tim Prince; +Cc: cygwin
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Strange errors running gcc tests on Cygwin
2017-03-05 7:32 ` Daniel Santos
@ 2017-03-05 11:08 ` David Billinghurst
2017-03-07 1:59 ` Daniel Santos
0 siblings, 1 reply; 29+ messages in thread
From: David Billinghurst @ 2017-03-05 11:08 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Strange errors running gcc tests on Cygwin
2017-03-05 11:08 ` David Billinghurst
@ 2017-03-07 1:59 ` Daniel Santos
2017-03-07 13:58 ` cyg Simple
0 siblings, 1 reply; 29+ messages in thread
From: Daniel Santos @ 2017-03-07 1:59 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Strange errors running gcc tests on Cygwin
2017-03-07 1:59 ` Daniel Santos
@ 2017-03-07 13:58 ` cyg Simple
2017-03-07 23:21 ` Daniel Santos
0 siblings, 1 reply; 29+ messages in thread
From: cyg Simple @ 2017-03-07 13:58 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Strange errors running gcc tests on Cygwin
2017-03-07 13:58 ` cyg Simple
@ 2017-03-07 23:21 ` Daniel Santos
2017-03-08 0:36 ` David Billinghurst
0 siblings, 1 reply; 29+ messages in thread
From: Daniel Santos @ 2017-03-07 23:21 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Strange errors running gcc tests on Cygwin
2017-03-07 23:21 ` Daniel Santos
@ 2017-03-08 0:36 ` David Billinghurst
2017-03-08 5:14 ` Daniel Santos
0 siblings, 1 reply; 29+ messages in thread
From: David Billinghurst @ 2017-03-08 0:36 UTC (permalink / raw)
To: cygwin, Daniel Santos
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Strange errors running gcc tests on Cygwin
2017-03-08 0:36 ` David Billinghurst
@ 2017-03-08 5:14 ` Daniel Santos
2017-03-08 8:21 ` Brian Inglis
0 siblings, 1 reply; 29+ messages in thread
From: Daniel Santos @ 2017-03-08 5:14 UTC (permalink / raw)
To: David Billinghurst, cygwin
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Strange errors running gcc tests on Cygwin
2017-03-08 5:14 ` Daniel Santos
@ 2017-03-08 8:21 ` Brian Inglis
2017-03-09 22:48 ` Daniel Santos
0 siblings, 1 reply; 29+ messages in thread
From: Brian Inglis @ 2017-03-08 8:21 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Strange errors running gcc tests on Cygwin
2017-03-08 8:21 ` Brian Inglis
@ 2017-03-09 22:48 ` Daniel Santos
2017-03-09 23:51 ` Brian Inglis
0 siblings, 1 reply; 29+ messages in thread
From: Daniel Santos @ 2017-03-09 22:48 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Strange errors running gcc tests on Cygwin
2017-03-09 22:48 ` Daniel Santos
@ 2017-03-09 23:51 ` Brian Inglis
2017-03-10 0:01 ` Tim Prince via cygwin
` (2 more replies)
0 siblings, 3 replies; 29+ messages in thread
From: Brian Inglis @ 2017-03-09 23:51 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Strange errors running gcc tests on Cygwin
2017-03-09 23:51 ` Brian Inglis
@ 2017-03-10 0:01 ` Tim Prince via cygwin
2017-03-10 18:56 ` Achim Gratz
2017-03-12 4:04 ` Daniel Santos
2 siblings, 0 replies; 29+ messages in thread
From: Tim Prince via cygwin @ 2017-03-10 0:01 UTC (permalink / raw)
To: 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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Strange errors running gcc tests on Cygwin
2017-03-09 23:51 ` Brian Inglis
2017-03-10 0:01 ` Tim Prince via cygwin
@ 2017-03-10 18:56 ` Achim Gratz
2017-03-10 20:30 ` Brian Inglis
2017-03-13 16:35 ` Daniel Santos
2017-03-12 4:04 ` Daniel Santos
2 siblings, 2 replies; 29+ messages in thread
From: Achim Gratz @ 2017-03-10 18:56 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Strange errors running gcc tests on Cygwin
2017-03-10 18:56 ` Achim Gratz
@ 2017-03-10 20:30 ` Brian Inglis
2017-03-10 20:48 ` Achim Gratz
2017-03-13 16:35 ` Daniel Santos
1 sibling, 1 reply; 29+ messages in thread
From: Brian Inglis @ 2017-03-10 20:30 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Strange errors running gcc tests on Cygwin
2017-03-10 20:30 ` Brian Inglis
@ 2017-03-10 20:48 ` Achim Gratz
0 siblings, 0 replies; 29+ messages in thread
From: Achim Gratz @ 2017-03-10 20:48 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Strange errors running gcc tests on Cygwin
2017-03-09 23:51 ` Brian Inglis
2017-03-10 0:01 ` Tim Prince via cygwin
2017-03-10 18:56 ` Achim Gratz
@ 2017-03-12 4:04 ` Daniel Santos
2 siblings, 0 replies; 29+ messages in thread
From: Daniel Santos @ 2017-03-12 4:04 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Strange errors running gcc tests on Cygwin
2017-03-10 18:56 ` Achim Gratz
2017-03-10 20:30 ` Brian Inglis
@ 2017-03-13 16:35 ` Daniel Santos
2017-03-13 17:25 ` Marco Atzeri
1 sibling, 1 reply; 29+ messages in thread
From: Daniel Santos @ 2017-03-13 16:35 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Strange errors running gcc tests on Cygwin
2017-03-13 16:35 ` Daniel Santos
@ 2017-03-13 17:25 ` Marco Atzeri
2017-03-15 16:50 ` Daniel Santos
0 siblings, 1 reply; 29+ messages in thread
From: Marco Atzeri @ 2017-03-13 17:25 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Strange errors running gcc tests on Cygwin
2017-03-13 17:25 ` Marco Atzeri
@ 2017-03-15 16:50 ` Daniel Santos
2017-03-15 19:36 ` Brian Inglis
0 siblings, 1 reply; 29+ messages in thread
From: Daniel Santos @ 2017-03-15 16:50 UTC (permalink / raw)
To: 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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Strange errors running gcc tests on Cygwin
2017-03-15 16:50 ` Daniel Santos
@ 2017-03-15 19:36 ` Brian Inglis
2017-03-16 20:55 ` Daniel Santos
0 siblings, 1 reply; 29+ messages in thread
From: Brian Inglis @ 2017-03-15 19:36 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Strange errors running gcc tests on Cygwin
2017-03-15 19:36 ` Brian Inglis
@ 2017-03-16 20:55 ` Daniel Santos
2017-03-17 5:17 ` Brian Inglis
0 siblings, 1 reply; 29+ messages in thread
From: Daniel Santos @ 2017-03-16 20:55 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Strange errors running gcc tests on Cygwin
2017-03-16 20:55 ` Daniel Santos
@ 2017-03-17 5:17 ` Brian Inglis
2017-03-18 13:48 ` Daniel Santos
0 siblings, 1 reply; 29+ messages in thread
From: Brian Inglis @ 2017-03-17 5:17 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Strange errors running gcc tests on Cygwin
2017-03-17 5:17 ` Brian Inglis
@ 2017-03-18 13:48 ` Daniel Santos
2017-03-18 14:52 ` cyg Simple
0 siblings, 1 reply; 29+ messages in thread
From: Daniel Santos @ 2017-03-18 13:48 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Strange errors running gcc tests on Cygwin
2017-03-18 13:48 ` Daniel Santos
@ 2017-03-18 14:52 ` cyg Simple
0 siblings, 0 replies; 29+ messages in thread
From: cyg Simple @ 2017-03-18 14:52 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 29+ messages in thread
end of thread, other threads:[~2017-03-18 14:52 UTC | newest]
Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-03-04 5:44 Strange errors running gcc tests on Cygwin Daniel Santos
2017-03-04 11:27 ` Tim Prince via cygwin
2017-03-05 2:49 ` Daniel Santos
2017-03-05 3:49 ` JonY
2017-03-05 4:20 ` Daniel Santos
2017-03-05 7:23 ` Daniel Santos
2017-03-05 7:32 ` Daniel Santos
2017-03-05 11:08 ` David Billinghurst
2017-03-07 1:59 ` Daniel Santos
2017-03-07 13:58 ` cyg Simple
2017-03-07 23:21 ` Daniel Santos
2017-03-08 0:36 ` David Billinghurst
2017-03-08 5:14 ` Daniel Santos
2017-03-08 8:21 ` Brian Inglis
2017-03-09 22:48 ` Daniel Santos
2017-03-09 23:51 ` Brian Inglis
2017-03-10 0:01 ` Tim Prince via cygwin
2017-03-10 18:56 ` Achim Gratz
2017-03-10 20:30 ` Brian Inglis
2017-03-10 20:48 ` Achim Gratz
2017-03-13 16:35 ` Daniel Santos
2017-03-13 17:25 ` Marco Atzeri
2017-03-15 16:50 ` Daniel Santos
2017-03-15 19:36 ` Brian Inglis
2017-03-16 20:55 ` Daniel Santos
2017-03-17 5:17 ` Brian Inglis
2017-03-18 13:48 ` Daniel Santos
2017-03-18 14:52 ` cyg Simple
2017-03-12 4:04 ` Daniel Santos
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).