The build_ext command does accept a handy --rpath option to encode an RPATH in the built extension modules. However RPATH is superseded by RUNPATH since the former can not be overwritten by the LD_LIBRARY_PATH environment varialbe, while the later can. While most linkers will add a RUNPATH automatically when you ask for an RPATH, GNU ld does not do this. Therefore this patch does detect if GNU ld is used and if so will use the --enable-new-dtags option which will add the RUNPATH.
I'm not convinced that would help much. The GNULD variable in the makefile is for when the default linker is used. If you change that by using LDSHARED then you're probably not going to be using --rpath but LDFLAGS to configure it the way you want. If anything maybe using configure/Makefile to detect if GNU ld is used is wrong just for the case they use LDSHARED (I didn't think of this before), since then they can use LDSHARED and --rpath and get misterious failures. But it seems a lot more complicated to do, LDSHARED can be set to something like "cc -shared" (the default) in which case we can't use -V and assume it's a non-GNU ld if we don't get "GNU" back. So we'd have to try and detect if LDSHARED is set to a compiler or a linker, then try to find which linker gets invoked etc. A lot more complicated and way more possibilities then I can test. I'd argue that when someone uses LDSHARED they should be using LDFLAGS intead of --rpath, they obviously know what they are doing. --rpath is there if you want to use the environment Python was compiled in to build an extension module with a RPATH/RUNPATH in.
