ITP: lapack-3.0
All, Based on the recent discussion regarding an approach to packaging lapack, I have put together a trial package for evaluation by core maintainers. As noted in the previous discussions, lapack is hardly worth the trouble without an optimized blas, but this is only available via an installation of atlas from source. Accordingly, I have merged the upstream lapack-3.0 and atlas-3.6.0 upstream sources for this lapack-3.0-1 package. The binary distribution and the normal build from source create a lapack library and a non-optimized reference implementation blas library from lapack source. Instructions are included in the CYGWIN-PATCHES subdir of the source distribution which allow building of locally optimized versions of these libraries using the lapack base plus the atlas source. The resulting dlls are then to be installed by hand in the /usr/local/bin subdirectory. This insures two things: 1) they will be loaded at run time instead of the nonoptimized dlls due to /usr/local/bin occuring before /usr/bin in the path set by /etc/profile; 2) they will not be overwritten by an upgrade or reinstallation of the binary distribution, which installs its dlls in /usr/bin. Please look over the structure of the package, and let me know if this is an acceptable packaging approach. It is located at ftp://antiskid.homelinux.net/pub/lapack/setup.hint ftp://antiskid.homelinux.net/pub/lapack/lapack-3.0-1.tar.bz2 ftp://antiskid.homelinux.net/pub/lapack/lapack-3.0-1-src.tar.bz2 I have done preliminary testing with octave-2.1.71 installed from source, and the package seems to work as designed. Installation of optimized dlls speeds up many matrix operations by a factor of 10.
Re: ITP: lapack-3.0
My experimental ftp server at antiskid.homelinux.net doesn't work for passive transfers. It works ok with ie, or with command line ftp. wget doesn't work. I'll have to figure out what the issue with PASV is. But for now, just use ie. Thanks Jim Phillips
Re: lapack-3.0
James R. Phillips wrote: All, Based on the recent discussion regarding an approach to packaging lapack, I have put together a trial package for evaluation by core maintainers. As noted in the previous discussions, lapack is hardly worth the trouble without an optimized blas, but this is only available via an installation of atlas from source. What sort of factors affect the optimization? Does the optimized library actually perform _worse_ than the non-optimized one if its binaries are copied to another computer? Accordingly, I have merged the upstream lapack-3.0 and atlas-3.6.0 upstream sources for this lapack-3.0-1 package. The binary distribution and the normal build from source create a lapack library and a non-optimized reference implementation blas library from lapack source. Instructions are included in the CYGWIN-PATCHES subdir of the source distribution which allow building of locally optimized versions of these libraries using the lapack base plus the atlas source. The resulting dlls are then to be installed by hand in the /usr/local/bin subdirectory. This insures two things: 1) they will be loaded at run time instead of the nonoptimized dlls due to /usr/local/bin occuring before /usr/bin in the path set by /etc/profile; 2) they will not be overwritten by an upgrade or reinstallation of the binary distribution, which installs its dlls in /usr/bin. Point 1) is valid only for executables not installed in /usr/bin themselves. Is it likely that we would ever want to accept packages which use lapack/atlas into the Cygwin distribution? If so, the above is not a wonderful solution. Max.
Re: lapack 3.0
--- Max Bowsher wrote: What sort of factors affect the optimization? Does the optimized library actually perform _worse_ than the non-optimized one if its binaries are copied to another computer? The optimized libraries depend on the floating point acceleration architecture. Atlas supports SSE2 (pentium 3), SSE3 (pentium 4), 3dnow (amd athlon ?), and a few more. Between these, there is no lowest common denominator, as 3dnow will not execute on a non-amd processor, and SSE2 will not execute on some amds, etc. So due to the variety of floating point acceleration architectures, it just isn't possible to provide one that is lowest common denominator, except the non-optimized reference implementation. installed by hand in the /usr/local/bin subdirectory. This insures two things: 1) they will be loaded at run time instead of the nonoptimized dlls Point 1) is valid only for executables not installed in /usr/bin themselves. Is it likely that we would ever want to accept packages which use lapack/atlas into the Cygwin distribution? If so, the above is not a wonderful solution. Umm, of course it is likely. This is the intent. My test configuration is of octave-2.1.71, installed from source in /usr/local/bin. In an official package it would be installed in /usr/bin, so this would be a problem. It just hasn't come up in my testing. I'll have to look into the issue. Suggestions involving minimal effort gratefully accepted.
Re: lapack 3.0
On Wed, 29 Jun 2005, James R. Phillips wrote: --- Max Bowsher wrote: installed by hand in the /usr/local/bin subdirectory. This insures two things: 1) they will be loaded at run time instead of the nonoptimized dlls Point 1) is valid only for executables not installed in /usr/bin themselves. Is it likely that we would ever want to accept packages which use lapack/atlas into the Cygwin distribution? If so, the above is not a wonderful solution. Umm, of course it is likely. This is the intent. My test configuration is of octave-2.1.71, installed from source in /usr/local/bin. In an official package it would be installed in /usr/bin, so this would be a problem. It just hasn't come up in my testing. I'll have to look into the issue. Suggestions involving minimal effort gratefully accepted. One problem I have with /usr/local/bin is that this will write over whatever local version of lapack/atlas the user has installed by hand. Let's leave /usr/local for the user. A possibility would be to use the /opt or /usr/lib hierarchy (i.e., install atlas DLLs in /opt/atlas/bin or /usr/lib/atlas/bin), and add a /etc/profile.d script that would prepend atlas directories to the PATH (that way, the atlas DLLs will override the lapack ones installed in /usr/bin, or even /usr/lib/lapack/bin). Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! The Sun will pass between the Earth and the Moon tonight for a total Lunar eclipse... -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT
Re: lapack 3.0
--- Igor Pechtchanski wrote: One problem I have with /usr/local/bin is that this will write over whatever local version of lapack/atlas the user has installed by hand. Let's leave /usr/local for the user. That's exactly what I'm trying to do. The atlas libs installed in /usr/local/bin would be installed by the user, after he compiles them. So if he has old verions in there, he can decide on his own whether to overwrite them. A possibility would be to use the /opt or /usr/lib hierarchy (i.e., install atlas DLLs in /opt/atlas/bin or /usr/lib/atlas/bin), and add a /etc/profile.d script that would prepend atlas directories to the PATH (that way, the atlas DLLs will override the lapack ones installed in /usr/bin, or even /usr/lib/lapack/bin). I think you are on to something here; we are getting close. The key is to _not_ install the binary distribution non-optimized lapack dlls in /usr/bin, because if they are in that directory they cannot be easily overridden for any app (such as octave) also in /usr/bin. This develops because windows always searches the current directory for binaries before searching the path, whereas *nix doesn't. So there is (for dll's) always an implied ./ at the beginning of the path. They need to live somewhere else that has been added to the _back_ end of the path by an init.d script, say /opt/lapack/bin. Then when the user installs optimized libs in /usr/local/bin, they will automatically be picked up ahead of the non-optimized libs in the path. On another issue: My patch works when applied in the forward sense, to create the patched source from the orignal source. However, I noticed that my patch fails when applied in reverse, to recreate the source distribution from the patched source. It succeeds for files that exist in the original distribution, but fails for files that do not exist in the original distribution. It doesn't successfully delete them. I've tried changing the -u flag to -c when creating the diff; makes no difference. Neither does adding the -E option to the reverse patch. Any ideas will be gratefully accepted.
Re: lapack 3.0
On Wed, Jun 29, 2005 at 11:59:16AM -0700, James R. Phillips wrote: --- Igor Pechtchanski wrote: One problem I have with /usr/local/bin is that this will write over whatever local version of lapack/atlas the user has installed by hand. Let's leave /usr/local for the user. That's exactly what I'm trying to do. The atlas libs installed in /usr/local/bin would be installed by the user, after he compiles them. So if he has old verions in there, he can decide on his own whether to overwrite them. FWIW, I don't think we want to start a precedent of official cygwin releases installing things in /usr/local. cgf
Re: lapack 3.0
--- Christopher Faylor wrote: FWIW, I don't think we want to start a precedent of official cygwin releases installing things in /usr/local. The intent of the packaging design is that the official cygwin binary release would _not_ install anything in /usr/local. However, with installation of the source package, it would be possible to build the locally optimized atlas libraries. These would be compiled from source and installed by a local administrator. That being the case, the preferred location would be /usr/local, per fhs guidelines. The binary release, as initially designed, would install link libraries in /usr/lib and dlls in /usr/bin. However, locating the dlls in /usr/bin is problematic, because they become impossible to override with path manipulations for binaries living in /usr/bin. So this part of the design needs to be revised. After thinking about it, I don't think use of the /opt tree makes that much sense; probably the easiest modification is to create a /usr/bin/lapack subdirectory for the nonoptimized libraries to live in, and add it to the back of the path in an init.d script. This is what I am leaning towards.
Re: lapack 3.0
On Wed, 29 Jun 2005, James R. Phillips wrote: --- Christopher Faylor wrote: FWIW, I don't think we want to start a precedent of official cygwin releases installing things in /usr/local. The intent of the packaging design is that the official cygwin binary release would _not_ install anything in /usr/local. However, with installation of the source package, it would be possible to build the locally optimized atlas libraries. These would be compiled from source and installed by a local administrator. That being the case, the preferred location would be /usr/local, per fhs guidelines. The binary release, as initially designed, would install link libraries in /usr/lib and dlls in /usr/bin. However, locating the dlls in /usr/bin is problematic, because they become impossible to override with path manipulations for binaries living in /usr/bin. So this part of the design needs to be revised. After thinking about it, I don't think use of the /opt tree makes that much sense; probably the easiest modification is to create a /usr/bin/lapack subdirectory for the nonoptimized libraries to live in, and add it to the back of the path in an init.d script. This is what I am leaning towards. Make that /usr/lib/lapack, please -- see how gcc does it. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! The Sun will pass between the Earth and the Moon tonight for a total Lunar eclipse... -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT
Re: lapack 3.0
James R. Phillips wrote: --- Christopher Faylor wrote: FWIW, I don't think we want to start a precedent of official cygwin releases installing things in /usr/local. The intent of the packaging design is that the official cygwin binary release would _not_ install anything in /usr/local. However, with installation of the source package, it would be possible to build the locally optimized atlas libraries. These would be compiled from source and installed by a local administrator. That being the case, the preferred location would be /usr/local, per fhs guidelines. The binary release, as initially designed, would install link libraries in /usr/lib and dlls in /usr/bin. However, locating the dlls in /usr/bin is problematic, because they become impossible to override with path manipulations for binaries living in /usr/bin. So this part of the design needs to be revised. After thinking about it, I don't think use of the /opt tree makes that much sense; probably the easiest modification is to create a /usr/bin/lapack subdirectory for the nonoptimized libraries to live in, and add it to the back of the path in an init.d script. This is what I am leaning towards. No subdirectories below /usr/bin, please. To be honest, I cannot follow the discussion. Why is it not possible to put the DLLs into /usr/bin? Is there another official package which includes the same libraries? Gerrit -- =^..^=
Re: lapack 3.0 (OpenGL and ncurses maintainers please take note)
On Thu, Jun 30, 2005 at 12:09:03AM +0200, Gerrit P. Haase wrote: No subdirectories below /usr/bin, please. Right. This memo apparently didn't go out to the ncurses and opengl maintainers. cgf
Re: lapack 3.0
--- Gerrit P. Haase wrote: No subdirectories below /usr/bin, please. OK, could you live with /usr/lib/lapack? To be honest, I cannot follow the discussion. Why is it not possible to put the DLLs into /usr/bin? Is there another official package which includes the same libraries? The design of the package is to install official nonoptimized binaries built from lapack source. But then to also allow local build and installation of optimized atlas library versions if the source package is downloaded and installed. In order to accomplish this, the lapack and atlas source trees are merged in the source package. If/when optimized dll's created by atlas are installed, we want them to be used instead of the nonoptimized libraries, but we don't really want to delete the nonoptimized libraries. So we would like to put them in /usr/local/bin, and have the path string take care of the problem for us (/usr/local/bin precedes /usr/bin in the path defined by /etc/profile). If we were on *nix, we would be done. But, we aren't. It has been pointed out that if a binary lives in /usr/bin, and uses the lapack dll, it will immediately find the nonoptimized version, if that version lives in /usr/bin, because windows always searches the current directory before the path. So, the initial approach needs to be modified: we don't want the nonoptimized binaries to live in /usr/bin, because we want to be able to override them, but not delete them, with a local install. These leads us to consider /usr/lib/lapack. Such a solution will work, but requires a script in /etc/profile.d to put /usr/lib/lapack in the path, at the back, so it will be preceded by /usr/local/bin. Then if/when optimized dlls are installed in /usr/local/bin, they will be found before the default nonoptimized ones. Thanks for the feedback on /usr/bin/lapack, I'll scratch that off, and make it /usr/lib/lapack, unless someone has a problem with that.
Re: lapack 3.0
James R. Phillips wrote: --- Gerrit P. Haase wrote: No subdirectories below /usr/bin, please. OK, could you live with /usr/lib/lapack? Yes. To be honest, I cannot follow the discussion. Why is it not possible to put the DLLs into /usr/bin? Is there another official package which includes the same libraries? The design of the package is to install official nonoptimized binaries built from lapack source. But then to also allow local build and installation of [...] Thanks for the detailed explanation. Gerrit -- =^..^=
Please upload email-2.3.4-1
Hi. Please upload new email-2.3.4-1 files: http://www.smithii.com/files/cygwin/email/email-2.3.4-1.tar.bz2 http://www.smithii.com/files/cygwin/email/email-2.3.4-1-src.tar.bz2 897a837b182a0ad7420147657c05ca63 *email-2.3.4-1-src.tar.bz2 bd5469e06281d50d279d68c1d169cf59 *email-2.3.4-1.tar.bz2 and remove old 2.3.0-2 files. Upstream changelog at http://cleancode.org/cgi-bin/viewcvs.cgi/email/ChangeLog?rev=1.15 For more information about email, see http://email.cleancode.org/ Thanks, Ross
Re: Please upload email-2.3.4-1
On Wed, Jun 29, 2005 at 04:56:42PM -0700, Ross Smith II wrote: Please upload new email-2.3.4-1 files: http://www.smithii.com/files/cygwin/email/email-2.3.4-1.tar.bz2 http://www.smithii.com/files/cygwin/email/email-2.3.4-1-src.tar.bz2 Uploaded. Thanks. cgf
Re: update-alternatives
Sorry for the slow reply...
Op Mon, 27 Jun 2005 00:17:01 -0400 schreef Charles Wilson
in [EMAIL PROTECTED]:
: Bas van Gompel wrote:
[Re-adding attribution:]
+ Charles Wilson:
[...]
: : without using execvp().
[...]
: : Plus, alternatives itself needs to be smart
: : about when to use a wrap executable, and when to use normal symlinks.
[...]
: Certainly. I'd think generally one should only wrap executables.
: (*and take real special care of dll's.*)
:
: Yes.
What I meant to say was: ``Special care should be taken *not* to wrap
DLLs, although they appear as executables in the file-system.''
: : So, (a) alternatives isn't set up, YET, to use any sort of wrap prog,
: : and (b) when it is, it probably shouldn't use your wrap, directly.
[how ``alternatives'' works]
: update-alternatives manages the symlinks in /usr/bin AND the symlinks in
: /etc/alternatives/. Under a wrap scenario, update-alternatives would
: need to know (sometimes) to make the item in /usr/bin be a wrap
: executable, pointing to the appropriate /etc/alternatives/ target
: symlink, which in turns points back to /usr/bin/...
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.
: Your wrap program seems intended for a different audience: the end user
: -- who might copy the orginal exe away to some other directory, and
: put the wrap program in the original location -- thus leading to DLL
: search issues, as you say.
It's more intended for when a package uses a symlink to an executable,
and you want to use the program from outside of cygwin.
(e.g. unison.exe being replaced with a(n ``alternatives'') symlink, as
multiple versions became supported or to have a ``rbash'', ``egrep'',
``fgrep'' etc. which can be invoked from windows, without having
to resort to hardlinks/copying.)
I never intended to say anything about DLL search issues. :]
[...]
: I will look into creating a (new) executable to do what
: ``alternatives'' wants, as soon as I find out what format the
: links in /etc/alternatives take.
:
: 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. :)
When I have resolved FHS-issues...
(I'm going for ${libdir}/wrap/ to store the binaries, ${bindir}/
for the install-scripts, pointerfiles/links go in ${sysconfdir}/wrap
and ${sysconfdir}/alternatives, respectively, for now.
Preliminary binary package file-list:
/usr/bin/wrap
/usr/bin/wrap-alternative
/usr/lib/wrap/wrap.bin
/usr/lib/wrap/wrap-alternative.bin
/usr/share/doc/wrap-1.0/AUTHORS
/usr/share/doc/wrap-1.0/ChangeLog
/usr/share/doc/wrap-1.0/COPYING
/usr/share/doc/wrap-1.0/INSTALL
/usr/share/doc/wrap-1.0/NEWS
/usr/share/doc/wrap-1.0/README
/usr/share/doc/Cygwin/wrap-1.0.README
Any comments?)
...and have thought over info/man-pages, the ITP will follow,
L8r,
Buzz. [If this is too OT do feel free to TITTTL, I read there as well.]
BTW: The ``alternatives'' man-page points to a ``Red Hat'' bugzilla,
and mentions a copyright by them. Is that as should be?
--
) | | ---/ ---/ 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
Re: update-alternatives
On Thu, 30 Jun 2005, Bas van Gompel wrote:
Sorry for the slow reply...
Op Mon, 27 Jun 2005 00:17:01 -0400 schreef Charles Wilson:
: Bas van Gompel wrote:
[Re-adding attribution:]
+ Charles Wilson:
[...]
: : without using execvp().
[...]
: : Plus, alternatives itself needs to be smart
: : about when to use a wrap executable, and when to use normal symlinks.
[...]
: Certainly. I'd think generally one should only wrap executables.
: (*and take real special care of dll's.*)
:
: Yes.
What I meant to say was: ``Special care should be taken *not* to wrap
DLLs, although they appear as executables in the file-system.''
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?
: : So, (a) alternatives isn't set up, YET, to use any sort of wrap prog,
: : and (b) when it is, it probably shouldn't use your wrap, directly.
[how ``alternatives'' works]
: update-alternatives manages the symlinks in /usr/bin AND the symlinks in
: /etc/alternatives/. Under a wrap scenario, update-alternatives would
: need to know (sometimes) to make the item in /usr/bin be a wrap
: executable, pointing to the appropriate /etc/alternatives/ target
: symlink, which in turns points back to /usr/bin/...
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'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...
When I have resolved FHS-issues...
(I'm going for ${libdir}/wrap/ to store the binaries, ${bindir}/
for the install-scripts, pointerfiles/links go in ${sysconfdir}/wrap
and ${sysconfdir}/alternatives, respectively, for now.
Preliminary binary package file-list:
/usr/bin/wrap
/usr/bin/wrap-alternative
/usr/lib/wrap/wrap.bin
/usr/lib/wrap/wrap-alternative.bin
/usr/share/doc/wrap-1.0/AUTHORS
/usr/share/doc/wrap-1.0/ChangeLog
/usr/share/doc/wrap-1.0/COPYING
/usr/share/doc/wrap-1.0/INSTALL
/usr/share/doc/wrap-1.0/NEWS
/usr/share/doc/wrap-1.0/README
/usr/share/doc/Cygwin/wrap-1.0.README
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.
...and have thought over info/man-pages, the ITP will follow,
HTH,
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
The Sun will pass between the Earth and the Moon tonight for a total
Lunar eclipse... -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT
Re: update-alternatives
On Wed, Jun 29, 2005 at 10:32:17PM -0400, Igor Pechtchanski wrote: On Thu, 30 Jun 2005, Bas van Gompel wrote: Sorry for the slow reply... Op Mon, 27 Jun 2005 00:17:01 -0400 schreef Charles Wilson: : Bas van Gompel wrote: [Re-adding attribution:] + Charles Wilson: [...] : : without using execvp(). [...] : : Plus, alternatives itself needs to be smart : : about when to use a wrap executable, and when to use normal symlinks. [...] : Certainly. I'd think generally one should only wrap executables. : (*and take real special care of dll's.*) : : Yes. What I meant to say was: ``Special care should be taken *not* to wrap DLLs, although they appear as executables in the file-system.'' 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? It seems plausible, and maybe even useful, to me, FWIW. cgf
Re: lapack 3.0 (OpenGL and ncurses maintainers please take note)
Christopher Faylor wrote: On Thu, Jun 30, 2005 at 12:09:03AM +0200, Gerrit P. Haase wrote: No subdirectories below /usr/bin, please. Right. This memo apparently didn't go out to the ncurses and opengl maintainers. I fixed that months ago. ncurses test programs now install into /usr/lib/ncurses/; none of the current ncurses sub-packages install anything into subdirs of /usr/bin/. FWIW, I think the /opt tree is PRECISELY the right thing to do with regards to the un-optimized lapack DLLs. With PATH manipulations, binaries like octave.exe can find the appropriate lapack DLLs -- unoptimized if /opt/lapack/bin is the only dir in PATH containing them; optimized if the local administrator installs optimized versions somewhere (/usr/local/bin?) and takes affirmative steps to ensure that /usr/local/bin precedes /opt/lapack/bin in $PATH. -- Chuck
Re: update-alternatives
Igor Pechtchanski wrote: 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? hoo boy. thinking about wrapping dlls makes my hair bleed. I'm gonna pretend this was never mentioned. :-) 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? Actually, I was kinda thinking about something like this: $ ls /usr/bin ... /usr/bin/my-app.from-package-1.exe /usr/bin/my-app.from-package-2.exe ... $ cp alternatives-wrap.exe /usr/bin/my-app.exe $ ln -fs /usr/bin/my-app.from-package-1.exe /etc/alternatives/my-app $ ln -fs /etc/alternatives/my-app '/usr/bin/.##wrap##my-app' Obviously, those last three commands would actually be handled by the update-alternatives program, and not done manually. Also, it'd be a little different if the ultimate target were a script instead of a binary executable. The idea would be that the alternatives-wrap.exe binary would know to look in its current directory for a symlink with the name .##wrap##XX, where XX is argv[0] stripped of its .exe extension and path. This avoids one issue with Bas' one-directory-to-wrap-them-all approach: what if you have two different (but identically-named) binaries which live in different directories, and you want to wrap them both? (Yes, it's a pathological corner case [WHY would you ever want to do that?] -- but somebody, somewhere, will try it -- and the results would be confusing to say the least, under Bas' implementation). 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. That's a really good idea, for inclusion with the main wrap program that Bas is proposing. The workalike for use by alternatives doesn't need one; update-alternatives itself would be the only authorized manipulator of alternatives-wrap and associated files/databases. -- Chuck
Re: lapack 3.0 (OpenGL and ncurses maintainers please take note)
--- Charles Wilson wrote: FWIW, I think the /opt tree is PRECISELY the right thing to do with regards to the un-optimized lapack DLLs. With PATH manipulations, binaries like octave.exe can find the appropriate lapack DLLs -- unoptimized if /opt/lapack/bin is the only dir in PATH containing them; optimized if the local administrator installs optimized versions somewhere (/usr/local/bin?) and takes affirmative steps to ensure that /usr/local/bin precedes /opt/lapack/bin in $PATH. Are there any other official packages that install to /opt? I don't have an /opt at all in my cygwin directory tree. I am reluctant to create a new top-level directory just for part of one package. Not that this couldn't work. What were down to is just a preference. Somewhere in opt would work; so would /usr/lib/lapack.
