The SWIG logic in the go tool builds a dynamic library of most of the wrapper code
generated by the swig tool and is dynamically linked at runtime. This causes a few
problems:
 - An extra dynamic library is needed to distribute the binary (at least one for each swig enabled package)
 - In places where rpath doesn't work as expected (eg: OSX), extra measures are needed to ensure the library is found (eg: [DY]LD_LIBRARY_PATH)
 - go build throws away this "intermediate file", before you can use the generated binary
 - go test builds the library, but it's left in a subdirectory of the temporary $WORK directory that is different from the subdirectory the test binary itself is in, so it can't be found for testing
 - a go installed version of the package will put a shared library in a place that may be discovered by go build/test binaries, but it would likely be out of date for a package in development

Now that we have external linking, it should be possible to instead statically link the
SWIG generated wrapper, and thus eliminate most/all these problems.