[Octave-bug-tracker] [bug #56171] [octave forge] (control) fails to build and install

[Andrew Janke]

Follow-up Comment #3, bug #56171 (project octave):

This does sound like a local configuration issue or a Homebrew formula
definition or "bottling" issue.

On my macOS 10.14.4 box with Xcode 10.2 installed, `pkg install -forge
control` succeeds for me in Octave.app 5.1.0 beta 3, which is a customized
Homebrew-based installation. (Raises warnings as usual, but the actual build &
installation succeeds.) But Octave.app uses customized formulae and builds
everything from source, so that doesn't necessarily reflect what's happening
with core Homebrew octave installs.

On my vanilla Homebrewed Octave 5.1.0 installation, however, it's busted.
Different error message, but definitely busted:


octave:5> ver
----------------------------------------------------------------------
GNU Octave Version: 5.1.0 (hg id: d05d6eebde10)
GNU Octave License: GNU General Public License
Operating System: Darwin 18.5.0 Darwin Kernel Version 18.5.0: Mon Mar 11
20:40:32 PDT 2019; root:xnu-4903.251.3~3/RELEASE_X86_64 x86_64
----------------------------------------------------------------------
no packages installed.
octave:6> pkg install -forge control
[...]
warning: LFLAGS is deprecated and will be removed in a future version of
Octave, use LDFLAGS instead
ld: warning: directory not found for option
'-L/usr/local/opt/gcc/lib/gcc/8/gcc/x86_64-apple-darwin18.2.0/8.3.0'
ld: warning: directory not found for option
'-L/usr/local/opt/gcc/lib/gcc/8/gcc/x86_64-apple-darwin18.2.0/8.3.0/../../..'
ld: library not found for -lgfortran
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
make: *** [__control_slicot_functions__.oct] Error 1
tar -xzf slicot.tar.gz
/usr/local/Cellar/octave/5.1.0/bin/mkoctfile-5.1.0 -Wall
-Wno-deprecated-declarations  __control_helper_functions__.cc
mkdir sltmp
mv slicot/src/*.f ./sltmp
mv slicot/src_aux/*.f ./sltmp
cp TG04BX.fortran ./sltmp/TG04BX.f
cp TB01ZD.fortran ./sltmp/TB01ZD.f
cd sltmp; /usr/local/Cellar/octave/5.1.0/bin/mkoctfile-5.1.0 -c *.f
ar -rc slicotlibrary.a ./sltmp/*.o
rm -rf sltmp slicot
LFLAGS="-L/usr/local/Cellar/octave/5.1.0/lib/octave/5.1.0
-L/usr/local/Cellar/octave/5.1.0/lib  -L/usr/local/opt/veclibfort/lib
-lvecLibFort 
-L/usr/local/opt/gcc/lib/gcc/8/gcc/x86_64-apple-darwin18.2.0/8.3.0
-L/usr/local/opt/gcc/lib/gcc/8/gcc/x86_64-apple-darwin18.2.0/8.3.0/../../..
-lgfortran -lquadmath -lm" \
    /usr/local/Cellar/octave/5.1.0/bin/mkoctfile-5.1.0 -Wall
-Wno-deprecated-declarations  __control_slicot_functions__.cc common.cc
slicotlibrary.a

pkg: error running `make' for the control package.
error: called from
    configure_make at line 99 column 9
    install at line 184 column 7
    pkg at line 441 column 9
octave:6>


My Homebrew and overall OS installation on this box are pretty well managed
imho, so it's less likely to be a local configuration issue here.

gfortran linkage issue? gfortran is provided by gcc.

The gcc Homebrew formula has been updated recently, and the octave
formula/bottle has not been updated since:


$ brew log gcc | head -6
commit ddde81887459bc4855031fb5b6919032f35f277b
Author: BrewTestBot <address@hidden>
Date:   Fri Apr 19 09:46:10 2019 +0000

    gcc: update 8.3.0_1 bottle.

[~]
$ brew log octave | head -6
commit 33a5454868538fee44e7d398b5259b95a5f53f44
Author: BrewTestBot <address@hidden>
Date:   Tue Mar 26 20:40:27 2019 +0000

    octave: update 5.1.0 bottle.


Often, when a Homebrew formula is updated, its dependencies that have binary
linkage to it must also be updated, with a "revision bump" that's just a
rebuild to update the bottle to link against the new dependency's build. That
may well be what's happening here. Normally, Homebrew's CI infrastructure
detects these linkage problems because it runs `brew test` on all the updated
formula's dependents. But `brew test` on octave does not involve installing
Octave Forge packages, or doing any C/C++/Fortran/mkoctfile compilation. And
the Octave installation does not have direct linkage to the gcc libraries (I
think). So it may well have missed this.

Reinstalling `octave` from source fixed it for me.


[~]
$ brew uninstall octave
Uninstalling /usr/local/Cellar/octave/5.1.0... (2,261 files, 53.5MB)
[~]
$ brew install -s octave
==> Downloading https://ftp.gnu.org/gnu/octave/octave-5.1.0.tar.xz
########################################################################
100.0%
==> ./configure --prefix=/usr/local/Cellar/octave/5.1.0 --disable-silent-rules
--enable-link-all-dependencies --enable-shared --disable-static
--with-hdf5-includedir=/usr
==> make all
==> make install
🍺  /usr/local/Cellar/octave/5.1.0: 2,261 files, 53.8MB, built in 9 minutes
2 seconds
[~]
$ octave
octave:1> pkg install -forge control
warning: LFLAGS is deprecated and will be removed in a future version of
Octave, use LDFLAGS instead
[...]
warning: LFLAGS is deprecated and will be removed in a future version of
Octave, use LDFLAGS instead
ld: warning: could not create compact unwind for _sb10yd_: stack subq
instruction is too different from dwarf stack size
ld: warning: could not create compact unwind for _mb03xp_: stack subq
instruction is too different from dwarf stack size
For information about changes from previous versions of the control package,
run 'news control'.
octave:2> pkg list
Package Name  | Version | Installation directory
--------------+---------+-----------------------
     control  |   3.2.0 | /Users/janke/octave/control-3.2.0
octave:3>


This is consistent with the Homebrew bottle needing a rebuild to account for
the gcc update.

Please report this downstream to Homebrew core at
https://github.com/Homebrew/homebrew-core/issues. Tell them specifically that
"octave may need a revision bump to handle the recent gcc update". Include a
link to this Savannah issue so they can see the background of what's going
on.

In the meantime, you can run `brew reinstall -s octave` from the shell command
line to probably get a working Octave installation.

Also make sure you have run Xcode once and accepted the license agreement it
presents, just to make sure.

Also, perhaps Homebrew core should add a trivial usage of `mkoctfile` to the
Octave `brew test`, to make sure the development/compilation parts of Octave
work. That's a significant component of how Octave is used in the wild. Not
sure how you'd set up a trivial mkoctfile that involved Fortran compilation,
though. That's probably something Octave itself should ship in its bundled
test suite if it wants downstream packagers to exercise it. If this was done,
then Homebrew would be able to automatically detect when an Octave rebuild was
needed to take care of this case.

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?56171>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/