Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Message-ID: <182801c19eee$f0166890$0200a8c0@lifelesswks>
From: "Robert Collins" <robert.collins@itdomain.com.au>
To: "Reini Urban" <rurban@x-ray.at>,
   "Larry Hall \(RFK Partners, Inc\)" <lhall@rfk.com>
Cc: <cygwin@cygwin.com>
References: <1011214219.8034.ezmlm@cygwin.com> <4.3.1.2.20020116182829.02304590@pop.ma.ultranet.com> <3C4617B1.7A7A5C31@x-ray.at>
Subject: Re: error trying to compile anything
Date: Thu, 17 Jan 2002 11:35:59 +1100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

----- Original Message -----
From: "Reini Urban" <rurban@x-ray.at>
> cygwin does support softlinks, so we should use them.

But .dll's are loaded by the win32 (on 95) and the Native API (NT).
Cygwin symlinks are _not_ supported by those OS's, so symlinking is not
an option.

> the implementation is trivial, but there should be consense.

Implementation is non trivial (IMO). Here are some potential
implementations:
1) For win95, produce a kernel VXD that patches the CreateProcess call
to interpret symlinks.
2) For winNT, create a kernel thunk to do the same.
3) Create an NT service/device driver that creates an NT Reparse point,
and returns the correct cygwin1.dll canonical location. hardlinks aren't
good enough, they can't go across file systems.
4) Create replacement assembly stub for gcc to use when linking against
cygwin1.dll that will interpret symlinks and then at runtime fix up the
symbols that should have resolved to cygwin1.dll, to resolve against a
dynamically opened cygwin1.dll. Note that this will have to execute
before any .dll startup code.

Now, if you still think it's trivial, I'll be happy to review your
(trivial) patch to implement that.

Rob


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/