cygwin packaging approach for atlas3.6 and lapack3
Sun Jun 26 16:38:00 GMT 2005
On Sat, 25 Jun 2005, James R. Phillips wrote:
> --- Igor Pechtchanski <pechtcha@XX.XXX.XXX> wrote:
> > Why not include a postinstall script for atlas that would compile and
> > install the executables?
> The atlas compilation and optimization process takes up to an hour or
> two, or even longer if full optimization is requested. It also requires
> user interaction. These two features render it unsuitable for a
> postinstall script.
Ah, yes, that's definitely a complication. I assume the user interaction
is required to either find out about the architecture (which is likely
available from some tool or another) or to set compilation parameters (for
which one could pick reasonable defaults). But the two-hour compilation
time is indeed a showstopper (though there were precedents ];-> ).
> > Would it be possible to build a helper DLL that would look for and
> > load the atlas DLLs dynamically? That way, you don't have to replace
> > existing DLLs (always a shaky proposition).
> I dunno. My best programming language is matlab/octave m-file. I can
> write simple console programs in C, but I have never developed systems
> software for windows.
Building a DLL isn't hard. Writing a function that dlopen's a DLL and
checks for the return value isn't very hard either. This isn't
systems-level stuff... It all depends on the amount of time you'd like to
invest in this, of course.
> > The problem with your approach is that if you install both the binary and
> > the source packages, and then upgrade the binary package, the optimized
> > versions will be gone. I'd prefer the postinstall solution, combined with
> > a helper DLL that delegates to either the default or the optimized DLLs.
> > Igor
> Agreed, this is an issue. It is ameliorated by slow release cycles for
> atlas and lapack. Actually there hasn't been a new lapack release since
> 2000/05. atlas is under active development, but stable releases tend to
> be a year or more apart.
This is not a question of release cycles. If someone reinstalls the
current version of lapack, they'll lose the optimized atlas DLLs just as
surely as they would on an upgrade. Besides, if there are packaging or
Cygwin-specific problems, you may want to make a few Cygwin releases based
on the same upstream versions of lapack/atlas, which the users would have
to upgrade to.
How does the Linux version of atlas handle these issues? Does it use
symlinks to shared libraries?
> Thanks for your thoughts.
|\ _,,,---,,_ firstname.lastname@example.org
ZZZzz /,`.-'`' -. ;-;;,_ email@example.com
|,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
More information about the Cygwin-apps