There is an inconsistency between python-config.py and python-config.sh with the output of --ldflags.  The .sh version include -L$libdir but the .py version does not include the -L flag unless a non-shared version of Python is built.

As a result, on Darwin (macOS), where python-config.py is used it is not possible to use python-config to get the correct linker flags when "python-config --embed --ldflags" is run if Python is installed in a directory with a lib dir that is not in the compiler's default search path.

For example, if Python is installed in /usr/local/python, we see the following on Linux (using python-config.sh):

$ python3-config --ldflags --embed
 -L/usr/local/python/lib -lpython3.10 -lcrypt -lpthread -ldl  -lutil -lm -lm

But on macOS, using python-config.py:

$ python3-config --ldflags --embed
-lpython3.10 -lintl -ldl -framework CoreFoundation

There is no -L flag to tell the compiler where to find the python3.10 library, so an attempt to link with it will fail.

Agree that this should be fixed. If you want, I can send a PR.

> If you want, I can send a PR.

Thanks, that would be good. Embedding is something we currently don't really test, unfortunately. Off the top of my head, I'm not sure how feasible it would be to add some tests for embedding, especially given the range of configurations we support but something would be better than nothing.

Maybe unit tests can be written on python-config.sh and python-config.py commands.