I'm running Pd-0.52-2 on MacOS Monterey (12.6) and having trouble with externals that I created. When developing/debugging, everything is fine. I have 4 externals with extensions .pd_darwin, each dependent upon a DLL named libo2pd.dylib. With everything in ~/Documents/Pd/externals/, I can start my locally compiled pd-0.52-2.app, and everything works. But if I run a downloaded /Applications/Pd-052-2.app and try to create one of these external objects, I get the message:

/Users/rbd/Documents/Pd/externals/o2ensemble.pd_darwin: dlopen(/Users/rbd/Documents/Pd/externals/o2ensemble.pd_darwin, 0x000A): Library not loaded: 'libo2pd.dylib'
  Referenced from: '/Users/rbd/Documents/Pd/externals/o2ensemble.pd_darwin'
  Reason: tried: 'libo2pd.dylib' (relative path not allowed in hardened program), '/usr/lib/libo2pd.dylib' (no such file)
 o2ensemble o2global
... couldn't create

I get the same results running from the command line, and running from the directory with the .dylib and externals does not make any difference. Note that /usr/lib is protected even using sudo, so even if I could install libo2pd.dylib there, I don't think it's an acceptable solution.

I suspect this problem stems from Apple security policies, but I don't know how Pd searches for .dylibs and there's a lot of ambiguity in documentation and discussions since "libraries" and "paths" are used in multiple ways. I also tried setting LD_LIBRARY_PATH and running from the command line, but that didn't work.

Does anyone know to set up Pd for an external that depends on a DLL?

The usual way I've messed with it is by changing RPATH and using the otool and install_name_tool utilities. Usually I use the pd-lib-builder project to include libraries for me
https://github.com/pure-data/pd-lib-builder

But I think you're correct that judging by the message it's a notarizing issue. It may be necessary to open an issue in pd for adding the necessary entitlements to the .plist file

You could also try compiling/notarizing pd yourself and adding the necessary entitlements to the .plist yourself.. (& if you figure it out maybe open a pull request on github..)
Edit: I see that it works if you compile yourself. That probably means that pd you downloaded needed different notarization

Can you open other externals in pd ok? In that case maybe you can/need to do something to notarize the external itself..

Thanks! I finally got back to this and found a very clear tutorial about paths and dynamic libraries. In my case, I think the externals are loaded because Pd constructs an explicit full path to them, but they depend on a shared library that I thought would simply load from the same place or maybe the executable directory. But no, a "full path" is needed. I put that in quotes, because, while the error message says you cannot use a relative path, the solution in fact is to use a relative path! The trick is that you have to provide an explicit relative path policy (this is not Apple's terminology and they seem a little confused). Policies include executable-relative, loader-relative, and RPATH-relative. In my case, I needed to write @loader_path/libo2pd.dylib to mean "find libo2pd.dylib relative to the path where the loader found the Pd external." I made things work using the following:

install_name_tool -id @loader_path/libo2pd.dylib libo2pd.dylib
install_name_tool -change libo2pd.dylib @loader_path/libo2pd.dylib o2ensemble.pd_darwin
install_name_tool -change libo2pd.dylib @loader_path/libo2pd.dylib o2property.pd_darwin
install_name_tool -change libo2pd.dylib @loader_path/libo2pd.dylib o2receive.pd_darwin
install_name_tool -change libo2pd.dylib @loader_path/libo2pd.dylib o2send.pd_darwin

where the .dylib file is the one loaded and required by the .pd_darwin files. There must be ways to specify all this as linker options, but I haven't gotten there yet.

I hope this might help someone make sense of their dll problems.