#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.
Attachments (1)
Change History (21)
Changed 10 months ago by Schamschula (Marius Schamschula)
Attachment: | config.log added |
---|
comment:1 Changed 10 months ago by ryandesign (Ryan Carsten Schmidt)
Description: | modified (diff) |
---|
comment:2 Changed 10 months ago by ryandesign (Ryan Carsten Schmidt)
Owner: | set to ryandesign |
---|---|
Resolution: | → fixed |
Status: | new → closed |
comment:3 Changed 10 months ago by ryandesign (Ryan Carsten Schmidt)
Resolution: | fixed |
---|---|
Status: | closed → reopened |
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 10 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 10 months ago by ryandesign (Ryan Carsten Schmidt)
Keywords: | arm64 added |
---|
comment:6 Changed 10 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 10 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 10 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:10 Changed 10 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 10 months ago by ryandesign (Ryan Carsten Schmidt)
Owner: | changed from ryandesign to Schamschula |
---|---|
Status: | reopened → assigned |
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 10 months ago by Schamschula (Marius Schamschula)
See the upstream bug report: https://savannah.gnu.org/bugs/index.php?61668
comment:13 Changed 10 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 10 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 10 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.
comment:16 Changed 10 months ago by Schamschula (Marius Schamschula)
Well, that was simple. canonical_host_type
shows up several times.
comment:17 Changed 10 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: | assigned → closed |
octave-gsl
has been removed form MacPorts repository.
comment:20 Changed 6 months ago by Dave-Allured (Dave Allured)
Cc: | Dave-Allured added |
---|
In 9f4179bb590086063329e8c3409bf17ea9e57429/macports-ports (master):