Roel Janssen writes: > Marius Bakke writes: > >> Roel Janssen writes: >> >>> Marius Bakke writes: >>> >>>> Roel Janssen writes: >>>> >>>>> From 80b26cfcc3d64588738e5fecc92f3eabc214ed4c Mon Sep 17 00:00:00 2001 >>>>> From: Roel Janssen >>>>> Date: Wed, 28 Mar 2018 18:13:23 +0200 >>>>> Subject: [PATCH] gnu: virtuoso-ose: Unbundle zlib and build with readline >>>>> support. >>>>> >>>>> * gnu/packages/databases.scm (virtuoso-ose): Unbundle zlib and build with >>>>> readline support. >>>> >>>> Please mention the changes to [inputs] and [arguments] here. Also, >>>> assuming there is an internal copy of zlib, can you remove it with a >>>> source 'snippet'? >>> >>> Thanks for the quick response! >>> >>> Then I'll need to rerun “autogen.sh” to make sure >>> “libsrc/zlib/Makefile.in” isn't included in the configure phase. That >>> in turns needs the following packages added to native-inputs: autoconf, >>> automake, bison, flex, gettext, gperf, libtool, perl, and pkg-config. >> >> I came across a similar problem in . Can >> you see if the same solution works for you (preserve the autoconfery)? > > I couldn't get this to work after spending two hours at it. So I > checked whether it actually affects the build, and here's what I found: > > Built with “--without-internal-zlib”: > roel@yellowstone /gnu/store/lngvklw1hniykn6skz3gghps3d08is7d-virtuoso-ose-7.2.4.2/bin$ ldd virtuoso-t > linux-vdso.so.1 (0x00007ffe331a0000) > libssl.so.1.0.0 => /gnu/store/ggrpw6gh2rnqjwyjf99z8cdw5digc4hb-openssl-1.0.2o/lib/libssl.so.1.0.0 (0x00007f2b552a7000) > libcrypto.so.1.0.0 => /gnu/store/ggrpw6gh2rnqjwyjf99z8cdw5digc4hb-openssl-1.0.2o/lib/libcrypto.so.1.0.0 (0x00007f2b54e50000) > liblzma.so.5 => /gnu/store/pj8xqlnkwgjia87jy6i8slglip9k8x6a-xz-5.2.3/lib/liblzma.so.5 (0x00007f2b54c2a000) > libpthread.so.0 => /gnu/store/4sqaib7c2dfjv62ivrg9b8wa7bh226la-glibc-2.26.105-g0890d5379c/lib/libpthread.so.0 (0x00007f2b54a0c000) > libdl.so.2 => /gnu/store/4sqaib7c2dfjv62ivrg9b8wa7bh226la-glibc-2.26.105-g0890d5379c/lib/libdl.so.2 (0x00007f2b54808000) > libm.so.6 => /gnu/store/4sqaib7c2dfjv62ivrg9b8wa7bh226la-glibc-2.26.105-g0890d5379c/lib/libm.so.6 (0x00007f2b544bc000) > libz.so.1 => /gnu/store/8hxm8am4ll05sa8wlwgdq2lj4ddag464-zlib-1.2.11/lib/libz.so.1 (0x00007f2b542a1000) > libgcc_s.so.1 => /gnu/store/2ifmksc425qcysl5rkxkbv6yrgc1w9cs-gcc-5.5.0-lib/lib/libgcc_s.so.1 (0x00007f2b5408a000) > libc.so.6 => /gnu/store/4sqaib7c2dfjv62ivrg9b8wa7bh226la-glibc-2.26.105-g0890d5379c/lib/libc.so.6 (0x00007f2b53cd8000) > /gnu/store/4sqaib7c2dfjv62ivrg9b8wa7bh226la-glibc-2.26.105-g0890d5379c/lib/ld-linux-x86-64.so.2 (0x00007f2b5551a000) > > Built without “--without-internal-zlib”: > roel@yellowstone /gnu/store/nf3j0zc64flq47nlq65kvnhqzmp3lm1v-virtuoso-ose-7.2.4.2/bin$ ldd virtuoso-t > linux-vdso.so.1 (0x00007ffda150f000) > libssl.so.1.0.0 => /gnu/store/ggrpw6gh2rnqjwyjf99z8cdw5digc4hb-openssl-1.0.2o/lib/libssl.so.1.0.0 (0x00007f09d4f93000) > libcrypto.so.1.0.0 => /gnu/store/ggrpw6gh2rnqjwyjf99z8cdw5digc4hb-openssl-1.0.2o/lib/libcrypto.so.1.0.0 (0x00007f09d4b3c000) > liblzma.so.5 => /gnu/store/pj8xqlnkwgjia87jy6i8slglip9k8x6a-xz-5.2.3/lib/liblzma.so.5 (0x00007f09d4916000) > libpthread.so.0 => /gnu/store/4sqaib7c2dfjv62ivrg9b8wa7bh226la-glibc-2.26.105-g0890d5379c/lib/libpthread.so.0 (0x00007f09d46f8000) > libdl.so.2 => /gnu/store/4sqaib7c2dfjv62ivrg9b8wa7bh226la-glibc-2.26.105-g0890d5379c/lib/libdl.so.2 (0x00007f09d44f4000) > libm.so.6 => /gnu/store/4sqaib7c2dfjv62ivrg9b8wa7bh226la-glibc-2.26.105-g0890d5379c/lib/libm.so.6 (0x00007f09d41a8000) > libgcc_s.so.1 => /gnu/store/2ifmksc425qcysl5rkxkbv6yrgc1w9cs-gcc-5.5.0-lib/lib/libgcc_s.so.1 (0x00007f09d3f91000) > libc.so.6 => /gnu/store/4sqaib7c2dfjv62ivrg9b8wa7bh226la-glibc-2.26.105-g0890d5379c/lib/libc.so.6 (0x00007f09d3bdf000) > /gnu/store/4sqaib7c2dfjv62ivrg9b8wa7bh226la-glibc-2.26.105-g0890d5379c/lib/ld-linux-x86-64.so.2 (0x00007f09d5206000) > > So at least it does seem to affect the resulting binaries. > > I also tried adding the native-inputs and run autogen.sh. This also > failed to build when removing the “libsrc/zlib” directory. It seems to > be tied into the build deeper than I thought at first. > > What should I do now? Oh well. I guess leaving it is fine, with a TODO note somewhere. Thanks for checking!