We Keep Coding

Linking to system python gives 'binary is not an allowed client' error

I have just updated my Macbook to Monterey and installed XCode 13. I'm now seeing errors when trying to link my code - for example one library needs to link to the system python2.7, but gives the error:
Keiths-MacBook-Pro:libcdb keith$ make rm -f libcdb.1.0.0.dylib
libcdb.dylib libcdb.1.dylib libcdb.1.0.dylib
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++
-stdlib=libc++ -headerpad_max_install_names -arch x86_64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.0.sdk
-mmacosx-version-min=10.13 -Wl,-rpath,#executable_path/../Frameworks -Wl,-rpath,/usr/local/Qt-5.15.7/lib -single_module -dynamiclib -compatibility_version 1.0 -current_version 1.0.0 -install_name libcdb.1.dylib -o libcdb.1.0.0.dylib release/db.o release/KDTree.o release/db_Wlist.o release/db_VSeg.o
release/db_View.o release/db_ViaInst.o release/db_ViaGen.o
release/db_Via.o release/db_Vertex.o release/db_Vector.o
release/db_Utils.o release/db_Trapezoid.o release/db_Transform64.o
release/db_Transform.o release/db_Techfile.o release/db_Style.o
release/db_Signal.o release/db_Shape.o release/db_SegParam.o
release/db_Segment.o release/db_Rectangle.o release/db_Rect.o
release/db_QTree.o release/db_Property.o release/db_Polygon.o
release/db_PointList.o release/db_Point.o release/db_Pin.o
release/db_Path.o release/db_ObjList.o release/db_Obj.o
release/db_Net.o release/db_Mst.o release/db_Mpp.o release/db_Lpp.o
release/db_Line.o release/db_Library.o release/db_Layer.o
release/db_Label.o release/db_InstPin.o release/db_Inst.o
release/db_HVTree.o release/db_HSeg.o release/db_HierObj.o
release/db_Group.o release/db_Ellipse.o release/db_Edge.o
release/db_CellView.o release/db_Cell.o release/db_Array.o
release/db_Arc.o -F/usr/local/Qt-5.15.7/lib -L../libcpp/release -lcpp
-L/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/config
-lpython2.7 -framework QtWidgets -framework QtGui -framework AppKit -framework Metal -framework QtNetwork -framework QtCore -framework DiskArbitration -framework IOKit -framework OpenGL -framework AGL
ld: cannot link directly with dylib/framework, your binary is not an
allowed client of
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.0.sdk/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/config/libpython2.7.tbd
for architecture x86_64 clang: error: linker command failed with exit
code 1 (use -v to see invocation) make: ***
[release/libcdb.1.0.0.dylib] Error 1
Given that I have recompiled (successfully) the Qt libs and the code for this library, why is it giving me this 'your binary is not an allowed client' error?
As far as I can see the python2.7 paths have not changed, so the error is baffling.

So the quick and diirty fix is to edit the Python.tdb file that is located at:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.0.sdk/System/Library/Frameworks/Python.framework/Versions/Current/Python.tdb
And add your library/executable targets to the clients list.
Of course, there is a reason Apple are doing this - python2 is deprecated and sooner or later they will drop it. But until they do, this works.

What fixed it for me was to drop the Python2 framework and link with the framework provided by my version of Python3 installed via Brew.
Locate your installation of Python3 by using this command in Terminal: ls -la $(which python3).
The framework is in the "Frameworks" folder located one level above "bin", for example: /usr/local/Cellar/python#3.9/3.9.7_1/Frameworks
Once your have the location of the Python3 framework, add it as a framework in your XCode project.
In the Build Settings, don't forget to add:
the Frameworks folder location in Framework Search Path (e.g. "/usr/local/Cellar/python#3.9/3.9.7_1/Frameworks")
the framework's Headers folder in Header Search Path (e.g. "/usr/local/Cellar/python#3.9/3.9.7_1/Frameworks/Python.framework/Headers")
Some functions changed in version 3 so you'll need to update some of your Python function calls.

Python / C++ binding, how to link agains static c++ library (portaudio) with distutils?

I am trying to staticaly link the "c++ portaudio library" against my "C++ demo module" which is a python callable library (module).
I'm doing this with distutils, and in order to perform the static linking, I've added the libportaudio to the extra_objects argument, as follows:
module1 = Extension(
"demo",
sources=cppc,
# TODO remove os dependency
extra_compile_args=gccArgs,
# link against shared libraries
#libraries=[""]
# link against static libraries
extra_objects=["./clib-3rd-portaudio/libportaudio.a"]) # << I've added the static lib here
Compiling with "python setup.py build" results in the following linker error:
/usr/bin/ld: ./clib-3rd-portaudio/libportaudio.a(pa_front.o): relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a shared object; recompile with -fPIC
./clib-3rd-portaudio/libportaudio.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
So at this point I've tried the obvious, I've added the -fPIC flagg to gccArgs (note extra_compile_args=gccArgs above), as follows:
gccArgs = [
"-Icsrc",
"-Icsrc/paExamples",
"-Icinc-3rd-portaudio",
"-Icinc-3rd-portaudio/common",
"-Icinc-3rd-portaudio/linux",
"-fPIC"] # << I've added the -fPIC flag here
However this results in the exact same error, so I guess the -fPIC flag is not the root cause. I'm probably missing something trivial, but I'm a bit lost here, hope somebody can help.

As the error message said, you should recompile the external library libportaudio.a with -fPIC argument, NOT your own codes. That's why it doesn't help to add -fPIC to your extra_compile_args.
Several other posts suggest that the file libportaudio.a cannot be used to build shared library, probably because the default build settings of portaudio don't include -fPIC.
To recompile portaudio correctly, download the source and try to run ./configure with -shared option (or something similar). If you cannot find the proper option, then modify the Makefile and append -fPIC to the extra compile options. You can also compile each object file manually and pack them into libportaudio.a.
Since your target file (libdemo.so) is a shared library, you must make sure ANY object codes included inside are compiled with -fPIC option. To understand why you need this option, please refer to:
What does -fPIC mean when building a shared library? and Position Independent Code (PIC) in shared libraries

Building and installing for multiple versions of Python using autotools

I'm trying to figure out how to build my project for multiple versions of Python.
I'm testing this on Debian wheezy, where the default version of Python is 2.7.
but 2.6 is also supported and installed. However, automake is only installing
and compiling for Python 2.7. I'd like it to compile for 2.6 as well.
Here are the configure.ac and Makefile.am. I can provide more details if necessary, but hopefully these will suffice.
I'm a beginner with Autotools, so there may be some obvious solution to this.
There is what appears to be a wishlist bug about this:
RFE: build against multiple python stacks. There is also
a similar discussion here: RFC: (automake) add support for dual python 2 / python 3 builds.
There is also a proposed solution (which looks complicated), given at
CDBS + Autotools + Python
This is configure.ac.
##################################################################################
# -*- Autoconf -*-
# Process this file with autoconf to produce a configure script.
AC_PREREQ([2.69])
AC_INIT([corrmodel], [0.1], [faheem#faheem.info])
AM_INIT_AUTOMAKE([foreign -Wall -Werror -Wno-extra-portability parallel-tests])
AM_MAINTAINER_MODE
AC_CONFIG_MACRO_DIR([m4])
AC_CONFIG_HEADERS([config.h])
AC_CONFIG_FILES([Makefile])
# Checks for programs.
AC_PROG_CXX
AC_PROG_CC
AM_PATH_PYTHON([2.6])
# Checks for libraries.
AX_BOOST_BASE
AX_BOOST_PYTHON
# Checks for header files.
# Checks for typedefs, structures, and compiler characteristics.
# Checks for library functions.
#AC_CONFIG_SUBDIRS([hello/hello-2.9])
LT_INIT
AC_OUTPUT
##################################################################################
Here is Makefile.am.
##################################################################################
# Define primaries
noinst_LTLIBRARIES = libcommon.la
dist_sysconf_DATA = corrmodel/default_conf.yaml
COMMON_CPPFLAGS = -I /usr/include/python$(PYTHON_VERSION) -L/usr/lib/python$(PYTHON_VERSION)/config -ftemplate-depth-100 -fno-strict-aliasing -fno-common -ansi -Wextra -Wall -Werror -Wno-unused-function -Wc++0x-compat -Wshadow -Wpointer-arith -Wcast-qual -Wcast-align -std=c++11 -march=native -mtune=native -mfpmath=sse -msse3 -O3 -DBOOST_PYTHON_DYNAMIC_LIB -DBOOST_PYTHON_MAX_ARITY=20
libcommon_la_SOURCES = randutil.cc util.cc gendata_fn.cc model.cc score_fn.cc search_fn.cc pval.cc print.cc \
common.hh util.hh model.hh gendata_fn.hh randutil.hh score_fn.hh search_fn.hh pval.hh \
print.hh
COMMON_LDFLAGS = -lblitz -lRmath -lpython$(PYTHON_VERSION) -lm -lboost_python
libcommon_la_CPPFLAGS = $(COMMON_CPPFLAGS)
#libcommon_la_LDFLAGS = $(COMMON_LDFLAGS)
# name of Python library.
# See http://www.gnu.org/software/automake/manual/html_node/Python.html
pkgpyexec_LTLIBRARIES = cpplib.la
cpplib_la_SOURCES = cpparr_conv_pif.cc cppmap_conv_pif.cc cpppair_conv_pif.cc cppset_conv_pif.cc cpptup_conv_pif.cc \
cppvec_conv_pif.cc cppunicode_conv_pif.cc util_pif.cc gendata_fn_pif.cc model_pif.cc score_fn_pif.cc \
search_fn_pif.cc pval_pif.cc main.cc conv_pif.hh util_pif.hh gendata_fn_pif.hh score_fn_pif.hh search_fn_pif.hh
cpplib_la_CPPFLAGS = $(COMMON_CPPFLAGS)
cpplib_la_LDFLAGS = -module -avoid-version -share $(COMMON_LDFLAGS)
cpplib_la_LIBADD = libcommon.la
ACLOCAL_AMFLAGS = -I m4
pkgpython_PYTHON = corrmodel/dbschema.py corrmodel/__init__.py corrmodel/init_schema.py corrmodel/modeldist.py corrmodel/crossval.py corrmodel/dbutils.py corrmodel/getmodel.py corrmodel/load.py corrmodel/utils.py
##################################################################################

Automake's job is to create a buildsystem consisting of a configure script and a set of Makefiles which detect the properties of the build environment in an appropriate level of detail so the software package can be built for that build environment.
Build environments might be just a specific set of options to configure to run your compiler with different options. Or to run with a different compiler the same machine. Or inside another operating system in a container or a VM, or on two racks full of build server farms.
Defining, setting up, accessing and maintaining those different build environments is outside of Automake's scope. You need to do that yourself with the help of whatever set of tools you want to use for that.
Then you can (or have your special tool set) run the Automake generated buildsystem within these different build environments to build the software package.

Compile PJSUA on OS X 10.9

First time using stackoverflow, please tell me, if I'm doing something wrong!
I want to use PJSIP 2.1s python module (wrapper). I tried it like so:
Read the documentation.
Check the requirements accordingly. This is my setup:
OS X 10.9 (Mavericks)
GNU Make 3.81
binutils 2.23.2 (probably via Macports.. not actually sure)
Apple LLVM 5.0
Download v2.1: pjproject-2.1.tar.bz2 and extracted it into my home dir.
Cd into pjproject-2.1 and run this in terminal: ./configure && make dep && make.
When it comes to this line (which is during make, I believe): gcc -o ../bin/pjmedia-test-i386-apple-darwin13.0.0, the following error gets thrown right into my face :/
Undefined symbols for architecture x86_64:
"_aes_icm_advance_ismacryp", referenced from:
_aes_icm_encrypt_ismacryp in libsrtp-i386-apple-darwin13.0.0.a(aes_icm.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [../bin/pjmedia-test-i386-apple-darwin13.0.0] Error 1
make[1]: *** [pjmedia-test] Error 2
make: *** [all] Error 1
The script then aborts.
Do you have any suggestions, what might be the problem, or how to avoid it? Will be glad for any help!
Would it help, to force gcc to compile to 32 bit?

i am not sure, if this solves your problem, but for me it worked:
Disable SRTP (Secure Real-Time Transport Protocol)
Add the following to the file pjlib/include/pj/config_site.h
#define PJMEDIA_HAS_SRTP 0
make again - should work.
The right solution would be to reimplement the missing structure in the c code. Probably better to wait for a patch.

"cannot find -lpq" when trying to install psycopg2

Intro: I'm trying to migrate our Trac SQLite to a PostgreSQL backend, to do that I need psycopg2. After clicking past the embarrassing rant on www.initd.org I downloaded the latest version and tried running setup.py install. This didn't work, telling me I needed mingw. So I downloaded and installed mingw.
Problem: I now get the following error when running setup.py build_ext --compiler=mingw32 install:
running build_ext
building 'psycopg2._psycopg' extension
writing build\temp.win32-2.4\Release\psycopg\_psycopg.def
C:\mingw\bin\gcc.exe -mno-cygwin -shared -s build\temp.win32-2.4\Release\psycopg
\psycopgmodule.o build\temp.win32-2.4\Release\psycopg\pqpath.o build\temp.win32-
2.4\Release\psycopg\typecast.o build\temp.win32-2.4\Release\psycopg\microprotoco
ls.o build\temp.win32-2.4\Release\psycopg\microprotocols_proto.o build\temp.win3
2-2.4\Release\psycopg\connection_type.o build\temp.win32-2.4\Release\psycopg\con
nection_int.o build\temp.win32-2.4\Release\psycopg\cursor_type.o build\temp.win3
2-2.4\Release\psycopg\cursor_int.o build\temp.win32-2.4\Release\psycopg\lobject_
type.o build\temp.win32-2.4\Release\psycopg\lobject_int.o build\temp.win32-2.4\R
elease\psycopg\adapter_qstring.o build\temp.win32-2.4\Release\psycopg\adapter_pb
oolean.o build\temp.win32-2.4\Release\psycopg\adapter_binary.o build\temp.win32-
2.4\Release\psycopg\adapter_asis.o build\temp.win32-2.4\Release\psycopg\adapter_
list.o build\temp.win32-2.4\Release\psycopg\adapter_datetime.o build\temp.win32-
2.4\Release\psycopg\_psycopg.def -LC:\Python24\libs -LC:\Python24\PCBuild -Lc:/P
ROGRA~1/POSTGR~1/8.3/lib -lpython24 -lmsvcr71 -lpq -lmsvcr71 -lws2_32 -ladvapi32
-o build\lib.win32-2.4\psycopg2\_psycopg.pyd
C:\mingw\bin\..\lib\gcc\mingw32\3.4.5\..\..\..\..\mingw32\bin\ld.exe: cannot fin
d -lpq
collect2: ld returned 1 exit status
error: command 'gcc' failed with exit status 1
What I've tried - I noticed the forward slashes in the -L option, so I manually entered my PostgreSQL lib directory in the library_dirs option in the setup.cfg, to no avail (the call then had a -L option with backslashes, but the error message stayed the same).

Have you tried the binary build of psycopg2 for windows? If that works with your python then it mitigates the need to build by hand.
I've seen random people ask this question on various lists and it seems one recommendation is to build postgresql by hand to work around this problem.

Compiling extensions on windows can be tricky. There are precompiled libraries available however: http://www.stickpeople.com/projects/python/win-psycopg/