Christian Bell wrote:
> On Mon, 15 Oct 2007, Brian Barrett wrote:
>
>> No! :)
>>
>> It would be good for everyone to read the Libtool documentation to
>> see why versioning on the release number would be a really bad idea.
>> Then comment. But my opinion would be that you should change
BTW, Here's the documentation I was referring to:
http://www.gnu.org/software/libtool/manual.html#Versioning
Now, the problem Open MPI faces is that while our MPI interface
rarely changes (and almost never in a backwards-incompatible way),
the interface between components and libraries
Ok, having read the libtool docs now, I see why the release number is
a bad idea. :-)
I'm assuming that:
- The libmpi interface will rarely change, but we may add to it over
time (there's a specific point about this in the libtool docs -- no
problem)
- The libopen-rte interface
Christian Bell wrote:
On Mon, 15 Oct 2007, Brian Barrett wrote:
No! :)
It would be good for everyone to read the Libtool documentation to
see why versioning on the release number would be a really bad idea.
Then comment. But my opinion would be that you should change based
on
On Mon, 15 Oct 2007, Brian Barrett wrote:
> No! :)
>
> It would be good for everyone to read the Libtool documentation to
> see why versioning on the release number would be a really bad idea.
> Then comment. But my opinion would be that you should change based
> on interface
No! :)
It would be good for everyone to read the Libtool documentation to
see why versioning on the release number would be a really bad idea.
Then comment. But my opinion would be that you should change based
on interface changes, not based on release numbers.
Brian
On Oct 15,
I have had several people try the temp branch, and things are looking ok.
Therefore, I am planning on moving this change into the trunk (hopefully)
later this week. Please let me know if there are outstanding problems that
have not been reported back to the list.
Thanks,
Rich
--
Rolf --
I didn't object to this RFC, but I didn't understand that you were
going to *always* have a valid output stream for mca_btl_base_output
(vs. being -1 when verbosity was not enabled).
Is this what you meant to do? It enabled some output from the openib
btl (on the trunk) when
WHAT: Add versioning to all OMPI libraries so that shared libraries
use the real version number in the filename (vs. the current "*.so.
0.0.0")
WHY: It's a Good Thing(tm) to do.
WHERE: Minor changes in a few Makefile.am's; probably some small
tweaking to top-level configure.ac and/or some
Agreed. Mohamad -- can you fix?
On Oct 15, 2007, at 11:42 AM, Josh Hursey wrote:
I'm getting the following from 'uh'. The problem is that they supply
'-np' with no argument. The submit script is rejecting the submit, so
the database is fine. I think this is a user problem, but it kind of
I'm getting the following from 'uh'. The problem is that they supply
'-np' with no argument. The submit script is rejecting the submit, so
the database is fine. I think this is a user problem, but it kind of
looks like a client problem.
Thought I would post to see if anyone has any
Hi,
Each time a someone needs to wait for request completion he
implements the same piece of code. Why not put this code into
inline function and use it instead. Look at the included patch, it
moves the common code into ompi_request_wait_completion() function.
Does somebody have any objection
Can an RM approve https://svn.open-mpi.org/trac/ompi/ticket/1153 for
1.2.5?
It's a fix for the upgrade to AM 1.10 for the Objective C (OSX)
support in OMPI that was broken in 1.2.4.
--
Jeff Squyres
Cisco Systems
13 matches
Mail list logo
