This is the mail archive of the
mailing list for the Cygwin project.
Re: error trying to compile anything
Robert Collins schrieb:
> From: "Reini Urban" <firstname.lastname@example.org>
> > 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-184.108.40.206.dll /bin/cygwin1.dll
and not those by
$ ln -s /bin/cygwin-220.127.116.11.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
> 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