[MDEV-4893] MariaDB10 "-DWITH-SSL=/path/to/external/install" not sufficient; fails to link against external libs Created: 2013-08-13 Updated: 2013-08-14 Resolved: 2013-08-14 |
|
| Status: | Closed |
| Project: | MariaDB Server |
| Component/s: | None |
| Affects Version/s: | 10.0.4 |
| Fix Version/s: | 10.0.5 |
| Type: | Bug | Priority: | Minor |
| Reporter: | pgnd | Assignee: | Vladislav Vaintroub |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Environment: |
uname -a |
||
| Description |
|
I'm building MariaDB 10, r3781, on
I've built/installed OpenSSL into an external path
Checking MariaDB/cmake ssl-related vars prior to build
talking with serg @irc, spec'ing
should be sufficient for a link of external SSL libs. However, with just
That's NOT the case – MariaDB bins are STILL un-linked against external SSL libx, using default system-installed SSL instead,
OTOH, adding ADDITIONAL flags,
builds/links as intended against external SSL
For a 'simple' external SSL install, in a single DIR (e.g., /usr/local/ssl), a
config spec should be sufficient, with rpath'ing properly configured. For more complex installs, e.g., in /usr/local, the additional flags should be available, and consistently named. |
| Comments |
| Comment by Sergei Golubchik [ 2013-08-14 ] |
|
I'm not quite sure how to fix this. Simple -DWITH_SSL=/path doesn't reconfigure the existing build because it uses cached values for OPENSSL_INCLUDE_DIR, etc. If I manually remove all SSL-related variables from the CMakeCache.txt then -DWITH_SSL=/path works. But if ssl.cmake will unset them, then user-specified values (from the command line) for OPENSSL_INCLUDE_DIR won't work. |
| Comment by Vladislav Vaintroub [ 2013-08-14 ] |
|
It is the case, when change of one cached cmake variable (WITH_SSL) should results in changes to many cached variables (OPENSSL_XXX) |
| Comment by Vladislav Vaintroub [ 2013-08-14 ] |
|
Closing as "won't fix", since I do nto have a good idea on how to fix, and issue is minor |
| Comment by pgnd [ 2013-08-14 ] |
|
??? That's one way to reduce the bug queue, I suppose. |
| Comment by Vladislav Vaintroub [ 2013-08-14 ] |
|
I tried to explain why I think it is good way to close the bug. I do not mind a discussion, but you should have a better argument than ??? |