bug-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#30006: bzip2 does not provide libbz2.so


From: Ludovic Courtès
Subject: bug#30006: bzip2 does not provide libbz2.so
Date: Sat, 24 Mar 2018 18:01:02 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)

Marius Bakke <address@hidden> skribis:

> Tobias Geerinckx-Rice <address@hidden> writes:
>
>> Marius,
>>
>> On 2018-03-23 13:02, Marius Bakke wrote:
>>> diff --git a/gnu/packages/compression.scm 
>>> b/gnu/packages/compression.scm
>>> index b158feac4..fd111e579 100644
>>> --- a/gnu/packages/compression.scm
>>> +++ b/gnu/packages/compression.scm
>>> @@ -272,6 +272,9 @@ file; as a result, it is often used in conjunction 
>>> with \"tar\", resulting in
>>>             (lambda* (#:key outputs #:allow-other-keys)
>>>               (let* ((out    (assoc-ref outputs "out"))
>>>                      (libdir (string-append out "/lib")))
>>> +               ;; The Make target above does not create "libbz2.so", 
>>> only
>>> +               ;; the versioned libs, so we have to create it 
>>> ourselves.
>>> +               (symlink "libbz2.so.1.0" "libbz2.so")
>>
>> How about symlinking to (string-append ... version) directly?
>> Seems more robust & worked fine when I tried it, I think.™
>
> That makes sense.  I just wanted to stay close to the typical Autotools
> way of creating these links, where libfoo.so points to libfoo.so.1 which
> points to libfoo.so.1.2.  I'll change to (version-major+minor ...)
> instead, in the off chance that bzip2 ever gets a new version.

Note that there’s no reason for the SONAME numbers to match the version
number (it’s even not recommended to do that because it may not carry
the relevant info regarding ABI compatibility.)

So I think the hard-coded number is fine, but we should probably do:

  (symlink … "libbz2.so")
  (unless (file-exists? "libbz2.so)
    (error "wrong symlink target!" (readlink "libbz2.so")))

to be on the safe side.

> Side note: "copy-file" (and thus "install-file") actually dereferences
> symlinks, so in the end you get three copies of the same library.  Is
> there an alternative to "copy-file" that preserves soft links?  Not that
> it matters in practice due to deduplication, but still...

There’s no such function, which is unfortunate.  But I agree it’s nicer
to preserve symlinks in this case.

Perhaps we should actually do:

  (with-directory-excursion libdir
    (symlink … "libbz2.so"))

?

Thanks,
Ludo’.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]