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.

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?

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?

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.

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.
Examples:

>>>>> 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).

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?

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.

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:
/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:
failed to load: No such process

I will appreciate a verification on other systems