* Different package version in same environment was: Re: [bug#54261] Acknowledgement ([PATCH]: Update GTK to 4.6.1.) [not found] ` <1d1cc9a4a82aec7dd23e954fa0a68167c5806a07.camel@telenet.be> @ 2022-03-12 16:06 ` Zhu Zihao 2022-03-13 14:55 ` Maxime Devos 0 siblings, 1 reply; 2+ messages in thread From: Zhu Zihao @ 2022-03-12 16:06 UTC (permalink / raw) To: Maxime Devos; +Cc: guix-devel [-- Attachment #1: Type: text/plain, Size: 1300 bytes --] This problem is not related to that patch so I would like to discuss here. Maxime Devos <maximedevos@telenet.be> writes: > [[PGP Signed Part:Undecided]] > Zhu Zihao schreef op za 12-03-2022 om 10:38 [+0800]: >> > What if a program uses both 'pango' and gtk? Then IIUC, it would >> > simultanuously use pango and pango-next in the same process, which >> can >> > easily cause problems (see e.g. the bug report about segfaults >> > involving multiple libcairos). Can you show me the link of the libcairo conflict example you said? I don't know what cause the segfaults in your example. C linker will embed the full path of the library into the RUNPATH, unless LD_LIBRARY_PATH is set, C library will use the dependencies they found in link time. >> >> i've asked in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44327 and >> suggest to introduce priority mechanism like Nix. But Ludovic Courtès >> doesn't accept my suggestion > > How could a priority mechanism solve the segfaults? 'priority' will let user to specify which package can override other packages, if some of their contents overlapped with each other. Now Guix will silently choose one. -- Retrieve my PGP public key: gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F Zihao [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 255 bytes --] ^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Different package version in same environment was: Re: [bug#54261] Acknowledgement ([PATCH]: Update GTK to 4.6.1.) 2022-03-12 16:06 ` Different package version in same environment was: Re: [bug#54261] Acknowledgement ([PATCH]: Update GTK to 4.6.1.) Zhu Zihao @ 2022-03-13 14:55 ` Maxime Devos 0 siblings, 0 replies; 2+ messages in thread From: Maxime Devos @ 2022-03-13 14:55 UTC (permalink / raw) To: Zhu Zihao; +Cc: guix-devel [-- Attachment #1: Type: text/plain, Size: 783 bytes --] Zhu Zihao schreef op zo 13-03-2022 om 00:06 [+0800]: > Can you show me the link of the libcairo conflict example you said? > > I don't know what cause the segfaults in your example. C linker will > embed the full path of the library into the RUNPATH, unless > LD_LIBRARY_PATH is set, C library will use the dependencies they > found in > link time. It will embed the full path of the library. The problem is, it might embed multiple variants of the same library in the same binary. For the libcairo problem, see <https://issues.guix.gnu.org/47115#22>. Turns out it wasn't a segfault but another kind of problem. And it wasn't due to deduplication but rather buggy grafting. Still, I suppose something similar can happen with propagation. Greetings, Maxime. [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 260 bytes --] ^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2022-03-13 14:55 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <86pmn04f4s.fsf@163.com>
[not found] ` <handler.54261.B.164649346324787.ack@debbugs.gnu.org>
[not found] ` <864k4c4cmv.fsf@163.com>
[not found] ` <86ilsky0xb.fsf@163.com>
[not found] ` <149614fb88e1afab846783a5d3b1bbe0bde640f0.camel@telenet.be>
[not found] ` <865yojnb25.fsf@163.com>
[not found] ` <1d1cc9a4a82aec7dd23e954fa0a68167c5806a07.camel@telenet.be>
2022-03-12 16:06 ` Different package version in same environment was: Re: [bug#54261] Acknowledgement ([PATCH]: Update GTK to 4.6.1.) Zhu Zihao
2022-03-13 14:55 ` Maxime Devos
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/guix.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).