 |
 |
@matthewfeickert, several things which I have already noted in detail above, so I'll briefly reiterate it here:
my system's default setting was already set for openssl3 as I noted above and for the version of xrootd that root was downloading, it failed to compile for openssl3. Once I picked up the xrootd master version, it then builds fine. But as of now if someone were to build root from source (having openssl3 as their default openssl version), the version of xrootd that root downloads won't build for openssl3. All details of that has already be shown above.
And because at that time I couldn't get it to build for openssl3, I attempted to build it against an older version of openssl (which I also had on my system but just not set as the default, that is it's place in some other non-system directory). As I noted above, because I didn't want it to pick up the default openssl (since it wouldn't compile), I did use OPENSSL_SSL_LIBRARY, OPENSSL_CRYPTO_LIBRARY, and OPENSSL_INCLUDE_DIR to point to the older version (while keeping the default openssl version in my system to be openssl3 since other tools were dependent on that). And still, it failed to build because the ordering of the includes statement fed to the compiler is not correct (and instead picks up the headers from openssl3 instead of the older openssl version despite providing it the openssl options to cmake). When using those openssl cmake options, you shouldn't have, in addition to, defined any cxxflags or ldflags (if you have to, that's not a solution, that's a hack). The specified directory of the openssl include is in fact passed to the compiler using those cmake options you noted, the problem is the list of includes that is passed to the compiler, is in the wrong order. Quick look at xrootd, it doesn't seem to use cmake's find_package to set openssl include/directory and seems to have it's own cmake script of finding openssl. I believe that the way find_package works, if you provided it with the various openssl options (note the 3 options you provided above isn't generally the only set of options of specifying a specific version of openssl, but being that find_package isn't use here, it limits one to those 3 parameters), find_package would have been aware that as part of the cmake options, a specific version of openssl was indicated (e.g. likely a version that wasn't the default version found in nominal system directories) and therefore would likely have placed the directory specified by OPENSSL_INCLUDE_DIR first in its list of includes, before any other system include directories, which would have avoid that compilation error that I got when specifying the openssl paths that wasn't the default one. I'd recommend to use find_package or for newer cmake versions FindOpenSSL (it basically uses find_package underneath it) to set openssl include/libs location because it will likely order those includes correctly.
xrootd should be setup to build with a versions of openssl, that's not necessarily the default version (e.g. not in the nominal system directories), after all that's why cmake provided the various openssl options.
In any case, the solution at least for me is to wait for a newer version of root that will download the latest version of xrootd so it will compile against openssl3.
PS, I didn't use brew (to install root). I was building root from source since I needed it to be built with C++17 on. Also I use macport; not brew to setup other stuff.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Use REPLY-ALL to reply to list
To unsubscribe from the XROOTD-DEV list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1