octave-gsl: conftest.cpp:52:10: fatal error: 'ov-scalar.h' file not found

[Schamschula (Marius Schamschula)]

Even though I previously pushed [f9a52fee058be438407d02e814d7f7202a038c02/macports-ports] to address this issue, the patch is ignored by the current version of octave mkoctfile.

Also see: ​https://savannah.gnu.org/bugs/index.php?61668

[ryandesign (Ryan Carsten Schmidt)]

In 9f4179bb590086063329e8c3409bf17ea9e57429/macports-ports (master):

octave-gsl: Patch configure, not configure.ac

Closes: #69246

[ryandesign (Ryan Carsten Schmidt)]

I could not reproduce the issue on my Monterey system (even when using the newer MacPorts clang 17 compiler) and I made a guess that that would fix it but it doesn't appear to have done so.

[ryandesign (Ryan Carsten Schmidt)]

So far we only see the problem on our Apple Silicon buildbot machines, not Intel. And I see your config.log is from Apple Silicon. My machine is Intel.

On the macOS 14 Intel build that's working, we see:

checking ov-scalar.h usability... yes
checking ov-scalar.h presence... yes
checking for ov-scalar.h... yes

and on the macOS 14 Apple Silicon build that's failing, we see:

checking ov-scalar.h usability... no
checking ov-scalar.h presence... no
checking for ov-scalar.h... no
configure: error: ov-scalar.h header not found

I verified that the Apple Silicon build does actually contain ov-scalar.h.

The patchfile is only fixing the third test, "checking for ov-scalar.h"; the presence and usability checks are handled by standard autoconf header checking macros.

Checking my own config.log was a little difficult because it gets both created and deleted during the configure phase. I had to cancel the configure phase in progress after it found the headers. Mine says:

configure:3128: checking ov-scalar.h usability
configure:3128: ccache /usr/bin/clang++ -c -pipe -Os -std=c++11 -stdlib=libc++ -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk -arch x86_64 -I/opt/local/include/octave-8.4.0/octave -I/opt/local/include -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk conftest.cpp >&5
configure:3128: $? = 0
configure:3128: result: yes
configure:3128: checking ov-scalar.h presence
configure:3128: ccache /usr/bin/clang++ -E -I/opt/local/include/octave-8.4.0/octave -I/opt/local/include -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk conftest.cpp
configure:3128: $? = 0
configure:3128: result: yes
configure:3128: checking for ov-scalar.h
configure:3128: result: yes

Yours says:

configure:3128: checking ov-scalar.h usability
configure:3128: /usr/bin/clang++ -c -pipe -Os -std=c++11 -stdlib=libc++ -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk -arch arm64 -I -I/opt/local/include -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk conftest.cpp >&5
conftest.cpp:52:10: fatal error: 'ov-scalar.h' file not found
#include <ov-scalar.h>
         ^~~~~~~~~~~~~
1 error generated.
configure:3128: $? = 1
configure: failed program was:
[snip]
configure:3128: result: no
configure:3128: checking ov-scalar.h presence
configure:3128: /usr/bin/clang++ -E -I -I/opt/local/include -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk conftest.cpp
conftest.cpp:19:10: fatal error: 'ov-scalar.h' file not found
#include <ov-scalar.h>
         ^~~~~~~~~~~~~
1 error generated.
configure:3128: $? = 1
configure: failed program was:
[snip]
configure:3128: result: no
configure:3128: checking for ov-scalar.h
configure:3128: result: no
configure:3132: error: ov-scalar.h header not found

Yours is missing the -I/opt/local/include/octave-8.4.0/octave flag that would let it find the header. Investigating why that is, I see that my config.log says at the top:

configure:2185: checking for Octave's canonical_host_type
configure:2193: result: x86_64-apple-darwin21.6.0
configure:2206: checking for Octave's include directory
configure:2214: result: /opt/local/include/octave-8.4.0/octave

while yours says:

configure:2185: checking for Octave's canonical_host_type
configure:2193: result: 
configure:2206: checking for Octave's include directory
configure:2214: result: 

[ryandesign (Ryan Carsten Schmidt)]

It looks like the way it finds these values is to run:

octave -qf --eval "                   \
  if exist ('__octave_config_info__')                       \
    disp  (__octave_config_info__ ('canonical_host_type'))  \
  else                                                      \
    disp  (octave_config_info ('canonical_host_type'))      \
  end"

octave -qf --eval "              \
  if exist ('__octave_config_info__')                 \
    disp  (__octave_config_info__ ('octincludedir'))  \
  else                                                \
    disp  (octave_config_info ('octincludedir'))      \
  end"

On my system these produce the right values:

x86_64-apple-darwin21.6.0

/opt/local/include/octave-8.4.0/octave

What do they do on your system?

[Schamschula (Marius Schamschula)]

I get

aarch64-apple-darwin22.6.0

and

/opt/local/include/octave-8.4.0/octave

respectively.

[ryandesign (Ryan Carsten Schmidt)]

Oh interesting.

Actually I see it's not running octave but /usr/bin/arch -arch arm64 /opt/local/bin/octave-8.4.0. Does that change anything?

[Schamschula (Marius Schamschula)]

Same result both ways.

[ryandesign (Ryan Carsten Schmidt)]

Weird that it works from the command line but not from the configure script.

There's some other weird output in the buildbot logs. It may not be related since it appears on both arm64 and x86_64 builds. On the other hand both builds are missing the canonical host type (whereas it showed up on my local build), it's weird that there appears to be a crash, and it is unexpected that anything in the build is trying to use the pasteboard.

​arm64

checking for Octave's canonical_host_type... PasteBoard: Error creating pasteboard: com.apple.pasteboard.clipboard [-4960]
PasteBoard: Error creating pasteboard: com.apple.pasteboard.find [-4960]
2024-01-29 02:04:53.040 octave-gui[19103:2995538] XType: Using static font registry.
fatal: caught signal Trace/BPT trap: 5 -- stopping myself...

checking for Octave's include directory... PasteBoard: Error creating pasteboard: com.apple.pasteboard.clipboard [-4960]
PasteBoard: Error creating pasteboard: com.apple.pasteboard.find [-4960]
2024-01-29 02:04:54.513 octave-gui[19106:2995595] XType: Using static font registry.
fatal: caught signal Trace/BPT trap: 5 -- stopping myself...

​x86_64

checking for Octave's canonical_host_type... PasteBoard: Error creating pasteboard: com.apple.pasteboard.clipboard [-4960]
PasteBoard: Error creating pasteboard: com.apple.pasteboard.find [-4960]
2024-01-18 11:38:52.719 octave-gui[2976:1781191] XType: Using static font registry.
fatal: caught signal Illegal instruction: 4 -- stopping myself...

checking for Octave's include directory... PasteBoard: Error creating pasteboard: com.apple.pasteboard.clipboard [-4960]
PasteBoard: Error creating pasteboard: com.apple.pasteboard.find [-4960]
2024-01-18 11:38:57.586 octave-gui[2979:1781258] XType: Using static font registry.
fatal: caught signal Illegal instruction: 4 -- stopping myself...
/opt/local/include/octave-8.4.0/octave

[ryandesign (Ryan Carsten Schmidt)]

Oh and I should give this back to you because I don't think I'll be able to work on it further right now.

And it's interesting that the build succeeded on the buildbot on arm64 macOS 11 and 12 back in August when the current version of octave was 8.3.0. It already failed on arm64 macOS 13 back then but the build logs are no longer available to see if it was the same problem we're seeing now.

[Schamschula (Marius Schamschula)]

See the upstream bug report: ​https://savannah.gnu.org/bugs/index.php?61668

[ryandesign (Ryan Carsten Schmidt)]

The upstream bug report is a confusing multi-year jumble of three different unrelated bugs.

The original bug, the one that configure tests fail because main is defined with no return type, was already fixed with the configure/configure.ac patch above.

For the second bug, the one we're discussing here now where the configure script can't determine Octave's canonical_host_type and/or Octave's include directory in some situations, upstream suggested an external 4000-line configure script patch and you said there that it worked. Did you use the entire patch or just pull out the changes relating to CANONICAL_HOST_TYPE and OCTINCLUDEDIR? I don't see that patch in the octave-gsl port yet. I would hate to add a configure patch that huge to any port, but if just those few changes were enough, that wouldn't be too bad.

For the third bug, error: use of undeclared identifier 'feval' and error: no member named 'is_real_type' in 'octave_value', you said it was fixed by a patch we already have.

So what remains to do to resolve this ticket?

[Schamschula (Marius Schamschula)]

Agreed, I'll need to do a triage of which parts of the patch are really needed.

Currently, I'm cleaning up all octave packages after updating the octave PortGroup.

I'll have a look once I'm done with that.

[Schamschula (Marius Schamschula)]

I just tried to run port configure octave-gel w/o and with the mega-patch. Somehow the canonical_host_type goes away when the patch has been applied. I will investigate.

[Schamschula (Marius Schamschula)]

Well, that was simple. canonical_host_type shows up several times.

[Schamschula (Marius Schamschula)]

It looks like the entire patch for src/configure is actually needed:

Without it I see a whole list of errors

/configure: line 3920: ac_fn_cxx_check_func: command not found
./configure: line 3933: ac_fn_cxx_check_func: command not found
./configure: line 3946: ac_fn_cxx_check_func: command not found
./configure: line 3959: ac_fn_cxx_check_func: command not found
./configure: line 3972: ac_fn_cxx_check_func: command not found
./configure: line 3985: ac_fn_cxx_check_func: command not found
./configure: line 3998: ac_fn_cxx_check_func: command not found
...

Only the patches to src/configure.ac and src/configure.ac can be removed. This still is a large patch of 3717 lines.

It would be useful for upstream to fix this set of issues. However, the gsl package appears to be w/o maintainer.

[ryandesign (Ryan Carsten Schmidt)]

I hadn't seen that the patch included not only the several-thousand-line-long configure patch but also the very short patches for configure.ac and configure.ac.in from which the configure patch was generated. I would much rather use the small configure.ac or configure.ac.in patch and run autoreconf than use the huge configure patch. Here's a PR to do that: ​https://github.com/macports/macports-ports/pull/22787

[Schamschula (Marius Schamschula)]

octave-gsl has been removed form MacPorts repository.