Should LD_FLAGS be the same across all linuxen?

[timsnyder]

ctng-compiler-activation-feedstock/recipe/conda_build_config.yaml

Lines 87 to 96 in 93ab56f

	FINAL_LDFLAGS_linux_64:
	- -Wl,-O2 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now -Wl,--disable-new-dtags -Wl,--gc-sections -Wl,--allow-shlib-undefined
	FINAL_LDFLAGS_linux_32:
	- -Wl,-O2 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now -Wl,--disable-new-dtags -Wl,--gc-sections -Wl,--allow-shlib-undefined
	FINAL_LDFLAGS_linux_ppc64le:
	- -Wl,-O2 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now -Wl,--allow-shlib-undefined
	FINAL_LDFLAGS_linux_aarch64:
	- -Wl,-O2 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now -Wl,--allow-shlib-undefined
	FINAL_LDFLAGS_linux_s390x:
	- -Wl,-O2 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now -Wl,--allow-shlib-undefined

linux-ppc64le, linux-aarch64 and linux-s390x don't use -disable_new_dtags but linux-32 and linux-64 do. It has been my impression since the beginning of conda that we rely on the semantics of DT_RPATH as opposed to DT_RUNPATH, specifically that DT_RPATH applies to direct and transitive dynamic link resolution whereas DT_RUNPATH must be specified at each level of dynamic library. The other less-important (i.e. non-breaking) difference between DT_RPATH and DT_RUNPATH is that LD_LIBRARY_PATH is searched after DT_RPATH and before DT_RUNPATH (i.e. DT_RUNPATH can be overridden by LD_LIBRARY_PATH)

Perhaps someone made the conscious decision to use RUNPATH on the newer architectures because they didn't have packages that were already built using RPATH but I have been unable to locate where -disable_new_dtags was added into the recipe. I know -disable_new_dtags wasn't used in https://github.com/conda-archive/conda-recipes/tree/master/cross-compilers but it is used in the first commit in the current repository history.

It might be for the best that the newer architectures are using DT_RUNPATH because DT_RPATH has been 'deprecated' [1] or 'moved to level 2 of the [GNU v4+] ABI' [2] depending on where you look:
[1] https://man7.org/linux/man-pages/man8/ld.so.8.html search for 'DT_RPATH is deprecated'
[2] https://refspecs.linuxbase.org/elf/gabi4+/ch5.dynamic.html#shobj_dependencies 'DT_RPATH, has been moved to level 2 in the ABI'

Because the linker will use RUNPATH and ignore RPATH if they both exist, any migration of x86 packages to using RUNPATH would need to be done in dependence order. I suppose that is what migrations do though, isn't it?

I'm not convinced that there is a problem here and if there is, what the solution should be. I mainly wanted to document what I relearned about DT_RPATH and DT_RUNPATH when I noticed that we aren't being consistent across architectures.

[timsnyder]

Finally, -Wl,--gc-sections is safe to add to the other architectures because the linker will ignore it if the architecture does not support the feature.

[jakirkham]

Can't speak to any difference between builds. However going with DT_RPATH has led to fewer issues. Inevitably users set LD_LIBRARY_PATH (sometimes even in as part of shell initialization). The result was lots of issues raised with feedstocks, which could be answered by don't do that after figuring out exactly what users were doing. So using DT_RPATH has helped avoid these kinds of issues as user configuration was less likely to break an otherwise working Conda environment