[Octave-bug-tracker] [bug #59820] build fails on macOS

[Markus Mützel]

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

Like I already wrote, I can't really solve this because I don't have a Mac.

Some general advice for someone motivated:
For me, it worked best to try and tackle the missing symbols one at a time.
E.g. for the missing symbol "_set_liboctave_warning_with_id_handler":
0 Try and find where in the sources that symbol should be defined. For that
symbol, it is most likely a C mangled version (leading underscore) of the
function "set_liboctave_warning_with_id_handler" defined in
"liboctave/util/lo-error.cc".
0 Check which symbols are exported by that compile unit. I don't know the
naming conventions on Mac or whether it has "nm" at all. On Linux, I'd try:

nm -C liboctave/util/.libs/libutil_la-lo-error.o | grep
"set_liboctave_warning_with_id_handler"

0 If the symbol is exported from that compile unit, check if the name is
mangled as expected:

nm liboctave/util/.libs/libutil_la-lo-error.o | grep
"set_liboctave_warning_with_id_handler"

0 If this is also ok, check if it is exported from the corresponding library.
On Linux for that file, that would be:

nm -C liboctave/.libs/liboctave.so | grep
"set_liboctave_warning_with_id_handler"


The symbol must be in the exported symbol table of that library. With "nm"
that is indicated by e.g. "T" or "W" before the symbol name.

Depending on which step failed, try and find out why that is...

If there is a pattern, it might make sense to apply the solution to similar
symbols.

Good luck hunting down the issues.

If there are changesets that allow linking on MacOS, I'm happy to check if
those would be compatible with gcc and clang on Linux and possibly also with
Windows targets.

    _______________________________________________________

Reply to this item at:

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

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