homepage

Installing Python with prefix that equals "/" seems to not install the dymic libraries like _collections. The steps I performed to install it:
./configure --prefix=/ \
 --with-threads \
 --enable-shared \
 --enable-ipv6 \
 --with-system-ffi \
 --with-system-expat
make
make install
I saw that during the installation that the sharedinstall rule from Makefile.pre (originally defined in Makefile.pre.in) fails to remove $(DESTDIR)$(DESTSHARED)/_sysconfigdata.py* so I manually created the leading directory and touched the file it was looking for (I could've modified Makefile.pre too) and it actually worked - lib-dynload was created and the .so files where installed in it.
I have tried using empty string as prefix but that causes runtime issues since - Python is not able to find the site-packages directory.
Cheers!

Without more information it is hard to provide a meaningful response. You don't say which version of Python nor which platform you are trying to install on. Be aware that the default for --prefix is '/usr/local'. On most POSIX platforms, you should not be trying to use --prefix='/'; I believe that would attempt to install into the /bin, /lib, /include, et al which is very likely *not* what you want to do and could be harmful to your system. If you are trying to install into the standard system locations (usually also not a good idea if it conflicts with the platform's own packages), you would use --prefix='/usr'.

Right, I'm building it on custom Linux distribution on which software is installed on / instead of /usr on purpose. And the Python version is 2.7.9.

Sorry, I tried using your ./configure with a 2.7.9 tarball on a Debian VM from which I removed the system Python 2.7 and, despite installing into the non-standard locations, at a quick look everything seemed to work OK. For example,
>>> import _collections
>>> _collections.__file__
'/lib/python2.7/lib-dynload/_collections.so'
If you are building with --enable-shared, make sure the build isn't being influenced by a previously installed system or local Python 2.7.

I don't know how --enable-shared can have effect on this but I do not know much about the build system either (I just quick scoped trough it) so I tried that - it doesn't change anything. Also, I have only one version of Python installed and that is 2.7.9.
I have tried bind mounting / to /usr in case of some hardcoded path check (I deal with that a lot) but that does not help either. I guess I'll have to poke deeper and figure it out on my own. I'll let you know if I find the source of that issue.
Cheers!

--enable-shared builds in some cases can erroneously link with an already installed Python library of the same version. That's what happened on my first try, before removing the system 2.7. In any case, I'm closing this issue for now. Feel free to reopen if you can identify a reproducible problem on a supported configuration. Good luck!

I found the source of the problem, it's in distutils. at line 148 in Lib/distutils/util.py (in the tarball) the path join does not handle the full path properly (os.path.join returns the second path if it is full path), as a workaround I used "return new_root + pathname[1:]" and it worked as expected.
Do note that I've forgot to mention in my initial comment/message on this issue does not mention that I'm trying to install it ala DESTDIR. Trying to install Python as regular user failed because it was trying to place files on / instead of the sepcified DESTDIR.
Will you do something about this?

So the real problem here is configuring with --prefix=/ and then using make install DESTDIR to install to a temporary location. This is a duplicate of Issue9674; the problem is that --prefix=/ results in build variable the start with '//', like '//lib', and that confuses os.path.join as used in Distutils. You might want to try the patch available there and comment on that issue.