Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
--with-ssl=/nonexistent/path ignores specified path and builds against another SSL implementation #2580
I did this
Attempted to build libcurl against libressl by specifying a path thusly:
However, I neglected to build libressl prior to doing this hence /path/to/libressl didn't exist.
I expected the following
An error telling me I gave a nonexistent path to --with-ssl.
Ideally if the directory exists but doesn't contain openssl headers/libraries this should also be an error but maybe this is asking too much.
libcurl built itself against system openssl which is an entirely different ssl implementation without any errors.
There are two mentions of
configure: PKG_CONFIG_LIBDIR will be set to "/path/to/libressl/lib/pkgconfig" configure: Added /path/to/libressl/lib to CURL_LIBRARY_PATH
So, my specified path is simply added (prepended I imagine) to search directories.
7.60.0 from source/release tarball
Ubuntu Trusty VM
This issue may well affect other --with-* options, I added a generic guard for directory existence to my build process now.
I'm pretty sure this happens because the test for the ssl library still works because it finds a system one installed and uses that (in one of the default paths). So while a check for the dir existing would catch your specific case if you truly point to a missing directory, it would still work like this if you point to an empty directory...
I can't think of any easy ways to detect this. The linker has a default path that might make it find another library if the given path isn't working. To detect that, we have to add some custom logic that verifies the given path to make sure it actually contains a (working) openssl installation and that does feel very error-prone.
Or do you have any ideas on how this process could be improved?
Well, do we need to know it is a working installation in the specified directory? Wouldn't it be enough that we find at least the "entry header file" in the directory? If the user points to a broken installation, that'll likely become obvious at a later stage when it doesn't compile or otherwise breaks.
Other than that, I can only think of of documenting the possible pitfall.
When given a prefix, the $PREFIX_OPENSSL/lib/openssl.pc or $PREFIX_OPENSSL/include/openssl/ssl.h files must be present or cause an error. Helps users detect when giving configure the wrong path. Reported-by: Oleg Pudeyev Assisted-by: Per Malmberg Fixes #2580