This is the mail archive of the
mailing list for the Cygwin project.
Re: error trying to compile anything
- From: "Robert Collins" <robert dot collins at itdomain dot com dot au>
- To: "Reini Urban" <rurban at x-ray dot at>,"Larry Hall \(RFK Partners, Inc\)" <lhall at rfk dot com>
- Cc: <cygwin at cygwin dot com>
- Date: Thu, 17 Jan 2002 11:35:59 +1100
- Subject: Re: error trying to compile anything
- References: <firstname.lastname@example.org> <email@example.com> <3C4617B1.7A7A5C31@x-ray.at>
----- Original Message -----
From: "Reini Urban" <firstname.lastname@example.org>
> 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
> the implementation is trivial, but there should be consense.
Implementation is non trivial (IMO). Here are some potential
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.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html