[Octave-bug-tracker] [bug #53627] build: oct files should not need to link with -loctinterp -loctave

[Mike Miller]

Follow-up Comment #13, bug #53627 (project octave):

The linker errors here


  CXXLD    libinterp/dldfcn/__delaunayn__.la
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
...


seem to indicate that the macOS linker requires some resolution of undefined
symbols even in a plugin-type shared object.

On GNU/Linux, the advice for building plugin-style loadable modules is to
avoid linking them with libraries that the executable will already have opened
in the application process space.

For example, when building Python extensions in C, the .so files are not
linked against libpython, even though the extension will be calling Python C
API functions. At build time, these are unresolved symbols, but the linker
does not care.

I guess we need to know what the equivalent build process should be on macOS
and we'll do it.

How are C Python extensions built on macOS? Is a single compiled extension
portable between two different instances of the same version of Python?

    _______________________________________________________

Reply to this item at:

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

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