[Numpy-discussion] recompiling needed for binary module after numpy 1.0

Robert Kern robert.kern at gmail.com
Sat Jan 13 19:16:57 CST 2007


Erin Sheldon wrote:
> On 1/9/07, Robert Kern <robert.kern at gmail.com> wrote:
>> Erin Sheldon wrote:
>>> I'm finally getting to this, I'm on the road.  Here is
>>> what gdb gives me
>>>
>>> --snip--
>>> Reading symbols for shared libraries . done
>>> Reading symbols for shared libraries . done
>>> Reading symbols for shared libraries .. done
>>>
>>> Program received signal EXC_BAD_ACCESS, Could not access memory.
>>> Reason: KERN_INVALID_ADDRESS at address: 0x5a6ae09a
>>> parse_fond (fond_data=0x5a6ae060 <Address 0x5a6ae060 out of bounds>,
>>> have_sfnt=0x5a6ae09c, sfnt_id=0xbfff8f4e, lwfn_file_name=0xbfff8e4a
>>> "", face_index=0) at
>>> /usr/local/src/freetype-2.2.1/src/base/ftmac.c:628
>>> 628     /usr/local/src/freetype-2.2.1/src/base/ftmac.c: No such file
>>> or directory.
>>>         in /usr/local/src/freetype-2.2.1/src/base/ftmac.c
>>>
>>> For some reason it is looking for something from freetype
>>> in /usr/local/src but this directory has never existed
>>> on my computer.  This is a new computer and I used the migration
>>> assistant to copy things from my old computer, so perhaps some
>>> paths got messed up.   I don't know how to address
>>> that type of issue on a Mac with no ld.so.conf type of file.
>> Your build of matplotlib is probably picking up a different freetype library
>> than the one you intended, one which somebody else built. Possibly the one in
>> /usr/X11R6/lib/. You can use otool(1) to figure out what shared libraries your
>> extension modules are linking against:
>>
>>
>> [matplotlib]$ otool -L ft2font.so
>> ft2font.so:
>>         /opt/local/lib/libfreetype.6.dylib (compatibility version 10.0.0,
>> current version 10.8.0)
>>         /opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current
>> version 1.2.3)
>>         /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version
>> 7.4.0)
>>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
>> 88.3.3)
>>         /usr/local/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current
>> version 1.0.0)
> 
> Here is what I get
>> otool -L /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/matplotlib/ft2font.so
> /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/matplotlib/ft2font.so:
>         /usr/local/lib/libfreetype.6.dylib (compatibility version
> 10.0.0, current version 10.10.0)
>         /usr/lib/libz.1.dylib (compatibility version 1.0.0, current
> version 1.2.3)
>         /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0,
> current version 7.4.0)
>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
> current version 88.3.3)
>         /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0,
> current version 1.0.0)
> 
> Is there something wrong with this?  I still don't seen anything
> about /usr/local/src/freetype in here (btw I switched from fink to the versions
> installed by i-installer because the odd warnings disappeared when
> compiling matplotlib; the same segfault occurs with either).

Right. You won't see anything about /usr/local/src/freetype-2.2.1/ there. What
you see is the location of the library when ft2font.so was built. That's the
library that it is trying to link against at runtime. I presume that that is the
one you installed with i-installer. Now, whoever built that library was building
from sources that he unpacked in /usr/local/src/freetype-2.2.1/ . That
information is recorded in the binary file for debugging purposes.

Now, since the bug is actually in freetype, not matplotlib or numpy, I suggest
finding a new build of freetype. I use MacPorts and have had absolutely no
trouble with it.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco


More information about the Numpy-discussion mailing list