--- Begin Message ---
|
Subject: |
[PATCH] gnu: virtuoso-ose: Unbundle zlib and build with readline |
|
Date: |
Wed, 28 Mar 2018 18:17:27 +0200 |
|
User-agent: |
mu4e 1.0; emacs 25.3.1 |
0001-gnu-virtuoso-ose-Unbundle-zlib-and-build-with-readli.patch
Description: Text Data
Dear Guix,
I'd like to change the Virtuoso recipe to use readline so that we can go
to previous commands in the “isql” command-line program. And I'd like
to unbundle zlib.
Kind regards,
Roel Janssen
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: [bug#30972] [PATCH] gnu: virtuoso-ose: Unbundle zlib and build with readline |
|
Date: |
Tue, 03 Apr 2018 13:10:57 +0200 |
|
User-agent: |
mu4e 1.0; emacs 25.3.1 |
Marius Bakke <address@hidden> writes:
> Roel Janssen <address@hidden> writes:
>
>> Marius Bakke <address@hidden> writes:
>>
>>> Roel Janssen <address@hidden> writes:
>>>
>>>> Marius Bakke <address@hidden> writes:
>>>>
>>>>> Roel Janssen <address@hidden> writes:
>>>>>
>>>>>> From 80b26cfcc3d64588738e5fecc92f3eabc214ed4c Mon Sep 17 00:00:00 2001
>>>>>> From: Roel Janssen <address@hidden>
>>>>>> 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 <https://bugs.gnu.org/30974>. 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”:
>> address@hidden
>> /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”:
>> address@hidden
>> /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!
Thanks for your reply!
I added the TODO note, and pushed in 6d09a7b5e.
Kind regards,
Roel Janssen
--- End Message ---