Justus Winter <4win...@informatik.uni-hamburg.de> writes: > But why do we do that? I always thought that rpath causes more > problems and is to be avoided if possible [0]. But otoh, I didn't even > knew that the notmuch build system uses rpath. > > 0: e.g. http://wiki.debian.org/RpathIssue
RPATH is bad for distributions, but great for private installs. > I actually have no strong feelings for or against this proposal. I'm > merely surprised that there is an issue that you are trying to fix > here since exactly this configuration has worked for me since the day > I started using notmuch. Sure, but you always set LD_LIBRARY_PATH instead of relying on RPATH. > And from my point of view LD_LIBRARY_PATH is the correct way to > instruct the dynamic linker (and as a similar facility the ctypes > library loader) where to look for additional libraries. LD_LIBRARY_PATH is inconvenient as hell if you have multiple installs living in different places, i.e., you write /path/to/A/bin/notmuch and have it use /path/to/B/lib/libnotmuch.so.3 just because you placed /path/to/B/lib in your LD_LIBRARY_PATH at some point in the distant past when it was needed by /path/to/B/bin/other-thing that may not even be installed any more. This happens a lot more with languages other than C and when you have different compilers with mutually-incompatible ABIs or packages that didn't bother with soname versioning. _______________________________________________ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch