This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: update-alternatives
Op Wed, 29 Jun 2005 22:32:17 -0400 (EDT) schreef Igor Pechtchanski
in <Pine.GSO.4.61.0506292219060.15060@slinky.cs.nyu.edu>:
: On Thu, 30 Jun 2005, Bas van Gompel wrote:
[...]
: > Op Mon, 27 Jun 2005 00:17:01 -0400 schreef Charles Wilson:
: > : Bas van Gompel wrote:
: > [Re-adding attribution:]
: > + > Charles Wilson:
[``wrap'' *not* to wrap DLLs.]
:
: Umm, why not? I mean, the mechanism for wrapping DLLs is very different
: than that of wrapping executables (and much more involved), but isn't
: there a possibility of writing a "wrapdll.dll" that looks up the name of
: the DLL in the /etc/alternatives database, dlopen's it, and emulates all
: of its functions somehow? ISTR something like this done in my OS class
: ages ago, but don't recall the exact details. Am I misremembering?
I Don't see how this could work. ``Statically'' linked, the wrapper's
``exports''-table would be consulted, would it not?
I can imagine building a custom wrapper-dll for each wrappee, using an
autoload-like method, but don't intend to investigate further, for now.
Wouldn't this kind of thing be easier to address from the context of
``libtool'', in each DLL's build-system?
So far, I can envision this working (reasonably) only when making
gcc/binutils a run-time requirement of ``wrap'', or having a topheavy
(dll-analyzing/building) installer, both of which I'd prefer not to.
[how ``alternatives'' works]
: > Yes. I have since seen that ``alternatives'' uses a pure ``C'' approach,
: > so my shell-script installers might not be appropriate. It should not be
: > hard for ``alternatives'' to copy the wrapper bin-file itself, however.
:
: I wonder if these could be "real" symlink approximations, i.e., the path
: to the executable to run would sit in some static string at a known
: offset, and the installer could simply write into the executable at that
: offset? Or is this too much?
I guess this could be done... Nice idea. I will look into it.
Thanks.
There is probably a CRC to contend with somewhere.
: > : I'm not sure it's worth your time to do so right now. I think the
: > : /bin/ash vs. /bin/bash thing will be resolved some other way, and that's
: > : the only pressing need for an MSWin-friendly symlink-wrap-thingy from
: > : the perspective of update-alternatives.
: >
: > I did since however write a ``wrap-alternative'' executable, which uses
: > execv... Not having to read a file makes it even simpler than the
: > ``wrap'' executable. :)
:
: That actually sounds like what I mentioned above...
It isn't, however. The link is read from ${sysconfdir} + "/alternatives/" +
basename(argv[0])''
[FHS-issues]
: > Preliminary binary package file-list:
: >
: > /usr/bin/wrap
: > /usr/bin/wrap-alternative
: > /usr/lib/wrap/wrap.bin
: > /usr/lib/wrap/wrap-alternative.bin
[...]
: > Any comments?)
:
: Looks good. You could also provide a "create-wrap" script/program, that
: would have "ln -s" semantics and create a wrapped executable (and it could
: also check that the thing you're wrapping *is* an executable, and not,
: say, a DLL). That way, if you decide to switch the implementation later,
: the scripts that create wrapped executables won't have to change.
In the above, /usr/bin/wrap and /usr/bin/wrap-alternative are the
scripts you suggest (No checking for DLLs (or non-executables for that
matter) yet, though). I should rename them I guess. It's confusing
already. create-wrap? install-wrap? mkwrap?
: HTH,
It does, thanks.
L8r,
Buzz.
--
) | | ---/ ---/ Yes, this | This message consists of true | I do not
-- | | / / really is | and false bits entirely. | mail for
) | | / / a 72 by 4 +-------------------------------+ any1 but
-- \--| /--- /--- .sigfile. | |perl -pe "s.u(z)\1.as." | me. 4^re