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
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
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
--- 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
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
--- 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
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
--- 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
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
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.
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
--- 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?
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
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
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
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
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
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
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
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,
--- 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
21 matches
Mail list logo
