> > Also on the fantasy wish list is for the libraries to
> > be installed in libtool form (unless you go away from autotools
> > altogether).
>
> Do you mean install the .la files as well as the usual .so and .a
> files? If so, we already do that. If you mean something else, could
> you ex
[an aside for the mailing list admin before the main message:
I want to subscribe a secondary address
and then check the box that
says nomail in the mailman membership list.
The secondary address can post mail but runs no
server to accept inbound mail, which tends to squish
the confirm portion of
On Wed, Jun 15, 2005 at 08:27:58PM -0400, Jeff Squyres wrote:
> On Jun 15, 2005, at 7:02 PM, Ben Allan wrote:
>
> Ah -- I thought that that would be a different issue (I presume you're
> speaking of the compile/lib flags command, like gnome-config et
> al.)...? Are you say
> > It takes time to incorporate a new mpi implementation (and yet
> > another set of awful build requirement peculiarities) into a
> > a package like mine that is expected to be portable and to cope
> > seamlessly with every mpi that comes along.
>
> What is your tool, BTW?
Well, several. Primar
On Thu, Jun 16, 2005 at 06:33:51PM -0400, Jeff Squyres wrote:
> On Jun 16, 2005, at 2:58 PM, Ben Allan wrote:
>
> The only reason to have something like ompiConf.sh is to use the
> frameworks that already exist (like the gnome-conf thingy). I was only
> tossing that out as
Please paste the quoted text (appropriately expanded)
into a readme or install or some other prominent doc location/appendix
as soon as possible if it isn't there already.
Details like this matter a lot to a few of us,
and many of us haven't drunk completely the 3000 gallons of twisted logic
that
Having been a vict^H^H^H^Hproducer of rpms for hpc apps,
and from what i've seen of your installed files (which isn't an
extremely large set) I vote as follows:
1) all-in-one. given the current state of HPC, nearly all "users"
are also developers.
2) I'm in favor of source rpms, most particularl
Please see
Re: [O-MPI users] Questions on status Jeff Squyres (2005-06-15 19:56:09)
in
http://www.open-mpi.org/community/lists/users/2005/06/date.php
and the long related message thread for clarification on the limitations
of the alpha testing and the plans for beta testing.
in the meantime, mpi
Hi again,
We have a number of applications interested in mixing java and
mpi on clusters. (I know, shudder, but we do...)
I thought before I go off and hack that I should see if work
is already on-going, if quiet, for open-mpi to have a java and/or gcj
binding. Clearly there might be some issues
might present a
chance to create a defacto standard in preparation for
extending the standard to include java. Clearly not
high on everybody's list of favorite things to think about.
Ben
On Fri, Jul 15, 2005 at 11:18:31AM -0400, Jeff Squyres wrote:
> On Jul 15, 2005, at 10:55 AM, Be
I'm dealing with mixed language requirements, the babel interoperability
tool from LLNL, gcj and whatever other mpis or javas I may have to resort
to. Good to hear others more or less hit the same issues with
mpi-java prototypes that are published.
Ben
On Fri, Jul 15, 2005 at 04:04:27PM -0400, Sc
Hi,
I deal with mixed-language c/c++/fortran codes and
it appears I might be able to define an inter-language
opaque reference (e.g. a Comm) as C int64t for passing
to fortran and using the MPI_Comm_c2f/f2c macros to encode/decode it on the C
side.
The MPI standard says that on the FORTRAN side
rs, I can post a patch
somewhere to address this. It appears that of these, only
sizeof_int affects more than a few source files.
thanks,
Ben Allan
On Wed, Feb 20, 2008 at 06:15:27AM -0700, Jeff Squyres wrote:
> The #defines that are mpi.h are limited to the ones that we need for
> that file itself. More specifically: the majority of the #define's that
> are generated via OMPI's configure are not in mpi.h.
And that's much appreciated.
>
A build-related questions about 1.1.4
Is parallel make usage (make -j 8) supported (at least if make is gnu?).
thanks,
Ben
What you really want, after configure has confirmed openmpi with the
macro check, is to extract the libraries listed in the output of
mpif90 -v test.f
that are needed.
Ideally someone could update ompi_config to output the link flags for 3 cases:
C++ linking without using mpicxx
F90 linking with
Jeff is right-- if you've already confirmed ompi,
just use the ompi specific arguments to get the
MPI LDFLAGS out. I withdraw the comment about adding
a feature to ompi_info.
It is unfortunate, but true, that the mpi compiler wrappers
give no hint of the existence of -show, --showme:link, etc
befo
s almost certain to be slower.
Where things get interesting (and encouraging) is if you increase
the total data being processed (hold data quantity per node constant).
ben allan
On Thu, Jun 07, 2007 at 08:24:03PM -0400, Aaron Thompson wrote:
> Hello,
> Does anyone have experience usin
18 matches
Mail list logo
