bugGNU Octave - Bugs: bug #55033, mkoctfile link failure on macos

 
 

bug #55033: mkoctfile link failure on macos

Submitter:  Carlo de Falco <cdf>
Submitted:  Fri 16 Nov 2018 06:38:47 AM UTC
   
 
Category:  Configuration and Build System Severity:  5 - Blocker
Priority:  5 - Normal Item Group:  Other
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * Mac OS
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sat 05 Jan 2019 06:30:05 PM UTC, comment #29: 

@Ben: I've pushed your change.  Let's see if anyone reports any problems when we push 5.0 release candidates.  I think the code does the right thing and that we are okay.

Rik <rik5>
Group administrator
Sat 05 Jan 2019 05:00:06 PM UTC, comment #28: 

@Rik,

If the changed to configure.ac causes problems with other platforms, the change can be made in src/mkoctfile.in.cc in a manner similar to Windows.

I expect the current implementation which removes the la-files and adds liboctave and liboctinterp is correct.

Ben Abbott <bpabbott>
Group Member
Wed 02 Jan 2019 07:11:11 PM UTC, comment #27: 

Marking as fixed and closing report.

Rik <rik5>
Group administrator
Wed 02 Jan 2019 05:55:37 PM UTC, comment #26: 

Hi,

I just pulled revision 16607f64eea1 (stable) I made a completely
clean new build and installed it.

given the file pippo.cc

#include <octave/oct.h>
 DEFUN_DLD(pippo, args, nargout, "") { return octave_value_list(); }


the following test works for me

$ /opt/octave/5.0.1/bin/mkoctfile pippo.cc
clang: warning: argument unused during compilation: '-pthread' [-Wunused-command-line-argument]
$ /opt/octave/5.0.1/bin/octave --eval pippo


I think it would be OK to mark this as fixed.
Thanks to Ben for the patch!


Carlo de Falco <cdf>
Group Member
Wed 02 Jan 2019 05:24:01 PM UTC, comment #25: 

Yes, please test stable as that will become the new 5.0 release.

Rik <rik5>
Group administrator
Wed 02 Jan 2019 04:53:25 PM UTC, comment #24: 

@Rik

I just started a new build of the default branch with Ben's
patch a few minutes before you pushed.

I now see you pushed to stable and did not merge to default,
would it be more useful if I test the stable branch instead of default?


Carlo de Falco <cdf>
Group Member
Wed 02 Jan 2019 04:44:09 PM UTC, comment #23: 

@Ben: I pushed your changeset to stable.  The only change I made was to be a bit more specific in the commit message.  These changes don't affect everyone, just Mac users and those who have configure to link all dependencies.  The commit message I used was


Include -loctave -loctinterp and lib path to mkoctfile link command (bug #55033).

* configure.ac: Set MKOCTFILE_OCT_LINK_DEPS to LIBOCTINTERP and LIBOCTAVE when
configured with --enable-link-all-dependencies.

* src/mkoctfile.in.cc (main): Include -L$OCTLIBDIR in DEFAULT_LFLAGS when
compiling for Mac.


I'm marking this as ready for test which really means Carlo since neither Mike nor I have a Mac system.

Rik <rik5>
Group administrator
Wed 02 Jan 2019 06:31:45 AM UTC, comment #22: 

Updated changeset.

(file #45833)

Ben Abbott <bpabbott>
Group Member
Wed 02 Jan 2019 03:21:51 AM UTC, comment #21: 

Below in mkoctfile.in.cc is a possibility.


 217 #if defined (OCTAVE_USE_WINDOWS_API) || defined (CROSS)
 218
 219   // We'll be linking the files we compile with -loctinterp and
 220   // -loctave, so we need to know where to find them.
 221
 222   DEFAULT_LFLAGS += "-L" + quote_path (vars["OCTLIBDIR"]);
 223 #endif


But I don't know how to check if link_all_deps is true.

OCT_LINK_OPTS looks to be setup for building octave, and not for mkoctfile by users.


mkoctfile -p OCT_LINK_OPTS
 -L/usr/local/opt/readline/lib -L/usr/local/opt/sqlite/lib -L/usr/local/opt/openssl/lib -L/usr/local/opt/bison/lib -L/usr/local/opt/gettext/lib -L/usr/local/opt/libffi/lib -L/usr/local/opt/icu4c/lib -F/usr/local/opt/qt5/lib -L/usr/local/opt/sundials27/lib -L/usr/local/opt/zlib/lib -L/usr/local/opt/qrupdate/lib


I'm attached the diff converted to a changeset.





(file #45831)

Ben Abbott <bpabbott>
Group Member
Tue 01 Jan 2019 04:03:44 PM UTC, comment #20: 

@Ben: I don't have any problems wit the diff you submitted so why don't you turn it in to a full changeset.

As for where to place linker options like "-Ldirectory", I think I would defer to Mike on that.  The command in mkoctfile.in.cc is


      std::string cmd
        = (vars["DL_LD"] + ' ' + vars["ALL_CXXFLAGS"] + ' '
           + vars["DL_LDFLAGS"] + ' ' + pass_on_options
           + " -o " + octfile + ' ' + objfiles + ' ' + libfiles + ' '
           + ldflags + ' ' + vars["LFLAGS"] + ' ' + octave_libs + ' '
           + vars["OCT_LINK_OPTS"] + ' ' + vars["OCT_LINK_DEPS"]);


If this is known at configure time it could go in to the variable OCT_LINK_OPTS.

Alternatively, it could go into a regular shell environment variable LFLAGS.

The naming convention of LFLAGS (which are really for lex flags) rather than using the stand LDFLAGS is already the subject of bug report #48678.

Rik <rik5>
Group administrator
Tue 01 Jan 2019 01:56:39 PM UTC, comment #19: 

I have a patch that works for me. I'm still too unfamiliar with this part of the code to be comfortable, and expect changes will be needed.

I'm happy to convert to a changeset once problems are resolved.

(file #45822)

Ben Abbott <bpabbott>
Group Member
Tue 01 Jan 2019 12:17:49 PM UTC, comment #18: 

The patch below almost works.


diff --git a/configure.ac b/configure.ac
--- a/configure.ac
+++ b/configure.ac
@@ -2759,7 +2759,7 @@ if test $link_all_deps = yes; then
   OCT_GUI_LINK_DEPS="libgui/liboctgui.la libinterp/liboctinterp.la liboctave/liboctave.la"

   MKOCTFILE_OCTAVE_LINK_DEPS="$LIBOCTINTERP_LINK_DEPS $MKOCTFILE_LIBOCTAVE_LINK_DEPS"
-  MKOCTFILE_OCT_LINK_DEPS="$OCT_LINK_DEPS $MKOCTFILE_LIBOCTINTERP_LINK_DEPS"
+  MKOCTFILE_OCT_LINK_DEPS="$LIBOCTINTERP $LIBOCTAVE"

   LIBOCTINTERP_LINK_DEPS="$LIBOCTINTERP_LINK_DEPS $LIBOCTAVE_LINK_DEPS"
   LIBOCTINTERP_LINK_OPTS="$LIBOCTINTERP_LINK_OPTS $LIBOCTAVE_LINK_OPTS"


It is still necessary to add the path to Octave's libs.


OCTLIBDIR = mkoctfile ('-p', 'OCTLIBDIR');
OCTLIBDIR(OCTLIBDIR < ' ') = [];
OCTLIBDIR = sprintf ('-L%s/', OCTLIBDIR);
mkoctfile (OCTLIBDIR, 'example.cc')


I don't see how to include the OCTLIBDIR in configure.ac. If there isn't a way, I'll need to add the -L$OCTLIBDIR in mkoctfile.in.cc. Thoughts?


Ben Abbott <bpabbott>
Group Member
Tue 01 Jan 2019 03:51:19 AM UTC, comment #17: 

MKOCTFILE

@Mike,

Sorry, you are correct. I misunderstood, and was under the impression that MKOCTFILE_OCT_LINK_DEPS should be set to "libinterp/liboctinterp.la liboctave/liboctave.la" with --enable-link-all-dependencies. That obviously created a conundrum for me.

Thanks for the repeating until it sunk in.

@Rik,

As my build on macOS is now stable, I'm installing 6.0.0.

Thanks for tracing the symbols. I'm left with the impression that there is an incomplete work in progress. I'd be more comfortable moving forward if I understood the what was intended.  In any event, the definitions below exist.

LIBOCTAVE = "-loctave"
LIBOCTINTERP = "-loctinterp"

Thus, I’m inclined to make the change …

MKOCTFILE_OCT_LINK_DEPS="$LIBOCTINTERP $LIBOCTAVE"

Does that make sense?

Ben

Ben Abbott <bpabbott>
Group Member
Mon 31 Dec 2018 11:15:00 PM UTC, comment #16: 

It sounds as though the following is true:

1) --enable-link-all-dependencies is required on Mac platforms.

This adds "libinterp/liboctinterp.la liboctave/liboctave.la" to the link command when creating a .oct file in the build system when compiling an Octave distribution.

2) Run 'make install'

I wasn't sure if this was actually getting run on Ben's machine.

3) mkoctfile helloworld.cc

The installed version of mkoctfile should use MKOCTFILE_OCT_LINK_DEPS.  This is the code in mkoctfile.in.cc which looks correct.


  vars["OCT_LINK_DEPS"] = get_variable ("OCT_LINK_DEPS",
                                        %OCTAVE_CONF_MKOCTFILE_OCT_LINK_DEPS%);


4) The variable %OCTAVE_CONF_MKOCTFILE_OCT_LINK_DEPS% is substituted by build-aux/subst-config-vals.in.sh


  -e "s|%OCTAVE_CONF_MKOCTFILE_OCT_LINK_DEPS%|\"${MKOCTFILE_OCT_LINK_DEPS}\"|" \


5) MKOCTFILE_OCT_LINK_DEPS is defined in configure.ac by the following.


if test $link_all_deps = yes; then
  OCT_LINK_DEPS="libinterp/liboctinterp.la liboctave/liboctave.la"
  OCT_GUI_LINK_DEPS="libgui/liboctgui.la libinterp/liboctinterp.la liboctave/liboctave.la"

  MKOCTFILE_OCTAVE_LINK_DEPS="$LIBOCTINTERP_LINK_DEPS $MKOCTFILE_LIBOCTAVE_LINK_DEPS"
  MKOCTFILE_OCT_LINK_DEPS="$OCT_LINK_DEPS $MKOCTFILE_LIBOCTINTERP_LINK_DEPS"

  LIBOCTINTERP_LINK_DEPS="$LIBOCTINTERP_LINK_DEPS $LIBOCTAVE_LINK_DEPS"
  LIBOCTINTERP_LINK_OPTS="$LIBOCTINTERP_LINK_OPTS $LIBOCTAVE_LINK_OPTS"

  OCTAVE_LINK_DEPS="$LIBOCTINTERP_LINK_DEPS"
  OCTAVE_LINK_OPTS="$LIBOCTINTERP_LINK_OPTS"


I think the line that defines MKOCTFILE_OCT_LINK_DEPS is where I would start.  I don't think it should include $OCT_LINK_DEPS because that is what is getting you liboctinterp.la and liboctave.la.  Secondarily, MKOCTFILE_LIBOCTINTERP_LINK_DEPS doesn't exist anywhere in the source tree so it is useless.  As a start, maybe try


MKOCTFILE_OCT_LINK_DEPS="-loctinterp -loctave"




Rik <rik5>
Group administrator
Mon 31 Dec 2018 06:51:15 PM UTC, comment #15: 

I hope it doesn't look like I'm repeating myself, but the task needed is to make sure that MKOCTFILE_OCT_LINK_DEPS has the right contents. "libinterp/liboctinterp.la liboctave/liboctave.la" is clearly not the right contents.

Mike Miller <mtmiller>
Group Member
Mon 31 Dec 2018 12:31:12 PM UTC, comment #14: 

Based upon what I saw below (comment #13), I tried adding the expected content of OCTAVE_LIBS and their path. The result was successful.


mkoctfile ('-v', 'example.cc', '-L/usr/local/bpabbott/octave/lib/octave/6.0.0/', '-loctave', '-loctinterp')
g++ -std=gnu++11 -c  -I/usr/local/opt/readline/include -I/usr/local/opt/sqlite/include -I/usr/local/opt/openssl/include -I/usr/local/opt/gettext/include -I/usr/local/opt/icu4c/include -I/usr/local/opt/qt5/include -I/usr/local/opt/sundials27/include -I/usr/local/opt/zlib/include -fPIC -I/usr/local/bpabbott/octave/include/octave-6.0.0/octave/.. -I/usr/local/bpabbott/octave/include/octave-6.0.0/octave -I/usr/local/bpabbott/octave/include  -D_THREAD_SAFE -pthread -g -O2    example.cc -o /var/tmp//oct-G4QR4S.o
g++ -std=gnu++11 -I/usr/local/bpabbott/octave/include/octave-6.0.0/octave/.. -I/usr/local/bpabbott/octave/include/octave-6.0.0/octave -I/usr/local/bpabbott/octave/include  -D_THREAD_SAFE -pthread -g -O2 -bundle -bundle_loader /usr/local/bpabbott/octave/bin/octave-6.0.0  -o example.oct  /var/tmp//oct-G4QR4S.o   -L/usr/local/bpabbott/octave/lib/octave/6.0.0/ -loctave -loctinterp  -L/usr/local/bpabbott/octave/lib   -L/usr/local/opt/readline/lib -L/usr/local/opt/sqlite/lib -L/usr/local/opt/openssl/lib -L/usr/local/opt/bison/lib -L/usr/local/opt/gettext/lib -L/usr/local/opt/libffi/lib -L/usr/local/opt/icu4c/lib -F/usr/local/opt/qt5/lib -L/usr/local/opt/sundials27/lib -L/usr/local/opt/zlib/lib -L/usr/local/opt/qrupdate/lib


I also modified mkoctfile (lines 304-305)


  vars["OCT_LINK_DEPS"] = get_variable ("OCT_LINK_DEPS", "");
//                                   "libinterp/liboctinterp.la liboctave/liboctave.la ");


OCTAVE_LIBS contains the intended symbols.


mkoctfile -p OCTAVE_LIBS
-loctinterp -loctave


As does OCTLIBDIR


mkoctfile -p OCTLIBDIR
/usr/local/bpabbott/octave/lib/octave/6.0.0


Should OCTAVE_LIBS and OCTLIBDIR being finding their way into the link phase automatically?

Ben Abbott <bpabbott>
Group Member
Mon 31 Dec 2018 09:49:42 AM UTC, comment #13: 

Comparing verbose output from mkoctfile. Octave 4.2.1 works and Octave 6.0.0 fails.

Octave-6.0.0 Compile:


g++ -std=gnu++11 -c -I/usr/local/opt/readline/include -I/usr/local/opt/sqlite/include -I/usr/local/opt/openssl/include -I/usr/local/opt/gettext/include -I/usr/local/opt/icu4c/include -I/usr/local/opt/qt5/include -I/usr/local/opt/sundials27/include -I/usr/local/opt/zlib/include -fPIC -I/usr/local/bpabbott/octave/include/octave-6.0.0/octave/.. -I/usr/local/bpabbott/octave/include/octave-6.0.0/octave -I/usr/local/bpabbott/octave/include -D_THREAD_SAFE -pthread -g -O2 example.cc -o /var/tmp//oct-x6OiAH.o


Octave-4.2.1 Compile:


clang++ -std=gnu++11 -c -fPIC -I/usr/local/Cellar/octave/4.4.1_2/include/octave-4.4.1/octave/.. -I/usr/local/Cellar/octave/4.4.1_2/include/octave-4.4.1/octave -I/usr/local/Cellar/octave/4.4.1_2/include -D_THREAD_SAFE -pthread -I/Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home/include -I/Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home/include/darwin example.cc -o example.o


Octave-6.0.0 Link:


g++ -std=gnu++11 -I/usr/local/bpabbott/octave/include/octave-6.0.0/octave/.. -I/usr/local/bpabbott/octave/include/octave-6.0.0/octave -I/usr/local/bpabbott/octave/include -D_THREAD_SAFE -pthread -g -O2 -bundle -bundle_loader /usr/local/bpabbott/octave/bin/octave-6.0.0 -o example.oct /var/tmp//oct-x6OiAH.o -L/usr/local/bpabbott/octave/lib -L/usr/local/opt/readline/lib -L/usr/local/opt/sqlite/lib -L/usr/local/opt/openssl/lib -L/usr/local/opt/bison/lib -L/usr/local/opt/gettext/lib -L/usr/local/opt/libffi/lib -L/usr/local/opt/icu4c/lib -F/usr/local/opt/qt5/lib -L/usr/local/opt/sundials27/lib -L/usr/local/opt/zlib/lib -L/usr/local/opt/qrupdate/lib libinterp/liboctinterp.la liboctave/liboctave.la


Octave-4.2.1 Link:


clang++ -std=gnu++11 -I/usr/local/Cellar/octave/4.4.1_2/include/octave-4.4.1/octave/.. -I/usr/local/Cellar/octave/4.4.1_2/include/octave-4.4.1/octave -I/usr/local/Cellar/octave/4.4.1_2/include -D_THREAD_SAFE -pthread -I/Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home/include -I/Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home/include/darwin -bundle -bundle_loader /usr/local/Cellar/octave/4.4.1_2/bin/octave-4.4.1 -o example.oct example.o -L/usr/local/Cellar/octave/4.4.1_2/lib/octave/4.4.1 -L/usr/local/Cellar/octave/4.4.1_2/lib -loctinterp -loctave


There are other differences, but the two that stands out are " -loctinterp -loctave" is missing from 6.0.0 and "ibinterp/liboctinterp.la liboctave/liboctave.la" is present.

For both 4.2.1 and 6.0.0 "mkoctfile -p OCTAVE_LIBS" returns "-loctinterp -loctave". But the link phase for 6.0.0 does not include these libs.


Ben Abbott <bpabbott>
Group Member
Mon 31 Dec 2018 08:18:11 AM UTC, comment #12: 

Hi Carlo,

I've played a bit. I don't see a simple fix. From the default branch ...


mkoctfile example.cc
clang: error: no such file or directory: 'libinterp/liboctinterp.la'
clang: error: no such file or directory: 'liboctave/liboctave.la'
warning: mkoctfile: building exited with failure status


Now with the proper path to the la-files


setenv OCT_LINK_DEPS '/usr/local/bpabbott/octave/lib/octave/6.0.0/liboctave.la /usr/local/bpabbott/octave/lib/octave/6.0.0/liboctinterp.la'
>> mkoctfile example.cc
ld: warning: ignoring file /usr/local/bpabbott/octave/lib/octave/6.0.0/liboctave.la, file was built for unsupported file format ( 0x23 0x20 0x6C 0x69 0x62 0x6F 0x63 0x74 0x61 0x76 0x65 0x2E 0x6C 0x61 0x20 0x2D ) which is not the architecture being linked (x86_64): /usr/local/bpabbott/octave/lib/octave/6.0.0/liboctave.la
ld: warning: ignoring file /usr/local/bpabbott/octave/lib/octave/6.0.0/liboctinterp.la, file was built for unsupported file format ( 0x23 0x20 0x6C 0x69 0x62 0x6F 0x63 0x74 0x69 0x6E 0x74 0x65 0x72 0x70 0x2E 0x6C ) which is not the architecture being linked (x86_64): /usr/local/bpabbott/octave/lib/octave/6.0.0/liboctinterp.la
Undefined symbols for architecture x86_64:
  "check_version(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)", referenced from:
      _Gexample in oct-j2wwT6.o
  "dim_vector::nil_rep()", referenced from:
      octave_value_list::octave_value_list<std::initializer_list>(std::initializer_list<octave_value> const&) in oct-j2wwT6.o
  "octave_value::nil_rep()", referenced from:
      Array<octave_value>::ArrayRep::ArrayRep(long long) in oct-j2wwT6.o
  "octave_dld_function::create(octave_value_list (*)(octave_value_list const&, int), octave::dynamic_library const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)", referenced from:
      _Gexample in oct-j2wwT6.o
  "Array<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >::nil_rep()", referenced from:
      octave_value_list::octave_value_list<std::initializer_list>(std::initializer_list<octave_value> const&) in oct-j2wwT6.o
  "dim_vector::safe_numel() const", referenced from:
      Array<octave_value>::Array<std::initializer_list>(std::initializer_list<octave_value> const&, dim_vector const&) in oct-j2wwT6.o
  "dim_vector::str(char) const", referenced from:
      Array<octave_value>::Array<std::initializer_list>(std::initializer_list<octave_value> const&, dim_vector const&) in oct-j2wwT6.o
  "Array<octave_value>::resize_fill_value() const", referenced from:
      vtable for Array<octave_value> in oct-j2wwT6.o
  "Array<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >::resize_fill_value() const", referenced from:
      vtable for string_vector in oct-j2wwT6.o
      vtable for Array<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > in oct-j2wwT6.o
  "_current_liboctave_error_handler", referenced from:
      Array<octave_value>::Array<std::initializer_list>(std::initializer_list<octave_value> const&, dim_vector const&) in oct-j2wwT6.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
warning: mkoctfile: building exited with failure status


Ben Abbott <bpabbott>
Group Member
Mon 31 Dec 2018 06:45:45 AM UTC, comment #11: 

Hi Ben,

I think -—enable-link-all-dependencies is needed on macos.

without -—enable-link-all-dependencies mkoctfile.cc has


  vars["OCT_LINK_DEPS"] = get_variable ("OCT_LINK_DEPS",


but the build fails at the linking stage


CXXLD    libinterp/dldfcn/__delaunayn__.la
clang: warning: argument unused during compilation: '-pthread' [-Wunused-command-line-argument]
clang: warning: argument unused during compilation: '-pthread' [-Wunused-command-line-argument]
Undefined symbols for architecture x86_64:
  "print_usage()", referenced from:
      F__delaunayn__(octave_value_list const&, int) in __delaunayn___la-__delaunayn__.o
  "check_version(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)", referenced from:
      _G__delaunayn__ in __delaunayn___la-__delaunayn__.o
  "error(char const*, ...)", referenced from:
      F__delaunayn__(octave_value_list const&, int) in __delaunayn___la-__delaunayn__.o
  "warning(char const*, ...)", referenced from:
      free_qhull_memory() in __delaunayn___la-__delaunayn__.o
  "MatrixType::MatrixType()", referenced from:
      F__delaunayn__(octave_value_list const&, int) in __delaunayn___la-__delaunayn__.o
  "MatrixType::~MatrixType()", referenced from:
      F__delaunayn__(octave_value_list const&, int) in __delaunayn___la-__delaunayn__.o
  "dim_vector::nil_rep()", referenced from:
      F__delaunayn__(octave_value_list const&, int) in __delaunayn___la-__delaunayn__.o
  "octave_value::nil_rep()", referenced from:
      octave_value_list::elem(long long) in __delaunayn___la-__delaunayn__.o
      Array<octave_value>::ArrayRep::ArrayRep(octave_value*, long long) in __delaunayn___la-__delaunayn__.o
  "octave_value::octave_value(Matrix const&, MatrixType const&)", referenced from:
      F__delaunayn__(octave_value_list const&, int) in __delaunayn___la-__delaunayn__.o
  "octave_value::octave_value(RowVector const&)", referenced from:
      F__delaunayn__(octave_value_list const&, int) in __delaunayn___la-__delaunayn__.o
  "octave_value::octave_value(double)", referenced from:
      F__delaunayn__(octave_value_list const&, int) in __delaunayn___la-__delaunayn__.o
  "octave_dld_function::create(octave_value_list (*)(octave_value_list const&, int), octave::dynamic_library const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)", referenced from:
      _G__delaunayn__ in __delaunayn___la-__delaunayn__.o
  "Array<octave_value>::resize(dim_vector const&, octave_value const&)", referenced from:
      octave_value_list::resize(long long, octave_value const&) in __delaunayn___la-__delaunayn__.o
  "Array<octave_value>::nil_rep()", referenced from:
      F__delaunayn__(octave_value_list const&, int) in __delaunayn___la-__delaunayn__.o
  "Array<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >::nil_rep()", referenced from:
      F__delaunayn__(octave_value_list const&, int) in __delaunayn___la-__delaunayn__.o
  "Array<double>::fortran_vec()", referenced from:
      F__delaunayn__(octave_value_list const&, int) in __delaunayn___la-__delaunayn__.o
  "dim_vector::safe_numel() const", referenced from:
      Array<double>::Array(dim_vector const&) in __delaunayn___la-__delaunayn__.o
  "dim_vector::redim(int) const", referenced from:
      Array<double>::as_matrix() const in __delaunayn___la-__delaunayn__.o
  "Array<octave_value>::resize_fill_value() const", referenced from:
      vtable for Array<octave_value> in __delaunayn___la-__delaunayn__.o
  "Array<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >::resize_fill_value() const", referenced from:
      vtable for string_vector in __delaunayn___la-__delaunayn__.o
      vtable for Array<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > in __delaunayn___la-__delaunayn__.o
  "Array<double>::resize_fill_value() const", referenced from:
      vtable for MArray<double> in __delaunayn___la-__delaunayn__.o
      vtable for Array<double> in __delaunayn___la-__delaunayn__.o
      vtable for Matrix in __delaunayn___la-__delaunayn__.o
      vtable for NDArray in __delaunayn___la-__delaunayn__.o
      vtable for RowVector in __delaunayn___la-__delaunayn__.o
  "Array<double>::transpose() const", referenced from:
      Matrix::transpose() const in __delaunayn___la-__delaunayn__.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [libinterp/dldfcn/__delaunayn__.la] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2


c.

Carlo de Falco <cdf>
Group Member
Mon 31 Dec 2018 04:32:31 AM UTC, comment #10: 

From what I can tell MKOCTFILE_OCT_LINK_DEPS and OCT_LINK_DEPS are empty during the build process for Octave 5.0 ... in case it matters, I'm using --disable-link-all-dependencies now.

You mentioned your OCT_LINK_DEPS on line 304 of mkoctfile.cc is empty. Does that mean ...


  vars["OCT_LINK_DEPS"] = get_variable ("OCT_LINK_DEPS",
                                        "”);


MKOCTFILE_OCT_LINK_DEPS is not used by mkoctfile for Octave 5.0, and did not exist for Octave 4.2.

Any idea which systems would have non-empty MKOCTFILE_OCT_LINK_DEPS and/or OCT_LINK_DEPS? Would "libinterp/liboctinterp.la liboctave/liboctave.la" ever be a valid for post install mkoctfile?



Ben Abbott <bpabbott>
Group Member
Mon 31 Dec 2018 03:59:48 AM UTC, comment #9: 

You'll want to trace those variables yourself to see what the values are and where they come from.

mkoctfile.cc comes from mkoctfile.in.cc by way of a set of sed substitions. The script that calls sed is build-aux/subst-cross-config-vals.sh, which is in turn built from build-aux/subst-cross-config-vals.in.sh. I think you'll see that it all traces back to variables defined in configure.

Like I said, there needs to be one set of linker options for building oct files inside of the Octave build tree, before mkoctfile exists, and another set of linker options for building oct files outside of the Octave build, after Octave is installed and mkoctfile exists.

On my system these are all empty strings so I can't easily compare notes against a system where they need to be defined correctly.

Mike Miller <mtmiller>
Group Member
Mon 31 Dec 2018 03:08:59 AM UTC, comment #8: 

mkoctfile includes the part below.


 vars["OCT_LINK_DEPS"] = get_variable ("OCT_LINK_DEPS",
                                       "libinterp/liboctinterp.la liboctave/liboctave.la ");


I don't see MKOCTFILE_OCT_LINK_DEPS in my mkoctfile.cc (not in 4.4 or 5.0).

Are they each present in yours?



Ben Abbott <bpabbott>
Group Member
Mon 31 Dec 2018 02:51:31 AM UTC, comment #7: 

Yes, I meant --enable-link-all-dependencies.

No, they are not valid after installing Octave, that's what I understand is the intended difference between OCT_LINK_DEPS (for building oct files in-tree) and MKOCTFILE_OCT_LINK_DEPS (for building oct files with mkoctfile). If these two variables have the same value, then that's probably where to start.

Mike Miller <mtmiller>
Group Member
Mon 31 Dec 2018 02:45:50 AM UTC, comment #6: 

@Mike, I assume you meant --enable-link-all-dependencies?

Are libinterp/liboctinterp.la liboctave/liboctave.la valid on linux after install? I don't see those directories in my macOS install (I'm looking at Octave 4.4).

@Carlo, building with --disable-link-all-dependencies results in ...


 vars["OCT_LINK_DEPS"] = get_variable ("OCT_LINK_DEPS",
                                       "");


Can you check if this breaks mkoctfile on macOS?

Ben Abbott <bpabbott>
Group Member
Mon 31 Dec 2018 02:01:12 AM UTC, comment #5: 

We have two sets of variables, OCT_LINK_DEPS and MKOCTFILE_OCT_LINK_DEPS. On a GNU/Linux system, these are both empty by default, oct files can be built with undefined symbols, and they will be resolved at run time.

On a system with --enable-all-link-dependencies, I think that OCT_LINK_DEPS should be set to "libinterp/liboctinterp.la liboctave/liboctave.la" and MKOCTFILE_OCT_LINK_DEPS should be set to "-loctinterp -loctave", plus whatever system libraries are needed. Otherwise the oct file build will fail with undefined symbols.

Mike Miller <mtmiller>
Group Member
Mon 31 Dec 2018 01:30:25 AM UTC, comment #4: 

@Carlo,

I'll comment, please correct if I leave anything relevant out.

The mkoctfile on macOS has spurious libs ('libinterp/liboctinterp.la' and 'libinterp/liboctave.la') appended to the link command.


 vars["OCT_LINK_DEPS"] = get_variable ("OCT_LINK_DEPS",
                                       "libinterp/liboctinterp.la liboctave/liboctave.la ");


These will in general not exist, UNLESS launching mkoctfile from the root of the build tree.

@Carlo/Mike/Rik,

Would anything break if we skipped appending these libs when OCT_LINK_DEPS is empty?




Ben Abbott <bpabbott>
Group Member
Sun 30 Dec 2018 09:45:08 PM UTC, comment #3: 

@Ben, @Carlo: I saw traffic on the Octave-Maintainer's list related to mkoctfile on Mac platforms.  Is there a solution we can make a part of the Octave build system?

Rik <rik5>
Group administrator
Wed 21 Nov 2018 03:30:28 PM UTC, comment #2: 

Hi Carlo,

I'd been hoping to find time to look at this since you first posted. Unfortunately, my free time for Octave is too sparse and I don't have 5" installed. Have you tried looking at the setting of variables that mkoctfille depends on to see what changed? For example in Makefile.in ...


MKOCTFILE_AR = @MKOCTFILE_AR@
MKOCTFILE_CC = @MKOCTFILE_CC@
MKOCTFILE_CXX = @MKOCTFILE_CXX@
MKOCTFILE_DL_LD = @MKOCTFILE_DL_LD@
MKOCTFILE_DL_LDFLAGS = @MKOCTFILE_DL_LDFLAGS@
MKOCTFILE_F77 = @MKOCTFILE_F77@
MKOCTFILE_LD_CXX = @MKOCTFILE_LD_CXX@
MKOCTFILE_OCTAVE_LINK_DEPS = @MKOCTFILE_OCTAVE_LINK_DEPS@
MKOCTFILE_OCT_LINK_DEPS = @MKOCTFILE_OCT_LINK_DEPS@
MKOCTFILE_RANLIB = @MKOCTFILE_RANLIB@


I haven't tried before, but "mkoctfile --print VAR" should be what is needed. Also the doc-string list more variables.

Ben Abbott <bpabbott>
Group Member
Wed 21 Nov 2018 09:37:12 AM UTC, comment #1: 

Hi,

Is anyone else experiencing anything like this?
It is really a blocker for testing Octave 5 on the mac
because package installation does not work.

I tried all obvious workaround patches that I could think of
but cannot make up anything that works

Carlo de Falco <cdf>
Group Member
Fri 16 Nov 2018 06:38:47 AM UTC, original submission:  


With a recent revision of the development branch,
building an oct-file with mkoctfile fails at the
linking stage


$ /opt/octave/5.0.0/bin/mkoctfile -v pippo.cc
/usr/bin/clang++ -std=gnu++11 -c -O0 -g -I/opt/sundials/3.1.0/include -I/opt/local/include -I/opt/X11/include -fPIC -I/opt/octave/5.0.0/include/octave-5.0.0/octave/.. -I/opt/octave/5.0.0/include/octave-5.0.0/octave -I/opt/octave/5.0.0/include  -D_THREAD_SAFE -pthread -O0 -g    pippo.cc -o /var/tmp//oct-yYy4vZ.o
/usr/bin/clang++ -std=gnu++11 -I/opt/octave/5.0.0/include/octave-5.0.0/octave/.. -I/opt/octave/5.0.0/include/octave-5.0.0/octave -I/opt/octave/5.0.0/include  -D_THREAD_SAFE -pthread -O0 -g -bundle -bundle_loader /opt/octave/5.0.0/bin/octave-5.0.0  -o pippo.oct  /var/tmp//oct-yYy4vZ.o    -L/opt/octave/5.0.0/lib  -O0 -g -L/opt/sundials/3.1.0/lib -lsundials_sunlinsolklu -lsundials_sunmatrixsparse  -L/opt/local/lib -L/opt/X11/lib -L/opt/local/libexec/qt5/lib -lqscintilla2_qt5 -F/opt/local/libexec/qt5/lib libinterp/liboctinterp.la liboctave/liboctave.la
clang: error: no such file or directory: 'libinterp/liboctinterp.la'
clang: error: no such file or directory: 'liboctave/liboctave.la'


for comparison, see the output from mkoctfile-4.4.1


$ /opt/octave/4.4.1/bin/mkoctfile -v pippo.cc
/usr/bin/clang++ -std=gnu++11 -c -O0 -g -I/opt/sundials/3.1.0/include -I/opt/local/include -I/opt/X11/include -fPIC -I/opt/octave/4.4.1/include/octave-4.4.1/octave/.. -I/opt/octave/4.4.1/include/octave-4.4.1/octave -I/opt/octave/4.4.1/include  -D_THREAD_SAFE -pthread -O0 -g    pippo.cc -o pippo.o
/usr/bin/clang++ -std=gnu++11 -I/opt/octave/4.4.1/include/octave-4.4.1/octave/.. -I/opt/octave/4.4.1/include/octave-4.4.1/octave -I/opt/octave/4.4.1/include  -D_THREAD_SAFE -pthread -O0 -g -bundle -bundle_loader /opt/octave/4.4.1/bin/octave-4.4.1  -o pippo.oct  pippo.o   -L/opt/octave/4.4.1/lib/octave/4.4.1 -L/opt/octave/4.4.1/lib -loctinterp -loctave -O0 -g -L/opt/sundials/3.1.0/lib -lsundials_sunlinsolklu -lsundials_sunmatrixsparse  -L/opt/local/lib -L/opt/X11/lib -L/opt/local/libexec/qt5/lib -lqscintilla2_qt5 -F/opt/local/libexec/qt5/lib   -L/opt/local/lib  -L/opt/local/lib -L/opt/local/lib           -L/opt/local/lib  -L/opt/local/lib -L/opt/local/lib -L/opt/local/lib



the issue seems to be that " libinterp/liboctinterp.la liboctave/liboctave.la " appended to the command



Carlo de Falco <cdf>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #45833:  changeset.patch added by bpabbott (1KiB - application/octet-stream)
file #45831:  changeset.patch added by bpabbott (2KiB - application/octet-stream)
file #45822:  bug55033.diff added by bpabbott (2KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by bpabbott (Posted a comment)
  • -email is unavailable- added by cdf (Submitted the item)
  • -email is unavailable- added by cdf
  • -email is unavailable- added by cdf
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 12 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-01-02 rik5 StatusPatch Submitted Fixed
        Open/ClosedOpen Closed
    2019-01-02 cdf StatusReady For Test Patch Submitted
    2019-01-02 rik5 StatusPatch Submitted Ready For Test
    2019-01-02 bpabbott Attached File- Added changeset.patch, #45833
        StatusPatch Reviewed Patch Submitted
    2019-01-02 bpabbott Attached File- Added changeset.patch, #45831
    2019-01-01 rik5 StatusNeed Info Patch Reviewed
    2019-01-01 bpabbott Attached File- Added bug55033.diff, #45822
    2018-12-30 rik5 StatusNone Need Info
    2018-11-16 cdf Carbon-Copy- Added -email is unavailable-
        Carbon-Copy- Added -email is unavailable-

    Back to the top

    Powered by Savane 3.13-cf05.
    Corresponding source code