shebang env sh stopped working with coreutils-8.32-1

shebang env sh stopped working with coreutils-8.32-1

[Daniel Jeliński]

Hi all,
As the title says. To reproduce:
- create a file (test.sh) with the following contents:

#!/usr/bin/env sh
echo success

- make it executable (chmod a+x test.sh)
- execute (./test.sh)

With coreutils-8.26-2 the script prints "success". With
coreutils-8.32-1 and 9.1-1 nothing happens.
Regards,
Daniel

Re: shebang env sh stopped working with coreutils-8.32-1

[Ken Brown]

On 6/1/2022 8:33 AM, Daniel Jeliński wrote:
> Hi all,
> As the title says. To reproduce:
> - create a file (test.sh) with the following contents:
> 
> #!/usr/bin/env sh
> echo success
> 
> - make it executable (chmod a+x test.sh)
> - execute (./test.sh)
> 
> With coreutils-8.26-2 the script prints "success". With
> coreutils-8.32-1 and 9.1-1 nothing happens.

Works for me.

$ cat test.sh
#!/usr/bin/env sh
echo success

$ ./test.sh
success

$ cygcheck -cd coreutils
Cygwin Package Information
Package              Version
coreutils            8.32-1

There must be something else going on in your environment.

Ken

Re: shebang env sh stopped working with coreutils-8.32-1

[Daniel Jeliński]

Hi Ken,
Thanks for checking.
You're right, I'm still on cygwin 3.2.0 because of issues with running
make (see "GNU make losing jobserver tokens").
Tested with cygwin-3.3.5 and env seems to work.
Sorry for the noise.
Regards,
Daniel

śr., 1 cze 2022 o 15:03 Ken Brown <kbrown@cornell.edu> napisał(a):
>
> On 6/1/2022 8:33 AM, Daniel Jeliński wrote:
> > Hi all,
> > As the title says. To reproduce:
> > - create a file (test.sh) with the following contents:
> >
> > #!/usr/bin/env sh
> > echo success
> >
> > - make it executable (chmod a+x test.sh)
> > - execute (./test.sh)
> >
> > With coreutils-8.26-2 the script prints "success". With
> > coreutils-8.32-1 and 9.1-1 nothing happens.
>
> Works for me.
>
> $ cat test.sh
> #!/usr/bin/env sh
> echo success
>
> $ ./test.sh
> success
>
> $ cygcheck -cd coreutils
> Cygwin Package Information
> Package              Version
> coreutils            8.32-1
>
> There must be something else going on in your environment.
>
> Ken
>
> --
> Problem reports:      https://cygwin.com/problems.html
> FAQ:                  https://cygwin.com/faq/
> Documentation:        https://cygwin.com/docs.html
> Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple

Re: shebang env sh stopped working with coreutils-8.32-1

[Ken Brown]

On 6/1/2022 9:29 AM, Daniel Jeliński wrote:
> You're right, I'm still on cygwin 3.2.0 because of issues with running
> make (see "GNU make losing jobserver tokens").

The original report on that issue 
(https://cygwin.com/pipermail/cygwin/2022-March/251095.html) described it as 
long-standing.  Are you saying that it got worse with cygwin-3.3.x?  That would 
be disappointing, because we overhauled the internal implementation of pipes in 
cygwin-3.3.0.

> Tested with cygwin-3.3.5 and env seems to work.
> Sorry for the noise.

NP.

Ken

Re: shebang env sh stopped working with coreutils-8.32-1

[Daniel Jeliński]

śr., 1 cze 2022 o 18:21 Ken Brown <kbrown@cornell.edu> napisał(a):
>
> On 6/1/2022 9:29 AM, Daniel Jeliński wrote:
> > You're right, I'm still on cygwin 3.2.0 because of issues with running
> > make (see "GNU make losing jobserver tokens").
>
> The original report on that issue
> (https://cygwin.com/pipermail/cygwin/2022-March/251095.html) described it as
> long-standing.  Are you saying that it got worse with cygwin-3.3.x?  That would
> be disappointing, because we overhauled the internal implementation of pipes in
> cygwin-3.3.0.

Yessir. I'm also using Cygwin to build OpenJDK. With Cygwin 3.2.0, the
build starts with 8 threads and usually loses no more than 1-2 tokens;
with 3.3.5 the build either finishes with a single token, or segfaults
after a few seconds.
FWIW, I haven't seen any problems with single-threaded builds.

Regards,
Daniel

Re: shebang env sh stopped working with coreutils-8.32-1

[Takashi Yano]

On Wed, 1 Jun 2022 21:38:53 +0200
Daniel Jeliński wrote:
> śr., 1 cze 2022 o 18:21 Ken Brown <kbrown@cornell.edu> napisał(a):
> > The original report on that issue
> > (https://cygwin.com/pipermail/cygwin/2022-March/251095.html) described it as
> > long-standing.  Are you saying that it got worse with cygwin-3.3.x?  That would
> > be disappointing, because we overhauled the internal implementation of pipes in
> > cygwin-3.3.0.
> 
> Yessir. I'm also using Cygwin to build OpenJDK. With Cygwin 3.2.0, the
> build starts with 8 threads and usually loses no more than 1-2 tokens;
> with 3.3.5 the build either finishes with a single token, or segfaults
> after a few seconds.
> FWIW, I haven't seen any problems with single-threaded builds.

How can we reproduce the losing jobserver token issue?

I tried the following steps, however, no such messages appeared.

1) git clone https://git.openjdk.java.net/jdk/
2) cd jdk
3) export TEMP=/tmp
4) bash configure
5) make images

The summary of the configuration is as follows:

Configuration summary:
* Name:           windows-x86_64-server-release
* Debug level:    release
* HS debug level: product
* JVM variants:   server
* JVM features:   server: 'cds compiler1 compiler2 epsilongc g1gc jfr jni-check jvmci jvmti management parallelgc serialgc services shenandoahgc vm-structs zgc'
* OpenJDK target: OS: windows, CPU architecture: x86, address length: 64
* Version string: 19-internal-adhoc.yano.jdk (19-internal)
* Source date:    Determined at build time

Tools summary:
* Environment:    cygwin version 3.3.5-341.x86_64, 2022-05-13 12:27 UTC; windows version 10.0.19044.1706; prefix "/cygdrive"; root "C:\cygwin64"
* Boot JDK:       java version "18" 2022-03-22 Java(TM) SE Runtime Environment (build 18+36-2087) Java HotSpot(TM) 64-Bit Server VM (build 18+36-2087, mixed mode, sharing) (at /cygdrive/c/progra~1/java/jdk-18)
* Toolchain:      microsoft (Microsoft Visual Studio 2022)
* C Compiler:     Version 19.32.31329 (at /cygdrive/c/progra~1/micros~1/2022/commun~1/vc/tools/msvc/1432~1.313/bin/hostx86/x64/cl.exe)
* C++ Compiler:   Version 19.32.31329 (at /cygdrive/c/progra~1/micros~1/2022/commun~1/vc/tools/msvc/1432~1.313/bin/hostx86/x64/cl.exe)

Build performance summary:
* Build jobs:     8
* Memory limit:   16136 MB


$ cygcheck -c autoconf make zip unzip
Cygwin Package Information
Package              Version        Status
autoconf             15-1           OK
make                 4.3-1          OK
unzip                6.0-17         OK
zip                  3.0-12         OK

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

Re: shebang env sh stopped working with coreutils-8.32-1

[Daniel Jeliński]

Hi Takashi,
Thank you for posting your steps, they helped me solve this issue.
Everything on my end was similar, except that instead of bash
configure I used a custom script that was supposed to prepare the
environment. On closer inspection, it turned out that the script was
downloading make 4.0 and running bash configure with parameter
MAKE=/path/to/make-4.0. After removing that, the build finished
without any issues. It was also much faster than with
cygwin-3.2/make-4.0.
Thanks again,
Daniel

Re: shebang env sh stopped working with coreutils-8.32-1

[Ken Brown]

On 6/2/2022 8:49 AM, Daniel Jeliński wrote:
> Thank you for posting your steps, they helped me solve this issue.
> Everything on my end was similar, except that instead of bash
> configure I used a custom script that was supposed to prepare the
> environment. On closer inspection, it turned out that the script was
> downloading make 4.0 and running bash configure with parameter
> MAKE=/path/to/make-4.0. After removing that, the build finished
> without any issues. It was also much faster than with
> cygwin-3.2/make-4.0.

I've added Magnus to the CC since he's the one who originally reported the 
jobserver issue.  Magnus, does Daniel's solution also work for you?  Can we 
consider this issue solved?

Ken

Re: shebang env sh stopped working with coreutils-8.32-1

[Ken Brown]

[Resending with CC.]

On 6/2/2022 10:02 AM, Ken Brown wrote:
> On 6/2/2022 8:49 AM, Daniel Jeliński wrote:
>> Thank you for posting your steps, they helped me solve this issue.
>> Everything on my end was similar, except that instead of bash
>> configure I used a custom script that was supposed to prepare the
>> environment. On closer inspection, it turned out that the script was
>> downloading make 4.0 and running bash configure with parameter
>> MAKE=/path/to/make-4.0. After removing that, the build finished
>> without any issues. It was also much faster than with
>> cygwin-3.2/make-4.0.
> 
> I've added Magnus to the CC since he's the one who originally reported the 
> jobserver issue.  Magnus, does Daniel's solution also work for you?  Can we 
> consider this issue solved?
> 
> Ken
>