Re: lapack 3.0 (OpenGL and ncurses maintainers please take note)
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 would be a good start. Please look over the directory structure of the trial binary package at ftp://antiskid.homelinux.net/pub/lapack It doesn't seem all that complex to me, but if it passes the /opt complex threshold for you, please advise how package subtrees would best be reallocated. I.E. should /opt have its own share/doc subtree, etc. The /usr/lib/lapack packaging is fine with me, I had just the idea that your own /opt/lapack dir could help with the local optimized stuff. For instance consider /opt/lapack/default/bin - Contains the non-opimized DLLs /opt/lapack/bin - is empty Now the build instruction for the optimized build are so that the optimized stuff will be installed to /opt/lapack/bin and your /etc/profile.d/lapack.(c)sh file tests roughly like this: if [ -f /opt/lapack/bin/cyglapack.dll ] then PATH=$PATH:/opt/lapack/bin else PATH=$PATH:/opt/lapack/default/bin fi 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. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com Red Hat, Inc.
Re: lapack 3.0 (OpenGL and ncurses maintainers please take note)
--- 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 packaged (the goal of the whole excercise). Thanks, Jim Phillips PS Checked /opt on my debian box. Only occupied by a foreign package I converted from .tar.bz2 to .deb. Have the impression that /opt is used mostly for third-party binary apps, not built from source.
Re: lapack 3.0 (OpenGL and ncurses maintainers please take note)
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 approval from cgf ( Corinna?) -- but to date, nobody has wanted to be the first to split off from the main /usr tree. And that's a GOOD thing... From the original post where I raised the issue: http://www.cygwin.com/ml/cygwin-apps/2003-04/msg00305.html Now, if adopted, I believe that the /opt tree should be RARELY used. I hope we don't see an explosion of official cygwin packages that use it; MOST packages should continue to go into /usr (or /usr/X11R6/) as before. Right now, the only candidates for /opt that I can think of are: kerberos, cvsnt, and the gnu tool replacements that ship with ast-ksh. There was a fair bit of discussion concerning ast-ksh and its tools about six months ago (maybe longer), but I believe that those folks decided to (a) keep their cygwin packages of ast-ksh separate from our mirror system (b) install directly into /usr/bin. But I could be wrong. My old (unsupported, unofficial) kerberos port doesn't install into /opt, but if I ever get around to spinning a new version it will go there. In answer to a question you asked later in the thread concerning man pages and such, it's all spelled out in the FHS -- but I quote again from the above listmessage: --- begin quote --- For more information on the /opt heirarchy, see http://www.pathname.com/fhs/2.2/fhs-3.12.html Basically, a package to be installed under /opt creates an entire tree: /opt/package/bin /opt/package/lib /opt/package/share /opt/package/man /opt/package/info /opt/package/etc (*) /opt/package/var (**) (*) contents may be targets of symlinks originating in /etc/opt/ (**) may be a symlink to /var/opt/package/ The package will look for its config files (if any) in /opt/package/etc/ (e.g. --sysconfdir=/opt/package/etc/), the symlinks from /etc/opt are placed there to assist the sysadmin. There's also an optional /opt/bin, /opt/man, /opt/... set of directories that can OPTIONALLY contain symlinks back to /opt/package/bin/myprog.exe, to prevent PATH / MANPATH / INFOPATH explosion. BUT, packages installed into /opt/package/ MUST work properly even without /opt/bin friends. --- end quote --- Not that this couldn't work. What were down to is just a preference. Somewhere in opt would work; so would /usr/lib/lapack. However, I have no objections if you want to use /usr/lib/lapack/ instead. I assume the roll your own optimized DLLs from -src package procedure will end up putting the new DLLs in... /usr/bin ? Will that also replace the import libs (and pseudo-staticlib symlinks to them) in /usr/lib/ ? Or is the DLL interface absolutely unchanged by this recompile, so that the old import libs are still good? -- Chuck P.S. I've had some experience with LAPACK and ATLAS on other platforms, so I know the trouble it can often be to get this beastie to compile correctly -- and optimally. Kudos for taking on this task!!
Re: lapack 3.0 (OpenGL and ncurses maintainers please take note)
James R. Phillips wrote: --- 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 packaged (the goal of the whole excercise). As I stated in my earlier message, I've no objections to /usr/lib/lapack -- you're the maintainer. However, there are a few nits: (1) aren't there some header files that need to be packaged, as well? (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) 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 the typical DLLPkg-mainPkg-develPkg separation... lapack-X.Y.Z-REL /etc/profile.d/* /usr/share/doc/CYGWIN/* /usr/share/doc/lapack-X.Y.Z/lapack/* /usr/share/doc/lapack-X.Y.Z/blas/* /usr/share/man/* /usr/share/info/* liblapackN-X.Y.Z-REL /usr/lib/lapack/cygblas-N.dll /usr/lib/lapack/cyglapack-N.dll lapack-devel-X.Y.Z-REL /usr/include/lapack/* /usr/include/blas/* /usr/include/* /usr/lib/lapack.dll.a /usr/lib/blas.dll.a /usr/lib/lapack.a /usr/lib/blas.a This is necessary, if, for instance, the blas or lapack interface changes, and you want to release a new version of the DLLs -- but some people might be using your old octave, or *some other client they compiled themselves which you do not control* which needs the old interface and the old DLLs. If they blindly upgrade to the new package, without any safegaurds like this DLL-in-separate-package-with-vernums scheme (liblapackN not liblapack; cyglapack-N.dll not cyglapack.dll), then that upgrade will break their clients. You only bump the DLLnum when existing DLL entrypoints are modified or removed; not merely when new entrypoints are added. Now, blas and lapack are highly stable, and I doubt their interface will change at all. BUT, I have had to bump DLL numbers in the past due to OTHER circumstances, like the grand cygwin 1.3.xx-TO-1.5.xx transition, or because I changed calling conventions ( stdcall vs. cdecl vs. fastcall? You might actually want to look at fastcall for efficiency...but you'd be pioneering on cygwin AFAIK. ) The worst example was when I had to change the interface of ncurses MYSELF, even though the upstream package didn't: it had long exported data items that weren't effectively handled by the pseudo-reloc code (see 'info ld'). However, a new release of ncurses ADDED an entrypoint, which caused clients via macros to access this DATA export; common clients had never before accessed this DATA export, so I never knew there was a problem with it. To correct the issue, I added an accessor method instead and stopped trying to export the DATA directly. This required header file changes to fool upstream clients into using my accessor...and obviously they had to recompile and relink against the new DLL version: I had changed an existing interface. But until the other maintainers released recompiled versions, I didn't want every ncurses-using client to break, so both DLLs had to coexist on the user's machine. Hence, the DLLnum for ncurses is up to 8 now. Sigh. Back on point: regardless, you do NOT need to do anything this fancy right now. In fact, you may never need to -- since lapack/blas is so stable. But header files might be important. :-) -- Chuck
Re: lapack 3.0 (OpenGL and ncurses maintainers please take note)
--- 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 want to use /usr/lib/lapack/ instead. I assume the roll your own optimized DLLs from -src package procedure will end up putting the new DLLs in... /usr/bin ? No, /usr/local/bin. This is more compatible with fhs, since these are local libraries built from source. Will that also replace the import libs (and pseudo-staticlib symlinks to them) in /usr/lib/ ? Or is the DLL interface absolutely unchanged by this recompile, so that the old import libs are still good? Yes, the import libs will be in /usr/lib, and will still be good (by design). I've tested this by building octave, linking against the old import libs, but running with the optimized dll's. Works quite well. The build process for the optimized libraries creates import libraries, but it is not necessary to install them. The atlas compile process also creates (and requires) cblas libraries, but I link those in statically. There are no cblas entry points exposed in the optimized dll's. The import libs are liblapack.dll.a and libblas.dll.a. I provide symlinks for liblapack.a and libblas.a, pointing back to the import libs. This seems to be adequate for autoconf to find the libs; at least it is for building octave. This in effect only provides support for shared libraries. I suppose I could provide a separate package with static libs. I haven't noticed an overwhelming demand for it. ;) so I know the trouble it can often be to get this beastie to compile correctly -- and optimally. Kudos for taking on this task!! Thanks. The nice thing about this package is, once we get it right, it won't need to be updated very often. Jim Phillips
Re: lapack 3.0 (OpenGL and ncurses maintainers please take note)
--- Charles Wilson wrote: As I stated in my earlier message, I've no objections to /usr/lib/lapack -- you're the maintainer. However, there are a few nits: (1) aren't there some header files that need to be packaged, as well? Actually, no. lapack and blas are fortran77 libraries, and fortran77 doesn't require headers. Now if I were delivering a cblas library, headers would be required (cblas is a c interface to the blas). What could reasonably be desired are man pages for all the routines, as well as some kind of index. Debian supplies this stuff in a separate lapack-doc 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) ditto the cygwin specific README /usr/share/doc/Cygwin/lapack-3.0.README OK. Since apparently there hasn't been an upload yet, I'll just fix that before there is. I would also mention that you might (but I doubt it; see below) find it necessary to adopt the typical DLLPkg-mainPkg-develPkg separation... This is necessary, if, for instance, the blas or lapack interface changes, and you want to release a new version of the DLLs -- but some people might be using your old octave, or *some other client they compiled themselves which you do not control* which needs the old interface and the old DLLs. If they blindly upgrade to the new package, without any safegaurds like this DLL-in-separate-package-with-vernums scheme (liblapackN not liblapack; cyglapack-N.dll not cyglapack.dll), then that upgrade will break their clients. [...snip...] Back on point: regardless, you do NOT need to do anything this fancy right now. In fact, you may never need to -- since lapack/blas is so stable. Yes, I could make the package name lapack3, and so forth. Tell you what: I'll append the version number when upstream releases a new version ;). Actually, atlas is in development. It is possible a new stable release will come out in the not too distant future. This wouldn't change the cygwin binary package though; only the source package. The binary package will always supply the blas reference implementation from lapack. If I update the source package with new atlas source, I'll probably just increment the cygwin release digit. Thanks for giving all this a careful vetting. Jim Phillips
Re: lapack 3.0 (OpenGL and ncurses maintainers please take note)
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 /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. 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. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com Red Hat, Inc.
Re: lapack 3.0 (OpenGL and ncurses maintainers please take note)
--- 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 the directory structure of the trial binary package at ftp://antiskid.homelinux.net/pub/lapack It doesn't seem all that complex to me, but if it passes the /opt complex threshold for you, please advise how package subtrees would best be reallocated. I.E. should /opt have its own share/doc subtree, etc. Thanks, Jim Phillips
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 (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: 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.
