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]

cygexec mounted binaries don't inherit PATH during dynamic loading


The last month or so I've been fooling around with using the 'cygexec'
feature of the mount table to tell Cygwin that everything under /usr/bin
is a Cygwin executable (except for strace and cygcheck.)

However, a strange thing started happening recently.  With the x11
server running I would try to launch an xterm, and I would get the
windows popup "DLL missing  - Can't find cygX11-6.dll".  Puzzled, I
check $PATH from the prompt and indeed /usr/X11R6/bin is in my path. 
Let me be clear at this point that this particular example involves
xterm and X11 but as you'll see that's just a specific example of a more
general problem.

I figured out that removing the cygexec mounted /usr/bin solves the
problem - an xterm can launch normally.

So I used process explorer to look at the environment of the xterm.exe
process while the error popup was on the screen.  The process had the
default, system-wide PATH (as defined in Windows system properties
page.)  In my case, I have \cygwin\bin in that PATH but I rely on the
profile scripts to add /usr/X11R6/bin to the path, and thus the
cygX11-6.dll was indeed not in the path at that moment.

I poked around in the source code and sure enough, environ.cc, function
build_env() gets passed a true value for "no_envblock" if the thing
being spawned is mounted cygexec.  It proceeds to set envblock to NULL
which I presume means take the default system environment.

Now, I realize that since Cygwin is spawning a Cygwin application it
will pass stuff like the environment and argv[] directly through the
shared memory region and bypass Windows' methods entirely.  So I realize
that *eventually* the process will inherit the correct PATH.  But my
question/problem is that during the dynamic loading phase, Windows needs
the inherited PATH too - otherwise you get these strange unexplainable
runtime link errors.  (I was seeing this before in another way when a
dlopen() kept returning win32 errno 126 even though the damn DLL was
right where it was supposed to be and had the right permissions.)

So my question is simply this: in the case of spawning a cygexec-mounted
binary, shouldn't build_env at least fill in PATH from the calling
process' value, so that Windows can do its runtime DLL loading?

Brian

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


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