seen with at least 2.7, 3.2 and 3.3:

$ python-config --libs
-lpthread -ldl -lutil -lm -lpython2.7

$ pkg-config python --static --libs
-lpthread -ldl -lutil -lpython2.7

python-config uses the SYSLIBS macro, while pkg-config uses the LIBS macro.

depending on what you want to do, both can be wrong or right:

 - to build an extension, LIBS should be used.

 - to link an embedded interpreter, SYSLIBS should be used,
   which might not be complete.
   Howver in this case MODLIBS is missing.

a patch should be easy once we can define the intended behaviour.

Behavior of 'pkg-config python' is more useful since without --static option only the set of directly needed libraries is returned.

In Python 3.3 or 3.4 --static option could be introduced in python-config and behavior without this option could be changed to match 'pkg-config python'.

Well, they should not be identical, as they are for different use cases.

"pkg-config python" is to build an application containing a python interpreter (like python$EXE):
 + Link against libpython.so. Additionally,
 + re-export symbols from libpython.so for the python-modules (platform-specific).
 = This is similar to build against any other library, thus using 'pkg-config python'.

"python-config" is to build a python-module (like build/lib.<platform>-<pyver>/*.so):
 + No need to link against libpython.so, instead
 + expect symbols from libpython.so to be available at runtime, platform specific either
 + as a list of symbols to import from "the main executable" (AIX), or
 + as undefined symbols at build-time (Linux, others), or
 = This is specific to python-modules, thus using 'python-config'.

They are not for different cases. Difference between is a result of the fact that they were implemented independently at different times.

Linking of extension modules against libpythonX.Y.so is a good idea anyway. It avoids build failure with LDFLAGS="-Wl,--no-undefined".

they are.  assume you build the zlib and elementtree extensions as builtins, then libs for an interpreter includes libz and libexpat, while they are not needed for extensions.

So this diff - depending on issue#21660 - now drops showing any $LIBS from python-config, as python-modules usually do not link against any python-known libraries.

Instead, now there is a new configure variable LINKFORMODULE, which is shown by python-config --ldflags.

And $LINKFORSHARED is added to python.pc (for pkg-config).

Eventually, this allows to drop those Darwin hackery wrt. python-framework, as the python library isn't linked against the modules any more - but to PYTHONFRAMEWORK via LINKFORMODULE instead.

However, I don't have any Darwin around here: anyone?

For AIX, this looks good so far.

Thanks!

Michael Haubenwallner: Could you show output of 'python-config-3.5 --ldflags' and 'python-config-3.5 --libs' without and with this patch (on GNU/Linux and AIX)?

For AIX, with both these configure variants:
  $ configure --prefix=/prefix --enable-shared CC=gcc CXX=g++ OPT=
  $ configure --prefix=/prefix --enable-shared --without-computed-gotos CC=xlc_r CXX=xlC_r OPT=
the output changes like this:

   $ PKG_CONFIG_PATH=/prefix/lib/pkgconfig pkg-config --libs python-3.4
old: -L/prefix/lib -lpython3.4m
new: -L/prefix/lib -lpython3.4m -Wl,-bE:/prefix/lib/python3.4/config-3.4m/python.exp -lld

   $ /prefix/bin/python3.4-config --ldflags
old:  -L/prefix/lib -lintl -ldl -lm  -lpython3.4m -Wl,-bE:Modules/python.exp -lld
new: -Wl,-bI:/prefix/lib/python3.4/config-3.4m/python.exp



For Linux, with this configure variant:
  $ configure --prefix=/prefix --enable-shared CC=gcc CXX=g++
the output changes like this:

  $ PKG_CONFIG_PATH=/prefix/lib/pkgconfig pkg-config --libs python-3.4
old: -L/prefix/lib -lpython3.4m
new: -L/prefix/lib -lpython3.4m -Xlinker -export-dynamic

   $ /prefix/bin/python3.4-config --ldflags
old:   -L/prefix/lib -lpthread -ldl  -lutil -lm  -lpython3.4m -Xlinker -export-dynamic
new: # Yes, nothing. Not sure if python modules should have undefined python symbols, or link against libpython.so

Just found out that distutils.command.build_ext.get_libraries() does add libpython.so for Linux and similar (not Darwin and AIX).
Actually, distutils.command.build_ext.get_libraries() should add $LINKFORMODULE instead now, so LDSHARED does not need to carry.

More thoughts?  (will post results with --disable-shared as separate comment)

Now for --disable-shared:

For AIX, with both these configure variants:
  $ configure --prefix=/prefix --disable-shared CC=gcc CXX=g++ OPT=
  $ configure --prefix=/prefix --disable-shared --without-computed-gotos CC=xlc_r CXX=xlC_r OPT=
the output changes like this:

   $ PKG_CONFIG_PATH=/prefix/lib/pkgconfig pkg-config --libs python-3.4
old: -L/prefix/lib -lpython3.4m
new: -L/prefix/lib -lpython3.4m -Wl,-bE:/prefix/lib/python3.4/config-3.4m/python.exp -lld

   $ /prefix/bin/python3.4-config --ldflags
old: -L/prefix/lib/python3.4/config-3.4m -L/prefix/lib -lintl -ldl -lm  -lpython3.4m -Wl,-bE:Modules/python.exp -lld
new: -Wl,-bI:/prefix/lib/python3.4/config-3.4m/python.exp



For Linux, with this configure variant:
  $ configure --prefix=/prefix --enable-shared CC=gcc CXX=g++
the output changes like this:

  $ PKG_CONFIG_PATH=/prefix/lib/pkgconfig pkg-config --libs python-3.4
old: -L/prefix/lib -lpython3.4m
new: -L/prefix/lib -lpython3.4m -Xlinker -export-dynamic

   $ /prefix/bin/python3.4-config --ldflags
old: -L/prefix/lib/python3.4/config-3.4m -L/prefix/lib -lpthread -ldl  -lutil -lm  -lpython3.4m -Xlinker -export-dynamic
new: # Yes, nothing. 

And with --disable-shared, even distutils.command.build_ext.get_libraries() does *not* add libpython.so for Linux and similar, so python-shipped modules are linked with python symbols undefined now - but still as shared libraries.

Erm, the latter should read:
  For Linux, with this configure variant:
    $ configure --prefix=/prefix --disable-shared CC=gcc CXX=g++


Now reading GNU ld manpage for Linux:

>   $ PKG_CONFIG_PATH=/prefix/lib/pkgconfig pkg-config --libs python-3.4
> new: -L/prefix/lib -lpython3.4m -Xlinker -export-dynamic

ld(1), at '--export-dynamic', tells about '--dynamic-list=file' to export specific symbols only - which actually looks similar to '-bE:file' for AIX...

On Darwin, it would be nice if LINKFORMODULE used "-undefined dynamic_lookup" instead of explicitly linking to a framework binary. Modules with explicit links to a framework cause segfaults when they are imported from a different, but compatible, framework interpreter -- i.e., building against the system Python 2.7 but importing from a user-installed Python 2.7 causes an immediate crash.

I'm a maintainer of Homebrew, a package manager for OS X, and I spend a lot of time tracking down and eliminating errant explicit framework links because they make packaging binaries much harder for us and cause crashes for users.