guix-patches
[Top][All Lists]
Advanced

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

[bug#30340] [PATCH 1/6] gnu: qtbase: Use the store paths for other packa


From: Hartmut Goebel
Subject: [bug#30340] [PATCH 1/6] gnu: qtbase: Use the store paths for other packages and dynamically loaded libs.
Date: Mon, 12 Feb 2018 16:37:18 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0

Am 07.02.2018 um 17:16 schrieb Marius Bakke:
Hartmut Goebel <address@hidden> writes:

Adobt the NixOS patches as of 2018-01-19:
I don't see any patches in this series. 

I only *adopted* what NixOs does with patches, not the patches itself. I will rework this.

 FWIW I think we deviate enough
from NixOS at this point that the comments are unnecessary.

Are you referring to patch (1/6)? Or do you mean patches 2, 3, 5 and 6 are unnecessary?

I do not care about the comments, but FMPOV it is important to document somehow in the code or in the commits that all patches as of 2018-01-19 have been considered. an alternative would be to group these few commits into a (very short) branch and documenting the fact in the merge-commit.

WDYT?

- src/corelib/tools/qtimezoneprivate_tz.cpp: NixOS uses $TZDIR, we use
  hardcoded path to tzdata.
Why hardcode the path?  We set TZDIR as well in (gnu system).

The upstream code (qt.com) uses hard-coded path (/usr/share/zoneinfo/), so for me it seems to be much more natural to simply change this - and stay closer to upstream. NixOS seems to require TZDATA since some things work differently compared to guix. E.g. nixos is deriving library search paths from $PATH in some other patch. This is something guix does not need.

+         (add-after 'unpack 'patch-paths
+           ;; Use the absolute paths for dynamically loaded libs, otherwise
+           ;; the lib will be searched in the actual executable's RUNPATH,
+           ;; which may not include the requested lib.
Is there any reason we cannot add these libraries to RUNPATH instead?
The below approach seems somewhat fragile to me.

Rethinking this, this comment is wrong and I'll correct it. QLibrary (which is used an all these cases) is documented with:

When loading the library, QLibrary searches in all the system-specific library locations (e.g. LD_LIBRARY_PATH on Unix), unless the file name has an absolute path.
But guix does not set LD_LIBRARYPATH (e.g. in "guix environment"), thus we need to have absolute paths for the libraries.

Does this make sense?
-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | address@hidden               |
| www.crazy-compilers.com | compilers which you thought are impossible |

reply via email to

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