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 Issue11824, 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.