Re: Problem with 2.1.57 loading Octave binary format data file

[Glenn Golden]

David Bateman writes:
> 
> Note that I made large changes to the load-save stuff around 2.1.53,
> to allow for the saving of arbitrary types and NDArrays. Savinf of
> lists, structs, and cell arrays now works correctly.

I figured it was probably related to those changes, and I did take
a look thru the code to see if I could quickly get a handle on what
was happening. I just didn't have time to get far with it though,
other than that tc.load_binary() itself is returning in error, as
opposed to a problem at a higher level. 

> The changes are fully forward compatiable, so stuff you saved with
> 2.1.50 in any format can be reloaded in 2.1.57. However, the only
> backward compatiable formats are -ascii, -mat4 and -mat5, with
> limitations placed on what you can save, by what 2.1.50 is capable
> of loading.
> 

OK, well that accounts for 2.1.50 not loading the 2.1.57 -binary,
but I wasn't counting on that anyway, I just did that experiment
to see if I could isolate it to load or save.  So I guess there's
no conclusion on that.


> Now to your problem, frankly on Mandrake 9.2 I can't reproduce it. If I
> had to pick on something that is likely to be the issue, I'd say it is 
> your use of g++ 2.96 as the compiler. I'd suggest you use a newer compiler
> than this.
> 

OK, I'll try that this morning.

> You might also like to send me the binary file you saved, and I'll see if
> I can load it. This will isolate the problem to the load or save code.
> But I must admit if the problem is g++ 2.96 might tendancy would be to
> disallow the use of 2.96 in the configuration stage.
> 

I'll send you the binary file directly rather than clutter the list
with it.   And will post to the list my results with newer g++.

Thanks for your help.

Glenn

> 
> According to Glenn Golden <address@hidden> (on 04/01/04):
> > "Dmitri A. Sergatskov" writes:
> > > 
> > > FWIW: I works for me with octave-2.1.57 on both Fedora Core 1 (gcc 3.3.2)
> > > and Sun Solaris (gcc 3.3.3). It also works across (i.e. I can save on
> > > Solaris and open on FC1).  I do not have RH 7.3 around anymore...
> > > 
> > > There were reports of oddities when octave being build on a system which 
> > > has
> > > an older version of octave library installed. You may want to nuke
> > > 2.1.50 [*] and rebuild 2.1.57 from "make distclean" level.
> > >
> > > ([*] "find /usr/local -name "octave*" | xargs rm -rf" works for me)
> > > 
> > 
> > I did what ought to be effectively the same thing, except instead of
> > deleting the files, I just moved them all to /tmp so I can recover 
> > them easily later on.  So when I started the build, there was nothing
> > left under /usr/local matching the regexp 'octave*'.  I then ran
> > 
> >     make distclean
> >     make
> >     make check
> >     make install
> > 
> > all as root. Behavior same as before.
> > 
> > Anyone else out there running RH7.3 (or similar-vintage gnu/linuces)
> > that could check to see whether this is happening for them? Here's the
> > minimal example:
> > 
> >     1>   foo = rand(10);
> >     2>   save("-binary", "bar", "foo")
> >     3>   load bar
> >     error: load: trouble reading binary file `bar'
> > 
> > 
> > I admit that this seems like it's gotta be a build problem on my
> > part, but I sure can't find it.  More or less a vanilla build done
> > in a vanilla way. The only config options were --enabled-shared,
> > --enable-dl, and --enable-lite-kernel. 
> > 
> > > I think the issue was that sometimes the new octave gets linked against
> > > an old octave library. Since search on www.octave.org is not working
> > > I cannot find the relevant post. May be you can check it with ldd,
> > > 
> > 
> > I did that when I first came across the problem, but everything looked
> > right.  Here's the full ldd from the version I just built as per the above::
> > 
> >   liboctinterp.so => /usr/local/lib/octave-2.1.57/liboctinterp.so 
> > (0x40014000)
> >   liboctave.so => /usr/local/lib/octave-2.1.57/liboctave.so (0x40778000)
> >   libcruft.so => /usr/local/lib/octave-2.1.57/libcruft.so (0x40ca9000)
> >   liblapack.so.3 => /usr/lib/liblapack.so.3 (0x40d22000)
> >   libblas.so.3 => /usr/lib/libblas.so.3 (0x4115e000)
> >   libreadline.so.4 => /usr/lib/libreadline.so.4 (0x411a8000)
> >   libncurses.so.5 => /usr/lib/libncurses.so.5 (0x411ce000)
> >   libdl.so.2 => /lib/libdl.so.2 (0x4120d000)
> >   libm.so.6 => /lib/i686/libm.so.6 (0x41210000)
> >   libstdc++-libc6.2-2.so.3 => /usr/lib/libstdc++-libc6.2-2.so.3 (0x41232000)
> >   libc.so.6 => /lib/i686/libc.so.6 (0x42000000)
> >   /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
> > 
> > 
> > - Glenn
> > 
> > 
> > 
> > -------------------------------------------------------------
> > Octave is freely available under the terms of the GNU GPL.
> > 
> > Octave's home on the web:  http://www.octave.org
> > How to fund new projects:  http://www.octave.org/funding.html
> > Subscription information:  http://www.octave.org/archive.html
> > -------------------------------------------------------------
> 
> -- 
> David Bateman                                address@hidden
> Motorola CRM                                 +33 1 69 35 48 04 (Ph) 
> Parc Les Algorithmes, Commune de St Aubin    +33 1 69 35 77 01 (Fax) 
> 91193 Gif-Sur-Yvette FRANCE
> 
> The information contained in this communication has been classified as: 
> 
> [x] General Business Information 
> [ ] Motorola Internal Use Only 
> [ ] Motorola Confidential Proprietary



-------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.octave.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------