From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57785) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eljNr-0006nh-6o for guix-patches@gnu.org; Tue, 13 Feb 2018 17:49:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eljNm-0002tz-FG for guix-patches@gnu.org; Tue, 13 Feb 2018 17:49:07 -0500 Received: from debbugs.gnu.org ([208.118.235.43]:34010) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eljNm-0002tL-Aj for guix-patches@gnu.org; Tue, 13 Feb 2018 17:49:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eljNm-0004GD-0g for guix-patches@gnu.org; Tue, 13 Feb 2018 17:49:02 -0500 Subject: [bug#30340] [PATCH 1/6] gnu: qtbase: Use the store paths for other packages and dynamically loaded libs. Resent-Message-ID: From: Marius Bakke In-Reply-To: <180a63cd-4939-4752-f3ba-dc7534465cc9@crazy-compilers.com> References: <20180203192212.29173-1-h.goebel@crazy-compilers.com> <20180203192505.29516-1-h.goebel@crazy-compilers.com> <87k1voixl0.fsf@fastmail.com> <180a63cd-4939-4752-f3ba-dc7534465cc9@crazy-compilers.com> Date: Tue, 13 Feb 2018 23:48:18 +0100 Message-ID: <87sha4wlot.fsf@fastmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Hartmut Goebel , 30340@debbugs.gnu.org --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hartmut Goebel writes: > Am 07.02.2018 um 17:16 schrieb Marius Bakke: >> Hartmut Goebel writes: >> >>> Adobt the NixOS patches as of 2018-01-19: >> I don't see any patches in this series.=20 > > 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? I don't think the comments are all that useful. They only add noise in the commit log and the code -- since we have a working and up-to-date Qt, it is implied that we don't need anything more from NixOS or elsewhere. >>> - 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 nee= d. For tzdata in particular, we are trying to reduce the number of dependent packages so that we can update it directly on 'master'. Often a new tzdata release introduces changes with near-immediate effects, so it's important to be able to update it fast. Adding it to qtbase would add 282 new dependent packages, which is unfortunate. So I much prefer using TZDIR, even though it would be technically better to reference it directly. >>> + (add-after 'unpack 'patch-paths >>> + ;; Use the absolute paths for dynamically loaded libs, othe= rwise >>> + ;; the lib will be searched in the actual executable's RUNP= ATH, >>> + ;; 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? Yes, that makes sense :) --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEu7At3yzq9qgNHeZDoqBt8qM6VPoFAlqDazIACgkQoqBt8qM6 VPpazwgAjh7GWIxecnHW2H3xV0ITNownF3KK+Svji9XFJr0I3/WFDLasjmInjmMb 6wwULXHljqPcjsPhdQPQMANROhUwZLx7bx8rDjdJsz7gKCpq64FAgTM5t9gLFfQS WN2RIOwkLoWcdh8aksz+JCsv+bBHQ5n7eL+rQeJ+x0pHHk6nkYtiZlewlEU4G5Zr i1Js1DUpJ69rRkRS0Jr8CEEJuyLuK7XwNfiDXK+7a+EQgkFlrP7OvqWw7bEH48QE gp5Tym+J5wBvF1mBg3AAv7Kb5r9p12mHDevUjT5Vn+/TmXGXlq4lgDNpZqNjCQEZ Q/vb1h67dxtqljDnVXRsvoAKEVhJ3w== =Eiqj -----END PGP SIGNATURE----- --=-=-=--