search

cisco / libsrtp

Library for SRTP (Secure Realtime Transport Protocol)
Other
1.21k stars 474 forks source link

Do not use pkg-config for NSS when a custom NSS directory is specified #487

Closed itollefsen closed 3 years ago

itollefsen commented 4 years ago

When installing NSS (using make install), it's possible to specify a DESTDIR which will install it to that location instead of the location specified with --prefix during configuration.

However, package config files are generated based on the --prefix location, so even if installed to somewhere else, the package config file will still point to the final destination provided during configuration.

This configure script would call pkg-config, if available, also when --with-nss-dir was used. This is primarily because the --with-nss-dir handling is a copy-and-paste of the --with-openssl-dir handling, which also used to do this. That was changed in PR #481. This builds off that and essentially does the same thing for the --with-nss-dir flags.

If DESTDIR was used to install NSS, pkg-config would add flags pointing to the --prefix location used when building NSS, not the provided --with-nss-dir.

This could end up picking up a system library instead, or, if there happened to be a NSS library already at the given --prefix, that would be used.

Both of those scenarios are probably not what you'd expect to happen.

To fix this, this removes the use of pkg-config when --with-nss-dir is specified.

To further make sure that --with-nss-dir functions as the override it was meant to be, the check for a lib directory under the specified location is changed to a more comprehensive check for the library itself.

It uses the find utility to look for *nss3.*, which should find it for most naming schemes (it will find libnss3.a, libnns3.so, nss3.dll, etc.).

The find syntax used should be POSIX compliant. It has been tested with GNU, BSD and Solaris versions of find.

Note that this could break existing build configurations that uses --with-nss-dir to point to non-system package install location.

For instance, MacPorts installs NSS and NSPR to /opt/local, but in sub directories. So include files go in /opt/local/include/[nss|nspr] and libraries go in /opt/local/lib/[nss|nspr].

If you tried to use --with-nss-dir=/opt/local, this would fail to find a NSS library in /opt/local/lib, whereas the old method would find the nss.pc file in /opt/local/lib/pkgconfig and pick up the correct flags from running pkg-config.

If you're in this situation, with this change, you would have to set PKG_CONFIG_PATH before running configure instead of --with-nss-dir.

nils-ohlmeier commented 4 years ago

Thank you for identifying and fixing this @itollefsen

In my history with configure doing things bare bone with find instead of pkg-config has proven to be brittle. Now you have identified here cases where it appears to be the other way around.

Would there be a way to first try pkg-config and if the values from it appear to be unusable, then fall back to your approach with find @itollefsen ?

nils-ohlmeier commented 4 years ago

@itollefsen I assume this supersedes #481 ?

itollefsen commented 4 years ago

Would there be a way to first try pkg-config and if the values from it appear to be unusable, then fall back to your approach with find @itollefsen ?

No. And the reason for that is exactly that the pkg-config (which points to the actual install location) may indeed find a valid installation there. And that's not the one you want to use.

I assume this supersedes #481 ?

Yes. This didn't come out quite right. I did the OpenSSL change first and then this NSS change afterwards in a branch based on the OpenSSL changes. If accepted, then this is the only one of the two that needs merging.

itollefsen commented 4 years ago

Also, I'm contemplating going one step further after this change. We can't account for all sorts of differences and installations.

If you have a pkg-config you'd like to use, you should set PKG_CONFIG_PATH to point to it before running configure.

If you absolutely want to use a specific installation for which there is no (functional) pkg-config, then I think it makes more sense to split these --with-<foo>-dir into two: --with-<foo>-include-dir and --with-<foo>-lib-dir.

That should solve issues that crop up when libraries and headers are in non-standard locations, and it should solve issues related to different multi-lib strategies.

That's a further refinement though, and only indirectly related to the pkg-config that this tries to solve.

itollefsen commented 3 years ago

I have another take on this laying around. Closing this and will post another one later.