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:
shawn....@baesystems.com
10920 Technology Pl, San Diego, CA
-----Original Message-----
From: Cantor, Scott <canto...@osu.edu>
Sent: Wednesday, November 29, 2023 1:55 PM
To: dev@santuario.apache.org
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
