Although the build did succeed at generating outputs, I've noticed that the 'gmake install' command did not copy all of the .hpp files from the xsec/utils directory into the installation directory. Specifically it is not copying "xsec/utils/XSECDOMUtils.hpp".
Looking at the output of gmake install it is clear that it is excluded from the copy, but that was not the case when we last build Santuario v1.7.3. I don't see any options associated with the configure script that would explain why any header files wouldn't be installed. Tracing this back to the generated Makefile objects I noticed this and utils/XSECDOMUtils.hpp is excluded. Why? It was included in the 1.7.3 installation. Was it determined that the users of Santuario shouldn't need this or is there something in how the build is configured that could cause this? utils/XSECDOMUtils.hpp is not in the list of include_HEADERS utilsinclude_HEADERS = \ utils/XSECSafeBuffer.hpp \ utils/XSECSOAPRequestor.hpp \ utils/XSECTXFMInputSource.hpp \ utils/XSECNameSpaceExpander.hpp \ utils/XSECSOAPRequestorSimple.hpp \ utils/XSECXPathNodeList.hpp \ utils/XSECSafeBufferFormatter.hpp \ utils/XSECBinTXFMInputStream.hpp \ utils/XSECPlatformUtils.hpp Thanks, Shawn Fox -----Original Message----- From: Fox, Shawn D (US) Sent: Thursday, November 30, 2023 12:16 PM To: [email protected] Subject: RE: Apache Santuario config states that libcrypto is not found FYI, I was able to get Santuario 2.0.4 to build on our RHEL8 VMs in the following manner using the gcc-12 toolset. export PKG_CONFIG_PATH=/data/${USER}/repos/tp/openssl-102u-install/release/lib/pkgconfig:/data/${USER}/repos/tp/xerces-c-3.2.4-install/release/lib/pkgconfig export LDFLAGS="-L/data/${USER}/repos/tp/openssl-102u-install/release/lib" export LD_LIBRARY_PATH=/data/${USER}/repos/tp/xalan_c-1.12-gxp-install/release/lib:/data/${USER}/repos/tp/xerces-c-3.2.4-install/release/lib ./configure \ --prefix=/data/${USER}/repos/tp/santuario-2.0.4-install/release \ --with-xalan=/data/${USER}/repos/tp/xalan_c-1.12-gxp-install/release \ --with-openssl gmake 2>&1 | tee release_build.log gmake install Notice the use of the LDFLAGS variable. I found that to be odd that the -L /usr/lib64 was being put into the g++ command ahead of the -L to link in my openssl 1.0.2 installation. Originally I put the openssl path into LD_LIBRARY_PATH along with the xerces and xalan paths. However that didn't work in the case of openssl. For some reason the custom openssl path I am specifying was always being included as a linker path option after -L /user/lib64 so the build was finding the wrong version of openssl. There could be other ways of accomplishing this but that is what worked after trying about 15 different combinations of environment variables and options to the configure command. Thanks, Shawn Fox Sr Principal SW Engineer BAE Systems, Inc. Geospatial eXploitation Products T: 858-592-5310 office phone number | M: 858-337-2380 | E: [email protected] 10920 Technology Pl, San Diego, CA -----Original Message----- From: Cantor, Scott <[email protected]> Sent: Wednesday, November 29, 2023 1: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. > When we built Santuario v1.7.3, we never had to update LD_LIBRARY_PATH > to make the build work. Then the circumstances were different, but I can assure that's not new, I've had to use it in plenty of cases for a very long time. The only possible way of avoiding it is installing to known locations. > 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. It doesn't. autoconf does, to find the pkgconfig files to then supply the flags to the g++ commands to use. But they most definitely *cannot* avoid the need to set LD_LIBRARY_PATH. The linker might be fine with it, but the exec/run tests won't. > Would the "--with-pkgconfigdir" help? It's required if the pkgconfig files aren't in known places. -- Scott
