While investigating another freeze-related issue, I found that Tools/freeze seems to not work when used with an installed shared unix build. The symptom is that the linkage step in the freeze-produced Makefile fails with:

gcc -pthread -Xlinker -export-dynamic config.o frozen.o M___future__.o [...] M_zipfile.o /py/3x/unix/root/lib/python3.4/config-3.4dm/libpython3.4dm.so -lpthread -ldl -lutil -lm -o hello
gcc: error: /py/3x/unix/root/f/../lib/python3.4/config-3.4dm/libpython3.4dm.so: No such file or directory
Makefile:505: recipe for target 'hello' failed
make: *** [hello] Error 1

The problem is that the freeze linkage step is looking for the python library with a shared library extension (in this case, '.so') in the config-3.xmm directory but the library is installed as a static archive ('.a') there:

./lib/python3.4/config-3.4dm/libpython3.4dm.a

I'm unfamiliar with freeze and its history but it looks like the problem was introduced by the changes for bpo-11824, in particular this:

• libs = [os.path.join(binlib, 'libpython$(VERSION).a')]
  + libs = [os.path.join(binlib, '$(LDLIBRARY)')]

The Python Makefile target "libainstall" installs the Python library in the config* dir:
@if test -d $(LIBRARY); then :; else \
if test "$(PYTHONFRAMEWORKDIR)" = no-framework; then \
if test "$(SHLIB_SUFFIX)" = .dll; then \
$(INSTALL_DATA) $(LDLIBRARY) $(DESTDIR)$(LIBPL) ; \
else \
$(INSTALL_DATA) $(LIBRARY) $(DESTDIR)$(LIBPL)/$(LIBRARY) ; \
$(RANLIB) $(DESTDIR)$(LIBPL)/$(LIBRARY) ; \
fi; \
else \
echo Skip install of $(LIBRARY) - use make frameworkinstall; \
fi; \
fi

So, if I understand the cases correctly, for non-".dll" cases, the library is installed in the config* directory as file name $LIBRARY. But the changed code in the freeze-generated Makefile looks for the library as $LDLIBRARY. For static Python builds, $LIBRARY and $LDLIBRARY are (always?) the same, but for shared builds, they are (usually) not, for example:

    LDLIBRARY = "libpython3.4dm.so"
    LIBRARY = "libpython3.4dm.a"

I'm not sure what the complete solution should be but clearly what is there now is not right for shared unix builds.