Re: [pooma-dev] Re: pooma-dev Digest 23 Jun 2003 12:57:44 -0000 Issue 243

[John H. Hall]

Richard, et al.:
Shared libraries are big deal for the old major customer of POOMA, the 
Blanca Project. Link times with shared libraries were minutes compared 
to hours for static libraries. While a final optimized release might 
not want to rely on shared libraries fro some performance aspect, the 
debug cycle will probably need them. On the SGI's and Q machines almost 
all the system libraries are shared libraries, so I am not really sure 
what impact shared libraries have on the final code performance.
John Hall

On Thursday, June 26, 2003, at 12:23  PM, Richard Guenther wrote:

> On 23 Jun 2003, Mark Mitchell wrote:
>
> > > Ok, the things I am able to spent time on are:
> > > - use autoconf/automake/libtool to get rid of current build system
> >
> > I'd rather see us avoid automake and libtool, if we can.  I don't 
> > think
> > we should need automake if we use GNU make, probably.  I'm not sure
> > about libtool, but adding libtool to a build process seems to make it
> > complex, fragile, and slow almost all of the time...
> >
> > After all, POOMA is only going to be used on a few real systems these
> > days -- not a whole lot of 68K HP-UX boxes running POOMA...
>
> Ok, I can see this makes sense somehow. The only problem I see is 
> building
> shared libraries - though I think usage of shared libaries in high
> performance computation is very rare. Though, of course, using automake
> will help doing dependencies and installation rules. So while I'm in
> favour of dropping shared library support (and such libtool), I'd be
> rather not willing to miss automake.
>
> > > In this process we're going to loose a lot of the current configure
> > > options, also (initially) support for tau, paws, etc. (but cheetah).
> >
> > Yes, I'm not sure how much people need those things these days, but we
> > can add them back with --enable-tau, etc.
>
> Yes. Last time I checked, most of those packages are neither maintained
> anymore, nor do they compile on recent compilers/distros.
>
> > > If more people like to work on this, this can be done on a branch, 
> > > if not,
> > > I can try to do this locally in a bk repository.
> >
> > A branch is probably a good idea.
>
> Yes, I think so, too. Jeffrey?
>
> Richard.