Gnuplot Library Issues
Anthony Michael Agelastos
iqgrande at gmail.com
Fri Jul 23 21:02:11 PDT 2010
On Jul 23, 2010, at 11:57 PM, Ryan Schmidt wrote:
> On Jul 23, 2010, at 22:48, Anthony Michael Agelastos wrote:
>> On Jul 23, 2010, at 11:43 PM, Ryan Schmidt wrote:
>>> On Jul 23, 2010, at 22:36, Anthony Michael Agelastos wrote:
>>>
>>>> $ otool -L /opt/local/lib/libfreetype.6.dylib
>>>> /opt/local/lib/libfreetype.6.dylib:
>>>> /opt/local/lib/libfreetype.6.dylib (compatibility version 12.0.0, current version 12.1.0)
>>>> /opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5)
>>>> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.0)
>>>> $ lipo -info /opt/local/lib/libfreetype.6.dylib
>>>> Non-fat file: /opt/local/lib/libfreetype.6.dylib is architecture: i386
>>>>
>>>> All of that seems correct to me.
>>>
>>> Yes it does.... assuming this computer really is 32-bit only. You're sure it is? What's the output of
>>>
>>> sysctl hw.cpu64bit_capable
>>
>> $ sysctl hw.cpu64bit_capable
>> hw.cpu64bit_capable: 0
>
> Indeed. Well, I will guess that your non-MacPorts octave is using an older freetype, and that somehow, when gnuplot is used in the context of that octave, it then wants to use the same freetype, which MacPorts gnuplot is not designed to do. So I think the solution is to switch to using MacPorts octave. So tell us all you can about your problems building that so maybe we can fix that.
>
>
I am going to get it building that as soon as Xcode 3.2.3 finishes downloading. Thanks for all of your help on this. I'll post the build results in the morning after it has had time to compile.
More information about the macports-users
mailing list