Hi! Ludovic Courtès <l...@gnu.org> writes:
> Hi, > > Maxim Cournoyer <maxim.courno...@gmail.com> skribis: > >> $ guix build qtdeclarative | xargs -I{} find -L {} -name *libQt5Qml.so.5* >> substitute: updating substitutes from 'http://127.0.0.1:8080'... 100.0% >> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% >> The following files will be downloaded: >> /gnu/store/g1gxfbkyxilnx7s6mjdlj697y5n5wazn-qtdeclarative-5.15.2-debug >> /gnu/store/nvzvrr137qfqsn2875yrs9ilfd12wi96-qtdeclarative-5.15.2 >> substituting >> /gnu/store/g1gxfbkyxilnx7s6mjdlj697y5n5wazn-qtdeclarative-5.15.2-debug... >> downloading from >> https://ci.guix.gnu.org/nar/lzip/g1gxfbkyxilnx7s6mjdlj697y5n5wazn-qtdeclarative-5.15.2-debug >> ... >> qtdeclarative-5.15.2-debug 94.9MiB 1.2MiB/s >> 01:21 [##################] 100.0% >> >> The following graft will be made: >> /gnu/store/djhcai9rixm2j3jlamwdhsgwgidg7w74-qtdeclarative-5.15.2.drv >> applying 2 grafts for >> /gnu/store/djhcai9rixm2j3jlamwdhsgwgidg7w74-qtdeclarative-5.15.2.drv ... >> grafting >> '/gnu/store/g1gxfbkyxilnx7s6mjdlj697y5n5wazn-qtdeclarative-5.15.2-debug' -> >> '/gnu/store/l3h4ka7v3j1yhik0f1phwch08a09p0bx-qtdeclarative-5.15.2-debug'... >> grafting '/gnu/store/nvzvrr137qfqsn2875yrs9ilfd12wi96-qtdeclarative-5.15.2' >> -> '/gnu/store/pryhgzb6cwnzsskqwldwc6dxr6nwnywf-qtdeclarative-5.15.2'... >> updating '.gnu_debuglink' CRC in >> '/gnu/store/pryhgzb6cwnzsskqwldwc6dxr6nwnywf-qtdeclarative-5.15.2/bin/qml' >> updating '.gnu_debuglink' CRC in >> '/gnu/store/pryhgzb6cwnzsskqwldwc6dxr6nwnywf-qtdeclarative-5.15.2/bin/q >> [...] >> updating '.gnu_debuglink' CRC in >> '/gnu/store/pryhgzb6cwnzsskqwldwc6dxr6nwnywf-qtdeclarative-5.15.2/lib/qt5/qml/QtQuick/Window.2/libwindowplugin.so' >> updating '.gnu_debuglink' CRC in >> '/gnu/store/pryhgzb6cwnzsskqwldwc6dxr6nwnywf-qtdeclarative-5.15.2/lib/qt5/qml/QtTest/libqmltestplugin.so' >> successfully built >> /gnu/store/djhcai9rixm2j3jlamwdhsgwgidg7w74-qtdeclarative-5.15.2.drv >> /gnu/store/l3h4ka7v3j1yhik0f1phwch08a09p0bx-qtdeclarative-5.15.2-debug/lib/debug/gnu/store/pryhgzb6cwnzsskqwldwc6dxr6nwnywf-qtdeclarative-5.15.2/lib/libQt5Qml.so.5.15.2.debug >> /gnu/store/pryhgzb6cwnzsskqwldwc6dxr6nwnywf-qtdeclarative-5.15.2/lib/libQt5Qml.so.5.15.2 >> /gnu/store/pryhgzb6cwnzsskqwldwc6dxr6nwnywf-qtdeclarative-5.15.2/lib/libQt5Qml.so.5 >> /gnu/store/pryhgzb6cwnzsskqwldwc6dxr6nwnywf-qtdeclarative-5.15.2/lib/libQt5Qml.so.5.15 >> >> >> So far so good. The file hierarchy under the debug output matches the >> actual shared library file name. Next, let's verify which qtdeclarative >> shared libraries jami-qt is dynamically linked against: >> >> $ guix build jami-qt | tail -1 | xargs -I{} ldd {}/bin/.jami-qt-real | grep >> qtdeclarative >> libQt5QuickWidgets.so.5 => >> /gnu/store/mjl02yma4r5xjark6d8pp5h2j0a2vccs-qtdeclarative-5.15.2/lib/libQt5QuickWidgets.so.5 >> (0x00007fb9e38a8000) >> libQt5Quick.so.5 => >> /gnu/store/mjl02yma4r5xjark6d8pp5h2j0a2vccs-qtdeclarative-5.15.2/lib/libQt5Quick.so.5 >> (0x00007fb9dba47000) >> libQt5QmlModels.so.5 => >> /gnu/store/mjl02yma4r5xjark6d8pp5h2j0a2vccs-qtdeclarative-5.15.2/lib/libQt5QmlModels.so.5 >> (0x00007fb9db9c3000) >> libQt5Qml.so.5 => >> /gnu/store/mjl02yma4r5xjark6d8pp5h2j0a2vccs-qtdeclarative-5.15.2/lib/libQt5Qml.so.5 >> (0x00007fb9dae4e000) > > This is due to the fact that, when you run ‘guix build jami-qt’, the > grafting derivation dismisses the “debug” output of qtdeclarative, since > jami-qt does not depend on it. That way it doesn’t have to > build/download and graft qtdeclarative:debug. > > Conversely, when you run ‘guix build qtdeclarative’, it grafts both > outputs of qtdeclarative. Thus, this grafting derivation is different > from the one jami-qt.drv depends on. > > This behavior was implemented in commit > 482fda2729c3e76999892cb8f9a0391a7bd37119. Not sure what a good solution > would be. > > Thoughts? Yikes! This means that debugging with grafts (with the aid of debugging symbols) is no longer possible, right? I remember reading about a 2nd option to locate the separate debug symbol files with GDB in info '(gdb) Separate Debug Files': * The executable contains a "build ID", a unique bit string that is also present in the corresponding debug info file. (This is supported only on some operating systems, when using the ELF or PE file formats for binary files and the GNU Binutils.) For more details about this feature, see the description of the '--build-id' command-line option in *note Command Line Options: (ld)Options. The debug info file's name is not specified explicitly by the build ID, but can be computed from the build ID, see below. [...] * For the "build ID" method, GDB looks in the '.build-id' subdirectory of each one of the global debug directories for a file named 'NN/NNNNNNNN.debug', where NN are the first 2 hex characters of the build ID bit string, and NNNNNNNN are the rest of the bit string. (Real build ID strings are 32 or more hex characters, not 10.) What may help us here, compared to debug links, is that it seems to be file name agnostic; the debug files would be matched by an internal ID that they got at build time rather than from their file names (which doesn't work with the current different derivations in the presence of grafts). Perhaps it'd also lift the need to recompute the CRC checksum of the debug links produced when grafting! HTH! Maxim