bugGNU Octave - Bugs: bug #48601, 4.0.3 has build packages mismatch...


bug #48601: 4.0.3 has build packages mismatch with 4.0.1

Submitter:  marco atzeri <matzeri>
Submitted:  Sat 23 Jul 2016 01:22:56 PM UTC
Category:  Configuration and Build System Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Regression
Status:  Works For Me Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * 4.0.3 Operating System:  * Microsoft Windows
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment (Rich Markup)

Comment Type & Canned Response:


( Jump to the original submission )

Mon 21 Nov 2016 03:16:50 AM UTC, comment #14: 

Ok, closing as works for me. Sorry we weren't able to converge on a solution here. Please pursue again if this happens in a future patch-level release of Octave.

Mike Miller <mtmiller>
Project Administrator
Sun 20 Nov 2016 06:39:04 AM UTC, comment #13: 

As 4.2 is out the problem is not relevant anymore,
and I have no time to work anyway due to changes on my real job.
Please close it, I will rebuild all directly for 4.2

Is it possible that is a gcc mismatch, but it does not explain
why I can load new package on old 4.0.1

marco atzeri <matzeri>
Fri 04 Nov 2016 02:26:56 AM UTC, comment #12: 

Marco - I still have no insight into this problem and no way to test this, other than still confirm that I can load oct files that are built with 4.0.1 in Octave 4.0.3 on my system.

This is a stab in the dark guess, but is it possible that Octave 4.0.1 was built for cygwin with either GCC 4.x or with GCC 5 but using the old std::string / std::list ABI? And Octave 4.0.3 is being built with GCC using the new std::string / std::list ABI? I would be more sure about this if the error message were something like "foo.oct: failed to load: foo.oct: undefined symbol: <mangled symbol string>".

You can check whether the symbol ABIs match up using nm or objdump on the Octave shared libraries or on the oct files themselves. For example, the octave_mkdir public function takes a std::string parameter, so it's a good candidate to search for

$ objdump -T /opt/gnu/octave/lib/octave/4.0.1/liboctinterp.so | grep octave_mkdir
0000000000000000       F *UND*        0000000000000000              _Z12octave_mkdirRKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEjRS4_

Do the same functions in the 4.0.1 and 4.0.3 shared libraries match up? Does an oct file compiled with a call to octave_mkdir use the cxx11 or non-cxx11 ABI variant?

Mike Miller <mtmiller>
Project Administrator
Thu 11 Aug 2016 06:09:06 AM UTC, comment #11: 

Mike, all oct's I tested had the problem. In both directions:
octave 4.0.3 was not loading 4.0.1 built oct files and 4.0.1
was not loading the 4.0.3 ones.

Oct files are linked with the Octave libraries
For what I see the SONAME of the octave libraries is the same between 4.0.1 and 4.0.3.

This problem raised only between 4.0.1 and 4.0.3.
It was not present between 4.0.0 and 4.0.1.

Never built 4.0.2 as it was supposed to solve only a specific windows problem not impacting cygwin.

marco atzeri <matzeri>
Wed 10 Aug 2016 08:07:11 PM UTC, comment #10: 

Marco - still curious if this bug applies to any trivial oct file or whether it's only for particular oct files in particular Forge packages.

Does this possibly have to do with how linking of shared objects is done on cygwin and/or Windows? Does an oct file have to be linked against the liboctave and liboctinterp dlls that it was built for? And if so, does trying to load that oct file in a different version of Octave that links with a different set of liboctave and liboctinterp dlls cause a conflict?

Do you have precedence that this was not a problem in earlier versions of Octave, say 4.0.0 to 4.0.1? Is it because the liboctave and liboctinterp library revision numbers were incremented between version 4.0.1 and 4.0.2?

Mike Miller <mtmiller>
Project Administrator
Fri 05 Aug 2016 06:57:57 PM UTC, comment #9: 

I've found the deeper reason for my observed behavior, and opened a new bug report: bug #48710.

Hartmut <hardy>
Fri 05 Aug 2016 05:13:54 PM UTC, comment #8: 

If I'm interpreting both of your posts, I think Hartmut's problem has something to do with the load path being set when "pkg load" runs, while Marco's path seems to be correct, contains the .oct files in question, but they refuse to load.

Hartmut, if you explicitly add the "missing" directory to your path with addpath(), does everything start working? If that is the problem for you, please report a separate bug about pkg load not setting up the path.

Marco, can you reproduce this problem with a trivial "Hello world" oct file, or is it only with certain oct files in certain packages? I have only tested control and signal so far, I could try netcdf to see if it happens there.

Mike Miller <mtmiller>
Project Administrator
Fri 05 Aug 2016 03:38:04 PM UTC, comment #7: 



is the correct path of the oct file as I am building all cygwin packages in dedicated stage area. In this case:


I had the same failures when I installed the 4.0.3 binary
and started to use all the packages built with 4.0.1
in the usual location

marco atzeri <matzeri>
Fri 05 Aug 2016 12:01:50 PM UTC, comment #6: 

Running the tests of the signal package (as in comment #3) with the full path string (no tilde any more) I get "PASS   454, FAIL  48, XFAIL  1". And according to the generated fntest.log the failing tests are due to not finding the oct-file of the signal package.

>>>>> processing /home/hartmut/octave/signal-1.3.2/fracshift.m
***** test
!!!!! test failed
'upfirdn' undefined near line 110 column 11

>>>>> processing /home/hartmut/octave/signal-1.3.2/fwht.m
***** assert (fwht (zeros (16)), zeros (16));
!!!!! test failed
'__fwht__' undefined near line 88 column 9

When I try the test procedure from comment #5 I also get the same result: "PASS   454, FAIL  48, XFAIL  1".

So my original observation seems to stay valid (on my Ubuntu system): Octave 4.0.3 does not find the compiled package oct-files any more.

When I do "pkg load signal, test fwht" in Octave 4.0.3 I get "...!!! test failed... _fwht_ undefined", when I do the same command in Octave 4.0.1 I get "PASSES 14 out of 14 tests".

The root cause may be:

  • In Octave 4.0.3 the path functions gives me a list that contains ".../octave/signal-1.3.2" but NOT ".../octave/signal-1.3.2/x86_64-unknown-linux-gnu-api-v50+".
  • In Octave 4.0.1 the path functions gives me both above mentioned paths.

Note: The ".../octave/signal-1.3.2/x86_64-unknown-linux-gnu-api-v50+" part is the very first entry in my Octave search path. Somehow it got chopped off in Octave 4.0.3!

Can someone else have a look at the output of "path" in Octave, if it seems that the first line is chopped off? Normally each loaded package should have the package folder there, as well as the subfolder with the compiled oct-files (if it has any). I first observed the problem with the image package (de-installing and installing removed the problem). And now I have this problem with the signal package (I have not de-installed and re-installed, yet).

Hartmut <hardy>
Thu 04 Aug 2016 08:28:29 PM UTC, comment #5: 

This works the same for me in Octave 4.0.1 and 4.0.3

pfx = pkg ("prefix");
pkg load signal
__run_test_suite__ ({[pfx "/signal-1.3.2"]}, {})

where `pfx` is the same in both versions and the `path` function and test output verifies that it is using the same compiled oct files.

Mike Miller <mtmiller>
Project Administrator
Thu 04 Aug 2016 08:03:49 PM UTC, comment #4: 

I am unable to reproduce this (on Debian, unable to test on Windows). I just made fresh builds of Octave 4.0.1 and 4.0.3. I installed the control and signal packages in 4.0.1. The packages load and run correctly. I then started Octave 4.0.3 and pointed it to my 4.0.1 package path, and everything still loads and runs correctly.

Harmut: not every function in Octave does tilde expansion, try running the first command again with the full path, or use the function tilde_expand. This seems unrelated.

help upfirdn  ## works
test fwht     ## works, calls __fwht__ compiled function
help sosfilt  ## works

Marco: is "/cygdrive/e/cyg_pub/devel/octave-forge/arch/octave-netcdf-1.0.11-1.i686/inst/usr/lib/octave/packages/netcdf-1.0.11/i686-pc-cygwin-api-v50+/__netcdf__.oct" the correct path? That looks suspicious. Are packages installed with -local or -global in your environment? What is the pkg prefix supposed to be?

Mike Miller <mtmiller>
Project Administrator
Thu 04 Aug 2016 06:32:42 AM UTC, comment #3: 

When I run this:

pkg load signal
__run_test_suite__ ({'~/octave/signal-1.3.2'}, {})

Then I get "PASS    0, FAIL     " as result, no passes at all, but no fails either. The resulting file fntests.log shows a lot of lines like this:

>>>>> processing ~/octave/signal-1.3.2/barthannwin.m
????? ~/octave/signal-1.3.2/barthannwin.m does not exist in path

Nevertheless "test barthannwin" gives me 7/7 passing tests, so Octave somehow DOES find the m-file barthanwin.m. (But does NOT find the compiled oct-file of the signal package.)

Can anyone make sense out of this?

Hartmut <hardy>
Thu 04 Aug 2016 04:36:47 AM UTC, comment #2: 

It is similar behavior.
Octave 4.0.3 can not load the octfile built by 4.0.1.

You could be able to test all the functions with

_run_test_suite_ (testdir}, {})

testdir in your case should be ~/octave/signal-1.3.2.
All function tests depending on the oct file should fail.

marco atzeri <matzeri>
Wed 03 Aug 2016 07:56:24 PM UTC, comment #1: 

I might see something similar on linux (Ubuntu 14.04):

I have several packages installed with Octave 4.0.1 (or earlier) in ~/octave. After loading this packages in Octave 4.0.3 (both self compiled version from official release tar-balls), I do get help texts for m-file functions, but NOT for compiled oct-functions.

For example:

pkg load signal  % version 1.3.2 installed
help bilinear % m-file -> works fine
help sosfilt  % oct-file -> throws a "missing function" error

Or is this behavior something different than the original post?

Hartmut <hardy>
Sat 23 Jul 2016 01:22:56 PM UTC, original submission:  

on cygwin 32 and 64 bit.

The forge packages previously built with 4.0.1
don't load on version 4.0.3 (and reverse).
Every version is able to load packages built with itself.

error: import_netcdf:
failed to load: No such process

I will appreciate a verification on other systems

marco atzeri <matzeri>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

   bug dependencies.


Carbon-Copy List
  • -email is unavailable- added by rjbailey
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by hardy (Posted a comment)
  • -email is unavailable- added by matzeri (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only project members can vote.





    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-11-21 mtmiller Open/ClosedOpen Closed
    2016-08-10 rjbailey Carbon-Copy- Added rjbailey
    2016-08-10 mtmiller Dependencies- bugs #48735 is dependent
    2016-08-04 mtmiller StatusNone Works For Me

    Back to the top

    Powered by Savane 3.9