This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]