Trouble installing py2cairo on Mac OSX Lion - osx-lion

I have spent the last several nights trying to install py2cairo on Mac OSX Lion using gcc-4.2 and Python2.6, attempting a number of the approaches mentioned in these links (among many others; as a new user, I can post only two links):
http://www.niconomicon.net/blog/2011/10/09/2120.wrestling.python.snow.leopard
How to install PyCairo 1.10 on Mac OSX with default python
Unfortunately, I'm still running into a problem with the wrong header files being found. See below for my environment settings and the error output from waf build. I'd greatly appreciate any pointers. Thanks!
Steves-Mac-Pro:py2cairo-1.10.0 dr_steve_kramer$ env
MANPATH=/sw/share/man:/usr/share/man:/usr/local/share/man:/usr/X11/man:/usr/local/mysql/man:/sw/lib/perl5/5.12.3/man:/usr/X11R6/man
TERM_PROGRAM=Apple_Terminal
TERM=xterm-256color
SHELL=/bin/bash
TMPDIR=/var/folders/8r/2kt_yqyx2dg2g83m0dyhcy740000gn/T/
LIBRARY_PATH=/Developer/SDKs/MacOSX10.6.sdk/usr/lib
PERL5LIB=/sw/lib/perl5:/sw/lib/perl5/darwin
Apple_PubSub_Socket_Render=/tmp/launch-bnnjZo/Render
TERM_PROGRAM_VERSION=303
OLDPWD=/private/tmp
TERM_SESSION_ID=3A9C4E28-D669-4134-A333-A13920514ED7
USER=dr_steve_kramer
LD_LIBRARY_PATH=/Library/Frameworks/Python.framework/Versions/6.3/lib:/Library/Frameworks/Python.framework/Versions/6.3:
COMMAND_MODE=unix2003
SSH_AUTH_SOCK=/tmp/launch-c3CJUO/Listeners
__CF_USER_TEXT_ENCODING=0x1F5:0:0
Apple_Ubiquity_Message=/tmp/launch-pYg8fw/Apple_Ubiquity_Message
PATH=/Library/Frameworks/Python.framework/Versions/6.3/bin:/Library/Frameworks/Python.framework/Versions/Current/bin:/opt/local/bin:/opt/local/sbin:/sw/bin:/sw/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin:/usr/local/bin:/usr/local/mysql/bin:/usr/local/bin/f2j-0.7/bin:/usr/local/jaxws-ri:/usr/X11R6/bin
MKL_NUM_THREADS=1
C_INCLUDE_PATH=/Developer/SDKs/MacOSX10.6.sdk/usr/include
PWD=/private/tmp/py2cairo-1.10.0
LANG=en_US.UTF-8
JAXWS_HOME=/usr/local/jaxws-ri
CXX=g++-4.2
SHLVL=1
HOME=/Users/dr_steve_kramer
CFLAGS=-I/usr/include/gcc/darwin/4.2/
LINKFLAGS=-search_dylibs_first -L /Library/Frameworks/Python.framework/Versions/6.3/lib/
PYTHONPATH=/Library/Frameworks/Python.framework/Versions/6.3/bin
LOGNAME=dr_steve_kramer
ACLOCAL_FLAGS=-I/usr/local/Cellar/pkg-config/0.25/share/aclocal
PKG_CONFIG_PATH=/sw/bin/pkg-config
ARCHFLAGS=-arch x86_64
INFOPATH=/sw/share/info:/sw/info:/usr/share/info
CC=/usr/bin/gcc-4.2
DISPLAY=/tmp/launch-CzK5Wg/org.x:0
_=/usr/bin/env
Steves-Mac-Pro:py2cairo-1.10.0 dr_steve_kramer$ python2.6 waf configure
./options()
Setting top to : /private/tmp/py2cairo-1.10.0
Setting out to : /private/tmp/py2cairo-1.10.0/build_directory
./configure()
Checking for 'gcc' (c compiler) : ok
Checking for program python : /Library/Frameworks/Python.framework/Versions/6.3/bin/python
python executable '/Library/Frameworks/Python.framework/Versions/6.3/bin/python' different from sys.executable '/Library/Frameworks/Python.framework/Versions/6.3/Resources/Python.app/Contents/MacOS/Python'
Checking for python version : (2, 6, 6, 'final', 0)
Checking for library python2.6 : yes
Checking for program python2.6-config : /Library/Frameworks/Python.framework/Versions/6.3/bin/python2.6-config
Checking for header Python.h : yes
Checking for program pkg-config : /sw/bin/pkg-config
Checking for 'cairo' >= 1.10.0 : yes
Configuration:
PREFIX : /usr/local
LIBDIR : /usr/local/lib
'configure' finished successfully (1.577s)
Steves-Mac-Pro:py2cairo-1.10.0 dr_steve_kramer$ python2.6 waf build
./options()
Waf: Entering directory `/private/tmp/py2cairo-1.10.0/build_directory'
./build()
src/build()
[1/9] c: src/cairomodule.c -> build_directory/src/cairomodule.c.1.o
[2/9] c: src/context.c -> build_directory/src/context.c.1.o
[3/9] c: src/font.c -> build_directory/src/font.c.1.o
[4/9] c: src/path.c -> build_directory/src/path.c.1.o
[5/9] c: src/pattern.c -> build_directory/src/pattern.c.1.o
[6/9] c: src/matrix.c -> build_directory/src/matrix.c.1.o
[7/9] c: src/surface.c -> build_directory/src/surface.c.1.o
[8/9] subst: pycairo.pc.in -> pycairo.pc
In file included from /Library/Frameworks/Python.framework/Versions/6.3/include/python2.6/unicodeobject.h:4In file included from /Library/Frameworks/Python.framework/Versions/6.3/include/python2.6/unicodeobject.h:4In file included from /Library/Frameworks/Python.framework/Versions/6.3/include/python2.6/unicodeobject.h:4,
from /Library/Frameworks/Python.framework/Versions/6.3/include/python2.6/Python.h:85,
from /Library/Frameworks/Python.framework/Versions/6.3/include/python2.6/Python.h:85In file included from /Library/Frameworks/Python.framework/Versions/6.3/include/python2.6/unicodeobject.h:4,
from ../src/pattern.c:32,
from /Library/Frameworks/Python.framework/Versions/6.3/include/python2.6/Python.h:85In file included from /Library/Frameworks/Python.framework/Versions/6.3/include/python2.6/unicodeobject.h:4,
from ../src/surface.c:32,
from ../src/matrix.c:32In file included from /Library/Frameworks/Pyth:
:
/usr/include/gcc/darwin/4.2/stdarg.h:5:2:,
from /Library/Frameworks/Python.framework/Versions/6.3/include/python2.6/Python.h:85on.framework/Versions/6.3/include/python2.6/unicodeobject.h:4In file included from /Library/Frameworks/Python.framework/Versions/6.3/include/python2.6/unicodeobject.h:4,
from /Library/Frameworks/Python.framework/Versions/6.3/include/python2.6/Python.h:85/usr/include/gcc/darwin/4.2/stdarg.h:5:2: ,
from ../src/cairomodule.c:32:
error: :
,
from ../src/path.c:32 /usr/include/gcc/darwin/4.2/stdarg.h:5:2:,
from /Library/Frameworks/Python.framework/Versions/6.3/include/python2.6/Python.h:85#error ,
from /Library/Frameworks/Python.framework/Versions/6.3/include/python2.6/Python.h:85"This header only supports __MWERKS__." :
,
from ../src/context.c:32error: /usr/include/gcc/darwin/4.2/stdarg.h:5:2:,
from ../src/font.c:32error:
#error /usr/include/gcc/darwin/4.2/stdarg.h:5:2::
:
"This header only supports __MWERKS__." #error /usr/include/gcc/darwin/4.2/stdarg.h:5:2:/usr/include/gcc/darwin/4.2/stdarg.h:5:2:
"This header only supports __MWERKS__."error: #error
error: "This header only supports __MWERKS__."#error error: error:
"This header only supports __MWERKS__."#error #error
"This header only supports __MWERKS__.""This header only supports __MWERKS__."
In file included from /Developer/SDKs/MacOSX10.6.sdk/usr/include/wchar.h:111,
from /Library/Frameworks/Python.framework/Versions/6.3/include/python2.6/unicodeobject.h:120,
from /Library/Frameworks/Python.framework/Versions/6.3/include/python2.6/Python.h:85,
from ../src/matrix.c:32:
/usr/include/gcc/darwin/4.2/stdarg.h:5:2: error: #error "This header only supports __MWERKS__."

If you haven’t solved this yet, try cairocffi: http://packages.python.org/cairocffi/

In case anyone is still have issues with py2cairo on OSX. I was able to get running by using install_name_tool. The config/build process was working and finding the correct version of python. However the compiled binary was linked against the incorrect version of python. This appears to be a bug in waf build system.
To fix the problem...
$ cd /usr/local/lib/python2.7/site-packages/cairo
$ otool -L _cairo.so
_cairo.so:
/Users/charlie/Downloads/py2cairo/build_directory/src/_cairo.so (compatibility version 0.0.0, current version 0.0.0)
/usr/local/lib/libcairo.2.dylib (compatibility version 11403.0.0, current version 11403.2.0)
/System/Library/Frameworks/Python.framework/Versions/2.7/Python (compatibility version 2.7.0, current version 2.7.6)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)
$ sudo install_name_tool -change /System/Library/Frameworks/Python.framework/Versions/2.7/Python /Library/Frameworks/Python.framework/Versions/2.7/Python _cairo.so
$ otool -L _cairo.so
_cairo.so:
/Users/charlie/Downloads/py2cairo/build_directory/src/_cairo.so (compatibility version 0.0.0, current version 0.0.0)
/usr/local/lib/libcairo.2.dylib (compatibility version 11403.0.0, current version 11403.2.0)
/Library/Frameworks/Python.framework/Versions/2.7/Python (compatibility version 2.7.0, current version 2.7.6)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)
You can then import and use cairo in the version of python that you ran the waf script with.

Related

TestFlight build with error: One or more dynamic libraries that are referenced by your app are not present in the dylib search path

I've been recently trying to overcome the problem mentioned in the email I receive when I upload a build to TestFlight:
ITMS-90562: Invalid Bundle - One or more dynamic libraries that are referenced by your app are not present in the dylib search path.
I have added Google Admob via Cocoapods (it's the only library I have in Cocoapods) and I have several other libraries added via SPM:
I have also tried to validate the IPA generated for which I receive the dreadful email and Xcode says that it's a valid IPA.
I have also tried looking at https://medium.com/360learning-engineering/resolving-itms-90562-invalid-bundle-email-from-the-app-store-d4a1030418e5 and the frameworks that I get with the #rpath are the following, but the problem I have here is that since I'm using Cocoapods and SPM, there's no Frameworks folder:
#rpath/FBLPromises.framework/FBLPromises (compatibility version 1.0.0, current version 1.0.0)
#rpath/GoogleUtilities.framework/GoogleUtilities (compatibility version 1.0.0, current version 1.0.0)
#rpath/nanopb.framework/nanopb (compatibility version 1.0.0, current version 1.0.0)
#rpath/libswift_Concurrency.dylib (compatibility version 1.0.0, current version 5.6.0, weak)
This is the content of the folder:
I have also tried to add those libraries with the #rpath to the Link binary with libraries but I'm still getting the email.
I'm at this point completely stuck since I don't know what else I can do here, nor how to fix this, so any help is very much appreciated!
Thanks in advance!
The solution here is to disable bitcode

How to debug objc runtime linking multiple instances of the same library

I'm working on a Swift project which links agains libSDL2. I had to patch a few things in that library to fit my needs and thus it currently lives in the same directory as my project and is compiled and linked from there. When I run my application, I get a bunch of warning form:
objc[13894]: Class SDLApplication is implemented in both
/opt/local/lib/libSDL2-2.0.0.dylib (0x10f116228) and
/Users/<my-project>/Libraries/SDL-install/lib/libSDL2-2.0.0.dylib
(0x10ef6d240). One of the two will be used. Which one is undefined.
I do have a globally-installed instance of libSDL2 under /opt/local, installed via MacPorts and used by some applications also installed via MacPorts, so I can't remove that.
I tried looking at the libraries that the compiled binary links agains but could not find a reference to the instance installed in /opt/local.
$ otool -L .build/debug/TestLines
.build/debug/TestLines:
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1770.255.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.60.1)
/Users/<my-project>/Libraries/SDL-install/lib/libSDL2_image-2.0.0.dylib (compatibility version 3.0.0, current version 3.3.0)
/Users/<my-project>/Libraries/SDL-install/lib/libSDL2-2.0.0.dylib (compatibility version 17.0.0, current version 17.0.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1770.255.0)
#rpath/libswiftCore.dylib (compatibility version 1.0.0, current version 1200.2.41)
<...>
How can I debug this issue?
In the end it was easy to figure out. It turned out that the libSDL2_image-2.0.0.dylib was linked against the instance of libSDL2 from /opt/local. To figure this out I simply had to follow the libraries linked by my binary and inspect those instead of just the main binary:
$ otool -L Libraries/SDL-install/lib/libSDL2_image-2.0.0.dylib
Libraries/SDL-install/lib/libSDL2_image-2.0.0.dylib:
/Users/<my-project>/Libraries/SDL-install/lib/libSDL2_image-2.0.0.dylib (compatibility version 3.0.0, current version 3.3.0)
/opt/local/lib/libSDL2-2.0.0.dylib
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1)
/opt/local/lib/libiconv.2.dylib (compatibility version 9.0.0, current version 9.1.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 52.0.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1677.104.0)
/System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics (compatibility version 64.0.0, current version 1355.22.0)
/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 1069.24.0)
/System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO (compatibility version 1.0.0, current version 1.0.0)
(The root cause in this instance was that I had to pass --sdl-prefix in addition to --prefix to the ./configure script from SDL_image)

Determine the Swift compiler version used to create a Framework

I want to know what compiler version was used exactly. In my example I tried the following:
otool -L TestFramework
TestFramework:
#rpath/TestFramework.framework/Versions/A/TestFramework (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1675.129.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1)
#rpath/libswiftCore.dylib (compatibility version 1.0.0, current version 1103.8.25)
It looks like 1103.8.25 could be useful, but when I look the version up (on Wikipedia) it doesn't help, as the versions there look like this:
5.3 (swiftlang-1200.0.29.2 clang-1200.0.30.1),
5.3.1 (swiftlang-1200.0.41 clang-1200.0.32.8),
5.3.2 (swiftlang-1200.0.45 clang-1200.0.32.28)
etc..
It looks like that my 1103.8.25 might hint to one of these:
5.2 (swiftlang-1103.0.32.1 clang-1103.0.32.29),
5.2.2 (swiftlang-1103.0.32.6 clang-1103.0.32.51),
5.2.4 (swiftlang-1103.0.32.9 clang-1103.0.32.53),
5.2.4 (swiftlang-1103.0.32.9 clang-1103.0.32.53),
5.2.4 (swiftlang-1103.0.32.9 clang-1103.0.32.53)
, because of the 1103 but which one is it?
I am aware that I can check the .swiftinterface file if the binary has been compiled with ABI stability, but let's assume it hasn't been. How does Xcode do it?
Is there a list of libswiftCore.dylib versions somewhere that can be used for lookup?

gpuDevice() toolkit version always 5.5

No matter how I reinstall the CUDA driver and toolkit, when typing gpuDevice(), it always show s:
CUDADevice with properties:
Name: 'Quadro K2000M'
Index: 1
ComputeCapability: '3.0'
SupportsDouble: 1
DriverVersion: 6.5000
ToolkitVersion: 5.5000
MaxThreadsPerBlock: 1024
MaxShmemPerBlock: 49152
MaxThreadBlockSize: [1024 1024 64]
MaxGridSize: [2.1475e+09 65535 65535]
SIMDWidth: 32
TotalMemory: 2.1475e+09
FreeMemory: 2.0431e+09
MultiprocessorCount: 2
ClockRateKHz: 745000
ComputeMode: 'Default'
GPUOverlapsTransfers: 1
KernelExecutionTimeout: 0
CanMapHostMemory: 1
DeviceSupported: 1
DeviceSelected: 1
which I don't understand. Why the toolkit version is always 5.5? Can I upgrade it to 6.5?
As #Robert mentioned, you have to use the same cuda version but not necessarily if you use simple trick (I'm using CUDA 6.0 and MATLAB CUDA version is 5.0). To make it work, you do not need the complicated procedure, nor the mex for compiling all .cu files and copying the xml file ( as in Link) to the directory to compile. Type simply the following two lines in the matlab command,
!nvcc -O3 -DNDEBUG -c mexGPUExample.cu -Xcompiler -fPIC -I/MATLAB_ROOT/extern/include -I/MATLAB_ROOT/toolbox/distcomp/gpu/extern/include;
mex mexGPUExample.o -L/usr/local/cuda-6.0/lib64 -L/MATLAB_ROOT/bin/glnxa64 -lcudart -lcufft -lmwgpu
Then it will magically work even if your ToolkitVersion mismatches. (Change /MATLAB_ROOT to your matlab root path)
Why MATLAB CUDA Toolkit version is different from System CUDA version?
Regarding your question, the installed CUDA version is not the same CUDA that MATLAB use.
If you go to
/matlabroot/bin/maci64 (OS X)
/matlabroot/bin/glnxa64 (unix variant)
depending on your os,
you can see the [dynamic linking library, shared library]
libcudart.5.5.[dylib, so]
libcublas.5.5.[dylib, so]
libcufft.5.5.[dylib, so]
These are the libraries that MATLAB uses. To make matlab to use system libraries, follow the instructions below. (MAC only)
In sum,
The installed cuda version is different from MATLAB cuda since they have their own library
To trick it to load the new library, you might need to use install_name_tool to change the library link
Anyway you don't need it to have same version.
EDIT : How to make MATLAB to use System CUDA Library (OS X)
Make MATLAB to use System CUDA library, The default MATLAB CUDA library version is 5.5 and if you want to use the up-to-date library, read the following
Go to /Applications/MATLAB_R2014a.app/bin/maci64(MAC) or MATLAB_ROOT/bin/glxna64(LINUX)
See the library dependencies of libmwgpu.[dylib, so] this is the entry library that is loaded when you use CUDA
The result would look like
dnab404675:maci64 user$ otool -L libmwgpu.dylib
libmwgpu.dylib:
#rpath/libmwgpu.dylib (compatibility version 0.0.0, current version 0.0.0)
.... Some Libraries
#rpath/libcublas.5.5.dylib (compatibility version 5.5.0, current version 5.5.20)
#rpath/libcudart.5.5.dylib (compatibility version 5.5.0, current version 5.5.20)
#rpath/libcufft.5.5.dylib (compatibility version 5.5.0, current version 5.5.20)
... and more
Our goal is to modify the library dependency of `cublas`, `cudart`, `cufft` to
> /usr/local/cuda/lib/libcublas.dylib (compatibility version 5.5.0, current version 5.5.20)
/usr/local/cuda/lib/libcudart.dylib (compatibility version 5.5.0, current version 5.5.20)
/usr/local/cuda/lib/libcufft.dylib (compatibility version 5.5.0, current version 5.5.20)
Note that if you type gpuDevice, it will still show it as toolkit version 5. But it loads the new version. So how we do that?
Simply type
sudo install_name_tool -change #rpath/libcufft.5.5.dylib /usr/local/cuda/lib/libcufft.dylib libmwgpu.dylib
sudo install_name_tool -change #rpath/libcudart.5.5.dylib /usr/local/cuda/lib/libcudart.dylib libmwgpu.dylib
sudo install_name_tool -change #rpath/libcublas.5.5.dylib /usr/local/cuda/lib/libcublas.dylib libmwgpu.dylib
I still don't know how to change the shared library path in Linux. Probably have to use hexadecimal editor such as HT From Stackoverflow Answer
You can also use CUDA 6.5 with matlab under Windows. The tricky part is, you need to compile the mex files under Visual Studio rather than inside matlab. There are numerous tutorials introducing how to compile mex under VS so there is no need to repeat here. You need only to create a NVIDIA cuda project with .cu as the source, and follow the standard procedures to compile mex.

dyld: Library not loaded when build to iphone 4

I am using a third-party library,say: libABC.dylib
I want use the dylib in an open source application,and want to install into my iphone 4,with ios 6,without jailbroken.
On doing a
$ otool -L libABC.dylib
libABC.dylib:
libABC.dylib (compatibility version 1.0.0, current version 1.0.0)
libXYZ.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
111.1.5)
Now i want to ship the dylib, with my app , install into my iphone 4.
For that i have changed the dylib paths as
$ install_name_tool -id #executable_path/../Frameworks/libABC.dylib libABC.dylib
also,I added libABC.dylib to Frameworks under the project in Xcode.
This changes the inside dylib paths as
$ otool -L libABC.dylib
libABC.dylib:
#executable_path/../Frameworks/libABC.dylib (compatibility version
1.0.0, current version 1.0.0)
libXYZ.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
111.1.5)
The problem is:
libABC is loaded at app launch time,
i am unable to change this path, to a path relative to my mach-o binary
(inside my app bundle)
So my app is failing to load.
Dyld Error Message:
dyld: Library not loaded: /usr/local/lib/libABC.dylib
Referenced from:
....
Reason: image not found
Please suggest me some direction.
The third party library is only creating dylib, no static libs
I also tried setting XCode options to get dylib from "#executable_path" but
it didnt work.
and I don not load my dylib through code?
Please suggest. I am clueless here.
Advance Thanks :)
Unfortunately NO, you are out of luck, start looking for alternatives. You can't add custom/third party dylibs to an iOS project, iOS project only support addition of built-in dynamic libraries. Moreover any tries and success to add dylibs may cause you app rejected from apple.
Why? Have a look at this post for detailed discussion. specially the 2nd comment on marked answer.
Like you could read in #Adil Soomro's reference, third party frameworks are not supported because of security reasons. That's why you have to delete all the frameworks that appear inside the log when you try to build an app. Normally it should work if these Frameworks are not included. If the debugger will turn on while building you should press play till the app will be installed.
But keep looking what kind of frameworks you are using so you don't get rejected when the app will be reviewed.
Further more, a related error method can occure if you start an app on ios 5.1 or less and some of your frameworks are not supported on these os versions.