Yes, you are correct that xalan 1.11.0 did not build a pkg-config, but xalan 1.12.0 does. I can see why the --with-xalan option would still be useful so that the earlier version can be used.
When we built Santuario v1.7.3, we never had to update LD_LIBRARY_PATH to make the build work. We would only do that in our run-time environment when running our software executables. If the configure script is successfully finding xerces from the PKG_CONFIG_PATH, then I'm not clear why the g++ commands would fail unless g++ doesn't use the PKG_CONFIG_PATH. Would the "--with-pkgconfigdir" help? Perhaps this issue is a side effect of having to add paths to the PKG_CONFIG_PATH with the latest script. Maybe I need to specify some additional g++ options directly to the script or use some of the other options. The purpose of some of the options described by the 'configure --help' is ambiguous to me. I'll try a few things and experiment with that. I can always update the CXXFLAGS as a last resort. We are noticing that the yum repos for RHEL8 aren't showing autoconf 2.71 as the latest so we still have 2.69 installed. I had to run 'autoreconf -i -f' to regenerate some files so that I can proceed with configuring and building. Perhaps the yum repos aren't updated as quickly as the new versions become available. Is that a potential problem or does anyone know if the autoreconf is able to reliably regenerate some files to make it compatible with the older version? I'm not a linux admin on our systems, but perhaps we might have to download and manually install the latest if that is critical. Thanks, Shawn Fox -----Original Message----- From: Cantor, Scott <[email protected]> Sent: Wednesday, November 29, 2023 12:55 PM To: [email protected] Subject: Re: Apache Santuario config states that libcrypto is not found External Email Alert This email has been sent from an account outside of the BAE Systems network. Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros. For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar. I cannot spend enough time to really review your build, but the most obvious thing was that it can't find Xerces during the Xalan link tests, and that should obviously be down to LD_LIBRARY_PATH issues. You can't install shared libraries to unusual locations and expect a build will work if there are linker tests, it wouldn't have any means of locating them. I expect you need to set that. > I assume you are adding your xerces install path into the > PKG_CONFIG_PATH variable or are you instructing it where to find > xerces in some other way? I use (and maintained some) Macports for most things on that host, and the primary version of pkg-config it finds is in /opt/local/bin, so it already knows how to find all the port-installed files it needs. Since Xalan is the broken one here, and since using xml-sec with Xalan is...basically a security disaster, the best solution is just to not use it. My example does because I'm making sure it builds. I do not, and would never, build this code with Xalan in the same zip code for production use. > I tried to run the commands differently without the environment > variables like so and the results were the same. That's the point, they mostly aren't used, with the exception of Xalan, which I guess is because it's not providing a pkg-config file. It's possible it does by now and the script needs to be updated to use it. > 1) Are you not using openssl or is the --with-openssl option not > needed any longer if the path to it is in the PKG_CONFIG_PATH? The latter. I believe it autodetects both OpenSSL and NSS, though I don't have NSS installed and it wouldn't have found that. >2) You didn't specify a --prefix so how will the resulting files be installed? It was a test build from long ago and was not being installed anywhere, but the default is generally /usr/local if not set. That should never impact what it finds to use in the build process anyway. > 3) are the following version combinations acceptable? The santuario > website implies that xalan 1.11.0+ is needed so I assume that xalan > 1.12.0 is acceptable too No reason I would expect it's not usable. My ports are all out of date so I don't know what I specifically used that long ago. Xalan is effectively all but dead (slightly less than Xerces I suppose) so I can't imagine anything in 1.12 changed enough to break anything. -- Scott
