Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Message-ID: <424A3A3D.A4484691@dessent.net>
Date: Tue, 29 Mar 2005 21:33:49 -0800
From: Brian Dessent <brian AT dessent DOT net>
Organization: My own little world...
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: cygexec mounted binaries don't inherit PATH during dynamic loading
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: cygwin AT cygwin DOT com


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/