py26-numpy linking error? "Symbol not found: ___floatunditf"

[gerboland+macports@…]

I'm running a G4 iBook with 10.4.11.

Want to install numpy. Port's build completes successfully, but when using it in python get following error:

ImportError: dlopen(/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/
site-packages/numpy/core/multiarray.so, 2): Symbol not found: ___floatunditf

This causes any other port which depends on numpy to fail to build (e.g. scipy).

Symbol appears to be available:

gerry:/opt/local/lib$ grep -r floatunditf *
Binary file gcc43/gcc/ppc-apple-darwin8/4.3.4/libgcc.a matches
Binary file gcc43/libgcc_s.1.dylib matches
Binary file gcc43/libgcc_s.10.5.dylib matches
Binary file gcc43/libgcc_s_ppc64.1.dylib matches
Binary file gcc43/libgcc_s_x86_64.1.dylib matches

but I would expect those libs to be linked against automatically. Or is there a flag missing? Possible this is an architecture thing, as floatunditf looks to do soft floating-point ops.

Attached is my build log, and error output. I'd appreciate any advice!

-G

[gerboland+macports@…]

Build log of py26-numpy (completes successfully) - zipped

[gerboland+macports@…]

numpy error message

[gerboland+macports@…]

Also, I can't help noticing that my macport's install of python26 has the following heading when run:

Python 2.6.5 (r265:79063, May 17 2010, 10:42:33) 
[GCC 4.0.1 (Apple Computer, Inc. build 5370)] on darwin

Should it not be compiled with gcc4.3 supplied by macports too? Is this mixing two different compilers? Advice appreciated!

-G

[Veence (Vincent)]

What is the output of: otool -L /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/ site-packages/numpy/core/multiarray.so

[gerboland+macports@…]

Oh yes I should have included that.

/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/numpy/core/multiarray.so:
        /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.12)

For the record, my python2.6 binary is similar (my earlier comment rubbish)

otool -L /opt/local/Library/Frameworks/Python.framework/Versions/2.6/bin/python2.6
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/bin/python2.6:
        /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.12)

But indeed "floatunditf" is not defined in those files. Think I'll need to rebuild these ports with gcc4.3 somehow. Any better ideas?

-G

[Veence (Vincent)]

There seems to be a confusion between standard libs in /usr/lib and gcc-mp libs in /opt/local/gcc-mp…

Try this: go to the /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/ site-packages/numpy/core folder and type:

install_name_tool -change /usr/lib/libgcc_s.1.dylib /opt/local/lib/gcc43/libgcc_s.1.dylib

[Veence (Vincent)]

Oops. I forgot the name of the file. It should read:

install_name_tool -change /usr/lib/libgcc_s.1.dylib /opt/local/lib/gcc43/libgcc_s.1.dylib multiarray.so

[gerboland+macports@…]

That seems to have fixed it, thanks!

For the record, the command I ran was

install_name_tool -change /usr/lib/libgcc_s.1.dylib /opt/local/lib/gcc43/libgcc_s.1.dylib multiarray.so

in case others have the problem.

I'll see if I can track down the cause of these library problems. I would have expected macport's python to only use libs in /opt/local/lib, so will dig a bit further. This could cause me more problems down the line unless I deal with it now.

-G

[Veence (Vincent)]

As I said, the linker has mixed up standard and gcc libs. On my own version of Atlas, build on a gcc45/x86_64+i386/Mac 0S 10.6 system, multiarray.so has no dependencies besides libSystem. I guess this is to be considered as implementation details.

I close the bug, so. Good luck.

• V

[jmroot (Joshua Root)]

How is this fixed?

[Veence (Vincent)]

I closed the ticket because this seemed to be a hapax to me.

Somehow, anyway, atlas should be upgraded to avoid the use of gcc43 or any former compiler, since many reported compiling difficulties disappear when using gcc45 (and maybe gcc44). Now, if you have a G4 under Tiger and want to investigate, go ahead… :)

[gerboland+macports@…]

I'm still trying to figure out why this symbol error occurs. I'm suspecting that header files from the gcc4.3 install are being used by native gcc, hence the missing symbols on linking, but not sure yet. I'm not used to python-based build scripts, so is slow going:(

For the record, atlas built just fine for me with the native gcc4.0.1. But us Tiger users are in the minority by now.

[Veence (Vincent)]

So, what to do with this ticket?

[gerboland+macports@…]

I had no success fixing this problem, so I gave up and installed numpy manually. If you'd like, I can try to reproduce this again, but I have moved on from the project requiring this port.

[skymoo (Adam Mercer)]

I personally do not have access to a Tiger machine so have no way of debugging this issue... patches will be welcome.

[gerboland+macports@…]

Unfortunately I, the OP, don't have access to Tiger either. My machine died. Feel free to close this bug. -G