Hi. 

On MacOS 11.3 "Big Sur", with the latest 3.9.4 installed with the official installer downloaded from python.org, the DYLD_LIBRARY_PATH environment variable is not being respected. 

This looks very similar to Issue40198
https://bugs.python.org/issue40198

To begin everything looks correct as per 40198:

    ~ $ python3 --version
    Python 3.9.4
    ~ $ which python3
    /Library/Frameworks/Python.framework/Versions/3.9/bin/python3
    ~ $ codesign --display --entitlements=:- /Library/Frameworks/Python.framework/Versions/3.9/bin/python3
    Executable=/Library/Frameworks/Python.framework/Versions/3.9/bin/python3.9
    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
    <plist version="1.0">
    <dict>
    <key>com.apple.security.cs.allow-dyld-environment-variables</key>
    <true/>
    <key>com.apple.security.cs.disable-library-validation</key>
    <true/>
    <key>com.apple.security.cs.disable-executable-page-protection</key>
    <true/>
    <key>com.apple.security.automation.apple-events</key>
    <true/>
    </dict>
    </plist>


The active python is that from the official installer, and it looks to have the correct entitlements, as per the resolution to 40198. 

However, it's not working in practice. 

I create a script test: 

    ~ $ cat ~/bin/sqlite_config.py 
    import os
    import sqlite3

    print("DYLD_LIBRARY_PATH:" )
    print(os.getenv('DYLD_LIBRARY_PATH'))

    print("SQLite Version:")
    print(sqlite3.sqlite_version)

Together with a compiled SQLite version: 

    ~ $ ls /Users/carlton/lib/sqlite/3.35.4
    libsqlite3.dylib

Trying to use this, the dylib is not picked up: 

    ~ $ DYLD_LIBRARY_PATH="/Users/carlton/lib/sqlite/3.35.4" python3 ~/bin/sqlite_config.py 
    DYLD_LIBRARY_PATH:
    /Users/carlton/lib/sqlite/3.35.4
    SQLite Version:
    3.34.0

Contrast the same when run with a pyenv installed python: 

    ~ $ pyenv which python3.8
    /Users/carlton/.pyenv/versions/3.8.3/bin/python3.8
    ~ $ DYLD_LIBRARY_PATH="/Users/carlton/lib/sqlite/3.35.4" /Users/carlton/.pyenv/versions/3.8.3/bin/python3.8 ~/bin/sqlite_config.py 
    DYLD_LIBRARY_PATH:
    /Users/carlton/lib/sqlite/3.35.4
    SQLite Version:
    3.35.4

The expected result, in both cases, is that the last lines should read: 

    SQLite Version:
    3.35.4



I don't know if this is the result of a tightening in macOS' SIP in Big Sur (or something else entirely...) — I thought to test it by installing the official build in a different location (so not in the SIP protected `/Library/` space but somewhere in `~` but the installer doesn't look like it allows that (no doubt for good reasons). 

Next step for me with be building from source to see if I can dig deeper, but I thought I'd report it, as it does look like a change in behaviour from the *success* reported in 40198. 

Thanks very much!

Thanks for the report. However, I think you've drawn the wrong conclusion form what you've observed. The reason you are unable to do what you are trying to do is that the _sqlite3 module included with the python.org macOS Pythons is statically linked with its own copy of an sqlite3 library, not dynamically linked. This has been true for a long time (10+ years); I believe the original reason was to avoid linking with the Apple-supplied system copy of the sqlite3 library.  You can see this by using otool:

- with the python.org 3.9.4:

$ /usr/local/bin/python3.9 -c 'import sys;print(sys.version)'
3.9.4 (v3.9.4:1f2e3088f3, Apr  4 2021, 12:19:19)
[Clang 12.0.0 (clang-1200.0.32.29)]
$ /usr/local/bin/python3.9 -c 'import _sqlite3;print(_sqlite3.__file__)'
/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/lib-dynload/_sqlite3.cpython-39-darwin.so
$ otool -L $(/usr/local/bin/python3.9 -c 'import _sqlite3;print(_sqlite3.__file__)')
/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/lib-dynload/_sqlite3.cpython-39-darwin.so:
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.60.1)

- with a MacPorts python3.9.4:

$ /opt/macports/bin/python3.9 -c 'import _sqlite3;print(_sqlite3.__file__)'
/opt/macports/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/lib-dynload/_sqlite3.cpython-39-darwin.so
$ otool -L $(/opt/macports/bin/python3.9 -c 'import _sqlite3;print(_sqlite3.__file__)')
/opt/macports/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/lib-dynload/_sqlite3.cpython-39-darwin.so:
	/opt/macports/lib/libsqlite3.0.dylib (compatibility version 9.0.0, current version 9.6.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.60.1)

If you want to replace the sqlite3 library, you would need to rebuild the _sqlite3 module. That's not something we would encourage or support.

Hi Ned, 

Thank you for the reply. That explains a lot. I hadn't considered that SQLite would be statically linked. 

> I believe the original reason was to avoid linking with the Apple-supplied system copy of the sqlite3 library.

I can see that being a goal, yes. 

It's likely a niche use-case needing to adjust the SQLite version, so …

Thanks again!