On Wed, May 25, 2016 at 4:29 AM, Nick Wellnhofer <[email protected]> wrote:
> There's another complication which might affect the Python and Go bindings,
> too. If you link a static library into a dynamic library with GNU binutils,
> you have to use the `--whole-archive` linker option. Otherwise, some object
> files in the static library might be ignored. So the link command should
> look something like
>
> gcc \
> [.o files] \
> -Wl,--whole-archive \
> libclownfish.a \
> -Wl,--no-whole-archive \
> [dynamic libs] \
> ...
>
> The Solaris linker seems to require `-z allextract` and `-z defaultextract`.
> On OS X, we need `-all_load`. So it seems that we have to detect the linker
> as well.
Mmf. :(
With Python distutils as with Perl's Module::Build, it is at least
theoretically possible to provide a list of object files to be linked into the
host extension.
But with CGO, I don't know how to do that.
* You can't tell the Go build system about a list of compiled object files.
* You can't tell CGO about arbitrary directories full of C files to compile.
* You *can* put loose C files into the package directory, but only that one
dir -- nested dirs aren't allowed.
* You *can* hack in linker instructions using pseudo `#cgo` directives.
https://golang.org/cmd/cgo/#hdr-Using_cgo_with_the_go_command
We're currently using the last option to tell CGO about the static archive
built using Charmonizer/Make.
> What about code like `xs/XSBind.c`? Should it be compiled by the host, too?
Yes, IMO -- it's hard to handle otherwise because you have to know about
installation-specific include dirs and the like.
I'd should also mention that the current Python build on OSX has some
goofiness related to compilation settings.
* Python distutils sets MACOSX_DEPLOYMENT_TARGET to an earlier version,
deep within distutils/unixcompiler.py See
<http://stackoverflow.com/a/33308902>. This causes some weird warnings,
though I eventually figured out that they seem to be harmless.
* Python distutils compiles extensions with `-arch i386 -arch x86_64`. This
combination does not play well with `ar` -- you can't modify the archive,
which breaks incremental compiling when you modify a file in `core`:
`ar: libcfc.a is a fat file (use libtool(1) or lipo(1) and ar(1) on it)`
`ar: libcfc.a: Inappropriate file type or format`
The workaround is to start from scratch with a clean build.
Marvin Humphrey
