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

[Andrew Janke]

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

I don't really know how Python does things, but I think the macOS equivalent
for plugin-style loadable modules is building them as "dynamically loaded
modules" or "Mach-O bundles" (totally different from "app bundles") instead of
a "shared library".  

The `-bundle` option to macOS's `ld` looks relevant, along with `-undefined
dynamic_lookup`.

This is hard to Google because "bundle" seems to mean two different things in
the context of macOS: a Mach-O plugin-style loadable module like we want here,
and an "app bundle" directory structure, which is the more common usage.

In Python distutils' tests, there's a reference to using `-bundle -undefined
dynamic_lookup`, but I can't find it in the main code. From
`tests/test_unixccompiler.py`:


    @unittest.skipUnless(sys.platform == 'darwin', 'test only relevant for OS
X')
    def test_osx_cc_overrides_ldshared(self):
        # Issue #18080:
        # ensure that setting CC env variable also changes default linker
        def gcv(v):
            if v == 'LDSHARED':
                return 'gcc-4.2 -bundle -undefined dynamic_lookup '
            return 'gcc-4.2'


It looks like octave is already making some use of this. In `configure`:


    *-*-darwin*)
      DL_LDFLAGS="-bundle -bundle_loader
${ac_top_build_prefix}libinterp/octave ${LDFLAGS}"
                  MKOCTFILE_DL_LDFLAGS='-bundle -bundle_loader
${bindir}/octave-${version}'"${EXEEXT}"
      SH_LDFLAGS="-dynamiclib -single_module ${LDFLAGS}"


and in the output from my broken Octave build below:


/bin/sh ./libtool  --tag=CXX   --mode=link g++ -std=gnu++11 -fPIC
-D_THREAD_SAFE -pthread -Wall -W -Wshadow -Wold-style-cast -Wformat
-Wpointer-arith -Wwrite-strings -Wcast-align -Wcast-qual  -g -O2
-avoid-version -module -no-undefined     -o libinterp/dldfcn/__delaunayn__.la
-rpath /tmp/test-octave/lib/octave/5.0.0
libinterp/dldfcn/__delaunayn___la-__delaunayn__.lo   -lm
libtool: link: g++ -std=gnu++11  -o libinterp/dldfcn/.libs/__delaunayn__.so
-bundle libinterp/dldfcn/.libs/__delaunayn___la-__delaunayn__.o   -lm -pthread
-g -O2   -pthread


I can see that it's passing `-bundle`. It's also passing `-no-undefined`.
Maybe that needs to be `-undefined dynamic_lookup` instead of `-no-undefined`?
`-undefined dynamic_lookup` seems to be the magic sauce for having the linker
allow unresolved symbols at compilation/initial link time. That's what the Tim
Smith blog post links below indicates, for Python modules. It also mentions
crashes when not using this, which sounds like the behavior we're seeing with
octfiles and Homebrewed Octave on macOS.

> The best solution is to provide -bundle -undefined dynamic_lookup, 
> which has the same behavior as the Linux linker.

Based on my reading of that and other Google results for Python modules, then
yes, a single compiled extension is portable between two different instances
of the same version of Python.

Some references:

https://stackoverflow.com/questions/2339679/what-are-the-differences-between-so-and-dylib-on-osx

https://blog.tim-smith.us/2015/09/python-extension-modules-os-x/

https://cmake.org/pipermail/cmake/2005-March/006249.html

https://books.google.com/books?id=H3JmBgAAQBAJ&pg=PA197&lpg=PA197

>From `man ld` on macOS 10.13:


   Libraries
     A static library (aka static archive) is a collection of .o files with a
table of contents that lists the global sym-
     bols in the .o files.  ld will only pull .o files out of a static library
if needed to resolve some symbol reference.
     Unlike traditional linkers, ld will continually search a static library
while linking. There is no need to specify a
     static library multiple times on the command line.

     A dynamic library (aka dylib or framework) is a final linked image. 
Putting a dynamic library on the command line
     causes two things: 1) The generated final linked image will have encoded
that it depends on that dynamic library. 2)
     Exported symbols from the dynamic library are used to resolve
references.

[...]
     -undefined treatment
                 Specifies how undefined symbols are to be treated. Options
are: error, warning, suppress, or
                 dynamic_lookup.  The default is error.



Looks like Lua does the same thing for its dynamic modules:
http://lua-users.org/lists/lua-l/2005-03/msg00349.html



    _______________________________________________________

Reply to this item at:

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

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