py26-numpy install issues - ld: symbol(s) not found

[Michael Dickens]

On Sep 30, 2010, at 2:38 PM, Michael Dickens wrote:
> (3) an externally set LDFLAGS does override the internal definition just for the linalg module.  This is the only module that requires external fortran linking, and setting the external LDFLAGS causes the linking to fail in the way it does in your log file.  It's simple to patch the setup.py script for this module to include the correct link flags for Darwin.  Ideally, upstream would fix this issue, but until then using the simple patch works seems to work (as per the ticket).

Related to this discussion:

When building as +universal, the "arch" flags are set in CFLAGS, CXXFLAGS, LDFLAGS, and other environment variables.  Setting the python26 portgroup to not set LDFLAGS (via "python.add_archflags no") will disable +universal building, so this is not a good general solution.  IMHO, the pythonXX portgroups are just fine; it's the source code that's in error & needs to be fixed upstream somehow.  That said, for some platforms (e.g., Darwin), we can pretty easily patch the violating setup.py scripts to work around this issue.

For Darwin, the internal LDFLAGS that get overridden are "-undefined dynamic_lookup -bundle" -- the former pair allows for linking without all of the symbols being defined; the latter creates the shared library (dylib).  Without those flags, linking for any python module will error out with a bunch of "_Py*" symbols as well as "main" being undefined.  Adding in "-lpython" to linking will resolve the "_Py*" symbols, but still leaves "main" because the linking is for an application, not a shared library.  Linking works correctly by using the LDFLAGS "-bundle -lpython", but Python will not import the module because (I think) Python does not know how to handle the situation: since Python is running, the Python library is already loaded by dyld; importing the module results in dyld trying to load the Python library again, which crashes Python.  It might be possible for the upstream to improve the importing to check for this situation & work out how to resolve it dynamically, but using the "-undefined dynamic_lookup" LDFLAGS works more easily (and, is the default already).

Given the above, the best fix is for the upstream (somewhere, not necessary the numpy folks) to fix how the given setup.py works, such that external LDFLAGS are -appended- to those created internally -- for Fortran linking only, it seems, since the appending already works for C/C++ linking.

I hope this makes sense and helps clarify the situation. - MLD