Using ldd, I get this list of libraries that my installed developer build of ATS depends on. That is, the libraries used by the installed executables and libraries, including all core plugins, experimental or not.
libbrotlicommon.so.1 => /opt/edge/brotli/1.0/lib/libbrotlicommon.so.1 libbrotlienc.so.1 => /opt/edge/brotli/1.0/lib/libbrotlienc.so.1 libcap.so.2 => /lib64/libcap.so.2 libcjose.so.0 => /lib64/libcjose.so.0 libcrypto.so.1.1 => /opt/edge/openssl/1.1.1/lib/libcrypto.so.1.1 libdl.so.2 => /lib64/libdl.so.2 libhiredis.so.0.13 => /lib64/libhiredis.so.0.13 libjansson.so.4 => /lib64/libjansson.so.4 libluajit-5.1.so.2 => /lib64/libluajit-5.1.so.2 liblzma.so.5 => /lib64/liblzma.so.5 libMagick++-7.Q16HDRI.so.5 => not found libMagickCore-7.Q16HDRI.so.10 => not found libMagickWand-7.Q16HDRI.so.10 => not found libmaxminddb.so.0 => /lib64/libmaxminddb.so.0 libm.so.6 => /lib64/libm.so.6 libncursesw.so.6 => /lib64/libncursesw.so.6 libpcre.so.1 => /opt/edge/pcre/8.45/lib/libpcre.so.1 libpthread.so.0 => /lib64/libpthread.so.0 libresolv.so.2 => /lib64/libresolv.so.2 libssl.so.1.1 => /opt/edge/openssl/1.1.1/lib/libssl.so.1.1 libtinfo.so.6 => /lib64/libtinfo.so.6 libz.so.1 => /lib64/libz.so.1 The libs that are under /opt/edge are ones that Jason builds from source, for greater compatibility with all our prod environments. I think we must be clear on which libraries we want to assume will be in /lib64, and which ones we want to allow to be in customizable locations. As a test of the cmake build, I think we need to do a build that uses symbolic links for libraries whose location can be customized. For example, for the PCRE library in my environment: $ pwd /home/wkaras/symlinks $ ls -l pcre lrwxrwxrwx. 1 wkaras users 19 Oct 20 14:12 pcre -> /opt/edge/pcre/8.45 $ There are analogous issues with include files, but I can't think of a fast way to determine all ATS dependencies on external include files. Parenthetically, it looks like the autotools build is not putting the path(s) to the Magick libraries in the rpaths of the .so files of the plugins that use them (magick and webp_transform). But maybe I am missing an option on the configuration command. On Thu, Oct 19, 2023 at 9:45 PM James Peach <jpe...@apache.org> wrote: > Could you please summarize the current state of the cmake work? > > Is there any documentation for users of how to switch from autotools to > cmake? Are there any autotools build features that are not supported in > cmake? > > FWIW I have builds that are using > --prefix > --with-user > --with-openssl > --with-jemalloc > --disable-tests > —-disable-experimental-plugins > —-disable-example-plugins > —-enable-test-tools > —-enable-debug > —-enable-ccache > —-with-build-number > PKG_CONFIG_PATH > RPATH > > > On 20 Oct 2023, at 2:35 am, Chris McFarlen <ch...@mcfarlen.us> wrote: > > > > With each CI job now using cmake, the autotools configuration setup will > quickly become unusable. This is a proposal to go ahead and remove the auto > tools config from the tree to speed up the planned moves and upcoming > refactoring to the source code. Maintaining two sets of configuration files > has been necessary while the cmake build was reaching parity, but now it > will be difficult to detect breaking changes. > > > > What say you? > > > > Chris > > > > Sent with [Proton Mail]( > https://urldefense.com/v3/__https://proton.me/__;!!Op6eflyXZCqGR5I!HUGCiN9oJ_lfZrrh1rV0eCJfB9WnsWA-jZUjKev0qAKKKUEVyOguWwGME75g-9B3YRv_Ob8FYmHsHKM$ > ) secure email. > >
