Uploaders,
Please upload lapack-3.0-5, from:
ftp://antiskid.homelinux.net/pub/cygwin/release/lapack/lapack-3.0-5-src.tar.bz2
ftp://antiskid.homelinux.net/pub/cygwin/release/lapack/lapack-3.0-5.tar.bz2
This fixes the recently identified problem with /etc/profile.d/lapack.sh.
Thanks,
Jim
On Mar 24 04:42, James R. Phillips wrote:
Uploaders,
Please upload lapack-3.0-5, from:
ftp://antiskid.homelinux.net/pub/cygwin/release/lapack/lapack-3.0-5-src.tar.bz2
ftp://antiskid.homelinux.net/pub/cygwin/release/lapack/lapack-3.0-5.tar.bz2
Uploaded. I removed 3.0-3.
Corinna
Cygwin Uploaders:
Please upload lapack-3.0-4 from:
ftp://antiskid.homelinux.net/pub/lapack/lapack-3.0-4-src.tar.bz2
ftp://antiskid.homelinux.net/pub/lapack/lapack-3.0-4.tar.bz2
This fixes the incorrectly-implemented autobasing for the cyglapack and cygblas
dynamic link libraries. Thanks
On Jan 10 11:33, James R. Phillips wrote:
ftp://antiskid.homelinux.net/pub/lapack/lapack-3.0-4-src.tar.bz2
ftp://antiskid.homelinux.net/pub/lapack/lapack-3.0-4.tar.bz2
Uploaded. I removed 3.0-2.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin
On Aug 2 14:26, James R. Phillips wrote:
On Sat, Jul 16, 2005 at 10:52:36AM -0700, James R. Phillips wrote:
ftp://antiskid.homelinux.net/pub/lapack/lapack-3.0-3.tar.bz2
ftp://antiskid.homelinux.net/pub/lapack/lapack-3.0-3-src.tar.bz2
Uploaded. I removed 3.0-1.
Corinna
--
Corinna
--- Christopher Faylor [EMAIL PROTECTED] wrote:
On Sat, Jul 16, 2005 at 10:52:36AM -0700, James R. Phillips wrote:
ftp://antiskid.homelinux.net/pub/lapack/lapack-3.0-3.tar.bz2
ftp://antiskid.homelinux.net/pub/lapack/lapack-3.0-3-src.tar.bz2
Sorry, no can do:
ncftpget: cannot open
OK, sorry for the error and thanks for trying. I reconfigured the router and
tested the setup from home for proper operation of PASV command and wget, but
apparently caused some other issue with the reconfiguration. I am currently on
holiday, and the public library I use for web access doesn't
On Sat, Jul 16, 2005 at 10:52:36AM -0700, James R. Phillips wrote:
A bug has been found and fixed in the netlib reference cblas routines; this
upload fixes the bug and should allow the gsl package to link successfully to
the reference cblas.
ftp://antiskid.homelinux.net/pub/lapack/lapack-3.0-3
Hi Teun,
--- a.rburgers wrote:
I am starting to think we have a g77 bug here or my understanding ofparameter
passing is incomplete (though I have quite a bit of experience withcalling
Fortran from C).
If I change the wrapper function to have the dot argument as *first*argument
instead
of the
On Sat, Jul 16, 2005 at 10:33:26AM -0700, James R. Phillips wrote:
--- a.rburgers wrote:
I am starting to think we have a g77 bug here or my understanding
ofparameter passing is incomplete (though I have quite a bit of
experience withcalling Fortran from C). If I change the wrapper
function to
A bug has been found and fixed in the netlib reference cblas routines; this
upload fixes the bug and should allow the gsl package to link successfully to
the reference cblas.
ftp://antiskid.homelinux.net/pub/lapack/lapack-3.0-3.tar.bz2
ftp://antiskid.homelinux.net/pub/lapack/lapack-3.0-3
--- Christopher Faylor wrote:
Can we move away from using cygwin-apps as an all-lapack-all-the-time
mailing list and maybe start using the cygwin mailing list for bug
reports, please?
cgf
Sure. I've been treating lapack issues as packaging issues to this date, but I
agree this is a just
lapack-3.0 has been updated to a -2 release. The new release incorporates the
cblas library and header files, and also has been linked with the
--enable-auto-image-base option. This should enable other cygwin packages
(e.g. gsl) wishing to use the C interface to the fortran blas to compile
On Thu, Jul 14, 2005 at 06:05:09PM -0700, James R. Phillips wrote:
lapack-3.0 has been updated to a -2 release. The new release incorporates the
cblas library and header files, and also has been linked with the
--enable-auto-image-base option. This should enable other cygwin packages
(e.g. gsl
On Jul 1 22:31, James R. Phillips wrote:
Core Maintainers,
I fixed the two problems identified by Charles Wilson (removed cygwin release
version numbers from documentation directory and cygwin README).
ftp://antiskid.homelinux.net/pub/lapack/lapack-3.0-1.tar.bz2
ftp
On Jun 30 05:40, James R. Phillips wrote:
--- Corinna Vinschen wrote:
I'd opt for /opt (sorry for the pun). Bigger and more complex packages
are better served by getting their own /opt subdir in the long run.
Charles is asking for /opt for a while now anyway. Perhaps the lapack
package
--- Corinna Vinschen wrote:
It would help to keep everything in one place. As I said, I'm also
ok with using /usr/lib/lapack, but using /opt here looks neater to me.
Um, since you give me the option of keeping it as is, I'm going to do that. I
need to press on to getting octave
Core Maintainers,
lapack-3.0-1 source and binary packages are ready for uploading. These have
been tested with trial builds of octave-2.1.71, and have been found to work
properly. The packaging method is method 1. Thanks everyone for comments
helping settle the packaging issues.
ftp
James R. Phillips wrote:
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 yet. IIRC, the existence of /opt has gotten the go-ahead
should't include the REL number (e.g.
/usr/share/doc/lapack-3.0/ not /usr/share/doc/lapack-3.0-1/
(3) ditto the cygwin specific README
/usr/share/doc/Cygwin/lapack-3.0.README
(I *said* they were nits)
I would also mention that you might (but I doubt it; see below) find it
necessary to adopt
--- Charles Wilson wrote:
From the original post where I raised the issue:
http://www.cygwin.com/ml/cygwin-apps/2003-04/msg00305.html
Basically, a package to be installed under /opt creates an entire tree:
/opt/package/bin
Thanks for the info.
However, I have no objections if you
package. If there is demand for it, I suppose I could do something similar.
Most people can get what they need by browsing the html documentation at
netlib.
(2) the documentation directory should't include the REL number (e.g.
/usr/share/doc/lapack-3.0/ not /usr/share/doc/lapack-3.0-1/
(3
Core Maintainers,
I fixed the two problems identified by Charles Wilson (removed cygwin release
version numbers from documentation directory and cygwin README).
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
ftp
On Jun 29 22:40, James R. Phillips wrote:
--- 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
OK, I changed the installation dir for the unoptimized dll's to
/usr/lib/lapack. Updated source and binary packages are located at
ftp://antiskid.homelinux.net/pub/lapack
I still consider this a trial packaging; I'm not asking for an upload yet.
Core maintainers, please advise of any packaging
--- Corinna Vinschen wrote:
I'd opt for /opt (sorry for the pun). Bigger and more complex packages
are better served by getting their own /opt subdir in the long run.
Charles is asking for /opt for a while now anyway. Perhaps the lapack
package would be a good start.
Please look over
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
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
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
--- 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
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
--- 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
41 matches
Mail list logo
