[Octave-bug-tracker] [bug #41574] Current build approach causes mkoctfile to link to too many libraries on the Mac (patch supplied)

[Andrew Janke]

Follow-up Comment #10, bug #41574 (project octave):

I *think* this seems to be fixed now.

When building a "helloworld" octfile using Octave 4.4.0 on macOS 10.13.6 built
with Qt, it does not seem to be picking up links to additional dependencies.
(Aside from liboct and liboctinterp, as discussed in #53627.)


$ cat helloworld.cc
#include <octave/oct.h>

DEFUN_DLD (helloworld, args, nargout,
           "Hello World Help String")
{
  int nargin = args.length ();

  octave_stdout << "Hello World has "
                << nargin << " input arguments and "
                << nargout << " output arguments.\n";

  return octave_value_list ();
}
$ otool -L helloworld.oct
helloworld.oct:
        /usr/local/opt/octave-octave-app/lib/octave/4.4.0/liboctinterp.5.dylib
(compatibility version 6.0.0, current version 6.0.0)
        /usr/local/opt/octave-octave-app/lib/octave/4.4.0/liboctave.5.dylib
(compatibility version 6.0.0, current version 6.0.0)
        /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version
400.9.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
1252.50.4)


Similarly, the octfiles generated as part of `pkg install -forge control` do
not appear to have a bunch of extra linkages.


[~/octave/control-3.1.0/x86_64-apple-darwin17.7.0-api-v52]
$ otool -L __control_helper_functions__.oct
__control_helper_functions__.oct:
        /usr/local/opt/octave-octave-app/lib/octave/4.4.0/liboctinterp.5.dylib
(compatibility version 6.0.0, current version 6.0.0)
        /usr/local/opt/octave-octave-app/lib/octave/4.4.0/liboctave.5.dylib
(compatibility version 6.0.0, current version 6.0.0)
        /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version
400.9.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
1252.50.4)
[~/octave/control-3.1.0/x86_64-apple-darwin17.7.0-api-v52]
$ otool -L __control_slicot_functions__.oct
__control_slicot_functions__.oct:
        /usr/local/opt/veclibfort/lib/libvecLibFort.dylib (compatibility version
0.0.0, current version 0.0.0)
        /usr/local/opt/gcc/lib/gcc/8/libgfortran.5.dylib (compatibility version
6.0.0, current version 6.0.0)
        /usr/local/opt/gcc/lib/gcc/8/libquadmath.0.dylib (compatibility version
1.0.0, current version 1.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
1252.50.4)
        /usr/local/opt/octave-octave-app/lib/octave/4.4.0/liboctinterp.5.dylib
(compatibility version 6.0.0, current version 6.0.0)
        /usr/local/opt/octave-octave-app/lib/octave/4.4.0/liboctave.5.dylib
(compatibility version 6.0.0, current version 6.0.0)
        /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version
400.9.0)
        /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate
(compatibility version 1.0.0, current version 4.0.0)


Or do I need to do something like write an octfile that actually uses Qt
functions to trigger the bad behavior?

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?41574>

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