Opened 9 months ago

Closed 6 months ago

Last modified 6 months ago

#69246 closed defect (wontfix)

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

Reported by: Schamschula (Marius Schamschula) Owned by: Schamschula (Marius Schamschula)
Priority: Normal Milestone:
Component: ports Version:
Keywords: arm64 haspatch Cc: Dave-Allured (Dave Allured)
Port: octave-gsl

Description (last modified by ryandesign (Ryan Carsten Schmidt))

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

Attachments (1)

config.log (17.7 KB) - added by Schamschula (Marius Schamschula) 9 months ago.

Download all attachments as: .zip

Change History (21)

Changed 9 months ago by Schamschula (Marius Schamschula)

Attachment: config.log added

comment:1 Changed 9 months ago by ryandesign (Ryan Carsten Schmidt)

Description: modified (diff)

comment:2 Changed 9 months ago by ryandesign (Ryan Carsten Schmidt)

Owner: set to ryandesign
Resolution: fixed
Status: newclosed

In 9f4179bb590086063329e8c3409bf17ea9e57429/macports-ports (master):

octave-gsl: Patch configure, not configure.ac

Closes: #69246

comment:3 Changed 9 months ago by ryandesign (Ryan Carsten Schmidt)

Resolution: fixed
Status: closedreopened

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.

comment:4 Changed 9 months ago by 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: 

comment:5 Changed 9 months ago by ryandesign (Ryan Carsten Schmidt)

Keywords: arm64 added

comment:6 Changed 9 months ago by 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?

comment:7 Changed 9 months ago by Schamschula (Marius Schamschula)

I get

aarch64-apple-darwin22.6.0

and

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

respectively.

comment:8 Changed 9 months ago by 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?

comment:9 Changed 9 months ago by Schamschula (Marius Schamschula)

Same result both ways.

comment:10 Changed 9 months ago by 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

comment:11 Changed 9 months ago by ryandesign (Ryan Carsten Schmidt)

Owner: changed from ryandesign to Schamschula
Status: reopenedassigned

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.

comment:12 Changed 9 months ago by Schamschula (Marius Schamschula)

comment:13 Changed 9 months ago by 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?

comment:14 Changed 9 months ago by 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.

comment:15 Changed 9 months ago by Schamschula (Marius Schamschula)

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

Last edited 9 months ago by Schamschula (Marius Schamschula) (previous) (diff)

comment:16 Changed 9 months ago by Schamschula (Marius Schamschula)

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

comment:17 Changed 9 months ago by 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.

comment:18 Changed 9 months ago by ryandesign (Ryan Carsten Schmidt)

Keywords: haspatch added

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

comment:19 Changed 6 months ago by Schamschula (Marius Schamschula)

Resolution: wontfix
Status: assignedclosed

octave-gsl has been removed form MacPorts repository.

comment:20 Changed 6 months ago by Dave-Allured (Dave Allured)

Cc: Dave-Allured added
Note: See TracTickets for help on using tickets.