Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sources.redhat.com/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Message-ID:	<3C463058.CCF7A0EB@x-ray.at>
Date:	Thu, 17 Jan 2002 02:00:56 +0000
From:	Reini Urban <rurban AT x-ray DOT at>
Organization:	http://www.x-ray.at
X-Mailer:	Mozilla 4.7 [de] (WinNT; I)
X-Accept-Language:	de,en
MIME-Version:	1.0
To:	Robert Collins <robert DOT collins AT itdomain DOT com DOT au>
CC:	"Larry Hall (RFK Partners, Inc)" <lhall AT rfk DOT com>, cygwin AT cygwin DOT com
Subject:	Re: error trying to compile anything
References:	<1011214219 DOT 8034 DOT ezmlm AT cygwin DOT com> <4 DOT 3 DOT 1 DOT 2 DOT 20020116182829 DOT 02304590 AT pop DOT ma DOT ultranet DOT com> <3C4617B1 DOT 7A7A5C31 AT x-ray DOT at> <182801c19eee$f0166890$0200a8c0 AT lifelesswks>

Robert Collins schrieb:
> From: "Reini Urban" <rurban AT x-ray DOT at>
> > cygwin does support softlinks, so we should use them.

sorry about the confusion. I mixed copies (aka "cygwin file hardlinks") 
with softlinks. to stay zynical I meant those links which you create by 
$ ln /bin/cygwin-1.1.1.6.dll /bin/cygwin1.dll
and not those by 
$ ln -s /bin/cygwin-1.1.1.6.dll /bin/cygwin1.dll
which is of course not trivial :)

There can be only one, multiple strong version hardly linked into 
apps is wrong and I'll keep my mouth shut.

> 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.
-- 
Reini Urban
  http://atelier.akbild.ac.at/ (soon)
  http://xarch.tu-graz.ac.at/home/rurban/ (big)
  http://tv.mur.at/ (kulturelles)

--
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/

- Raw text -