On Sep 22, 2004, at 12:42 PM, Camm Maguire wrote:
>> No. We never guarantee binary compatibility between LAM releases --
>> not even between 7.0.x releases.
>
> !!!!! I'm hoping that the content of this hinges on the word
> 'guarantee'. There is a whole lot of software in Debian and
> presumably other distributions which links against lam as a shared
> library. Recompiling it all on 11 architectures will take weeks.
> Needless to say, such actions should be kept to a minimum. Debian has
> been building lam as a shared lib for sometime, before lam had such a
> build option, and so came up with its own soname to define when binary
> incompatible changes force a global recompile. Rightly or wrongly, we
> did this at 6.3->6.5, and 6.5->7.0. I've been meaning to ask you if
> your lam shared lib option uses a soname scheme in a similar fashion.
> I haven't had time to look into it myself.
We should, but don't. :-\ We were going to for 7.1, but got
sidetracked on other issues.
> In any case, I'd really hope that the soname wouldn't change with
> every release, but maybe it does. 'Guarantees' aside, is it *known*
> that binaries compiled against 7.0.6 will break against 7.1? Might we
> have binary compatibility by good fortune with this particular
> transition?
We've actually *never* guaranteed binary compatibility between
releases. We just don't have the time and resources do it,
unfortunately. That being said, MPI applications *usually* will be ok
with the upgrades unless we make major changes to:
- mpi.h
- the inlined C++ bindings
- lam_config.h
These are the only entry points for user applications that need to map
correctly onto the back-end LAM libraries.
I don't *think* that we changed enough in these files to cause a
problem between 7.0.x and 7.1, but I know offhand for sure. You would
have to try it to know. :-\
--
{+} Jeff Squyres
{+} jsquyres_at_[hidden]
{+} http://www.lam-mpi.org/
|
