octave-piqp @0.4.1: sh: /opt/local/bin/clang++-mp-16: No such file or directory

[ryandesign (Ryan Carsten Schmidt)]

​https://build.macports.org/builders/ports-10.11_x86_64-builder/builds/269379/steps/install-port/logs/stdio

sh: /opt/local/bin/clang++-mp-16: No such file or directory

[Schamschula (Marius Schamschula)]

It looks like gcc13-libcxx, which is a build/library requirement for octave, is built using clang-16. So it should be present.

[ryandesign (Ryan Carsten Schmidt)]

gcc13-libcxx has a build dependency on clang-16, so clang-16 is only guaranteed to be present when building gcc13-libcxx. It is not guaranteed to be present when gcc13-libcxx is later used. If gcc13-libcxx has that requirement then clang-16 needs to be changed to a library dependency. But I do not find any occurrences of "clang++-mp-16" in the files installed by the gcc13-libcxx port so I do not think such a change is necessary or appropriate.

This is a case of octave-piqp, and possibly all ports that use octave, not UsingTheRightCompiler. The log shows DEBUG: Using compiler 'Xcode Clang' and CXX='/usr/bin/clang++' and yet a different compiler was used; that is the bug. Additionally, it was trying to use this compiler during the destroot phase; compiling should happen during the build phase.

Downloading the 10.11 binary for octave from the private server, I see that the files /opt/local/bin/mkoctfile-9.2.0, /opt/local/lib/octave/9.2.0/liboctinterp.12.dylib, and /opt/local/lib/octave/9.2.0/liboctinterp.a all contain the string /opt/local/bin/clang++-mp-16. Perhaps octave is trying to use that compiler when compiling octave-piqp and possibly other modules, and needs to be told (by the port or the portgroup) not to do that. It needs to use the compiler MacPorts specifies.

If /usr/bin/clang++ is not usable for compiling octave-piqp and other octave modules, then the normal MacPorts compiler selection mechanisms need to be used to tell MacPorts to select a suitable compiler.

[Schamschula (Marius Schamschula)]

I've looked at my local install (Sonoma/arm64). I get

% otool -L /opt/local/bin/octave
/opt/local/bin/octave:
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 2420.0.0)
	/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 1226.0.0)
	/opt/local/lib/libreadline.8.dylib (compatibility version 8.2.0, current version 8.2.0)
	/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 170.0.0)
	/opt/local/lib/libiconv.2.dylib (compatibility version 9.0.0, current version 9.1.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1345.100.2)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1700.255.0)
	/System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics (compatibility version 64.0.0, current version 1774.4.3)

% mkoctfile -p ALL_LDFLAGS
 -fPIC -L/opt/local/lib/octave/9.2.0 -L/opt/local/lib -bundle -undefined dynamic_lookup -bind_at_load -bundle_loader /opt/local/bin/octave-9.2.0

and

 % otool -L /opt/local/share/octave/packages/piqp-0.4.1/piqp_oct.oct
/opt/local/share/octave/packages/piqp-0.4.1/piqp_oct.oct:
	/opt/local/lib/octave/9.x.x/liboctinterp.dylib (compatibility version 13.0.0, current version 13.1.0)
	/opt/local/lib/octave/9.x.x/liboctave.dylib (compatibility version 12.0.0, current version 12.1.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1700.255.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1345.100.2)

However,

% mkoctfile -p CC                                                  
/usr/bin/clang

and

% mkoctfile -p CXX
/usr/bin/clang++ -std=gnu++11

So octave packages are expected to use the Xcode compilers, unless the package needs Fortran, e.g. octave-control, or specifies a particular version of clang, e.g. octave-molsim.

The octave PortGroup is a little different. It is supposed to compile everything in the configure phase. The build phase does nothing. However, I agree that no compiling should happen in the destroot phase, but it happens all the time for aqua, i.e. Xcode, ports.

[kencu (Ken)]

The custom command used to regenerate packages:

post-activate {
    set octave_install_share ${prefix}/share/octave/packages
    set octave_install_lib   ${prefix}/lib/octave/packages
    system "${prefix}/bin/octave-cli -q -f -H --eval 'try; pkg prefix ${octave_install_share} ${octave_install_lib}; pkg -verbose -global rebuild; disp(lasterror.message); catch; exit(1); end_try_catch;'"
}

probably needs to have the selected compiler sent to it, otherwise it uses the one burned in when it was built:

% /opt/local/bin/mkoctfile-9.2.0 -p CXX
/usr/bin/clang++ -std=gnu++11

% CXX=g++ /opt/local/bin/mkoctfile-9.2.0 -p CXX
g++

[ryandesign (Ryan Carsten Schmidt)]

Replying to Schamschula:

I've looked at my local install (Sonoma/arm64). I get

% mkoctfile -p CC                                                  
/usr/bin/clang

and

% mkoctfile -p CXX
/usr/bin/clang++ -std=gnu++11

Yes, but that's not what happens with the package built on El Capitan:

% ./opt/local/bin/mkoctfile -p CC
/opt/local/bin/clang-mp-16
% ./opt/local/bin/mkoctfile -p CXX
/opt/local/bin/clang++-mp-16

Any port using the compiler specified by mkoctfile is wrong, regardless whether mkoctfile said to use Xcode clang or some MacPorts clang. All ports should use the compiler specified by configure.cc, configure.cxx, etc.

[Schamschula (Marius Schamschula)]

That means mkoktfile needs to be overridden. Perhaps, resetting CC and CXX to the proc octave.add_env similar to what is already done for LD_CXX and DL_LD might do.

[kencu (Ken)]

or some version of:

system "CXX=\"${configure.cxx}\" CC=\"${configure.cc}\" ${prefix}/bin/octave-cli -q -f -H --eval 'try; pkg prefix ${octave_install_share} ${octave_install_lib}; pkg -verbose -global rebuild; disp(lasterror.message); catch; exit(1); end_try_catch;'"