[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Problem with 2.1.57 loading Octave binary format data file
From: |
Glenn Golden |
Subject: |
Re: Problem with 2.1.57 loading Octave binary format data file |
Date: |
Thu, 01 Apr 2004 08:16:49 -0700 |
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
-------------------------------------------------------------
- Re: Problem with 2.1.57 loading Octave binary format data file, David Bateman, 2004/04/01
- Re: Problem with 2.1.57 loading Octave binary format data file,
Glenn Golden <=
- Re: Problem with 2.1.57 loading Octave binary format data file, Dmitri A. Sergatskov, 2004/04/01
- Re: Problem with 2.1.57 loading Octave binary format data file, David Bateman, 2004/04/01
- Re: Problem with 2.1.57 loading Octave binary format data file, Dmitri A. Sergatskov, 2004/04/01
- Re: Problem with 2.1.57 loading Octave binary format data file, Glenn Golden, 2004/04/01
- Re: Problem with 2.1.57 loading Octave binary format data file, Przemek Klosowski, 2004/04/01
- Re: Problem with 2.1.57 loading Octave binary format data file, Glenn Golden, 2004/04/01