Hi Ludo, > Can you see how we end up with those entries? These at DT_NEEDED > entries, not DT_RUNPATH, right? they definitely do not come from the hindent binary. `readelf -d` looks like this
---snip--- 0x0000000000000001 (NEEDED) Shared library: [libHSpath-io-1.7.0-Y7nuUr9RcCC0rgElOk2Zd-ghc9.2.5.so] 0x0000000000000001 (NEEDED) Shared library: [libHSunix-compat-0.5.4-2Fa5hW7FPv81iCQxP5gtt5-ghc9.2.5.so] 0x0000000000000001 (NEEDED) Shared library: [libHStemporary-1.3-K9lHfUrZ43CE7BhnE8cSVB-ghc9.2.5.so] … 0x000000000000001d (RUNPATH) Library runpath: [/gnu/store/2nrzbaxmqs2rq9yv52bpyn2azb3qj6h1-ghc-hindent-5.3.4/lib/x86_64-linux-ghc-9.2.5:/gnu/store/1cyk8j2nd6r0cvm6kx1408kd763yf8h5-ghc-9.2.5/lib/ghc-9.2.5/Cabal-3.6.3.0:/gnu/store/lk1mgbds7rf9ilv425msz840ky8cfn79-ghc-diff-0.4.1/lib/x86_64-linux-ghc-9.2.5:/gnu/store/866s8qcghallds7azzcx075a06mr64h4-ghc-hunit-1.6.2.0/lib/x86_64-linux-ghc-9.2.5:/gnu/store/rgm9h2a4v1zgwm1mbfb36ycjbkywlxj6-ghc-onetuple-0.3.1/lib/x86_64-linux-ghc-9.2.5:… ---snap--- and I believe GHC adds `-L/gnu/store/…` and `-lHSXXX` to the linker invokation only, which should be correct. However GHC’s bundled libraries are linked differently and result in a `readelf -d /gnu/store/1cyk8j2nd6r0cvm6kx1408kd763yf8h5-ghc-9.2.5/lib/ghc-9.2.5/Cabal-3.6.3.0/libHSCabal-3.6.3.0-ghc9.2.5.so` like this: ---snip--- 0x0000000000000001 (NEEDED) Shared library: [libHSprocess-1.6.16.0-ghc9.2.5.so] 0x0000000000000001 (NEEDED) Shared library: [libHSparsec-3.1.15.0-ghc9.2.5.so] 0x0000000000000001 (NEEDED) Shared library: [libHStext-1.2.5.0-ghc9.2.5.so] … 0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../process-1.6.16.0:$ORIGIN/../parsec-3.1.15.0:$ORIGIN/../text-1.2.5.0:$ORIGIN/../mtl-2.2.2:$ORIGIN/../transformers-0.5.6.2:$ORIGIN/../directory-1.3.6.2:$ORIGIN/../unix-2.7.2.2:$ORIGIN/../time-1.11.1.1:$ORIGIN/../filepath-1.4.2.2:$ORIGIN/../binary-0.8.9.0:$ORIGIN/../containers-0.6.5.1:$ORIGIN/../bytestring-0.11.3.1:$ORIGIN/../template-haskell-2.18.0.0:$ORIGIN/../pretty-1.1.3.6:$ORIGIN/../ghc-boot-th-9.2.5:$ORIGIN/../deepseq-1.4.6.1:$ORIGIN/../array-0.5.4.0:$ORIGIN/../base-4.16.4.0:$ORIGIN/../ghc-bignum-1.2:$ORIGIN/../ghc-prim-0.8.0:$ORIGIN/../rts:/gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/lib:/gnu/store/094bbaq6glba86h1d4cj16xhdi6fk2jl-gcc-10.3.0-lib/lib:/gnu/store/fwbiihd2sbhai63y1pvvdh0f2bakfzrf-gmp-6.2.1/lib:/gnu/store/094bbaq6glba86h1d4cj16xhdi6fk2jl-gcc-10.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/10.3.0/../../..] ---snap--- These obviously will get expanded to /gnu/store/1cyk8j2nd6r0cvm6kx1408kd763yf8h5-ghc-9.2.5/lib/ghc-9.2.5/Cabal-3.6.3.0/../process-1.6.16.0 And there’s about 40 of these bundled libraries referencing each other, which is why the problem is amplified. I still believe this is a bug in file-needed/recursive, because it recurses, but does not correctly keep track of “visited” shared libraries (by not canonicalizing paths). Its documentation also says that it returns a “list of absolute .so file names” – which I would expect not to have relative path elements in. The output of `ldd` does so too. So yes, canonicalize-path may be expensive, but evaluating 10000 shared libraries is too. Cheers, Lars PS: This is not a problem for wip-haskell any more, since I switched to static linking, but it’s going to bite someone else.