GNU bug report logs -
#61055
file-needed/recurive does not canonicalize paths
Previous Next
Full log
Message #8 received at 61055 <at> debbugs.gnu.org (full text, mbox):
Hi Lars,
Lars-Dominik Braun <lars <at> 6xq.net> skribis:
> during testing of wip-haskell I observed the make-dynamic-linker-cache
> phase is taking alot of time (up to two minutes on a fast machine with
> SSD). Looking at ghc-hindent for example [1]:
>
> starting phase `make-dynamic-linker-cache'
> created '/gnu/store/2nrzbaxmqs2rq9yv52bpyn2azb3qj6h1-ghc-hindent-5.3.4/etc/ld.so.cache' from 10085 library search path entries
> phase `make-dynamic-linker-cache' succeeded after 119.5 seconds
>
> And while Haskell packages link to a pretty large number of dynamic
> libraries (116 in this case), 10000 search path entries seems wrong. Running just
>
> (file-needed/recursive "/gnu/store/2nrzbaxmqs2rq9yv52bpyn2azb3qj6h1-ghc-hindent-5.3.4/bin/hindent")
>
> takes a long time and reveals entries like
> /gnu/store/1cyk8j2nd6r0cvm6kx1408kd763yf8h5-ghc-9.2.5/lib/ghc-9.2.5/Cabal-3.6.3.0/../directory-1.3.6.2/../unix-2.7.2.2/../bytestring-0.11.3.1/../template-haskell-2.18.0.0/../pretty-1.1.3.6/../array-0.5.4.0/../base-4.16.4.0/../ghc-bignum-1.2/../ghc-prim-0.8.0/libHSghc-prim-0.8.0-ghc9.2.5.so
> so it looks like it deduplicates values, but does not canonicalize
> paths. A relatively straight-forward fix could be the following change,
> but I don’t know if that would cause any issues, since canonicalize-path
> throws an exception if the resulting path does not exist. It’s also
> a world rebuild since pretty much any package uses this phase (and the
> reason and I cannot test it on a larger scale).
Right. Other arguments against systematic canonicalization: (1)
‘canonicalize-path’ is costly, (2) developers and tools might choose to
write ‘x/y/../z’ for a good reason and changing that could break their
expectations.
Can you see how we end up with those entries? These at DT_NEEDED
entries, not DT_RUNPATH, right?
If so, that probably means that ghc at some points invokes the linker
along the lines of:
ld -o hindent ../foo/../bar/../baz/libbaz.so
Could you check in build logs exactly how that executable gets linked?
Is there a way we could canonicalize there, or, better, get the build
system to do something like:
ld -o hindent -L ../foo/../bar/../baz -lbaz
? That way DT_NEEDED would be just “libbaz.so” instead of the complete
file name. DT_RUNPATH would contain the weird file name, but that’s
probably okay.
HTH,
Ludo’.
This bug report was last modified 2 years and 134 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.