Re: Octave 3.6.1-rc0 release candidate available for ftp

[Alexander Hansen]

On 2/7/12 4:27 PM, John W. Eaton wrote:
> On  7-Feb-2012, Lukas Reichlin wrote:
> 
> | I attached my MacPorts portfile. It works, but I had to recompile
> my oct-files. Not a tragedy at all, but IIRC, binary compatibility
> used to be a goal for minor revisions (like 3.6.0 to 3.6.1).
> 
> I'm surprised by that because nothing changed in libcruft and the
> only changes to liboctave and liboctinterp were internal.  There
> were no interface changes.  Following the advice of the libtool
> manual:
> 
> http://www.gnu.org/software/libtool/manual/libtool.html#Updating-version-info
>
>  I increased the "revision" version for liboctave and
> liboctinterp. But your old .oct files should still be able to work
> with the new version.  It seems to work correctly for me on my
> Debian system.
> 
> So precisely what was the error that you encountered?
> 
> jwe

I can't speak for Lucas.  However:  the library install_names change
in the default build:

$ otool -L /sw/lib/octave/3.6.1-rc0/libcruft.1.dylib
/sw/lib/octave/3.6.1-rc0/libcruft.1.dylib:
        /sw/lib/octave/3.6.1-rc0/libcruft.1.dylib (compatibility version
2.0.0, current version 2.0.0)

vs.

$ otool -L /sw/lib/octave/3.6.0/libcruft.1.dylib
/sw/lib/octave/3.6.0/libcruft.1.dylib:
        /sw/lib/octave/3.6.0/libcruft.1.dylib (compatibility version 2.0.0,
current version 2.0.0)
.

This is sufficient to render any dynamically linked oct-files on OS X
nonfunctional, irrespective of the symbol content, because OS X
encodes the paths to libraries.  Anything built against Octave-3.6.0's
libraries won't function if they are removed in favor of those from
3.6.1.  This is true for Octave-forge packages, as well as stuff that
users build themselves against the Octave libraries.

-- 
Alexander Hansen, Ph.D.
Fink User Liaison
http://finkakh.wordpress.com/