python binary retrieved via (cygwin) git clone does not execute - error 127

python binary retrieved via (cygwin) git clone does not execute - error 127

[Rick Springob]

I cloned a repository using the git that comes with 64-bit cygwin. 
Executing python.exe in the repository results in an immediate return 
and an exit code of 127.

The python executable was built in 32-bit cygwin. The executable works fine
is 32-bit cygwin and 64-bit cygwin shells as long as the repository was
cloned with the git I was using before, msysgit. 

I have had no problem with python in the same repository on the Ubuntu and 
Mac OS platforms. The problem has only been seen with the git 
that ships with 64-bit cygwin.

64-bit cygwin
 - cygwin version 1.7.33
 - git version 2.1.1

32-bit cygwin
 - cygwin version 1.7.18
 - git version 1.8.1.msysgit.1

I have tried the git config core.filemode option with true and false values. 
This did not help.

git ls-tree shows the same file mode and checksum in both repositories,:
100644 blob abc25ddb6ed66d1bfe3f58de77b3fd3437b8e21f    python.exe

As per a post on the web, I tried to fix this using:
git update-index --chmod=+x python.exe
git commit ...

While that does change the file mode, python still exits with 127:
100755 blob abc25ddb6ed66d1bfe3f58de77b3fd3437b8e21f    python.exe

Python is in the path:
$ which python
/home/x5551212/workspaces/infra/main/python/2.7.5/windows/python 


Any idea what the cygwin provided git is doing differently than other git
implementations? 

Thanks,
 -Rick


--
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: python binary retrieved via (cygwin) git clone does not execute - error 127

[Duane Ellis]

> The problem has only been seen with the git 
> that ships with 64-bit cygwin.

Use “ldd” - against the executable, determine the exact file (absolute path) of every dll that is used/required.

Including any missing DLLs.

You might also need to walk through your “Python Library” (where all of the python loadable modules are stored)
Remember: LDD will only tell you the DLLs that are used, it will not tell you about the modules that are loaded.

Use a “DLL Explorer” program to determine exactly what type of DLL  (32bit or 64bit) of each DLL.
Examples: Dependancy Walker, ‘DumpBin” - there are a number of tools that help

Painful process :-(  I have ran into this many times with other things.

have also run into problems with Python DLLs built with different versions of Visual Studio.
(The C runtime library is different)

In the end, I have had to put a shell wrapper around Python - so that it would *change/reset” various Python ENV variables.

With multiple versions of python (32,64, 2.7, 3.0, windows, cygwin, local-build) nothing is consistent.

Again painful.




--
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: python binary retrieved via (cygwin) git clone does not execute - error 127 - SOLVED

[Rick Springob]

Duane Ellis <duane <at> duaneellis.com> writes:

> 
> > The problem has only been seen with the git 
> > that ships with 64-bit cygwin.
> 
> Use “ldd” - against the executable, determine the exact file (absolute
path) of every dll that is used/required.
> 
> Including any missing DLLs.
> 
> You might also need to walk through your “Python Library” (where all of
the python loadable modules are stored)
> Remember: LDD will only tell you the DLLs that are used, it will not tell
you about the modules that are loaded.
> 
> Use a “DLL Explorer” program to determine exactly what type of DLL  (32bit
or 64bit) of each DLL.
> Examples: Dependancy Walker, ‘DumpBin” - there are a number of tools that help
> 
> Painful process   I have ran into this many times with other things.
> 
> have also run into problems with Python DLLs built with different versions
of Visual Studio.
> (The C runtime library is different)
> 
> In the end, I have had to put a shell wrapper around Python - so that it
would *change/reset” various Python
> ENV variables.
> 
> With multiple versions of python (32,64, 2.7, 3.0, windows, cygwin,
local-build) nothing is consistent.
> 
> Again painful.
> 
> 

Thanks, Duane.

You are definitely correct that locating all the loaded modules would take
awhile. The python binary only statically loads 4 Windows DLL's.

Though, this didn't seem to be the rabbit hole I should go down. The MD5 sum
is the same for the python.exe binaries whether they executed or not. 

I did an experiment. I copied the binary to another directory and executed
there. It worked! So, it was something about where the binary was rather
than what it was.

It turned out that the directory permissions were not correct:

# On the repo that works.
$ icacls windows
windows USWIN\V605040:(I)(F)
        CREATOR OWNER:(I)(OI)(CI)(IO)(F)
        USWIN\Domain Users:(I)(RX)
        CREATOR GROUP:(I)(OI)(CI)(IO)(RX)
        Everyone:(I)(OI)(CI)(RX)

# On the repo that does not work.
$ icacls windows
windows USWIN\V605040:(F)
        USWIN\Domain Users:(RX)
        Everyone:(RX)
        CREATOR OWNER:(OI)(CI)(IO)(F)
        CREATOR GROUP:(OI)(CI)(IO)(RX)
        Everyone:(OI)(CI)(IO)(RX)

The directory did not inherit permissions from its parent. Using explorer I
went to the advanced security settings and checked the "Replace all child
object permissions with the inheritable permissions from this object."

Voila! The failing binary started working.

Not sure that this is a cygwin/git bug. I would think this behavior would be
more widely reported if it was a bug. 

It is more likely that the problem was caused by either a security policy or
the "IT approved" version of cygwin had been modified. Company issued
laptops are heavily managed by IT department where I work. (And, dog slow
because of all the installed nannies.)

Re: python binary retrieved via (cygwin) git clone does not execute - error 127 - SOLVED

[Andrey Repin]

Greetings, Rick Springob!

> I did an experiment. I copied the binary to another directory and executed
> there. It worked! So, it was something about where the binary was rather
> than what it was.

> It turned out that the directory permissions were not correct:

> # On the repo that works.
> $ icacls windows
> windows USWIN\V605040:(I)(F)
>         CREATOR OWNER:(I)(OI)(CI)(IO)(F)
>         USWIN\Domain Users:(I)(RX)
>         CREATOR GROUP:(I)(OI)(CI)(IO)(RX)
>         Everyone:(I)(OI)(CI)(RX)

> # On the repo that does not work.
> $ icacls windows
> windows USWIN\V605040:(F)
>         USWIN\Domain Users:(RX)
>         Everyone:(RX)
>         CREATOR OWNER:(OI)(CI)(IO)(F)
>         CREATOR GROUP:(OI)(CI)(IO)(RX)
>         Everyone:(OI)(CI)(IO)(RX)

> The directory did not inherit permissions from its parent. Using explorer I
> went to the advanced security settings and checked the "Replace all child
> object permissions with the inheritable permissions from this object."

> Voila! The failing binary started working.

> Not sure that this is a cygwin/git bug. I would think this behavior would be
> more widely reported if it was a bug. 

It is a Cygwin, but it is not a bug, rather - intended behavior.
You can get around it by setting "noacl" flag on mount points you want to be
managed by Windows, or explicitly chmod +x necessary binaries. (Though, they
SHOULD be chmod'd in the git. Else it is just not suitable for the job of
VCS.)

> It is more likely that the problem was caused by either a security policy or
> the "IT approved" version of cygwin had been modified. Company issued
> laptops are heavily managed by IT department where I work. (And, dog slow
> because of all the installed nannies.)

.........no comments.


-- 
With best regards,
Andrey Repin
Thursday, June 25, 2015 15:33:56

Sorry for my terrible english...


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