GNU bug report logs - #22138
Search paths of dependencies are not honored

Previous Next

Full log

View this message in rfc822 format

From: Maxime Devos <maximedevos <at> telenet.be>
To: 22138 <at> debbugs.gnu.org
Subject: bug#22138: Search paths of dependencies are not honored
Date: Sat, 22 Jan 2022 22:27:15 +0100

[Message part 1 (text/plain, inline)]

Hi,

On second thought, honouring search paths of dependencies
(filtered by looking at the references?) would solve much more problems
than it could create -- a theoretical ‘problem’ is that more
environment variables than strictly needed might be defined (see e.g.
the wrap-program example) but it doesn't seem that it would create
problems in practice.

There's a limitation to keep in mind though: static libraries.

Suppose we have a static library variant curl/static tht links against
openssl:static.  Then due to the static linking, curl won't keep a
reference to openssl:static (*), so there won't be a SSL_CERT_DIR/FILE
search path.

(*) Actually, that might wrong, libcrypto.a keeps a reference to 
/gnu/store/plr00nij45964cyy7sfcg5rcsi8hks0h-openssl-1.1.1l.

For some examples in the wild where this kind of propagation(*) of
search paths is useful: all packages using ncurses (TERMINFO_DIRS),
openssl (SSL_CERT_DIR/SSL_CERT_FILE), all packages using glibc
(GUIX_LOCPATH) -- basically all software(!).

(*) it's not propagated-inputs but the concept doesn't seem completely
unlike.

As such, I agree with the concept (notwithstanding  the previous mail I
sent), with the caveat that I haven't investigated the implementation
or tested it.

Greetings,
Maxime

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.