Example on Fedora 30:

$ python3.8-config --ldflags
 -L/usr/lib64  -lcrypt -lpthread -ldl  -lutil -lm -lm 

This command output must not generate "-L/usr/lib64".

This bug report is based on this Fedora bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=1724190#c3


== Using "-L /usr/lib64" is wrong ==

If for example you are building something against a non-system version of a library, while you have a system version of that library installed. You would then have -L/<path to non-system version> in your LDFLAGS. If some configure script then adds -L/usr/lib64 to your LDFLAGS from python-config you might link to the system version instead, depending on in which order the Makefiles puts the options together.

If your are building a new version of a software of which you already have an older version installed. If the software provides both libraries and executables, the executables should be linked to the new version of the library you just built and not the system version in /usr/lib64. Depending on how the Makefiles are written you might get the wrong version if -L/usr/lib64 is added to LDFLAGS.


== pkg-config default is correct ==

pkg-config --libs does not generate any -L flags if the .pc file contains "libdir=/usr/lib64", "Libs: -L${libdir}". Example on Fedora 30:

$ pkg-config python-3.8 --libs # empty output

$ pkg-config python-3.8-embed --libs
-lpython3.8 

pkg-config has a --keep-system-libs flag which includes -L/usr/lib64 as expected:

$ pkg-config python-3.8-embed --libs --keep-system-libs
-L/usr/lib64 -lpython3.8


If PKG_CONFIG_SYSTEM_LIBRARY_PATH env var is set to a directory different than /usr/lib64, -L/usr/lib64 is generated:

$ PKG_CONFIG_SYSTEM_LIBRARY_PATH=/xxx pkg-config python-3.8-embed --libs  
-L/usr/lib64 -lpython3.8 


== pkg-config internals ==

Look at pkgconfig internals, so we can mimick the behavior.

On my Fedora 30, /usr/lib64/pkgconfig/python3.pc contains "Libs: -L${libdir} -lpython3.7m" with "libdir=/usr/lib64", but "pkg-config python3 --libs" only returns "-lpython3.7m": no -L flag.

pkg-config:

* https://github.com/pkgconf/pkgconf/tree/master/libpkgconf
* https://src.fedoraproject.org/rpms/pkgconf/blob/master/f/pkgconf.spec

pkg-config uses PKG_CONFIG_SYSTEM_LIBRARY_PATH environment variable if set, otherwise it uses &personality->filter_libdirs. "SystemLibraryPaths" value (&personality->filter_libdirs) can be read using the command:
---
$ pkg-config --dump-personality
Triplet: default
DefaultSearchPaths: /usr/lib64/pkgconfig /usr/share/pkgconfig
SystemIncludePaths: /usr/include
SystemLibraryPaths: /usr/lib64
---

The default personality uses SYSTEM_LIBDIR, macro defines by CMakeLists.txt, extract:
---
SET(libdir ${prefix}/lib)
SET(system_libdir "${libdir}" CACHE STRING "specify the system library directory (default LIBDIR)")
SET(SYSTEM_LIBDIR "${system_libdir}")
ADD_DEFINITIONS(-DSYSTEM_LIBDIR=\"${system_libdir}\")
---

Fedora pkgconf specfile overrides the system libdir:
---	
%configure --disable-static \
           --with-pkg-config-dir=%{pkgconf_libdirs} \
           --with-system-includedir=%{_includedir} \
           --with-system-libdir=%{_libdir}
---
https://src.fedoraproject.org/rpms/pkgconf/blob/master/f/pkgconf.spec#_110


== How to fix python3.8-config? ==

The logic to detect the "system library path(s)" looks highly platform dependent. Maybe Python configure script should get an optional --with-system-libdir=PATH which would strip -L option in python-config if it's value is equal to PATH.

pkg-config also supports PKG_CONFIG_SYSTEM_LIBRARY_PATH env var and --keep-system-libs command line option.


== Options ==

* Deprecate python3.8-config: promote pkg-config. Is pkg-config available on all platforms? (Linux, macOS, FreeBSD, AIX, etc.) => easy option, least work to do!

* Document python3.8-config current behavior (document that -L/usr/lib64), modify python3.8-config & update the doc. Need to decide which features do we want (env var and/or cmdline option?).